Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

[Aleksa Sarai]

On 2018-11-06, Steven Rostedt  wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai  wrote:
> 
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
> > with the refactor both of you are discussing).
> 
> By the way, I was playing with the the orc unwinder and stack traces
> from the function graph tracer return code, and got it working with the
> below patch. Caution, that patch also has a stack trace hardcoded in
> the return path of the function graph tracer, so you don't want to run
> function graph tracing without filtering.

Neat!

> diff --git a/kernel/trace/trace_functions_graph.c 
> b/kernel/trace/trace_functions_graph.c
> index 169b3c44ee97..aaeca73218cc 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -242,13 +242,16 @@ ftrace_pop_return_trace(struct ftrace_graph_ret *trace, 
> unsigned long *ret,
>   trace->calltime = current->ret_stack[index].calltime;
>   trace->overrun = atomic_read(¤t->trace_overrun);
>   trace->depth = index;
> +
> + trace_dump_stack(0);

Right, this works because save_stack is not being passed a pt_regs. But if
you pass a pt_regs (as happens with bpf_getstackid -- which is what
spawned this discussion) then the top-most entry of the stack will still
be a trampoline because there is no ftrace_graph_ret_addr call.

(I'm struggling with how to fix this -- I can't figure out what retp
should be if you have a pt_regs. ->sp doesn't appear to work -- it's off
by a few bytes.)

I will attach what I have at the moment to hopefully explain what the
issue I've found is (re-using the kretprobe architecture but with the
shadow-stack idea).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

Lemme fill in the scheduler and locking/atomics bits as well:

> +The tip tree contains the following subsystems:
> +
> +   - **x86 architecture**
> +
> + The x86 architecture development takes place in the tip tree except
> + for the x86 KVM and XEN specific parts which are maintained in the
> + corresponding subsystems and routed directly to mainline from
> + there. It's still good practice to Cc the x86 maintainers on
> + x86-specific KVM and XEN patches.
> +
> + Some x86 subsystems have their own maintainers in addition to the
> + overall x86 maintainers.  Please Cc the overall x86 maintainers on
> + patches touching files in arch/x86 even when they are not called out
> + by the MAINTAINER file.
> +
> + Note, that ``x...@kernel.org`` is not a mailing list. It is merely a
> + mail alias which distributes mails to the x86 top-level maintainer
> + team. Please always Cc the Linux Kernel mailing list (LKML)
> + ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
> + the private inboxes of the maintainers.
> +
> +   - **Scheduler**

Scheduler development takes place in the -tip tree, in the 
sched/core branch - with occasional sub-topic trees for 
work-in-progress patch-sets.

> +
> +   - **Locking and atomics**

Locking development (including atomics and other synchronization 
primitives that are connected to locking) takes place in the -tip 
tree, in the locking/core branch - with occasional sub-topic 
trees for work-in-progress patch-sets.

Thanks,

Ingo

Re: [PATCH 3/3] staging: iio: ad7780: generates pattern_mask from PAT bits

[Ardelean, Alexandru]

On Wed, 2018-11-07 at 16:50 -0200, Giuliano Belinassi wrote:
> Previously, all pattern_masks in the chip_info table were hardcoded. Now
> they
> are generated using the PAT macros, as described in the datasheets.
> 

I like this change :)
I only have nitpicks.
See inline.


> Signed-off-by: Giuliano Belinassi 
> ---
>  drivers/staging/iio/adc/ad7780.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 0a473aae52f2..fa9e047b5191 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -31,6 +31,8 @@
>  #define AD7780_PAT1  BIT(1)
>  #define AD7780_PAT0  BIT(0)
>  
> +#define AD7170_PAT2  BIT(2)
> +
>  struct ad7780_chip_info {
>   struct iio_chan_specchannel;
>   unsigned intpattern_mask;
> @@ -137,25 +139,25 @@ static const struct ad7780_chip_info
> ad7780_chip_info_tbl[] = {
>   [ID_AD7170] = {
>   .channel = AD7780_CHANNEL(12, 24),
>   .pattern = 0x5,
> - .pattern_mask = 0x7,
> + .pattern_mask = AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2,

If you are updating these pattern masks, you should update the default
patterns as well with the macros to be consistent.

And to be a bit more compact, you could define:

#define AD7170_PATTERN_MASK (AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
#d
efine AD7780_PATTERN_MASK   (AD7780_PAT0 | AD7780_PAT1)

#define AD7170_PATTERN  (AD7780_PAT1 | AD7170_PAT2)
#define AD7780_PATTERN  (AD7780_PAT0)

Then you can assign AD7170_PATTERN[_MASK] to AD7170/AD7171 & 
AD7780_PATTERN[_MASK] to AD7780/AD7781.

>   .is_ad778x = false,
>   },
>   [ID_AD7171] = {
>   .channel = AD7780_CHANNEL(16, 24),
>   .pattern = 0x5,
> - .pattern_mask = 0x7,
> + .pattern_mask = AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2,
>   .is_ad778x = false,
>   },
>   [ID_AD7780] = {
>   .channel = AD7780_CHANNEL(24, 32),
>   .pattern = 0x1,
> - .pattern_mask = 0x3,
> + .pattern_mask = AD7780_PAT0 | AD7780_PAT1,
>   .is_ad778x = true,
>   },
>   [ID_AD7781] = {
>   .channel = AD7780_CHANNEL(20, 32),
>   .pattern = 0x1,
> - .pattern_mask = 0x3,
> + .pattern_mask = AD7780_PAT0 | AD7780_PAT1,
>   .is_ad778x = true,
>   },
>  };

Re: [PATCH] fs/proc: introduce /proc/stat2 file

[Davidlohr Bueso]

On Wed, 07 Nov 2018, Davidlohr Bueso wrote:

I have not looked at how filesystems tune the batch size, but it would 
certainly be worth
looking into methinks.


nm this part, percpu_counter_batch is not tunable. It would
still probably be acceptable (famous last words) to at least
move the bottleneck in question to percpu_counter api.

Thanks,
Davidlohr

Re: [PATCH v6 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

[Liang Yang]

On 2018/11/7 0:16, Boris Brezillon wrote:

On Tue, 6 Nov 2018 19:08:27 +0800
Liang Yang  wrote:


On 2018/11/6 18:22, Boris Brezillon wrote:

On Tue, 6 Nov 2018 18:00:37 +0800
Liang Yang  wrote:
   

On 2018/11/6 17:28, Boris Brezillon wrote:

On Tue, 6 Nov 2018 17:08:00 +0800
Liang Yang  wrote:
  

On 2018/11/5 23:53, Boris Brezillon wrote:

On Fri, 2 Nov 2018 00:42:21 +0800
Jianxin Pan  wrote:
 

+
+static inline u8 meson_nfc_read_byte(struct mtd_info *mtd)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct meson_nfc *nfc = nand_get_controller_data(nand);
+   u32 cmd;
+
+   cmd = nfc->param.chip_select | NFC_CMD_DRD | 0;
+   writel(cmd, nfc->reg_base + NFC_REG_CMD);
+
+   meson_nfc_drain_cmd(nfc);


You probably don't want to drain the FIFO every time you read a byte on
the bus, and I guess the INPUT FIFO is at least as big as the CMD
FIFO, right? If that's the case, you should queue as much DRD cmd as
possible and only sync when the user explicitly requests it or when
the INPUT/READ FIFO is full.
 

Register 'NFC_REG_BUF' can holds only 4 bytes, also DRD sends only one
nand cycle to read one byte and covers the 1st byte every time reading.
i think nfc controller is faster than nand cycle, but really it is not
high efficiency when reading so many bytes once.
Or use dma command here like read_page and read_page_raw.


Yep, that's also an alternative, though you'll have to make sure the
buffer passed through the nand_op_inst is DMA-safe, and use a bounce
buffer when that's not the case.
  

ok, i will try dma here.


We should probably expose the bounce buf handling as generic helpers at
the rawnand level:

void *nand_op_get_dma_safe_input_buf(struct nand_op_instr *instr)
{
void *buf;

if (WARN_ON(instr->type != NAND_OP_DATA_IN_INSTR))
return NULL;

if (virt_addr_valid(instr->data.in) &&
!object_is_on_stack(instr->data.buf.in))
return instr->data.buf.in;

return kzalloc(instr->data.len, GFP_KERNEL);
}

void nand_op_put_dma_safe_input_buf(struct nand_op_instr *instr,
void *buf)
{
if (WARN_ON(instr->type != NAND_OP_DATA_IN_INSTR) ||
WARN_ON(!buf))
return;

if (buf == instr->data.buf.in)
return;

memcpy(instr->data.buf.in, buf, instr->data.len);
kfree(buf);
}

const void *nand_op_get_dma_safe_output_buf(struct nand_op_instr *instr)
{
void *buf;

if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR))
return NULL;

if (virt_addr_valid(instr->data.out) &&
!object_is_on_stack(instr->data.buf.out))
return instr->data.buf.out;

return kmemdup(instr->data.buf.out, GFP_KERNEL);
}

void nand_op_put_dma_safe_output_buf(struct nand_op_instr *instr,
void *buf)
{
if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR) ||
WARN_ON(!buf))
return;

if (buf != instr->data.buf.out)
kfree(buf);
}
  


that is more convenient.
i will use meson_chip->databuf as the bounce mid-buffer now.


It won't work: the bounce buffer is allocated after the detection, and
the detection code is calling ->exec_op().

Just add a new patch to you series adding these helpers to nand_base.c.



when using these helpers, i finally find that i still need a *info 
buffer* which is used to get status and ecc counter. even i don't need
to check *info buffer*, it is still needed. i just malloc *info_buffer* 
in driver now. and then i think some dedicated dma may need a minimum 
size(such as 4 bytes). it is luckly that meson nfc is not limited about 
the minimum size and i tested it.

so what is your suggestion about it?


.

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

* Thomas Gleixner  wrote:

> + - Signed-off-by: ``Patch handler ``
> +
> +   SOBs after the author SOB are from people handling and transporting the
> +   patch, but were not involved in development. If the handler made
> +   modifications to the patch or the changelog, then this should be
> +   mentioned **after** the changelog text and **above** all commit tags in
> +   the following format::
> +
> + ... changelog text ends.
> +
> + [ handler: Replaced foo by bar and updated changelog ]
> +
> + First-tag: .
> +
> +   Note the two empty new lines which separate the changelog text and the
> +   commit tags from that notice.

Even after a decade of introducing Git I still see Signed-off-by used as 
an Acked-by or Reviewed-by substitutes, so I'd suggest adding this small 
explanation as well:

  +   SOB chains should reflect the *real* route a patch took as it was 
  +   propagated to us, with the first SOB entry signalling primary
  +   authorship of a single author. Acks should be given as Acked-by 
  +   lines and review approvals as Reviewed-by lines.


> +   If a patch is sent to the mailing list by a handler then the author has
> +   to be noted in the first line of the changelog with::
> +
> + From: ``Author ``
> +
> + Changelog text starts here
> +
> +   so the authorship is preserved. The 'From:' line has to be followed by a
> +   empty newline. If that 'From:' line is missing, then the patch would be
> +   attributed to the person who sent (transported) it. The 'From:' line is
> +   automatically removed when the patch is applied and does not show up in
> +   the final git changelog. It merely affects the authorship information of
> +   the resulting git commit.

s/(transported)
 /(transported, handled)

to connect the text with the whole 'handler' language used before?

and since we are not talking about the 'git command', maybe also:

s/git
 /Git

?

> + - Cc: ``cc-ed-person ``
> +
> +   If the patch should be backported to stable, then please add a '``Cc:
> +   sta...@vger.kernel.org``' tag, but do not Cc stable when sending your
> +   mail.

Can I suggest a more canonical form:

Cc:  # v4.18 and later kernels

It would be nice if people adding Cc: stable lines would actually try to 
figure out which exact kernel versions are affected.

Also the '<>' form makes it easier to read and my email client will also 
syntax highlight it in that case. ;-)


> + - Link: ``https://link/to/information``
> +
> +   For referring to email on LKML or other kernel mailing lists, please use
> +   the lkml.kernel.org redirector URL::

s/referring to email
 /referring to an email

> +
> + https://lkml.kernel.org/r/email-message@id
> +
> +   The kernel.org redirector is considered a stable URL unlike other email
> +   archives.

s/URL unlike
 /URL, unlike

?

Thanks,

Ingo

Re: [PATCH 2/3] staging: iio: ad7780: check if ad778x before gain update

[Ardelean, Alexandru]

On Wed, 2018-11-07 at 16:50 -0200, Giuliano Belinassi wrote:
> Only the ad778x have the 'gain' status bit. Check it before updating.
> 

This looks good.
The only note is that it can be squashed with the 1st patch (which I noted
on the 1st patch).

> Signed-off-by: Giuliano Belinassi 
> ---
>  drivers/staging/iio/adc/ad7780.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 6e51bfdb076a..0a473aae52f2 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -114,10 +114,12 @@ static int ad7780_postprocess_sample(struct
> ad_sigma_delta *sigma_delta,
>   ((raw_sample & chip_info->pattern_mask) != chip_info->pattern))
>   return -EIO;
>  
> - if (raw_sample & AD7780_GAIN)
> - st->gain = 1;
> - else
> - st->gain = 128;
> + if (chip_info->is_ad778x) {
> + if (raw_sample & AD7780_GAIN)
> + st->gain = 1;
> + else
> + st->gain = 128;
> + }
>  
>   return 0;
>  }

Re: [PATCH 1/3] staging: iio: ad7780: Add is_ad778x flag chip info

[Ardelean, Alexandru]

On Wed, 2018-11-07 at 16:49 -0200, Giuliano Belinassi wrote:
> This patch allows further checking of whatever the chip is (ad778x or
> ad717x).

Hey,

The patch looks good overall.
I only have one nitpick for this patch. See inline.

And you can squash this patch with patch `[PATCH 2/3] staging: iio: ad7780:
check if ad778x before gain update`.
In fact, the title of the squashed patch can just be `staging: iio: ad7780:
check if ad778x before gain update` ; because the code in this patch
implies that it's used to check if the device is an ad778x chip.

This patch doesn't have much value on it's own without the 2nd patch, and
you can do them in a single go.

/*
 * Note: yes, I know that these subtle semantics between patch 
 * splitting & squashing can be a bit annoying ; I don't have a general
 * recommendation for them, other than just to keep sending patches
 */

Thanks
Alex

> 
> Signed-off-by: Giuliano Belinassi 
> ---
>  drivers/staging/iio/adc/ad7780.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 91e016d534ed..6e51bfdb076a 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -35,6 +35,7 @@ struct ad7780_chip_info {
>   struct iio_chan_specchannel;
>   unsigned intpattern_mask;
>   unsigned intpattern;
> + u8  is_ad778x;
You could make this `bool` type since you are assigning `true/false` values
to this field. It's generally good to be consistent between type names &
type values when using them [even though in C, these are pretty much the
same].

>  };
>  
>  struct ad7780_state {
> @@ -135,21 +136,25 @@ static const struct ad7780_chip_info
> ad7780_chip_info_tbl[] = {
>   .channel = AD7780_CHANNEL(12, 24),
>   .pattern = 0x5,
>   .pattern_mask = 0x7,
> + .is_ad778x = false,
>   },
>   [ID_AD7171] = {
>   .channel = AD7780_CHANNEL(16, 24),
>   .pattern = 0x5,
>   .pattern_mask = 0x7,
> + .is_ad778x = false,
>   },
>   [ID_AD7780] = {
>   .channel = AD7780_CHANNEL(24, 32),
>   .pattern = 0x1,
>   .pattern_mask = 0x3,
> + .is_ad778x = true,
>   },
>   [ID_AD7781] = {
>   .channel = AD7780_CHANNEL(20, 32),
>   .pattern = 0x1,
>   .pattern_mask = 0x3,
> + .is_ad778x = true,
>   },
>  };
>  

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

* Thomas Gleixner  wrote:

> + - Fixes: 12char-SHA1 ("sub/sys: Original subject line")
> +
> +   A Fixes tag should be added even for changes which do not need to be
> +   backported to stable kernels, i.e. when addressing a recently introduced
> +   issue which only affects tip or the current head of mainline. These tags
> +   are helpful to identify the original commit and are much more valuable
> +   than prominently mentioning the commit which introduced a problem in the
> +   text of the changelog itself because they can be automatically
> +   extracted.
> +
> +   The following example illustrates the difference::
> +
> + Commit
> +
> +   abcdef012345678 ("x86/xxx: Replace foo with bar")
> +
> + left an unused instance of variable foo around. Remove it.
> +
> + Signed-off-by: J.Dev 
> +
> +   Please say instead::
> +
> + The recent replacement of foo with bar left an unused instance of
> + variable foo around. Remove it.
> +
> + Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
> + Signed-off-by: J.Dev 

Let me extend this policy element, I frequently write out commits in the 
changelog itself *as well*, because that's where I utilize it myself when 
reading other people's changelogs.

I.e. I would convert this:

 The recent replacement of left with right left an unused instance of
 variable left around. Remove it.

 Fixes: abcdef012345678 ("x86/xxx: Replace 'left' with 'right')
 Signed-off-by: J.Dev 

... to the following form:

 Two years ago the following commit:

   abcdef012345678 ("x86/xxx: Replace foo with bar")

 ... left an unused instance of the variable 'left' around. Remove it.

 Fixes: abcdef012345678 ("x86/xxx: Replace 'left' with 'right')
 Signed-off-by: J.Dev 

This changelog style, while more verbose, has a couple of advantages:

 - It's a bad practice to force the reader to go the tags sections, fish
   out a commit ID, just to be able to see the original commit. 
   Especially with longer changelogs and with changelogs mentioning 
   multiple source commits in-lining the commit ID is useful.

 - Also note how this style allows for human-readable time information to
   be inserted - which can be important to backporters. While an unused
   variable warning might not be backported, in other cases the time
   information can be useful in prioritizing the backporting.

 - Also note another pet peeve of mine: the quotation marks around the 
   variable names 'left' and 'right'. I changed the variable names to 
   English words that are ambiguous in free-flowing changelog text, just
   to illustrate how important it can be to escape them for better
   readability.

The 'Fixes' tag is mainly a standard tag that backporter tooling can 
search for - otherwise for human readers the in-line explanation is more 
useful.

I really trivial cases the inlining can be skipped and only a 'Fixes' tag 
is perfectly sufficient.

Thanks,

Ingo

Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook

[Chen-Yu Tsai]

On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick  wrote:
>
> This commit enables I2S, digital and analog parts of audiocodec on
> Pinebook
>
> Signed-off-by: Vasily Khoruzhick 
> ---
>  .../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
>  1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> index 77fac84797e9..73f171f4ba9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> @@ -64,6 +64,23 @@
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> };
> +
> +   speaker_amp: speaker_amp {
> +   compatible = "simple-audio-amplifier";
> +   enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */

You might want to add a sound-name-prefix property. See

Documentation/devicetree/bindings/sound/name-prefix.txt

Also this should have a reference to its power supply regulator.

> +   };
> +};
> +
> +&codec {
> +   status = "okay";
> +};
> +
> +&codec_analog {
> +   status = "okay";
> +};
> +
> +&dai {
> +   status = "okay";
>  };
>
>  &ehci0 {
> @@ -267,6 +284,31 @@
> vcc-hdmi-supply = <®_dldo1>;
>  };
>
> +&sound {
> +   status = "okay";
> +   simple-audio-card,widgets = "Microphone", "Internal Microphone Left",
> +   "Microphone", "Internal Microphone Right",
> +   "Headphone", "Headphone Jack",
> +   "Speaker", "Internal Speaker";
> +   simple-audio-card,aux-devs = <&codec_analog>, <&speaker_amp>;
> +   simple-audio-card,routing =
> +   "Left DAC", "AIF1 Slot 0 Left",
> +   "Right DAC", "AIF1 Slot 0 Right",
> +   "INL", "LINEOUT",
> +   "INR", "LINEOUT",
> +   "Internal Speaker", "OUTL",
> +   "Internal Speaker", "OUTR",
> +   "Headphone Jack", "HP",
> +   "AIF1 Slot 0 Left ADC", "Left ADC",
> +   "AIF1 Slot 0 Right ADC", "Right ADC",
> +   "Left ADC", "ADC",
> +   "Right ADC", "ADC",
> +   "Internal Microphone Left", "MBIAS",
> +   "MIC1", "Internal Microphone Left",
> +   "Internal Microphone Right", "HBIAS",
> +   "MIC2", "Internal Microphone Right";

The schematics is missing the actual jack, but this looks to be correct.

ChenYu

> +};
> +
>  &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.19.1
>

Re: [PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine

[Vasily Khoruzhick]

On Wed, Nov 7, 2018 at 11:11 PM Chen-Yu Tsai  wrote:
>
> On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick  wrote:
> >
> > This commit enables I2S, digital and analog parts of audiocodec on
> > Pine64 and SoPine boards.
> >
> > Signed-off-by: Vasily Khoruzhick 
> > ---
> >  .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 28 +++
> >  .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
> >  2 files changed, 56 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > index c077b6c1f458..ff352bdfbb93 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > @@ -75,6 +75,18 @@
> > };
> >  };
> >
> > +&codec {
> > +   status = "okay";
> > +};
> > +
> > +&codec_analog {
> > +   status = "okay";
> > +};
> > +
> > +&dai {
> > +   status = "okay";
> > +};
> > +
> >  &de {
> > status = "okay";
> >  };
> > @@ -264,6 +276,22 @@
> > status = "disabled";
> >  };
> >
> > +&sound {
> > +   status = "okay";
> > +   simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > +   "Headphone", "Headphone Jack";
> > +   simple-audio-card,routing =
> > +   "Left DAC", "AIF1 Slot 0 Left",
> > +   "Right DAC", "AIF1 Slot 0 Right",
> > +   "Headphone Jack", "HP",
> > +   "AIF1 Slot 0 Left ADC", "Left ADC",
> > +   "AIF1 Slot 0 Right ADC", "Right ADC",
> > +   "Left ADC", "ADC",
> > +   "Right ADC", "ADC",
>
> As mentioned the above two don't belong in the device tree.
>
> > +   "Microphone Jack", "HBIAS",
>
> Schematics says this is NC or not connected by default.
> You may want to ask Pine64 about this?
>
> Same comments for SoPine.

I'll just drop it. Not connected on schematics - we don't put it in dts.

>
> > +   "MIC2", "Microphone Jack";
> > +};
> > +
> >  /* On Exp and Euler connectors */
> >  &uart0 {
> > pinctrl-names = "default";
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts 
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > index 53fcc9098df3..25d732df37c4 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > @@ -80,6 +80,18 @@
> > };
> >  };
> >
> > +&codec {
> > +   status = "okay";
> > +};
> > +
> > +&codec_analog {
> > +   status = "okay";
> > +};
> > +
> > +&dai {
> > +   status = "okay";
> > +};
> > +
> >  &de {
> > status = "okay";
> >  };
> > @@ -164,6 +176,22 @@
> > vcc-hdmi-supply = <®_dldo1>;
> >  };
> >
> > +&sound {
> > +   status = "okay";
> > +   simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > +   "Headphone", "Headphone Jack";
> > +   simple-audio-card,routing =
> > +   "Left DAC", "AIF1 Slot 0 Left",
> > +   "Right DAC", "AIF1 Slot 0 Right",
> > +   "Headphone Jack", "HP",
> > +   "AIF1 Slot 0 Left ADC", "Left ADC",
> > +   "AIF1 Slot 0 Right ADC", "Right ADC",
> > +   "Left ADC", "ADC",
> > +   "Right ADC", "ADC",
> > +   "Microphone Jack", "HBIAS",
> > +   "MIC2", "Microphone Jack";
> > +};
> > +
> >  &uart0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&uart0_pb_pins>;
> > --
> > 2.19.1
> >

Re: [PATCH] fs/proc: introduce /proc/stat2 file

[Davidlohr Bueso]

On Thu, 08 Nov 2018, Dave Chinner wrote:


If only we had percpu counters that had a fixed, extremely low read
overhead that doesn't care about the number of CPUs in the
machine

Oh, wait, we do: percpu_counters.[ch].

This all seems like a counter implementation deficiency to me, not
an interface problem...


Yeah fair point, as long as we can sacrifice accuracy by replacing
kernel_stat -- or maybe just replace the hard irq stats, which I
still think only accounts for 1% of all stat users. I have not looked
at how filesystems tune the batch size, but it would certainly be worth
looking into methinks.

Thanks,
Davidlohr

Re: [PATCH v2 3/4] mm: convert totalram_pages and totalhigh_pages variables to atomic

[Arun KS]

On 2018-11-07 14:34, Vlastimil Babka wrote:

On 11/6/18 5:21 PM, Arun KS wrote:

totalram_pages and totalhigh_pages are made static inline function.

Suggested-by: Michal Hocko 
Suggested-by: Vlastimil Babka 
Signed-off-by: Arun KS 
Reviewed-by: Konstantin Khlebnikov 
Acked-by: Michal Hocko 


Acked-by: Vlastimil Babka 

One bug (probably) below:


diff --git a/mm/highmem.c b/mm/highmem.c
index 59db322..02a9a4b 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -105,9 +105,7 @@ static inline wait_queue_head_t 
*get_pkmap_wait_queue_head(unsigned int color)

 }
 #endif

-unsigned long totalhigh_pages __read_mostly;
-EXPORT_SYMBOL(totalhigh_pages);


I think you still need to export _totalhigh_pages so that modules can
use the inline accessors.


Thanks for pointing this. I missed that. Will do the same for 
_totalram_pages.


Regards,
Arun




-
+atomic_long_t _totalhigh_pages __read_mostly;

 EXPORT_PER_CPU_SYMBOL(__kmap_atomic_idx);

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

* Thomas Gleixner  wrote:

> +Backtraces in changelogs
> +
> +
> +Backtraces can be useful to document the call chain which led to a
> +problem. Though not all back traces are really valuable because the call
> +chain is unique and obvious, e.g. in early boot code. Just copying the full
> +dmesg output is adding a lot of distracting information like timestamps,
> +module lists, register and stack dumps etc.
> +
> +Reducing the backtrace to the real relevant data helps to concentrate on
> +the issue and not being distracted by destilling the relevant information
> +out of the dump. Here is an example of a well trimmed backtrace::
> +
> +  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x
> +  0064) at rIP: 0xae059994 (native_write_msr+0x4/0x20)
> +  Call Trace:
> +  mba_wrmsr+0x41/0x80
> +  update_domains+0x125/0x130
> +  rdtgroup_mkdir+0x270/0x500

Yeah, so I frequently simplify such backtraces even more, i.e.:

> +  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x 
> 0064) at rIP: 0xae059994 (native_write_msr())
> +
> +  Call Trace:
> +mba_wrmsr()
> +update_domains()
> +rdtgroup_mkdir()

Note how the actual MSR contents and the attempted operation's parameters 
are important, the actual hexadecimal offsets of the function call 
backtrace are not. They are useful when trying to do fuzzy version 
matching and in the occasional case when there's a question about which 
exact call chain it is - but those are 0.01% cases really.

See for example this recent commit:

 commit e4a02ed2aaf447fa849e3254bfdb3b9b01e1e520 
(origin/locking-urgent-for-linus, locking-urgent-for-linus)
 Author: Guenter Roeck 
 Date:   Tue Oct 2 14:48:49 2018 -0700

locking/ww_mutex: Fix runtime warning in the WW mutex selftest

If CONFIG_WW_MUTEX_SELFTEST=y is enabled, booting an image
in an arm64 virtual machine results in the following
traceback if 8 CPUs are enabled:

  DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
  WARNING: CPU: 2 PID: 537 at kernel/locking/mutex.c:1033 
__mutex_unlock_slowpath+0x1a8/0x2e0
  ...
  Call trace:
   __mutex_unlock_slowpath()
   ww_mutex_unlock()
   test_cycle_work()
   process_one_work()
   worker_thread()
   kthread()
   ret_from_fork()

If requesting b_mutex fails with -EDEADLK, the error variable
is reassigned to the return value from calling ww_mutex_lock
on a_mutex again. If this call fails, a_mutex is not locked.
It is, however, unconditionally unlocked subsequently, causing
the reported warning. Fix the problem by using two error variables.

With this change, the selftest still fails as follows:

  cyclic deadlock not resolved, ret[7/8] = -35

However, the traceback is gone.

The C-style writing of the backtrace is more readable than listing the 
offsets.

Thanks,

Ingo

Re: [RFC PATCH 5/5] mm, memory_hotplug: be more verbose for memory offline failures

[Anshuman Khandual]

On 11/07/2018 03:48 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> There is only very limited information printed when the memory offlining
> fails:
> [ 1984.506184] rac1 kernel: memory offlining [mem 
> 0x826-0x8267fff] failed due to signal backoff
> 
> This tells us that the failure is triggered by the userspace
> intervention but it doesn't tell us much more about the underlying
> reason. It might be that the page migration failes repeatedly and the
> userspace timeout expires and send a signal or it might be some of the
> earlier steps (isolation, memory notifier) takes too long.
> 
> If the migration failes then it would be really helpful to see which
> page that and its state. The same applies to the isolation phase. If we
> fail to isolate a page from the allocator then knowing the state of the
> page would be helpful as well.
> 
> Dump the page state that fails to get isolated or migrated. This will
> tell us more about the failure and what to focus on during debugging.
> 
> Signed-off-by: Michal Hocko 
> ---
>  mm/memory_hotplug.c | 12 
>  mm/page_alloc.c |  1 +
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 1badac89c58e..bf214beccda3 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1388,10 +1388,8 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> long end_pfn)
>   page_is_file_cache(page));
>  
>   } else {
> -#ifdef CONFIG_DEBUG_VM
> - pr_alert("failed to isolate pfn %lx\n", pfn);
> + pr_warn("failed to isolate pfn %lx\n", pfn)>
> dump_page(page, "isolation failed");
> -#endif
>   put_page(page);
>   /* Because we don't have big zone->lock. we should
>  check this again here. */
> @@ -1411,8 +1409,14 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> long end_pfn)
>   /* Allocate a new page from the nearest neighbor node */
>   ret = migrate_pages(&source, new_node_page, NULL, 0,
>   MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> - if (ret)
> + if (ret) {
> + list_for_each_entry(page, &source, lru) {
> + pr_warn("migrating pfn %lx failed ",
> +page_to_pfn(page), ret);

Seems like pr_warn() needs to have %d in here to print 'ret'. Though
dumping return code from migrate_pages() makes sense, wondering if
it is required for each and every page which failed to migrate here
or just one instance is enough.

> + dump_page(page, NULL);
> + }

s/NULL/failed to migrate/ for dump_page().

>   putback_movable_pages(&source);
> + }
>   }
>  out:
>   return ret;
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a919ba5cb3c8..23267767bf98 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7845,6 +7845,7 @@ bool has_unmovable_pages(struct zone *zone, struct page 
> *page, int count,
>   return false;
>  unmovable:
>   WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
> + dump_page(pfn_to_page(pfn+iter), "has_unmovable_pages");

s/has_unmovable_pages/is unmovable/

If we eally care about the function name, then dump_page() should be
followed by dump_stack() like the case in some other instances.

>   return true;

This will be dumped from HugeTLB and CMA allocation paths as well through
alloc_contig_range(). But it should be okay as those occurrences should be
rare and dumping page state then will also help.

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

* Ingo Molnar  wrote:

> With tail comments the code looks like this:
> 
>   res = dostuff(); /* We explain something here. */
> 
>   seed = 1; /* Another explanation. */
> 
>   mod_timer(&our_object->our_timer, jiffies + OUR_INTERVAL); /* We like 
> to talk */
> 
>   res = check_stuff(our_object); /* We explain something here. */
>   if (res)
>   return -EINVAL;
> 
>   interval = nontrivial_calculation(); /* Another explanation. */
> 
>   mod_timer(&our_object->our_timer, jiffies + interval); /* This doesn't 
> race, because. */
> 
> ... while with freestanding comments it's:
> 
>   /* We explain something here: */
>   res = check_stuff(our_object);
>   if (res)
>   return -EINVAL;
> 
>   /* Another explanation: */
>   interval = nontrivial_calculation();
> 
>   /* This doesn't race with init_our_stuff(), because: */
>   mod_timer(&our_object->our_timer, jiffies + interval);
> 
> This comment placement style has several advantages:
> 
>   - Comments precede actual code - while in tail comments it's exactly
> the wrong way around.
> 
>   - We don't create over-long lines nor artificially short tail comments 
> just because we were trying to stay within the col80 limit with the 
> "this doesn't race" comment. The full-line comment was able to 
> explain that the race is with init_our_stuff().
> 
>   - Freestanding oneliner comments are much better aligned as well: note 
> how ever comment starts at the exact same column, making it very easy 
> to read (or not to read) these comments.
> 
>   - In short: predictable visual parsing rules and proper semantic 
> ordering of information is good, random joining of typographical 
> elements just to create marginally more compact source code is bad.
> 
>   - Just *look* at the tail comments example: it's a visually diffuse, 
> jumble of statements and misaligned comments with good structure.

Forgot to mention the role of punctuation:

- Also note how punctuation actually *helps* the integration of 
  comments and code. The ":" will direct attention to the code that 
  follows, making it clear that the sentence explains the next 
  statement. There are exceptions for when different type of 
  punctuation is a better choice, for example:

/* TODO: convert the code to our newest calc API ASAP. */
interval = nontrivial_calculation();

  Here we don't explain the statement but document a TODO entry. 

  Also, it's frequent practice to use multi-line comments to explain 
  the next section of code, with a particular note about the first 
  statement. Proper punctuation helps there too:

/*
 * Establish the timeout interval and use it to set up
 * the timer of our object. The object is going to be
 * freed when the last reference is released.
 *
 * Note, the initial calculation is non-trivial, because
 * our timeout rules have complexity A), B) and C):
 */
interval = nontrivial_calculation();

  Note how part of the multi-line comment describes overall 
  principles of the code to follow, while the last sentence 
  describes a noteworthy aspect of the next C statement.

Thanks,

Ingo

Re: [PATCH RFC] hist lookups

[Jiri Olsa]

On Wed, Nov 07, 2018 at 12:01:54PM -0800, David Miller wrote:
> From: Jiri Olsa 
> Date: Wed, 7 Nov 2018 20:43:44 +0100
> 
> > I pushed new version in my perf/fixes branch
> 
> Thanks, I'll check it out later today for sure!  This is pretty exciting
> work.
> 
> Just some random thoughts as I've been thinking about this whole
> situation a lot lately:
> 
> Something to consider might be consolidating all of the event rings
> into one.  This would force perf to process all events in "system
> order", ie. what order they actually occurred in the machine.
> 
> Yes, this means more contention for the entities inside the kernel
> queueing up the events, however the benefits are enormous.

yes, perf's ring buffer is real fast because it's per-cpu

> 
> Right now we go forwards and backwards in time as we move from one
> event ring to another, as you know.
> 
> However, we have to reconcile with the need we have to separate "high
> priority" (ie. cannot really lose) events like fork, mmap2, etc.  with
> "low priority" ones such as IP samples.
> 
> Perhaps another way to think about this is to go to the one huge mmap
> ring model, and do the prioritization internally in perf.
> 
> Actually, this opens up tons of possibilities in my mind.
> 
> Perf can queue to an internal high priority queue for fork and mmap2
> events, and never drop them.  Whilst at the same time queueing low
> priority events like IP samples into a low priority queue and dropping
> with whatever policy it wants when overloaded (f.e. drop older events
> before newer ones).

I think I can see the processing thread overloaded with data in tests,
I'll add some counters for it some we can see how much behind it gets

we could separated fork/mmaps to separate dummy event map, or just
parse them out in the read thread and create special queue for them
and drop just samples in case we are behind

jirka

> 
> I do not like the overwrite ring buffer mode that was implemented
> because it enforeces an entire set of policy decisions upon the user.
> Either the model works for you (which it currently does not for perf)
> or you can't use it at all.
> 
> If the issue is that newer events are more interesting than old ones,
> that is entirely perf's businness.  And it can implement this policy
> %100 internally to itself.  No kernel changes were ever needed to do
> this, as explained above.
> 
> Please, let's abandon this whole overwrite mode of the ring buffer.
> The old one works perfectly fine, we just have to use it properly.
> We should never have to shut off kernel side event queueing just
> because we are processing the event ring on the user side.
> 
> Thanks.

Re: [PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine

[Chen-Yu Tsai]

On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick  wrote:
>
> This commit enables I2S, digital and analog parts of audiocodec on
> Pine64 and SoPine boards.
>
> Signed-off-by: Vasily Khoruzhick 
> ---
>  .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 28 +++
>  .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
>  2 files changed, 56 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index c077b6c1f458..ff352bdfbb93 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -75,6 +75,18 @@
> };
>  };
>
> +&codec {
> +   status = "okay";
> +};
> +
> +&codec_analog {
> +   status = "okay";
> +};
> +
> +&dai {
> +   status = "okay";
> +};
> +
>  &de {
> status = "okay";
>  };
> @@ -264,6 +276,22 @@
> status = "disabled";
>  };
>
> +&sound {
> +   status = "okay";
> +   simple-audio-card,widgets = "Microphone", "Microphone Jack",
> +   "Headphone", "Headphone Jack";
> +   simple-audio-card,routing =
> +   "Left DAC", "AIF1 Slot 0 Left",
> +   "Right DAC", "AIF1 Slot 0 Right",
> +   "Headphone Jack", "HP",
> +   "AIF1 Slot 0 Left ADC", "Left ADC",
> +   "AIF1 Slot 0 Right ADC", "Right ADC",
> +   "Left ADC", "ADC",
> +   "Right ADC", "ADC",

As mentioned the above two don't belong in the device tree.

> +   "Microphone Jack", "HBIAS",

Schematics says this is NC or not connected by default.
You may want to ask Pine64 about this?

Same comments for SoPine.

> +   "MIC2", "Microphone Jack";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
> pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> index 53fcc9098df3..25d732df37c4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> @@ -80,6 +80,18 @@
> };
>  };
>
> +&codec {
> +   status = "okay";
> +};
> +
> +&codec_analog {
> +   status = "okay";
> +};
> +
> +&dai {
> +   status = "okay";
> +};
> +
>  &de {
> status = "okay";
>  };
> @@ -164,6 +176,22 @@
> vcc-hdmi-supply = <®_dldo1>;
>  };
>
> +&sound {
> +   status = "okay";
> +   simple-audio-card,widgets = "Microphone", "Microphone Jack",
> +   "Headphone", "Headphone Jack";
> +   simple-audio-card,routing =
> +   "Left DAC", "AIF1 Slot 0 Left",
> +   "Right DAC", "AIF1 Slot 0 Right",
> +   "Headphone Jack", "HP",
> +   "AIF1 Slot 0 Left ADC", "Left ADC",
> +   "AIF1 Slot 0 Right ADC", "Right ADC",
> +   "Left ADC", "ADC",
> +   "Right ADC", "ADC",
> +   "Microphone Jack", "HBIAS",
> +   "MIC2", "Microphone Jack";
> +};
> +
>  &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.19.1
>

drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.c:96: undefined reference to `thermal_zone_device_register'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   85758777c2a227fd1541b6dd122a08ab79c347ce
commit: e70a57fa59bb7fefe063780a49e063d0d0f61863 cxgb4: fix thermal 
configuration dependencies
date:   4 weeks ago
config: x86_64-randconfig-s0-11081213 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout e70a57fa59bb7fefe063780a49e063d0d0f61863
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.o: In function 
`cxgb4_thermal_init':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.c:96: undefined reference 
>> to `thermal_zone_device_register'
   drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.o: In function 
`cxgb4_thermal_remove':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.c:112: undefined reference 
>> to `thermal_zone_device_unregister'

vim +96 drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.c

b1871915 Ganesh Goudar 2018-10-09   72  
b1871915 Ganesh Goudar 2018-10-09   73  int cxgb4_thermal_init(struct adapter 
*adap)
b1871915 Ganesh Goudar 2018-10-09   74  {
b1871915 Ganesh Goudar 2018-10-09   75  struct ch_thermal *ch_thermal = 
&adap->ch_thermal;
b1871915 Ganesh Goudar 2018-10-09   76  int num_trip = CXGB4_NUM_TRIPS;
b1871915 Ganesh Goudar 2018-10-09   77  u32 param, val;
b1871915 Ganesh Goudar 2018-10-09   78  int ret;
b1871915 Ganesh Goudar 2018-10-09   79  
b1871915 Ganesh Goudar 2018-10-09   80  /* on older firmwares we may 
not get the trip temperature,
b1871915 Ganesh Goudar 2018-10-09   81   * set the num of trips to 0.
b1871915 Ganesh Goudar 2018-10-09   82   */
b1871915 Ganesh Goudar 2018-10-09   83  param = 
(FW_PARAMS_MNEM_V(FW_PARAMS_MNEM_DEV) |
b1871915 Ganesh Goudar 2018-10-09   84   
FW_PARAMS_PARAM_X_V(FW_PARAMS_PARAM_DEV_DIAG) |
b1871915 Ganesh Goudar 2018-10-09   85   
FW_PARAMS_PARAM_Y_V(FW_PARAM_DEV_DIAG_MAXTMPTHRESH));
b1871915 Ganesh Goudar 2018-10-09   86  
b1871915 Ganesh Goudar 2018-10-09   87  ret = t4_query_params(adap, 
adap->mbox, adap->pf, 0, 1,
b1871915 Ganesh Goudar 2018-10-09   88¶m, 
&val);
b1871915 Ganesh Goudar 2018-10-09   89  if (ret < 0) {
b1871915 Ganesh Goudar 2018-10-09   90  num_trip = 0; /* could 
not get trip temperature */
b1871915 Ganesh Goudar 2018-10-09   91  } else {
b1871915 Ganesh Goudar 2018-10-09   92  ch_thermal->trip_temp = 
val * 1000;
b1871915 Ganesh Goudar 2018-10-09   93  ch_thermal->trip_type = 
THERMAL_TRIP_CRITICAL;
b1871915 Ganesh Goudar 2018-10-09   94  }
b1871915 Ganesh Goudar 2018-10-09   95  
b1871915 Ganesh Goudar 2018-10-09  @96  ch_thermal->tzdev = 
thermal_zone_device_register("cxgb4", num_trip,
b1871915 Ganesh Goudar 2018-10-09   97  
 0, adap,
b1871915 Ganesh Goudar 2018-10-09   98  
 &cxgb4_thermal_ops,
b1871915 Ganesh Goudar 2018-10-09   99  
 NULL, 0, 0);
b1871915 Ganesh Goudar 2018-10-09  100  if (IS_ERR(ch_thermal->tzdev)) {
b1871915 Ganesh Goudar 2018-10-09  101  ret = 
PTR_ERR(ch_thermal->tzdev);
b1871915 Ganesh Goudar 2018-10-09  102  dev_err(adap->pdev_dev, 
"Failed to register thermal zone\n");
b1871915 Ganesh Goudar 2018-10-09  103  ch_thermal->tzdev = 
NULL;
b1871915 Ganesh Goudar 2018-10-09  104  return ret;
b1871915 Ganesh Goudar 2018-10-09  105  }
b1871915 Ganesh Goudar 2018-10-09  106  return 0;
b1871915 Ganesh Goudar 2018-10-09  107  }
b1871915 Ganesh Goudar 2018-10-09  108  
b1871915 Ganesh Goudar 2018-10-09  109  int cxgb4_thermal_remove(struct adapter 
*adap)
b1871915 Ganesh Goudar 2018-10-09  110  {
b1871915 Ganesh Goudar 2018-10-09  111  if (adap->ch_thermal.tzdev)
b1871915 Ganesh Goudar 2018-10-09 @112  
thermal_zone_device_unregister(adap->ch_thermal.tzdev);

:: The code at line 96 was first introduced by commit
:: b187191577629b5358acf4e234809ee8d441ceb4 cxgb4: Add thermal zone support

:: TO: Ganesh Goudar 
:: CC: David S. Miller 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [patch 2/2] Documentation/process: Add tip tree handbook

[Ingo Molnar]

* Thomas Gleixner  wrote:

> +Coding style notes
> +--
> +
> +Comment style
> +^
> +
> +Sentences in comments start with a uppercase letter.
> +
> +Single line comments::
> +
> + /* This is a single line comment */
> +
> +Multi-line comments::
> +
> + /*
> +  * This is a properly formatted
> +  * multi-line comment.
> +  *
> +  * Larger multi-line comments should be split into paragraphs.
> +  */
> +
> +No tail comments:
> +
> +  Please refrain from using tail comments. Tail comments disturb the
> +  reading flow in almost all contexts, but especially in code::
> +
> + if (somecondition_is_true) /* Don't put a comment here */
> + dostuff(); /* Neither here */
> +
> + seed = MAGIC_CONSTANT; /* Nor here */
> +
> +  Use freestanding comments instead::
> +
> + /* This condition is not obvious without a comment */
> + if (somecondition_is_true) {
> + /* This really needs to be documented */
> + dostuff();
> + }
> +
> + /* This magic initialization needs a comment. Maybe not? */
> + seed = MAGIC_CONSTANT;

Yeah, so I think a better way to visualize and explain the 'no tail 
comments' guideline in -tip is not these more complex code flows, but the 
totally simple linear flows of statements.

With tail comments the code looks like this:

res = dostuff(); /* We explain something here. */

seed = 1; /* Another explanation. */

mod_timer(&our_object->our_timer, jiffies + OUR_INTERVAL); /* We like 
to talk */

res = check_stuff(our_object); /* We explain something here. */
if (res)
return -EINVAL;

interval = nontrivial_calculation(); /* Another explanation. */

mod_timer(&our_object->our_timer, jiffies + interval); /* This doesn't 
race, because. */

... while with freestanding comments it's:

/* We explain something here: */
res = check_stuff(our_object);
if (res)
return -EINVAL;

/* Another explanation: */
interval = nontrivial_calculation();

/* This doesn't race with init_our_stuff(), because: */
mod_timer(&our_object->our_timer, jiffies + interval);

This comment placement style has several advantages:

  - Comments precede actual code - while in tail comments it's exactly
the wrong way around.

  - We don't create over-long lines nor artificially short tail comments 
just because we were trying to stay within the col80 limit with the 
"this doesn't race" comment. The full-line comment was able to 
explain that the race is with init_our_stuff().

  - Freestanding oneliner comments are much better aligned as well: note 
how ever comment starts at the exact same column, making it very easy 
to read (or not to read) these comments.

  - In short: predictable visual parsing rules and proper semantic 
ordering of information is good, random joining of typographical 
elements just to create marginally more compact source code is bad.

  - Just *look* at the tail comments example: it's a visually diffuse, 
jumble of statements and misaligned comments with good structure.

Do you want me to send a delta patch, or an edited document?

Thanks,

Ingo

[PATCH 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

[Shawn Guo]

From: Sriharsha Allenki 

It adds bindings for Synopsys 28nm femto phy controller that supports
LS/FS/HS usb connectivity on Qualcomm chipsets.

Signed-off-by: Sriharsha Allenki 
Signed-off-by: Anu Ramanathan 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Shawn Guo 
---
 .../phy/qcom,snps-28nm-usb-hs-phy.txt | 101 ++
 1 file changed, 101 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt

diff --git 
a/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
new file mode 100644
index ..75e7a09dd558
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
@@ -0,0 +1,101 @@
+Qualcomm Synopsys 28nm Femto phy controller
+===
+
+Synopsys 28nm femto phy controller supports LS/FS/HS usb connectivity on
+Qualcomm chipsets.
+
+Required properties:
+
+- compatible:
+Value type: 
+Definition: Should contain "qcom,usb-snps-hsphy".
+
+- reg:
+Value type: 
+Definition: USB PHY base address and length of the register map.
+
+- #phy-cells:
+Value type: 
+Definition: Should be 0.
+
+- clocks:
+Value type: 
+Definition: See clock-bindings.txt section "consumers". List of
+   three clock specifiers for reference, phy core and
+   sleep clocks.
+
+- clock-names:
+Value type: 
+Definition: Names of the clocks in 1-1 correspondence with the "clocks"
+   property. Must contain "ref", "phy" and "sleep".
+
+- resets:
+Value type: 
+Definition: See reset.txt section "consumers". PHY reset specifiers
+   for phy core and POR resets.
+
+- reset-names:
+Value type: 
+Definition: Names of the resets in 1-1 correspondence with the "resets"
+   property. Must contain "phy" and "por".
+
+- vdd-supply:
+Value type: 
+Definition: phandle to the regulator VDD supply node.
+
+- vdda1p8-supply:
+Value type: 
+Definition: phandle to the regulator 1.8V supply node.
+
+- vdda3p3-supply:
+Value type: 
+Definition: phandle to the regulator 3.3V supply node.
+
+- qcom,vdd-voltage-level:
+Value type: 
+Definition: This is a list of three integer values  where
+   each value corresponding to voltage corner in uV.
+
+Optional properties:
+
+- extcon:
+Value type: 
+Definition: Should contain the vbus extcon.
+
+- qcom,init-seq:
+Value type: 
+Definition: Should contain a sequence of  tuples to
+program 'value' into phy register at 'offset' with 'delay'
+   in us afterwards.
+
+Example:
+
+   phy@7a000 {
+   compatible = "qcom,usb-snps-hsphy";
+   reg = <0x7a000 0x200>;
+   #phy-cells = <0>;
+   clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
+<&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
+<&gcc GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "phy", "sleep";
+   resets = <&gcc GCC_USB_HS_PHY_CFG_AHB_BCR>,
+<&gcc GCC_USB2A_PHY_BCR>;
+   reset-names = "phy", "por";
+   vdd-supply = <&vreg_l4_1p2>;
+   vdda1p8-supply = <&vreg_l5_1p8>;
+   vdda3p3-supply = <&vreg_l12_3p3>;
+   qcom,vdd-voltage-level = <0 1144000 120>;
+   qcom,init-seq = <0xc0 0x01 0>,
+   <0xe8 0x0d 0>,
+   <0x74 0x12 0>,
+   <0x98 0x63 0>,
+   <0x9c 0x03 0>,
+   <0xa0 0x1d 0>,
+   <0xa4 0x03 0>,
+   <0x8c 0x23 0>,
+   <0x78 0x08 0>,
+   <0x7c 0xdc 0>,
+   <0x90 0xe0 20>,
+   <0x74 0x10 0>,
+   <0x90 0x60 0>;
+   };
-- 
2.18.0

[PATCH 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

[Shawn Guo]

It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.

Signed-off-by: Shawn Guo 
---
 drivers/phy/qualcomm/Kconfig  |  10 +
 drivers/phy/qualcomm/Makefile |   1 +
 .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c  | 494 ++
 3 files changed, 505 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 32f7d34eb784..c7b5ee82895d 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -82,3 +82,13 @@ config PHY_QCOM_USB_HSIC
select GENERIC_PHY
help
  Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
+
+config PHY_QCOM_USB_HS_SNPS_28NM
+   tristate "Qualcomm Synopsys 28nm USB HS PHY driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
+   select GENERIC_PHY
+   help
+ Enable this to support the Synopsys 28nm Femto USB PHY on Qualcomm
+ chips. This driver supports the high-speed PHY which is usually
+ paired with either the ChipIdea or Synopsys DWC3 USB IPs on MSM SOCs.
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index c56efd3af205..dc238d95b18c 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_QCOM_UFS_14NM) += 
phy-qcom-ufs-qmp-14nm.o
 obj-$(CONFIG_PHY_QCOM_UFS_20NM)+= phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_USB_HS)  += phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
+obj-$(CONFIG_PHY_QCOM_USB_HS_SNPS_28NM)+= phy-qcom-usb-hs-snsp-28nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c 
b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
new file mode 100644
index ..e3b23ccd4d37
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
@@ -0,0 +1,494 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2009-2018, Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY register and bit definitions */
+#define PHY_CTRL_COMMON0   0x078
+#define SIDDQ  BIT(2)
+#define PHY_IRQ_CMD0x0d0
+#define PHY_INTR_CLEAR00x0dc
+#define PHY_INTR_MASK0 0x0d4
+#define DPDM_MASK  0x1e
+#define DP_1_0 BIT(4)
+#define DP_0_1 BIT(3)
+#define DM_1_0 BIT(2)
+#define DM_0_1 BIT(1)
+
+enum hsphy_voltage {
+   VOL_NONE,
+   VOL_MIN,
+   VOL_MAX,
+   VOL_NUM,
+};
+
+enum hsphy_vreg {
+   VDD,
+   VDDA_1P8,
+   VDDA_3P3,
+   VREG_NUM,
+};
+
+struct hsphy_init_seq {
+   int offset;
+   int val;
+   int delay;
+};
+
+struct hsphy_priv {
+   void __iomem *base;
+   struct clk_bulk_data *clks;
+   int num_clks;
+   struct reset_control *phy_reset;
+   struct reset_control *por_reset;
+   struct regulator_bulk_data vregs[VREG_NUM];
+   unsigned int voltages[VREG_NUM][VOL_NUM];
+   struct hsphy_init_seq *init_seq;
+   bool cable_connected;
+   struct extcon_dev *vbus_edev;
+   struct notifier_block vbus_notify;
+   enum phy_mode mode;
+};
+
+static int qcom_snps_hsphy_config_regulators(struct hsphy_priv *priv, int high)
+{
+   int min, ret, i;
+
+   min = high ? 1 : 0; /* low or none? */
+
+   for (i = 0; i < VREG_NUM; i++) {
+   ret = regulator_set_voltage(priv->vregs[i].consumer,
+   priv->voltages[i][min],
+   priv->voltages[i][VOL_MAX]);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int qcom_snps_hsphy_enable_regulators(struct hsphy_priv *priv)
+{
+   int ret;
+
+   ret = qcom_snps_hsphy_config_regulators(priv, 1);
+   if (ret)
+   return ret;
+
+   ret = regulator_set_load(priv->vregs[VDDA_1P8].consumer, 19000);
+   if (ret < 0)
+   goto unconfig_regulators;
+
+   ret = regulator_set_load(priv->vregs[VDDA_3P3].consumer, 16000);
+   if (ret < 0)
+   goto unset_1p8_load;
+
+   ret = regulator_bulk_enable(VREG_NUM, priv->vregs);
+   if (ret)
+   goto unset_3p3_load;
+
+   return 0;
+
+unset_3p3_load:
+   regulator_set_load(priv->vregs[VDDA_3P3].consumer, 0);
+unset_1p8_load:
+   regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
+unconfig_regulators:
+   qcom_snps_hsphy_config_regula

[PATCH 0/2] Add Synopsys High-Speed USB PHY driver for Qualcomm SoCs

[Shawn Guo]

It's based on a downstream driver from Sriharsha Allenki 

that uses USB phy framework, and gets rewrote to adpot generic phy
framework together with quite some cleanups.

Shawn Guo (1):
  phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Sriharsha Allenki (1):
  dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

 .../phy/qcom,snps-28nm-usb-hs-phy.txt | 101 
 drivers/phy/qualcomm/Kconfig  |  10 +
 drivers/phy/qualcomm/Makefile |   1 +
 .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c  | 494 ++
 4 files changed, 606 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
 create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c

-- 
2.18.0

Re: [PATCH 5/5] hwspinlock: Add test module

[Bjorn Andersson]

On Wed 31 Oct 02:30 PDT 2018, Benjamin Gaignard wrote:

> Create a test module to perform simple unitary tests on hwspinlock.
> It doesn't cover all the possibles cases but at least allow to test
> that very basic features are working.
> 

I like the idea of making these things testable, but I would like to
hear from others how useful this module would be to them before merging
it.

> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/hwspinlock/Kconfig   |   9 +++
>  drivers/hwspinlock/Makefile  |   1 +
>  drivers/hwspinlock/hwspinlock_test.c | 132 
> +++
>  3 files changed, 142 insertions(+)
>  create mode 100644 drivers/hwspinlock/hwspinlock_test.c
> 
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index e1a20b460590..f340ebb4d1f7 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -68,3 +68,12 @@ config HWSPINLOCK_STM32
> Say y here to support the STM32 Hardware Spinlock device.
>  
> If unsure, say N.
> +
> +config HWSPINLOCK_TEST
> + tristate "hwspinlock test module"
> + depends on HWSPINLOCK && m
> + default n
> + help
> +   Select M here if you want to build hwspinlock test module
> +
> +   If unsure, say N.
> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> index c0a9505b4dcf..e6b3d0212fe0 100644
> --- a/drivers/hwspinlock/Makefile
> +++ b/drivers/hwspinlock/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_HWSPINLOCK_SIRF)   += 
> sirf_hwspinlock.o
>  obj-$(CONFIG_HWSPINLOCK_SPRD)+= sprd_hwspinlock.o
>  obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
>  obj-$(CONFIG_HWSPINLOCK_STM32)   += stm32_hwspinlock.o
> +obj-$(CONFIG_HWSPINLOCK_TEST)+= hwspinlock_test.o
> diff --git a/drivers/hwspinlock/hwspinlock_test.c 
> b/drivers/hwspinlock/hwspinlock_test.c
> new file mode 100644
> index ..75819337e45a
> --- /dev/null
> +++ b/drivers/hwspinlock/hwspinlock_test.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics SA 2018
> + * Author: Benjamin Gaignard  for 
> STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define TIMEOUT  50 /* ms */
> +
> +static void hwspin_lock_test_twice_request_specific(void)
> +{
> + struct hwspinlock *lock0 = hwspin_lock_request_specific(0);
> + struct hwspinlock *lock1 = hwspin_lock_request_specific(1);

In a platform with more than one hwspinlock this will test the
implementation that was first probed and it will assume that there's no
issues with messing with the first two locks from this provider.

> +
> + int ret;
> +
> + if (!lock0 || !lock1) {
> + pr_warn("Can't request twice hwspin_lock\n");
> + return;
> + }
> +
> + ret = hwspin_trylock(lock0);
> + if (ret)
> + pr_warn("Can't trylock requested hwspin_lock 0 (%d)\n", ret);
> +
> + ret = hwspin_trylock(lock1);
> + if (ret)
> + pr_warn("Can't trylock requested hwspin_lock 1 (%d)\n", ret);
> +
> + hwspin_unlock(lock0);
> + hwspin_unlock(lock1);

As described in the kerneldoc for these it's a bug to attempt to unlock
a unlocked lock. I believe this should be interpreted as it being
invalid to unlock unless hwspin_trylock() returned successfully.

> +
> + ret = hwspin_lock_free(lock0);
> + if (ret)
> + pr_warn("Can't free requested hwspin_lock 0\n");
> +
> + ret = hwspin_lock_free(lock1);
> + if (ret)
> + pr_warn("Can't free requested hwspin_lock 0\n");
> +}
> +
> +static void hwspin_lock_test_trylock(void)
> +{
> + struct hwspinlock *lock = hwspin_lock_request();
> + int ret;
> +
> + if (!lock) {
> + pr_warn("Can't request hwspin_lock\n");
> + return;
> + }
> +
> + ret = hwspin_trylock(lock);
> + if (ret)
> + pr_warn("Can't trylock requested hwspin_lock (%d)\n", ret);
> +
> + /* Try to lock a second time, this should failed */
> + ret = hwspin_trylock(lock);
> + if (ret != -EBUSY)
> + pr_warn("Getting twice the same lock ! (%d)\n", ret);

This shouldn't be a warning, as this is a test failure.

> +
> + hwspin_unlock(lock);
> + ret = hwspin_lock_free(lock);
> + if (ret)
> + pr_warn("Can't free requested hwspin_lock 0\n");
> +}
> +
> +static void hwspin_lock_test_request_specific(void)
> +{
> + /*
> +  * Let's assume that any hwspin_lock driver would at least have one
> +  * lock at index 0
> +  */
> + struct hwspinlock *lock = hwspin_lock_request_specific(0);
> + int ret;
> +
> + if (!lock) {
> + pr_warn("Can't request hwspin_lock 0\n");
> + return;
> + }
> +
> + ret = hwspin_lock_timeout(lock, TIMEOUT);
> + if (ret)
> + pr_warn("Can't lo

Re: [PATCH V2] binder: ipc namespace support for android binder

[Davidlohr Bueso]

On Mon, 29 Oct 2018, chouryzhou(??) wrote:

@@ -63,6 +63,12 @@ struct ipc_namespace {
   unsigned intmq_msg_default;
   unsigned intmq_msgsize_default;

+   /* next fields are for binder */
+   struct mutex  binder_procs_lock;
+   struct hlist_head binder_procs;
+   struct mutex  binder_contexts_lock;
+   struct hlist_head binder_contexts;


I don't think you want a mutex here protecting the binder_contexts list.
Afaict there is no concurrency going on: you only modify it in when doing
namespace init and exit (for which you have no serialization); do you even
need a lock here? Or at least I would think a more lightweight alternative
(rcu/spinlock/rwlock) would suffice.

Thanks,
Davidlohr

Re: [PATCH v6 1/3] arm64: dts: allwinner: a64: add nodes necessary for analog sound support

[Chen-Yu Tsai]

On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick  wrote:
>
> Add nodes for i2s, digital and analog parts of audiocodec on A64
>
> Signed-off-by: Vasily Khoruzhick 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++
>  1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index f3a66f888205..53796a3e6bf3 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -173,6 +173,34 @@
> compatible = "linux,spdif-dit";
> };
>
> +   sound: sound {
> +   compatible = "simple-audio-card";
> +   simple-audio-card,name = "sun50i-a64-audio";
> +   simple-audio-card,format = "i2s";
> +   simple-audio-card,frame-master = <&cpudai>;
> +   simple-audio-card,bitclock-master = <&cpudai>;
> +   simple-audio-card,mclk-fs = <512>;
> +   simple-audio-card,aux-devs = <&codec_analog>;
> +   simple-audio-card,routing =
> +   "Left DAC", "AIF1 Slot 0 Left",
> +   "Right DAC", "AIF1 Slot 0 Right",
> +   "AIF1 Slot 0 Left ADC", "Left ADC",
> +   "AIF1 Slot 0 Right ADC", "Right ADC",
> +   "Left ADC", "ADC",
> +   "Right ADC", "ADC",

The ADC widget is an overall enable control for the digital part of
the codec's ADC.
It is modeled as a supply widget in sun8i-codec. The routing should be internal
to sun8i-codec. See the following for the DAC routing:


https://elixir.bootlin.com/linux/v4.20-rc1/source/sound/soc/sunxi/sun8i-codec.c#L474

> +   "MIC1", "Mic",
> +   "MIC2", "Headset Mic";

Drop the last two. These belong at the board level. And as previously mentioned,
these two widgets from the sun8i-codec driver are bogus.

> +   status = "disabled";
> +
> +   cpudai: simple-audio-card,cpu {
> +   sound-dai = <&dai>;
> +   };
> +
> +   link_codec: simple-audio-card,codec {
> +   sound-dai = <&codec>;
> +   };
> +   };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts =  @@ -665,6 +693,30 @@
> status = "disabled";
> };
>
> +   dai: dai@1c22c00 {
> +   #sound-dai-cells = <0>;
> +   compatible = "allwinner,sun50i-a64-codec-i2s";
> +   reg = <0x01c22c00 0x200>;
> +   interrupts = ;
> +   clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +   clock-names = "apb", "mod";
> +   resets = <&ccu RST_BUS_CODEC>;
> +   reset-names = "rst";
> +   dmas = <&dma 15>, <&dma 15>;
> +   dma-names = "rx", "tx";
> +   status = "disabled";
> +   };
> +
> +   codec: codec@1c22e00 {
> +   #sound-dai-cells = <0>;
> +   compatible = "allwinner,sun8i-a33-codec";
> +   reg = <0x01c22e00 0x600>;
> +   interrupts = ;
> +   clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +   clock-names = "bus", "mod";
> +   status = "disabled";
> +   };
> +
> uart0: serial@1c28000 {
> compatible = "snps,dw-apb-uart";
> reg = <0x01c28000 0x400>;
> @@ -902,6 +954,12 @@
> #reset-cells = <1>;
> };
>
> +   codec_analog: codec-analog@1f015c0 {
> +   compatible = "allwinner,sun50i-a64-codec-analog";
> +   reg = <0x01f015c0 0x4>;
> +   status = "disabled";
> +   };
> +
> r_i2c: i2c@1f02400 {
> compatible = "allwinner,sun50i-a64-i2c",
>  "allwinner,sun6i-a31-i2c";
> --
> 2.19.1
>

Re: [PATCH] regulator: bd71837: add to fix build errors

[Matti Vaittinen]

Thanks Randy,

On Wed, Nov 07, 2018 at 08:38:50AM -0800, Randy Dunlap wrote:
> On 10/25/18 11:02 PM, Vaittinen, Matti wrote:
> > Hello,
> > 
> > From: Randy Dunlap 
> > 
> >> Fix build error due to missing header file:
> >>
> >> drivers/regulator/bd71837-regulator.c:242:3: error: implicit declaration 
> >> of function 'of_match_ptr' [-Werror=implicit-function-declaration]
> >>
> >> Fixes: ba08799e90b5 ("regulator: bd71837: BD71837 PMIC regulator driver")
> > 
> > //snip
> > 
> >> --- lnx-419.orig/drivers/regulator/bd71837-regulator.c
> >> +++ lnx-419/drivers/regulator/bd71837-regulator.c
> >> @@ -9,6 +9,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> > 
> > Not sure if this is relevant but if I am not mistaken this should already 
> > be fixed by: 
> > df43519eb706edfe951284a825642ce2e1d38d09 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df43519eb706edfe951284a825642ce2e1d38d09
> > 
> > 
> > Br,
> > Matti Vaittinen
> > 
> 
> Hi,
> 
> It seems that this same patch is now needed in
> drivers/regulator/bd718x7-regulator.c:

Noticed same thing. Few fixes seem to be lost when pickable ranges and bd71847
support was added. Sent this: 
https://lore.kernel.org/lkml/20181029121630.GA11183@localhost.localdomain/
to Mark few days ago. I guess this fix should end up in 4.20?

Br,
Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

Re: [PATCH stable 4.9] posix-timers: Sanitize overrun handling

[Thomas Gleixner]

Florian,

On Wed, 7 Nov 2018, Florian Fainelli wrote:
> On 11/1/18 1:02 PM, Florian Fainelli wrote:
> > From: Thomas Gleixner 
> > 
> > [ Upstream commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 ]
> > 
> > The posix timer overrun handling is broken because the forwarding functions
> > can return a huge number of overruns which does not fit in an int. As a
> > consequence timer_getoverrun(2) and siginfo::si_overrun can turn into
> > random number generators.
> > 
> > The k_clock::timer_forward() callbacks return a 64 bit value now. Make
> > k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal
> > accounting is correct. 3Remove the temporary (int) casts.
> > 
> > Add a helper function which clamps the overrun value returned to user space
> > via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value
> > between 0 and INT_MAX. INT_MAX is an indicator for user space that the
> > overrun value has been clamped.
> > 
> > Reported-by: Team OWL337 
> > Signed-off-by: Thomas Gleixner 
> > Acked-by: John Stultz 
> > Cc: Peter Zijlstra 
> > Cc: Michael Kerrisk 
> > Link: https://lkml.kernel.org/r/20180626132705.018623...@linutronix.de
> > [florian: Make patch apply to v4.9.135]
> > Signed-off-by: Florian Fainelli 
> > ---
> > Thomas, can you review for correctness? Thanks!
> 
> Thomas, John, does that look like a reasonable backport for 4.9?

Looks correct.

Thanks,

tglx

[tip:timers/urgent] posix-cpu-timers: Remove useless call to check_dl_overrun()

[tip-bot for Juri Lelli]

Commit-ID:  e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Gitweb: https://git.kernel.org/tip/e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Author: Juri Lelli 
AuthorDate: Wed, 7 Nov 2018 12:10:32 +0100
Committer:  Thomas Gleixner 
CommitDate: Thu, 8 Nov 2018 07:43:35 +0100

posix-cpu-timers: Remove useless call to check_dl_overrun()

check_dl_overrun() is used to send a SIGXCPU to users that asked to be
informed when a SCHED_DEADLINE runtime overruns occur.

The function is called by check_thread_timers() already, so the call in
check_process_timers() is redundant/wrong (even though harmless).

Remove it.

Fixes: 34be39305a77 ("sched/deadline: Implement "runtime overrun signal" 
support")
Signed-off-by: Juri Lelli 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt (VMware) 
Cc: linux-rt-us...@vger.kernel.org
Cc: mtk.manpa...@gmail.com
Cc: Mathieu Poirier 
Cc: Peter Zijlstra 
Cc: Luca Abeni 
Cc: Claudio Scordino 
Link: https://lkml.kernel.org/r/20181107111032.32291-1-juri.le...@redhat.com

---
 kernel/time/posix-cpu-timers.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index ce32cf741b25..8f0644af40be 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -917,9 +917,6 @@ static void check_process_timers(struct task_struct *tsk,
struct task_cputime cputime;
unsigned long soft;
 
-   if (dl_task(tsk))
-   check_dl_overrun(tsk);
-
/*
 * If cputimer is not running, then there are no active
 * process wide timers (POSIX 1.b, itimers, RLIMIT_CPU).

Re: [PATCH 3/5] ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC

[Bjorn Andersson]

On Wed 31 Oct 02:30 PDT 2018, Benjamin Gaignard wrote:

> Declare hwspinlock device for stm32mp157 SoC
> 
> Signed-off-by: Benjamin Gaignard 

Pending the clock-names question,

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm/boot/dts/stm32mp157c.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
> b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 185541a5b69f..9b16c28f8ac3 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -803,6 +803,15 @@
>   status = "disabled";
>   };
>  
> + hsem: hwspinlock@4c00 {
> + compatible = "st,stm32-hwspinlock";
> + #hwlock-cells = <1>;
> + reg = <0x4c00 0x400>;
> + clocks = <&rcc HSEM>;
> + clock-names = "hwspinlock";
> + status = "disabled";
> + };
> +
>   rcc: rcc@5000 {
>   compatible = "st,stm32mp1-rcc", "syscon";
>   reg = <0x5000 0x1000>;
> -- 
> 2.15.0
> 

[PATCH v2] ext4: missing !bh check in ext4_xattr_inode_write()

[Vasily Averin]

According to Ted Ts'o ext4_getblk() called in ext4_xattr_inode_write()
should not return bh = NULL

The only time that bh could be NULL, then, would be in the case of
something really going wrong; a programming error elsewhere (perhaps a
wild pointer dereference) or I/O error causing on-disk file system
corruption (although that would be highly unlikely given that we had
*just* allocated the blocks and so the metadata blocks in question
probably would still be in the cache).

Fixes e50e5129f384 ("ext4: xattr-in-inode support")
Cc: sta...@kernel.org # 4.13

Signed-off-by: Vasily Averin 
---
 fs/ext4/xattr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 0b9688683526..415f73d4c9e6 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1384,6 +1384,12 @@ static int ext4_xattr_inode_write(handle_t *handle, 
struct inode *ea_inode,
bh = ext4_getblk(handle, ea_inode, block, 0);
if (IS_ERR(bh))
return PTR_ERR(bh);
+   if (!bh) {
+   WARN_ON_ONCE(1);
+   __ext4_error_inode(ea_inode, __func__, __LINE__, 0,
+  "ext4_getblk() return bh = NULL");
+   return -EFSCORRUPTED;
+   }
ret = ext4_journal_get_write_access(handle, bh);
if (ret)
goto out;
-- 
2.17.1

Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD

[Michal Simek]

On 07. 11. 18 18:48, Nick Desaulniers wrote:
> On Wed, Nov 7, 2018 at 1:01 AM Michal Simek  wrote:
>>
>> On 07. 11. 18 9:55, Nathan Chancellor wrote:
>>> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
 On 01. 11. 18 1:57, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion from
> enumeration type 'enum zynq_pin_config_param' to different enumeration
> type 'enum pin_config_param' [-Wenum-conversion]
> {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
> ~   ^
> drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion from
> enumeration type 'enum zynq_pin_config_param' to different enumeration
> type 'enum pin_config_param' [-Wenum-conversion]
> = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
> ~~^
> ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
> macro 'PCONFDUMP'
> .param = a, .display = b, .format = c, .has_arg = d \
>  ^
> 2 warnings generated.

 This is interesting. I have never tried to use llvm for building the
 kernel. Do you have any description how this can be done?

>>>
>>> Depending on what version of Clang you have access to, it is usually just as
>>> simple as running 'make ARCH=arm CC=clang CROSS_COMPILE=arm-linux-gnueabi-'.
>>>
>>> Clang 7.0+ is recommended but 6.0 might work too.
>>
>> TBH I would expect to download container and run this there to make sure
>> that I don't break anything else.
> 
> This is the first request we've had for a container in order to test a
> patch.  If it comes up again from other folks, I think it makes sense
> to create one.  Until then, its nice to have.  It's definitely
> overkill for this patch.

I have played with it to see that error and here are some steps I did.

docker run --name test-clang -it --rm debian:latest bash
apt-get update
apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
build-essential bison flex make llvm vim libssl-dev sparse

git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth 1
cd linux

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-

make defconfig
make CC=clang drivers/pinctrl/pinctrl-zynq.o C=1 V=1

There was not a problem to run it for arm64 but I had issues to run this
for arm32.
Do you see any problem with above steps?

Thanks,
Michal

Re: [PATCH 1/5] dt-bindings: hwlock: Document STM32 hwspinlock bindings

[Bjorn Andersson]

On Wed 31 Oct 02:30 PDT 2018, Benjamin Gaignard wrote:

> Add bindings for STM32 hardware spinlock device
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  .../bindings/hwlock/st,stm32-hwspinlock.txt| 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.txt 
> b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.txt
> new file mode 100644
> index ..7a999479d802
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.txt
> @@ -0,0 +1,23 @@
> +STM32 Hardware Spinlock Device Binding
> +-
> +
> +Required properties :
> +- compatible : should be "st,stm32-hwspinlock".
> +- reg : the register address of hwspinlock.
> +- #hwlock-cells : hwlock users only use the hwlock id to represent a specific
> + hwlock, so the number of cells should be <1> here.
> +- clock-names : Must contain "hwspinlock".

This is supposed to be the name of the clock signal of this hardware
block, is it really named "hwspinlock"? Note that you can probably omit
the clock-names property, as you only have a single clock...

Apart from that, I think the binding looks good.

Regards,
Bjorn

> +- clocks : Must contain a phandle entry for the clock in clock-names, see the
> + common clock bindings.
> +
> +Please look at the generic hwlock binding for usage information for 
> consumers,
> +"Documentation/devicetree/bindings/hwlock/hwlock.txt"
> +
> +Example of hwlock provider:
> + hwspinlock@4c00 {
> + compatible = "st,stm32-hwspinlock";
> + #hwlock-cells = <1>;
> + reg = <0x4c00 0x400>;
> + clocks = <&rcc HSEM>;
> + clock-names = "hwspinlock";
> + };
> -- 
> 2.15.0
> 

[PATCH] regulator: as3711: convert to SPDX identifiers

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch updates license to use SPDX-License-Identifier
instead of verbose license text.

Signed-off-by: Kuninori Morimoto 
---
 drivers/regulator/as3711-regulator.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/regulator/as3711-regulator.c 
b/drivers/regulator/as3711-regulator.c
index 565a713..f7fe218 100644
--- a/drivers/regulator/as3711-regulator.c
+++ b/drivers/regulator/as3711-regulator.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * AS3711 PMIC regulator driver, using DCDC Step Down and LDO supplies
  *
  * Copyright (C) 2012 Renesas Electronics Corporation
  * Author: Guennadi Liakhovetski, 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the version 2 of the GNU General Public License as
- * published by the Free Software Foundation
  */
 
 #include 
-- 
2.7.4

[PATCH] regulator: bd9571mwv: convert to SPDX identifiers

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch updates license to use SPDX-License-Identifier
instead of verbose license text.

Signed-off-by: Kuninori Morimoto 
---
 drivers/regulator/bd9571mwv-regulator.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index 274c5ed..e12dd1f 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -1,17 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ROHM BD9571MWV-M regulator driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether expressed or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License version 2 for more details.
- *
  * Based on the TPS65086 driver
  *
  * NOTE: VD09 is missing
-- 
2.7.4

Re: [PATCH 2/5] hwspinlock: add STM32 hwspinlock device

[Bjorn Andersson]

On Wed 31 Oct 02:30 PDT 2018, Benjamin Gaignard wrote:
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index e895d29500ee..e1a20b460590 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -59,3 +59,12 @@ config HSEM_U8500
> SoC.
>  
> If unsure, say N.
> +
> +config HWSPINLOCK_STM32

Please keep these alphabetically sorted.

> + tristate "STM32 Hardware Spinlock device"
> + depends on MACH_STM32MP157
> + depends on HWSPINLOCK
> + help
> +   Say y here to support the STM32 Hardware Spinlock device.
> +
> +   If unsure, say N.
> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> index b87c01a506a4..c0a9505b4dcf 100644
> --- a/drivers/hwspinlock/Makefile
> +++ b/drivers/hwspinlock/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_HWSPINLOCK_QCOM) += qcom_hwspinlock.o
>  obj-$(CONFIG_HWSPINLOCK_SIRF)+= sirf_hwspinlock.o
>  obj-$(CONFIG_HWSPINLOCK_SPRD)+= sprd_hwspinlock.o
>  obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
> +obj-$(CONFIG_HWSPINLOCK_STM32)   += stm32_hwspinlock.o

Ditto.

> diff --git a/drivers/hwspinlock/stm32_hwspinlock.c 
> b/drivers/hwspinlock/stm32_hwspinlock.c
> new file mode 100644
> index ..6a0fafac7389
> --- /dev/null
> +++ b/drivers/hwspinlock/stm32_hwspinlock.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics SA 2018
> + * Author: Benjamin Gaignard  for 
> STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2

Didn't you already state your license terms with the SPDX header above?

> + */
[..]
> +static int stm32_hwspinlock_remove(struct platform_device *pdev)
> +{
> + struct stm32_hwspinlock *hw = platform_get_drvdata(pdev);
> + int ret;
> +
> + ret = hwspin_lock_unregister(&hw->bank);
> + if (ret) {
> + dev_err(&pdev->dev, "%s failed: %d\n", __func__, ret);
> + return ret;

The return value of platform_device is ignored, so printing an error
message is fine, but don't "abort".

> + }
> +
> + pm_runtime_disable(&pdev->dev);
> +
> + return 0;
> +}

Regards,
Bjorn

Re: [PATCH v8] clk: qcom: Add lpass clock controller driver for SDM845

[Taniya Das]

Thanks Stephen.

On 11/6/2018 10:46 PM, Stephen Boyd wrote:

Quoting Taniya Das (2018-11-02 20:16:20)

On 11/2/2018 10:08 PM, Stephen Boyd wrote:

Quoting Taniya Das (2018-10-28 00:35:40)



How about moving the QSPI clocks too under this qcom property? Later
could add the support?


Yes the plan would be to have QSPI clks there too. Bjorn has sent the
patch now.

  https://lkml.kernel.org/r/20181106055013.11271-1-bjorn.anders...@linaro.org

Would you be merging the code soon and then I should submit the cleaned 
up LPASS next series?


Please suggest.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

[PATCH v6 1/3] arm64: dts: allwinner: a64: add nodes necessary for analog sound support

[Vasily Khoruzhick]

Add nodes for i2s, digital and analog parts of audiocodec on A64

Signed-off-by: Vasily Khoruzhick 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f3a66f888205..53796a3e6bf3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -173,6 +173,34 @@
compatible = "linux,spdif-dit";
};
 
+   sound: sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "sun50i-a64-audio";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,frame-master = <&cpudai>;
+   simple-audio-card,bitclock-master = <&cpudai>;
+   simple-audio-card,mclk-fs = <512>;
+   simple-audio-card,aux-devs = <&codec_analog>;
+   simple-audio-card,routing =
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right",
+   "AIF1 Slot 0 Left ADC", "Left ADC",
+   "AIF1 Slot 0 Right ADC", "Right ADC",
+   "Left ADC", "ADC",
+   "Right ADC", "ADC",
+   "MIC1", "Mic",
+   "MIC2", "Headset Mic";
+   status = "disabled";
+
+   cpudai: simple-audio-card,cpu {
+   sound-dai = <&dai>;
+   };
+
+   link_codec: simple-audio-card,codec {
+   sound-dai = <&codec>;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
+   compatible = "allwinner,sun50i-a64-codec-i2s";
+   reg = <0x01c22c00 0x200>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+   clock-names = "apb", "mod";
+   resets = <&ccu RST_BUS_CODEC>;
+   reset-names = "rst";
+   dmas = <&dma 15>, <&dma 15>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   codec: codec@1c22e00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun8i-a33-codec";
+   reg = <0x01c22e00 0x600>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+   clock-names = "bus", "mod";
+   status = "disabled";
+   };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -902,6 +954,12 @@
#reset-cells = <1>;
};
 
+   codec_analog: codec-analog@1f015c0 {
+   compatible = "allwinner,sun50i-a64-codec-analog";
+   reg = <0x01f015c0 0x4>;
+   status = "disabled";
+   };
+
r_i2c: i2c@1f02400 {
compatible = "allwinner,sun50i-a64-i2c",
 "allwinner,sun6i-a31-i2c";
-- 
2.19.1

[PATCH v6 0/3] Add support for audiocodec in Allwinner A64

[Vasily Khoruzhick]

This series enables sound on Pine64, SoPine boards and Pinebook.

v2: - Use simple-amplifier for speaker amp on Pinebook
- Rename sun50i-a64-i2s to sun50i-a64-codec-i2s to preserve compatible
  string for other 3 I2S modules in A64 in case if there's any
  incompatibility with H3
v3: - renamed sunxi-adda-pr-regmap to sun8i-adda-pr-regmap
- use ilog2() to calculate reg value for LRCK div instead of using a
  table
v4: - dts: don't use 'Mic' and 'Headset Mic' widgets from sun8i-codec,
  define our board-level widgets instead.
v5: - collect all the tags
v6: - driver patches has been merged through ASoC tree
- rebase onto 4.20-rc1
- Drop 'Speaker' from routes on sopine and pine64, they don't have
  speaker.

Vasily Khoruzhick (3):
  arm64: dts: allwinner: a64: add nodes necessary for analog sound
support
  arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
  arm64: dts: allwinner: a64: enable sound on Pinebook

 .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 28 +
 .../dts/allwinner/sun50i-a64-pinebook.dts | 42 ++
 .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++
 4 files changed, 156 insertions(+)

-- 
2.19.1

[PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook

[Vasily Khoruzhick]

This commit enables I2S, digital and analog parts of audiocodec on
Pinebook

Signed-off-by: Vasily Khoruzhick 
---
 .../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index 77fac84797e9..73f171f4ba9b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -64,6 +64,23 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
+
+   speaker_amp: speaker_amp {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   };
+};
+
+&codec {
+   status = "okay";
+};
+
+&codec_analog {
+   status = "okay";
+};
+
+&dai {
+   status = "okay";
 };
 
 &ehci0 {
@@ -267,6 +284,31 @@
vcc-hdmi-supply = <®_dldo1>;
 };
 
+&sound {
+   status = "okay";
+   simple-audio-card,widgets = "Microphone", "Internal Microphone Left",
+   "Microphone", "Internal Microphone Right",
+   "Headphone", "Headphone Jack",
+   "Speaker", "Internal Speaker";
+   simple-audio-card,aux-devs = <&codec_analog>, <&speaker_amp>;
+   simple-audio-card,routing =
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right",
+   "INL", "LINEOUT",
+   "INR", "LINEOUT",
+   "Internal Speaker", "OUTL",
+   "Internal Speaker", "OUTR",
+   "Headphone Jack", "HP",
+   "AIF1 Slot 0 Left ADC", "Left ADC",
+   "AIF1 Slot 0 Right ADC", "Right ADC",
+   "Left ADC", "ADC",
+   "Right ADC", "ADC",
+   "Internal Microphone Left", "MBIAS",
+   "MIC1", "Internal Microphone Left",
+   "Internal Microphone Right", "HBIAS",
+   "MIC2", "Internal Microphone Right";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
-- 
2.19.1

[PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine

[Vasily Khoruzhick]

This commit enables I2S, digital and analog parts of audiocodec on
Pine64 and SoPine boards.

Signed-off-by: Vasily Khoruzhick 
---
 .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 28 +++
 .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
 2 files changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c077b6c1f458..ff352bdfbb93 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -75,6 +75,18 @@
};
 };
 
+&codec {
+   status = "okay";
+};
+
+&codec_analog {
+   status = "okay";
+};
+
+&dai {
+   status = "okay";
+};
+
 &de {
status = "okay";
 };
@@ -264,6 +276,22 @@
status = "disabled";
 };
 
+&sound {
+   status = "okay";
+   simple-audio-card,widgets = "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack";
+   simple-audio-card,routing =
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right",
+   "Headphone Jack", "HP",
+   "AIF1 Slot 0 Left ADC", "Left ADC",
+   "AIF1 Slot 0 Right ADC", "Right ADC",
+   "Left ADC", "ADC",
+   "Right ADC", "ADC",
+   "Microphone Jack", "HBIAS",
+   "MIC2", "Microphone Jack";
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index 53fcc9098df3..25d732df37c4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -80,6 +80,18 @@
};
 };
 
+&codec {
+   status = "okay";
+};
+
+&codec_analog {
+   status = "okay";
+};
+
+&dai {
+   status = "okay";
+};
+
 &de {
status = "okay";
 };
@@ -164,6 +176,22 @@
vcc-hdmi-supply = <®_dldo1>;
 };
 
+&sound {
+   status = "okay";
+   simple-audio-card,widgets = "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack";
+   simple-audio-card,routing =
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right",
+   "Headphone Jack", "HP",
+   "AIF1 Slot 0 Left ADC", "Left ADC",
+   "AIF1 Slot 0 Right ADC", "Right ADC",
+   "Left ADC", "ADC",
+   "Right ADC", "ADC",
+   "Microphone Jack", "HBIAS",
+   "MIC2", "Microphone Jack";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
-- 
2.19.1

Re: donated proposal

[MUSEO_BERSAGLIERI, AOO]

Good news $1,000,000.00 has been donated to you contact (2244108...@qq.com) for 
details.

- Messaggio originale -
Da: MUSEO_BERSAGLIERI, AOO 
A: aoo museo_bersaglieri 
Inviato: Wed, 07 Nov 2018 17:18:26 +0100 (CET)
Oggetto: donated  proposal

Re: [PATCH] dpaa_eth: add ethtool coalesce control

[David Miller]

From: Madalin Bucur 
Date: Wed,  7 Nov 2018 15:53:43 +0200

> +static int dpaa_set_coalesce(struct net_device *dev,
> +  struct ethtool_coalesce *c)
> +{
> + const cpumask_t *cpus = qman_affine_cpus();
> + struct qman_portal *portal;
> + u32 period;
> + u8 thresh;
> + int cpu;
> +
> + period = c->rx_coalesce_usecs;
> + thresh = c->rx_max_coalesced_frames;
> +
> + for_each_cpu(cpu, cpus) {
> + portal = qman_get_affine_portal(cpu);
> + qman_portal_set_iperiod(portal, period);
> + qman_dqrr_set_ithresh(portal, thresh);
> + }

You really have to check to see if the user is trying to configure
a setting you don't support, for example if the user tries
to set ->use_adative_rx_coalesce or uses a period or threshold
value which is out of range.

Thanks.

Re: [RFC PATCH v1 2/2] proc: add /proc//thread_state

[Ingo Molnar]

* Aubrey Li  wrote:

> Expose the per-task cpu specific thread state value, it's helpful
> for userland to classify and schedule the tasks by different policies

That's pretty vague - what exactly would use this information? I'm sure 
you have a usecase in mind - could you please describe it?

Thanks,

Ingo

Re: [PATCH V2] binder: ipc namespace support for android binder

[Davidlohr Bueso]

On Wed, 07 Nov 2018, Bueso wrote:


On Mon, 29 Oct 2018, chouryzhou(??) wrote:


+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.


/*
* comments like this please
*/


Actually, just drop the comment altogether. Forward declaring does not merit it.

Thanks,
Davidlohr

[RESEND PATCH V7 2/3] dt-bindings: input: Add document bindings for DA7280

[Roy Im]

Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.

Reviewed-by: Rob Herring .

Signed-off-by: Roy Im 

---
v7: No changes.
v6: No changes.
v5: Updated descriptions and fixed errors.
v4: Fixed commit message, properties.
v3: Fixed subject format.
v2: No changes


 .../devicetree/bindings/input/dlg,da7280.txt   |  105 
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt

diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt 
b/Documentation/devicetree/bindings/input/dlg,da7280.txt
new file mode 100644
index 000..a25a12f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.txt
@@ -0,0 +1,105 @@
+Dialog Semiconductor DA7280 Haptics bindings
+
+Required properties:
+- compatible: Should be "dlg,da7280".
+- reg: Specifies the I2C slave address.
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to
+  which the IRQs from DA7280 are delivered to.
+
+- dlg,actuator-type: Set Actuator type. it should be one of:
+  "LRA" - Linear Resonance Actuator type.
+  "ERM-bar" - Bar type Eccentric Rotating Mass.
+  "ERM-coin" - Coin type Eccentric Rotating Mass.
+
+- dlg,op-mode: Haptic operation mode.
+  Possible values:
+   1 - Direct register override(DRO) mode triggered by i2c(default),
+   2 - PWM data source mode controlled by PWM duty,
+   3 - Register triggered waveform memory(RTWM) mode, the pattern
+   assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP,
+   4 - Edge triggered waveform memory(ETWM) mode, external GPI(N)
+   control are required to enable/disable and it needs to keep
+   device enabled by sending magnitude (X > 0),
+   the pattern is assigned to the GPI(N)_SEQUENCE_ID below.
+   For more details, please see the datasheet.
+
+- dlg,nom-microvolt: Nominal actuator voltage rating.
+  Valid values: 0 - 600.
+- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
+  Valid values: 0 - 600.
+- dlg,imax-microamp: Actuator max current rating.
+  Valid values: 0 - 252000.
+  Default: 13.
+- dlg,impd-micro-ohms: the impedance of the actuator in micro ohms.
+  Valid values: 0 - 15.
+
+Optional properties:
+- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
+  PWM properties should be named "pwms". And number of cell is different
+  for each pwm device.
+  (See Documentation/devicetree/bindings/pwm/pwm.txt
+   for further information relating to pwm properties)
+
+- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
+  to play back when RTWM-MODE is enabled.
+  Valid range: 0 - 15.
+- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
+  pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
+  Valid range: 0 - 15.
+- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
+  when gpi0 is triggered, 'N' must be 0 - 2.
+  Valid range: 0 - 15.
+- dlg,gpiN-mode: the pattern mode which can select either
+  "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2.
+- dlg,gpiN-polarity: gpiN polarity which can be chosen among
+  "Rising-edge", "Falling-edge" and "Both-edge",
+  'N' must be 0 - 2
+  Haptic will work by this edge option in case of ETWM mode.
+
+- dlg,resonant-freq-hz: use in case of LRA.
+  the frequency range: 50 - 300.
+  Default: 205.
+
+- dlg,bemf-sens-enable: Enable for internal loop computations.
+- dlg,freq-track-enable: Enable for resonant frequency tracking.
+- dlg,acc-enable: Enable for active acceleration.
+- dlg,rapid-stop-enable: Enable for rapid stop.
+- dlg,amp-pid-enable: Enable for the amplitude PID.
+- dlg,mem-array: Customized waveform memory(patterns) data downloaded to
+  the device during initialization. This is an array of 100 values(u8).
+
+For further information, see device datasheet.
+
+==
+
+Example:
+
+   haptics: da7280-haptics@4a {
+   compatible = "dlg,da7280";
+   reg = <0x4a>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+   dlg,actuator-type = "LRA";
+   dlg,op-mode = <1>;
+   dlg,nom-microvolt = <200>;
+   dlg,abs-max-microvolt = <200>;
+   dlg,imax-microamp = <17>;
+   dlg,resonant-freq-hz = <180>;
+   dlg,impd-micro-ohms = <1050>;
+   dlg,freq-track-enable;
+   dlg,rapid-stop-enable;
+   dlg,mem-array = <
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0

[RESEND PATCH V7 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms

[Roy Im]

This patch adds the da7280 bindings doc and driver to the Dialog
Semiconductor support list.

Signed-off-by: Roy Im 

---
v7: No changes.
v6: No changes.
v5: No changes.
v4: No changes.
v3: No changes.
v2: No changes.


 MAINTAINERS |2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b22e7fd..1af587f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4313,6 +4313,7 @@ S:Supported
 F: Documentation/hwmon/da90??
 F: Documentation/devicetree/bindings/mfd/da90*.txt
 F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/input/dlg,da72??.txt
 F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
 F: Documentation/devicetree/bindings/regulator/da92*.txt
 F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt
@@ -4321,6 +4322,7 @@ F:drivers/gpio/gpio-da90??.c
 F: drivers/hwmon/da90??-hwmon.c
 F: drivers/iio/adc/da91??-*.c
 F: drivers/input/misc/da90??_onkey.c
+F: drivers/input/misc/da72??.[ch]
 F: drivers/input/touchscreen/da9052_tsi.c
 F: drivers/leds/leds-da90??.c
 F: drivers/mfd/da903x.c
-- 
end-of-patch for RESEND PATCH V7

[RESEND PATCH V7 3/3] Input: new da7280 haptic driver

[Roy Im]

Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.

Signed-off-by: Roy Im 

---
v7: 
- Added more attributes to handle one value per file.
- Replaced and updated the dt-related code and functions called.
- Fixed error/functions.
- Rebased to v4.19-rc6.
v6: No changes.
v5: Fixed errors in Kconfig file.
v4: Updated code as dt-bindings are changed.
v3: No changes.
v2: Fixed kbuild error/warning


 drivers/input/misc/Kconfig  |   13 +
 drivers/input/misc/Makefile |1 +
 drivers/input/misc/da7280.c | 1409 +++
 drivers/input/misc/da7280.h |  412 +
 4 files changed, 1835 insertions(+)
 create mode 100644 drivers/input/misc/da7280.c
 create mode 100644 drivers/input/misc/da7280.h

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..751cac6 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,17 @@ config INPUT_SC27XX_VIBRA
  To compile this driver as a module, choose M here. The module will
  be called sc27xx_vibra.
 
+config INPUT_DA7280_HAPTICS
+   tristate "Dialog Semiconductor DA7280 haptics support"
+   depends on INPUT && I2C
+   select INPUT_FF_MEMLESS
+   select REGMAP_I2C
+   help
+ Say Y to enable support for the Dialog DA7280 haptics driver.
+ The haptics can be controlled by i2c communication,
+ or by PWM input, or by GPI.
+
+ To compile this driver as a module, choose M here: the
+ module will be called da7280.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..d941348 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000)   += cma3000_d0x.o
 obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o
 obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
 obj-$(CONFIG_INPUT_CPCAP_PWRBUTTON)+= cpcap-pwrbutton.o
+obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o
 obj-$(CONFIG_INPUT_DA9052_ONKEY)   += da9052_onkey.o
 obj-$(CONFIG_INPUT_DA9055_ONKEY)   += da9055_onkey.o
 obj-$(CONFIG_INPUT_DA9063_ONKEY)   += da9063_onkey.o
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
new file mode 100644
index 000..b1072ef
--- /dev/null
+++ b/drivers/input/misc/da7280.c
@@ -0,0 +1,1409 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DA7280 Haptic device driver
+ *
+ * Copyright (c) 2018 Dialog Semiconductor.
+ * Author: Roy Im 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "da7280.h"
+
+/* uV unit for voltage rate */
+#define DA7280_VOLTAGE_RATE_MAX600
+#define DA7280_VOLTAGE_RATE_STEP   23400
+#define DA7280_NOMMAX_DFT  0x6B
+#define DA7280_ABSMAX_DFT  0x78
+
+#define DA7280_IMPD_MAX15
+#define DA7280_IMPD_DEFAULT2200
+
+#define DA7280_IMAX_DEFAULT0x0E
+/* uA unit step and limit for IMAX*/
+#define DA7280_IMAX_STEP   7200
+#define DA7280_IMAX_LIMIT  252000
+
+#define DA7280_RESONT_FREQH_DFT0x39
+#define DA7280_RESONT_FREQL_DFT0x32
+#define DA7280_MIN_RESONAT_FREQ_HZ 50
+#define DA7280_MAX_RESONAT_FREQ_HZ 300
+#define DA7280_MIN_PWM_FREQ_KHZ10
+#define DA7280_MAX_PWM_FREQ_KHZ250
+
+#define DA7280_SEQ_ID_MAX  15
+#define DA7280_SEQ_LOOP_MAX15
+#define DA7280_GPI1_SEQ_ID_DEFT0x0
+
+#define DA7280_SNP_MEM_SIZE100
+#define DA7280_SNP_MEM_MAX DA7280_SNP_MEM_99
+
+#define IRQ_NUM3
+
+#define DA7280_SKIP_INIT   0x100
+
+enum da7280_haptic_dev_t {
+   DA7280_LRA  = 0,
+   DA7280_ERM_BAR  = 1,
+   DA7280_ERM_COIN = 2,
+   DA7280_DEV_MAX,
+};
+
+enum da7280_op_mode {
+   DA7280_INACTIVE = 0,
+   DA7280_DRO_MODE = 1,
+   DA7280_PWM_MODE = 2,
+   DA7280_RTWM_MODE= 3,
+   DA7280_ETWM_MODE= 4,
+   DA7280_OPMODE_MAX,
+};
+
+struct da7280_gpi_ctl {
+   u8 seq_id;
+   u8 mode;
+   u8 polarity;
+};
+
+struct da7280_haptic {
+   struct regmap *regmap;
+   struct input_dev *input_dev;
+   struct device *dev;
+   struct i2c_client *client;
+   struct pwm_device *pwm_dev;
+   boollegacy;
+   int pwm_id;
+   struct work_struct work;
+
+   unsigned int magnitude;
+
+   u8 dev_type;
+   u8 op_mode;
+   u16 nommax;
+   u16 absmax;
+   u32 imax;
+   u32 impd;
+   u32 resonant_freq_h;
+   u32 resonant_freq_l;
+   bool bemf_sense_en;
+   bool freq_track_en;
+   bool acc_en;
+   bool 

Re: [RFC PATCH 4/5] mm, memory_hotplug: print reason for the offlining failure

[Anshuman Khandual]

On 11/07/2018 03:48 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> The memory offlining failure reporting is inconsistent and insufficient.
> Some error paths simply do not report the failure to the log at all.
> When we do report there are no details about the reason of the failure
> and there are several of them which makes memory offlining failures
> hard to debug.
> 
> Make sure that the
>   memory offlining [mem %#010llx-%#010llx] failed
> message is printed for all failures and also provide a short textual
> reason for the failure e.g.
> 
> [ 1984.506184] rac1 kernel: memory offlining [mem 
> 0x826-0x8267fff] failed due to signal backoff
> 
> this tells us that the offlining has failed because of a signal pending
> aka user intervention.
> 
> Signed-off-by: Michal Hocko 

It might help to enumerate these failure reason strings and use macros.

[RESEND PATCH V7 0/3] da7280: haptic driver submission

[Roy Im]

This patch adds support for the Dialog DA7280 Haptic driver IC.

In this patch set the following is provided:

[PATCH V7 1/3] MAINTAINERS file update for DA7280
[PATCH V7 2/3] DA7280 DT Binding
[PATCH V7 3/3] DA7280 Driver

This patch applies against linux-next and v4.19-rc6

Thank you,
Roy Im, Dialog Semiconductor Ltd.

Roy Im (3):
  MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms
  dt-bindings: input: Add document bindings for DA7280
  Input: new da7280 haptic driver

 .../devicetree/bindings/input/dlg,da7280.txt   |  105 ++
 MAINTAINERS|2 +
 drivers/input/misc/Kconfig |   13 +
 drivers/input/misc/Makefile|1 +
 drivers/input/misc/da7280.c| 1409 
 drivers/input/misc/da7280.h|  412 ++
 6 files changed, 1942 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt
 create mode 100644 drivers/input/misc/da7280.c
 create mode 100644 drivers/input/misc/da7280.h

-- 
end-of-patch for RESEND PATCH V7

Re: [PATCH] scripts/spdxcheck: make python3 compliant

[Uwe Kleine-König]

Hello Andrew,

On Wed, Nov 07, 2018 at 03:32:51PM -0800, Andrew Morton wrote:
> On Tue, 23 Oct 2018 09:08:02 +0200 Uwe Kleine-König 
>  wrote:
> 
> > Without this change the following happens when using Python3 (3.6.6):
> > 
> > $ echo "GPL-2.0" | python3 scripts/spdxcheck.py -
> > FAIL: 'str' object has no attribute 'decode'
> > Traceback (most recent call last):
> >   File "scripts/spdxcheck.py", line 253, in 
> > parser.parse_lines(sys.stdin, args.maxlines, '-')
> >   File "scripts/spdxcheck.py", line 171, in parse_lines
> > line = line.decode(locale.getpreferredencoding(False), 
> > errors='ignore')
> > AttributeError: 'str' object has no attribute 'decode'
> > 
> > So as the line is already a string, there is no need to decode it and
> > the line can be dropped.
> 
> I suppose people might want to run spdxcheck.py against (say) 4.19.x
> using python3.  So I'll add a cc:stable here, OK?

Not sure if people call spdxcheck.py stand-alone. checkpatch.pl calls it
using "python scripts/spdxcheck.py" which AFAICT should still be python2
on all machines. The shebang-line also uses "python" and not "python3".

So for now this is only cosmetic (unless there are distros that install
Python 3 as "python").

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH V2] binder: ipc namespace support for android binder

[Davidlohr Bueso]

On Mon, 29 Oct 2018, chouryzhou(??) wrote:


+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.


/*
* comments like this please
*/


+#if !defined(CONFIG_SYSVIPC) &&  !defined(CONFIG_POSIX_MQUEUE)
+struct ipc_namespace init_ipc_ns;

...

--- a/include/linux/ipc_namespace.h
+++ b/include/linux/ipc_namespace.h
@@ -63,6 +63,12 @@ struct ipc_namespace {
   unsigned intmq_msg_default;
   unsigned intmq_msgsize_default;

+   /* next fields are for binder */
+   struct mutex  binder_procs_lock;
+   struct hlist_head binder_procs;
+   struct mutex  binder_contexts_lock;
+   struct hlist_head binder_contexts;


Please make the above inside #ifdef CONFIG_ANDROID_BINDER_IPC.

Thanks,
Davidlohr

Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline asm

[Nadav Amit]

From: h...@zytor.com
Sent: November 7, 2018 at 9:50:28 PM GMT
> To: Logan Gunthorpe , Nadav Amit , 
> Ingo Molnar 
> Cc: LKML , X86 ML , Sam 
> Ravnborg , Michal Marek , Thomas 
> Gleixner , Linux Kbuild mailing list 
> , Stephen Bates 
> Subject: Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline 
> asm
> 
> 
> On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe  
> wrote:
>> On 2018-11-07 11:56 a.m., Nadav Amit wrote:
>>> HPA indicated more than once that this is wrong (and that was indeed
>> my
>>> initial solution), since it is not guaranteed that the compiler would
>> put
>>> the macro assembly before its use.
>> 
>> Hmm, that's very unfortunate. I don't really understand why the
>> compiler
>> would not put the macro assembly in the same order as it appears in the
>> code and it would be in the correct order there.
>> 
>> In any case, I've submitted a couple of issues to icecc[1] and
>> distcc[2]
>> to see if they have any ideas about supporting this on their sides.
>> 
>> Thanks,
>> 
>> Logan
>> 
>> [1] 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ficecc%2Ficecream%2Fissues%2F428&data=02%7C01%7Cnamit%40vmware.com%7C30ab3751343b49f869ab08d644fb1d8c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636772242666772528&sdata=dXKTR79LkFDQ9IXxYw9XYt0VPFa4MXrMUcc86w5uy%2Fk%3D&reserved=0
>> [2] 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdistcc%2Fdistcc%2Fissues%2F312&data=02%7C01%7Cnamit%40vmware.com%7C30ab3751343b49f869ab08d644fb1d8c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636772242666772528&sdata=XynZ1bFbKAb8V2eoPQbXudEJ%2B%2Bu8QA3mM4Sr4E%2FTzWs%3D&reserved=0
> 
> Apparently gcc will treat them like basic blocks and possibly move them 
> around.

Maybe it is possible to break the compilation of each object into two
stages: first, compile the source without assembly, and then take the
generated .s file and assemble it with the .s file of the macros.

Does it sounds as something that may work? I guess it should only be done
when distcc is used.

Re: [PATCH] KVM/VMX: Check ept_pointer before flushing ept tlb

[Tianyu Lan]

On 11/7/2018 6:49 PM, Vitaly Kuznetsov wrote:

Tianyu Lan  writes:


Hi Vitaly:
Thanks for your review.

On 11/6/2018 11:50 PM, Vitaly Kuznetsov wrote:

ltyker...@gmail.com writes:


From: Lan Tianyu 

This patch is to initialize ept_pointer to INVALID_PAGE and check it
before flushing ept tlb. If ept_pointer is invalidated, bypass the flush
request.



To be honest I fail to understand the reason behind the patch: instead
of doing one unneeded flush request with ept_pointer==0 (after vCPU is
initialized) we now do the check every time. Could you please elaborate
on why this is needed?


The reason to introduce the check here is to avoid flushing ept tlb
without valid ept table. When nested guest boots up and only BP is
active, we should not do flush for APs and L1 hypervisor hasn't set
valid EPT table for APs.


Yes, I understand that but I'm trying to avoid additional checks on
hotpath as during normal operation EPT pointer is always set.

Could we just initialize ept_pointers_match to something like
EPT_POINTERS_NOTSET and achive the same result?


vmx->ept_pointers_match presents match status of all vcpus' ept table. 
EPT_POINTER_NOSET should be per cpu status and so I select ept_pointer 
as check condition.


BTW, I think we may remove the check for match case which is normal 
status and all ept pointers should be set at that point. Mismatch status 
should be corner case when VM runs and this will not affect a lot.

Re: [PATCH RFC] hist lookups

[David Miller]

From: Arnaldo Carvalho de Melo 
Date: Wed, 7 Nov 2018 17:28:15 -0300

> So perhaps we should tell the kernel that is ok to lose SAMPLEs but not
> the other events, and make userspace ask for PERF_RECORD_!SAMPLE in all
> ring buffers? Duplication wouldn't be that much of a problem?

I think we should strive to keep the policy in userspace.

The kernel simply provides the events that happen, and the user's
job is to take the events in sort of a "high priority interrupt"
context and push the slow path processing to a separate thread of
execution where drop policy can be implemented.

Jiri's work provides a framework for exactly that.

So what we can have is:

cpu1  cpu2  cpu3  cpu4  cpu5  cpu6 ... cpuN
| | | | | ||

  |
  |
  | single event ring buffer
  |
  |
ultra-fast perf event dequeue
 queues in-order to event processing
  |
  event processing slow path
prioritization and drop policy
 histogram insert
etc.

Re: [PATCH 0/2] mach-omap2: handle autoidle denial

[Andreas Kemnade]

ping.

..after stumbling again about that problem during testing with 4.20-rc1.
will retest it there.

On Thu,  4 Oct 2018 22:38:15 +0200
Andreas Kemnade  wrote:

> On the gta04 with a dm3730 omap_hdq does not work properly when the
> device enters lower power states. Idling uart1 and 2 is enough
> to show up that problem, if there are no other things enabled.
> Further research reveals that hdq iclk must not be turned off during
> transfers, also according to the TRM. That fact is also correctly described
> in the flags but the code to handle that is incomplete.
> 
> To handle multiple users of a single ick, autoidle is disabled
> when a user of that ick requires that (has the OCPIF_SWSUP_IDLE))
> 
> Changes since the RFC version:
> - mutex lock for autoidle changes
> - deny_idle/allow_idle calls moved to clock enable/disable of the
>   individual modules
> 
> Andreas Kemnade (2):
>   clk: ti: add a usecount for autoidle
>   arm: omap_hwmod disable ick autoidling when a hwmod requires that
> 
>  arch/arm/mach-omap2/omap_hwmod.c | 16 
>  drivers/clk/ti/autoidle.c| 32 
>  include/linux/clk/ti.h   |  1 +
>  3 files changed, 37 insertions(+), 12 deletions(-)
> 
> -- 
> 2.11.0
> 
> 


pgpu1pXf6OHhC.pgp
Description: OpenPGP digital signature

[PATCH] regulator/of_get_regulator: add child path to find the regulator supplier

[zoro]

example code :
&vir_regulator {
ldo0_vir: ldo0-virtual {
regulator-compatible = "VIR_LDO0";
regulator-name= "VIR_LDO0";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <200>;
};
ldo1_vir: ldo1-virtual {
regulator-compatible = "VIR_LDO1";
regulator-name= "VIR_LDO1";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <300>;
ldo1-supply = <&ldo0_vir>;
};
...
};

when the VIR_LDO1 regulator supplier is it's brother,
we can't find the supplier.
so we add the child ptah to find the suppier.

Signed-off-by: zoro 
---
 drivers/regulator/core.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2c66b52..5dbfdba 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -239,6 +239,7 @@ static void regulator_unlock_supply(struct regulator_dev 
*rdev)
 static struct device_node *of_get_regulator(struct device *dev, const char 
*supply)
 {
struct device_node *regnode = NULL;
+   struct device_node *child = NULL;
char prop_name[32]; /* 32 is max size of property name */
 
dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
@@ -247,6 +248,11 @@ static struct device_node *of_get_regulator(struct device 
*dev, const char *supp
regnode = of_parse_phandle(dev->of_node, prop_name, 0);
 
if (!regnode) {
+   for_each_child_of_node(dev->of_node, child) {
+   regnode = of_parse_phandle(child, prop_name, 0);
+   if (regnode)
+   return regnode;
+   }
dev_dbg(dev, "Looking up %s property in node %pOF failed\n",
prop_name, dev->of_node);
return NULL;
-- 
1.7.9.5

Re: [PATCH 1/2] opp: ti-opp-supply: Dynamically update u_volt_min

[Viresh Kumar]

On 07-11-18, 10:04, Keerthy wrote:
> The voltage range (min, max) provided in the device tree is from
> the data manual and is pretty big, catering to a wide range of devices.
> On a i2c read/write failure the regulator_set_voltage_triplet function
> falls back to set voltage between min and max. The min value from Device
> Tree can be lesser than the optimal value and in that case that can lead
> to a hang or crash. Hence set the u_volt_min dynamically to the optimal
> voltage value.

And why shouldn't we fix the DT for this ?

-- 
viresh

Re: [PATCH 0/2] opp: ti-opp-supply: Fixes

[Viresh Kumar]

On 07-11-18, 10:04, Keerthy wrote:
> The series brings in couple of fixes to the ti-opp-supply driver.
> One of them updates u_volt_min dynamically and avoids hang due
> to lesser static u_volt_min and the other fixes the supply in
> _get_optimal_vdd_voltage.
> 
> Keerthy (2):
>   power: opp: ti-opp-supply: Dynamically update u_volt_min
>   power: opp: ti-opp-supply: Correct the supply in
> _get_optimal_vdd_voltage call

@Dave: I would like to get an Ack from you on these before applying.

-- 
viresh

[PATCH] sched/fair: make some function static

[Yi Wang]

Make some function static as they are not used outside of fair.c.

This fixes the following warning when building with 'W=1':

kernel/sched/fair.c:2439:6: warning: no previous prototype for ‘task_numa_work’ 
[-Wmissing-prototypes]
kernel/sched/fair.c:2584:6: warning: no previous prototype for ‘task_tick_numa’ 
[-Wmissing-prototypes]
kernel/sched/fair.c:3548:6: warning: no previous prototype for 
‘sync_entity_load_avg’ [-Wmissing-prototypes]
kernel/sched/fair.c:3561:6: warning: no previous prototype for 
‘remove_entity_load_avg’ [-Wmissing-prototypes]

Signed-off-by: Yi Wang 
---
 kernel/sched/fair.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ee271bb..615e168 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2436,7 +2436,7 @@ static void reset_ptenuma_scan(struct task_struct *p)
  * The expensive part of numa migration is done from task_work context.
  * Triggered from task_tick_numa().
  */
-void task_numa_work(struct callback_head *work)
+static void task_numa_work(struct callback_head *work)
 {
unsigned long migrate, next_scan, now = jiffies;
struct task_struct *p = current;
@@ -2581,7 +2581,7 @@ void task_numa_work(struct callback_head *work)
 /*
  * Drive the periodic memory faults..
  */
-void task_tick_numa(struct rq *rq, struct task_struct *curr)
+static void task_tick_numa(struct rq *rq, struct task_struct *curr)
 {
struct callback_head *work = &curr->numa_work;
u64 period, now;
@@ -3545,7 +3545,7 @@ static inline u64 cfs_rq_last_update_time(struct cfs_rq 
*cfs_rq)
  * Synchronize entity load avg of dequeued entity without locking
  * the previous rq.
  */
-void sync_entity_load_avg(struct sched_entity *se)
+static void sync_entity_load_avg(struct sched_entity *se)
 {
struct cfs_rq *cfs_rq = cfs_rq_of(se);
u64 last_update_time;
@@ -3558,7 +3558,7 @@ void sync_entity_load_avg(struct sched_entity *se)
  * Task first catches up with cfs_rq, and then subtract
  * itself from the cfs_rq (task must be off the queue now).
  */
-void remove_entity_load_avg(struct sched_entity *se)
+static void remove_entity_load_avg(struct sched_entity *se)
 {
struct cfs_rq *cfs_rq = cfs_rq_of(se);
unsigned long flags;
-- 
1.8.3.1

[PATCH 1/1] Bluetooth: make the balance of judgement condition to fix a false report

[Zumeng Chen]

This patch is to balance the condition scope between hci_get_cmd_complete and
hci_event_packet about orig_skb as follows: 

if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
event == HCI_EV_CMD_COMPLETE)
orig_skb = skb_clone(skb, GFP_KERNEL);

And hci_get_cmd_complete will bt_dev_err out when HCI_EV_CMD_STATUS, so a lot
of asymmetric conditions are triggered. Since both of them are the entry into
hci_get_cmd_complete, we'd better get STATUS into judge the false out there.

Signed-off-by: Zumeng Chen 
---

Hi expert,

This issue existed whether or not T_DBG had been changed into bt_dev_err, which
just shows the issue explicitly. I noticed actually that opcode doesn't match
ev->opcode either at the same time. And there might be some logic issue about
HCI_EV_CMD_COMPLETE between protocol and drivers. I'm not familar with the whole
bluetooth protocol, and not gonna to dig more, so all yours guys~

Cheers,
Zumeng

 net/bluetooth/hci_event.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 235b5aa..d848663 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5217,7 +5217,8 @@ static bool hci_get_cmd_complete(struct hci_dev *hdev, 
u16 opcode,
return true;
}
 
-   if (hdr->evt != HCI_EV_CMD_COMPLETE) {
+   if (!((hdr->evt == HCI_EV_CMD_COMPLETE) ||
+   (hdr->evt == HCI_EV_CMD_STATUS))) {
bt_dev_err(hdev, "last event is not cmd complete (0x%2.2x)",
   hdr->evt);
return false;
-- 
2.7.4

Re: [PATCH 1/2] dt-bindings: clk: Introduce 'protected-clocks' property

[Bjorn Andersson]

On Mon 05 Nov 17:04 PST 2018, Bjorn Andersson wrote:

> On Mon 05 Nov 11:40 PST 2018, Stephen Boyd wrote:
> 
> > Add a generic clk property for clks which are not intended to be used by
> > the OS due to security restrictions put in place by firmware. For
> > example, on some Qualcomm firmwares reading or writing certain clk
> > registers causes the entire system to reboot, but on other firmwares
> > reading and writing those same registers is required to make devices
> > like QSPI work. Rather than adding one-off properties each time a new
> > set of clks appears to be protected, let's add a generic clk property to
> > describe any set of clks that shouldn't be touched by the OS. This way
> > we never need to register the clks or use them in certain firmware
> > configurations.
> > 
> > Cc: Rob Herring 
> > Cc: Bjorn Andersson 
> 
> Reviewed-by: Bjorn Andersson 
> 

Gave this some additional thought. The way this is blacklisting
protected clocks makes it impossible to be backwards compatible with an
older DT while adding new protected clocks to an existing driver.

I don't have better suggestion for handling this and the problem should
primarily be isolated to the beginning of the upstream life of a
platform, so perhaps we can just ignore this issue?

Regards,
Bjorn

> Regards,
> Bjorn
> 
> > Cc: Taniya Das 
> > Signed-off-by: Stephen Boyd 
> > ---
> >  .../devicetree/bindings/clock/clock-bindings.txt | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt 
> > b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > index 2ec489eebe72..b646bbcf7f92 100644
> > --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > @@ -168,3 +168,19 @@ a shared clock is forbidden.
> >  
> >  Configuration of common clocks, which affect multiple consumer devices can
> >  be similarly specified in the clock provider node.
> > +
> > +==Protected clocks==
> > +
> > +Some platforms or firmwares may not fully expose all the clocks to the OS, 
> > such
> > +as in situations where those clks are used by drivers running in ARM secure
> > +execution levels. Such a configuration can be specified in device tree 
> > with the
> > +protected-clocks property in the form of a clock specifier list. This 
> > property should
> > +only be specified in the node that is providing the clocks being protected:
> > +
> > +   clock-controller@a000f000 {
> > +compatible = "vendor,clk95;
> > +reg = <0xa000f000 0x1000>
> > +#clocks-cells = <1>;
> > +...
> > +protected-clocks = , ;
> > +   };
> > -- 
> > Sent by a computer through tubes
> > 

Re: [QUESTION] Microsoft, WSL, and the Linux trademark (Edited For Readability)

[Hayden Barnes]

Mr. Caputo,

> In reading the news today, I stumbled across an article talking about a $20 
> "linux-based distro" app for Windows 10.

Hello. That was my idea. Please allow me to address some of the concerns you 
raised. 

> This is just a bundled userspace for WSL, there is no actual Linux in this 
> thing, 
> yet the trademarked Linux name is used throughout.
> Did Microsoft license the trademark or something?  Did I miss a memo?
> Does their joining the Linux Foundation as a Platinum member two years ago 
> include such use of the trademark? 
> I'm confused by what seems to be total silence about what _appears_ to be an 
> obvious large-scale trademark abuse in everything WSL-related.
> Could somebody informed please shed some light on this?

The Linux trademark is owned by Linus Torvalds and administered by the Linux 
Foundation 
through the Linux Mark Institute: https://www.linuxmark.org. The Linux 
trademark can be 
used by third parties subject to a Sublicense Agreement: 
https://www.linuxmark.org/programs/legal/trademark/sublicense-agreement. 

The terms of the Sublicense Agreement permit the use of the Linux trademark for 
derivative 
goods and services that deploy, document, facilitate the use of, or enhance 
Linux­-based goods.

WLinux does contain a bootable Linux kernel in a base image.  The criticism 
that 'WSL is 
not Linux' is because the kernel is not executed when the base image is 
installed and run 
from within the WSL layer on Windows 10. But WLinux can be used to patch and 
build the 
Linux kernel from sources to install on other devices, assist in deploying and 
configuring 
Linux on other devices, and can cross-compile software using standard Linux 
libraries, 
all when running on WSL. For more about how WSL works for those unfamiliar: 
https://github.com/sirredbeard/Awesome-WSL#overview. WLinux unquestionably 
contains 
derivations of the Linux kernel, relies on the WSL re-implementation of Linux 
kernel syscalls, 
and facilitates the use of and enhances Linux-based goods, all within the terms 
of the 
Linux Sublicense Agreement.

We obtained a valid Sublicense Agreement for the use of the Linux trademark for 
WLinux 
from the Linux Foundation before launching WLinux. All of our intellectual 
property 
compliance disclosures are here: 
https://github.com/WhitewaterFoundry/WLinux/blob/master/LICENSE.md

> The situation strikes me as harmful to the kernel as the majority of folks 
> being 
introduced to "Linux" this way will be tricked into thinking they're 
using/supporting Linux.

Users who purchase WLinux from the Microsoft Store are supporting the Linux 
ecosystem 
and free software generally. Everyone working on WLinux are Windows and Linux 
users
who are committed to making the Linux software ecosystem accessible to as many 
people 
as possible regardless of what device or operating system they are on. WLinux 
and WSL 
generally opens up new possibilities for bringing people to the Linux 
ecosystem, 
cross-platform development, and expanding access to free software and free 
software 
development tools. 

WLinux builds in a number of value-added enhancements and features, we provide 
end user support, and work with various developer communities and other open 
source 
companies to try to make it easy to get into the Linux ecosystem from Windows 
10.  We 
make it easy to get up and running with Go, Ruby, other dev toolchains, soon 
Docker, install 
various editors, configure predictive text input for non-Latin input, and 
implement a handful 
of other tweaks to defaults. I personally do not believe a frontend dev 
stepping into Linux 
should have to know how to partition and dual-boot a system, or even have to 
learn Docker, 
to get started using node.js and trying different packages off npm. They will 
get to that.

Many WLinux users are going to end up working on traditional server Linux 
eventually, 
if they don't already, as many of our users seem to work in hybrid environments 
as it is. 
I imagine a few will end up trying and then switching to desktop Linux, again 
if they don't 
use it already. But desktop Linux is just one small part of Linux, WLinux is 
not here to 
replace it, and WSL is not capable of doing so in it's current limitations. 
Users are not being
 'tricked'. Free upstream distros from Canonical, Debian, SuSE, and Kali are 
available where 
you can implement our tweaks and custom packages manually. Of the many copies 
we have
 sold we have only had two refund requests which we have promptly honored. 
Users always 
have the option of building WLinux from source using instructions we provide. 
WLinux is also 
heavily discounted or free in many less developed countries.

We turn the funds WLinux earns around to hire open source developers, sponsor 
bug and 
feature bounties, donate to upstream projects, and cover overhead. We are 
profitable and 
expect to pay out over $2,000 USD in bounties this month alone after being on 
the store for
 just six weeks. We 

[PATCH 2/6] fs/epoll: simplify ep_send_events_proc() ready-list loop

[Davidlohr Bueso]

The current logic is a bit convoluted. Lets simplify this with
a standard list_for_each_entry_safe() loop instead and just
break out after maxevents is reached.

While at it, remove an unnecessary indentation level in the loop
when there are in fact ready events.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 73 +-
 1 file changed, 37 insertions(+), 36 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 7ad020f1353b..101d46b81f64 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1624,21 +1624,22 @@ static __poll_t ep_send_events_proc(struct eventpoll 
*ep, struct list_head *head
 {
struct ep_send_events_data *esed = priv;
__poll_t revents;
-   struct epitem *epi;
-   struct epoll_event __user *uevent;
+   struct epitem *epi, *tmp;
+   struct epoll_event __user *uevent = esed->events;
struct wakeup_source *ws;
poll_table pt;
 
init_poll_funcptr(&pt, NULL);
+   esed->res = 0;
 
/*
 * We can loop without lock because we are passed a task private list.
 * Items cannot vanish during the loop because ep_scan_ready_list() is
 * holding "mtx" during this call.
 */
-   for (esed->res = 0, uevent = esed->events;
-!list_empty(head) && esed->res < esed->maxevents;) {
-   epi = list_first_entry(head, struct epitem, rdllink);
+   list_for_each_entry_safe(epi, tmp, head, rdllink) {
+   if (esed->res >= esed->maxevents)
+   break;
 
/*
 * Activate ep->ws before deactivating epi->ws to prevent
@@ -1658,42 +1659,42 @@ static __poll_t ep_send_events_proc(struct eventpoll 
*ep, struct list_head *head
 
list_del_init(&epi->rdllink);
 
-   revents = ep_item_poll(epi, &pt, 1);
-
/*
 * If the event mask intersect the caller-requested one,
 * deliver the event to userspace. Again, ep_scan_ready_list()
-* is holding "mtx", so no operations coming from userspace
+* is holding ep->mtx, so no operations coming from userspace
 * can change the item.
 */
-   if (revents) {
-   if (__put_user(revents, &uevent->events) ||
-   __put_user(epi->event.data, &uevent->data)) {
-   list_add(&epi->rdllink, head);
-   ep_pm_stay_awake(epi);
-   if (!esed->res)
-   esed->res = -EFAULT;
-   return 0;
-   }
-   esed->res++;
-   uevent++;
-   if (epi->event.events & EPOLLONESHOT)
-   epi->event.events &= EP_PRIVATE_BITS;
-   else if (!(epi->event.events & EPOLLET)) {
-   /*
-* If this file has been added with Level
-* Trigger mode, we need to insert back inside
-* the ready list, so that the next call to
-* epoll_wait() will check again the events
-* availability. At this point, no one can 
insert
-* into ep->rdllist besides us. The epoll_ctl()
-* callers are locked out by
-* ep_scan_ready_list() holding "mtx" and the
-* poll callback will queue them in ep->ovflist.
-*/
-   list_add_tail(&epi->rdllink, &ep->rdllist);
-   ep_pm_stay_awake(epi);
-   }
+   revents = ep_item_poll(epi, &pt, 1);
+   if (!revents)
+   continue;
+
+   if (__put_user(revents, &uevent->events) ||
+   __put_user(epi->event.data, &uevent->data)) {
+   list_add(&epi->rdllink, head);
+   ep_pm_stay_awake(epi);
+   if (!esed->res)
+   esed->res = -EFAULT;
+   return 0;
+   }
+   esed->res++;
+   uevent++;
+   if (epi->event.events & EPOLLONESHOT)
+   epi->event.events &= EP_PRIVATE_BITS;
+   else if (!(epi->event.events & EPOLLET)) {
+   /*
+* If this file has been added with Level
+* Trigger mode, we need to insert back inside
+* the ready list, so that the next call to
+* epoll_wait() will check again the events
+* availability. At this po

[PATCH -next 0/6] epoll: some miscellaneous optimizations

[Davidlohr Bueso]

Hi,

The following are some incremental optimizations on some of the epoll
core. Each patch has the details, but together, the series is seen
to shave off measurable cycles on a number of systems and workloads.

For example, on a 40-core IB, a pipetest as well as parallel epoll_wait()
benchmark show around a 20-30% increase in raw operations per second when
the box is fully occupied (incremental thread counts), and up to 15%
performance improvement with lower counts.

Passes ltp epoll related testcases. Please consider for v4.21/5.0.

Thanks!

Davidlohr Bueso (6):
  fs/epoll: remove max_nests argument from ep_call_nested()
  fs/epoll: simplify ep_send_events_proc() ready-list loop
  fs/epoll: drop ovflist branch prediction
  fs/epoll: robustify ep->mtx held checks
  fs/epoll: reduce the scope of wq lock in epoll_wait()
  fs/epoll: avoid barrier after an epoll_wait(2) timeout

 fs/eventpoll.c | 206 ++---
 1 file changed, 108 insertions(+), 98 deletions(-)

-- 
2.16.4

[PATCH 3/6] fs/epoll: drop ovflist branch prediction

[Davidlohr Bueso]

The ep->ovflist is a secondary ready-list to temporarily store
events that might occur when doing sproc without holding the
ep->wq.lock. This accounts for every time we check for ready
events and also send events back to userspace; both callbacks,
particularly the later because of copy_to_user, can account
for a non-trivial time.

As such, the unlikely() check to see if the pointer is being
used, seems both misleading and sub-optimal. In fact, we go
to an awful lot of trouble to sync both lists, and populating
the ovflist is far from an uncommon scenario.

For example, profiling a concurrent epoll_wait(2) benchmark,
with CONFIG_PROFILE_ANNOTATED_BRANCHES shows that for a two threads
a 33% incorrect rate was seen; and when incrementally increasing
the number of epoll instances (which is used, for example for
multiple queuing load balancing models), up to a 90% incorrect
rate was seen.

Similarly, by deleting the prediction, 3% throughput boost was
seen across incremental threads.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 101d46b81f64..347da3f4f5d3 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1153,7 +1153,7 @@ static int ep_poll_callback(wait_queue_entry_t *wait, 
unsigned mode, int sync, v
 * semantics). All the events that happen during that period of time are
 * chained in ep->ovflist and requeued later on.
 */
-   if (unlikely(ep->ovflist != EP_UNACTIVE_PTR)) {
+   if (ep->ovflist != EP_UNACTIVE_PTR) {
if (epi->next == EP_UNACTIVE_PTR) {
epi->next = ep->ovflist;
ep->ovflist = epi;
-- 
2.16.4

[PATCH 1/6] fs/epoll: remove max_nests argument from ep_call_nested()

[Davidlohr Bueso]

All callers pass the EP_MAX_NESTS constant already, so lets
simplify this a tad and get rid of the redundant parameter
for nested eventpolls.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 42bbe6824b4b..7ad020f1353b 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -471,7 +471,6 @@ static inline void ep_set_busy_poll_napi_id(struct epitem 
*epi)
  *  no re-entered.
  *
  * @ncalls: Pointer to the nested_calls structure to be used for this call.
- * @max_nests: Maximum number of allowed nesting calls.
  * @nproc: Nested call core function pointer.
  * @priv: Opaque data to be passed to the @nproc callback.
  * @cookie: Cookie to be used to identify this nested call.
@@ -480,7 +479,7 @@ static inline void ep_set_busy_poll_napi_id(struct epitem 
*epi)
  * Returns: Returns the code returned by the @nproc callback, or -1 if
  *  the maximum recursion limit has been exceeded.
  */
-static int ep_call_nested(struct nested_calls *ncalls, int max_nests,
+static int ep_call_nested(struct nested_calls *ncalls,
  int (*nproc)(void *, void *, int), void *priv,
  void *cookie, void *ctx)
 {
@@ -499,7 +498,7 @@ static int ep_call_nested(struct nested_calls *ncalls, int 
max_nests,
 */
list_for_each_entry(tncur, lsthead, llink) {
if (tncur->ctx == ctx &&
-   (tncur->cookie == cookie || ++call_nests > max_nests)) {
+   (tncur->cookie == cookie || ++call_nests > EP_MAX_NESTS)) {
/*
 * Ops ... loop detected or maximum nest level reached.
 * We abort this wake by breaking the cycle itself.
@@ -573,7 +572,7 @@ static void ep_poll_safewake(wait_queue_head_t *wq)
 {
int this_cpu = get_cpu();
 
-   ep_call_nested(&poll_safewake_ncalls, EP_MAX_NESTS,
+   ep_call_nested(&poll_safewake_ncalls,
   ep_poll_wakeup_proc, NULL, wq, (void *) (long) this_cpu);
 
put_cpu();
@@ -1333,7 +1332,6 @@ static int reverse_path_check_proc(void *priv, void 
*cookie, int call_nests)
}
} else {
error = ep_call_nested(&poll_loop_ncalls,
-   EP_MAX_NESTS,
reverse_path_check_proc,
child_file, child_file,
current);
@@ -1367,7 +1365,7 @@ static int reverse_path_check(void)
/* let's call this for all tfiles */
list_for_each_entry(current_file, &tfile_check_list, f_tfile_llink) {
path_count_init();
-   error = ep_call_nested(&poll_loop_ncalls, EP_MAX_NESTS,
+   error = ep_call_nested(&poll_loop_ncalls,
reverse_path_check_proc, current_file,
current_file, current);
if (error)
@@ -1876,7 +1874,7 @@ static int ep_loop_check_proc(void *priv, void *cookie, 
int call_nests)
ep_tovisit = epi->ffd.file->private_data;
if (ep_tovisit->visited)
continue;
-   error = ep_call_nested(&poll_loop_ncalls, EP_MAX_NESTS,
+   error = ep_call_nested(&poll_loop_ncalls,
ep_loop_check_proc, epi->ffd.file,
ep_tovisit, current);
if (error != 0)
@@ -1916,7 +1914,7 @@ static int ep_loop_check(struct eventpoll *ep, struct 
file *file)
int ret;
struct eventpoll *ep_cur, *ep_next;
 
-   ret = ep_call_nested(&poll_loop_ncalls, EP_MAX_NESTS,
+   ret = ep_call_nested(&poll_loop_ncalls,
  ep_loop_check_proc, file, ep, current);
/* clear visited list */
list_for_each_entry_safe(ep_cur, ep_next, &visited_list,
-- 
2.16.4

[PATCH 4/6] fs/epoll: robustify ep->mtx held checks

[Davidlohr Bueso]

Insted of just commenting how important it is, lets make
it more robust and add a lockdep_assert_held() call.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 347da3f4f5d3..6a0c2591e57e 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1637,6 +1637,8 @@ static __poll_t ep_send_events_proc(struct eventpoll *ep, 
struct list_head *head
 * Items cannot vanish during the loop because ep_scan_ready_list() is
 * holding "mtx" during this call.
 */
+   lockdep_assert_held(&ep->mtx);
+
list_for_each_entry_safe(epi, tmp, head, rdllink) {
if (esed->res >= esed->maxevents)
break;
-- 
2.16.4

[PATCH 5/6] fs/epoll: reduce the scope of wq lock in epoll_wait()

[Davidlohr Bueso]

This patch aims at reducing ep wq.lock hold times in epoll_wait(2).
For the blocking case, there is no need to constantly take and drop
the spinlock, which is only needed to manipulate the waitqueue.

The call to ep_events_available() is now lockless, and only exposed
to benign races. Here, if false positive (returns available events
and does not see another thread deleting an epi from the list) we call
into send_events and then the list's state is correctly seen. Otoh,
if a false negative and we don't see a list_add_tail(), for example,
from irq callback, then it is rechecked again before blocking, which
will see the correct state.

In order for more accuracy to see concurrent list_del_init(), use
the list_empty_careful() variant  -- of course, this won't the safe
against insertions from wakeup.

For the overflow list we obviously need to prevent load/store tearing
as we don't want to see partial values while the ready list is disabled.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 114 ++---
 1 file changed, 60 insertions(+), 54 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 6a0c2591e57e..f6c023f085f6 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -381,7 +381,8 @@ static void ep_nested_calls_init(struct nested_calls 
*ncalls)
  */
 static inline int ep_events_available(struct eventpoll *ep)
 {
-   return !list_empty(&ep->rdllist) || ep->ovflist != EP_UNACTIVE_PTR;
+   return !list_empty(&ep->rdllist) ||
+   READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR;
 }
 
 #ifdef CONFIG_NET_RX_BUSY_POLL
@@ -698,7 +699,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
 */
spin_lock_irq(&ep->wq.lock);
list_splice_init(&ep->rdllist, &txlist);
-   ep->ovflist = NULL;
+   WRITE_ONCE(ep->ovflist, NULL);
spin_unlock_irq(&ep->wq.lock);
 
/*
@@ -712,7 +713,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
 * other events might have been queued by the poll callback.
 * We re-insert them inside the main ready-list here.
 */
-   for (nepi = ep->ovflist; (epi = nepi) != NULL;
+   for (nepi = READ_ONCE(ep->ovflist); (epi = nepi) != NULL;
 nepi = epi->next, epi->next = EP_UNACTIVE_PTR) {
/*
 * We need to check if the item is already in the list.
@@ -730,7 +731,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
 * releasing the lock, events will be queued in the normal way inside
 * ep->rdllist.
 */
-   ep->ovflist = EP_UNACTIVE_PTR;
+   WRITE_ONCE(ep->ovflist, EP_UNACTIVE_PTR);
 
/*
 * Quickly re-inject items left on "txlist".
@@ -1153,10 +1154,10 @@ static int ep_poll_callback(wait_queue_entry_t *wait, 
unsigned mode, int sync, v
 * semantics). All the events that happen during that period of time are
 * chained in ep->ovflist and requeued later on.
 */
-   if (ep->ovflist != EP_UNACTIVE_PTR) {
+   if (READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR) {
if (epi->next == EP_UNACTIVE_PTR) {
-   epi->next = ep->ovflist;
-   ep->ovflist = epi;
+   epi->next = READ_ONCE(ep->ovflist);
+   WRITE_ONCE(ep->ovflist, epi);
if (epi->ws) {
/*
 * Activate ep->ws since epi->ws may get
@@ -1762,10 +1763,17 @@ static int ep_poll(struct eventpoll *ep, struct 
epoll_event __user *events,
} else if (timeout == 0) {
/*
 * Avoid the unnecessary trip to the wait queue loop, if the
-* caller specified a non blocking operation.
+* caller specified a non blocking operation. We still need
+* lock because we could race and not see an epi being added
+* to the ready list while in irq callback. Thus incorrectly
+* returning 0 back to userspace.
 */
timed_out = 1;
+
spin_lock_irq(&ep->wq.lock);
+   eavail = ep_events_available(ep);
+   spin_unlock_irq(&ep->wq.lock);
+
goto check_events;
}
 
@@ -1774,64 +1782,62 @@ static int ep_poll(struct eventpoll *ep, struct 
epoll_event __user *events,
if (!ep_events_available(ep))
ep_busy_loop(ep, timed_out);
 
+   eavail = ep_events_available(ep);
+   if (eavail)
+   goto check_events;
+
+   /*
+* Busy poll timed out.  Drop NAPI ID for now, we can add
+* it back in when we have moved a socket with a valid NAPI
+* ID onto the ready list.
+*/
+   ep_reset_busy_poll_napi_id(ep);
+
+   /*
+* We don't have any available event to return to the caller.
+* We need to sleep here, and we will be wake up by
+  

[PATCH 6/6] fs/epoll: avoid barrier after an epoll_wait(2) timeout

[Davidlohr Bueso]

Upon timeout, we can just exit out of the loop, without
the cost of the changing the task's state smp_store_mb
call. Just exit out of the loop and be done - setting
the task state afterwards will be, of course, redundant.

Signed-off-by: Davidlohr Bueso 
---
 fs/eventpoll.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f6c023f085f6..ec14e5bcdaa9 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1820,15 +1820,18 @@ static int ep_poll(struct eventpoll *ep, struct 
epoll_event __user *events,
res = -EINTR;
break;
}
-   if (ep_events_available(ep) || timed_out)
+   
+   if (ep_events_available(ep))
break;
if (signal_pending(current)) {
res = -EINTR;
break;
}
 
-   if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
+   if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) {
timed_out = 1;
+   break;
+   }
}
 
__set_current_state(TASK_RUNNING);
-- 
2.16.4

Re: [QUESTION] Microsoft, WSL, and the Linux trademark

[Hayden Barnes]

Mr. Caputo,

Please allow me to address some of the concerns you raised. 

The Linux trademark is owned by Linus Torvalds and administered by the Linux 
Foundation through the Linux Mark Institute: https://www.linuxmark.org. The 
Linux trademark can be used by third parties subject to a Sublicense Agreement: 
https://www.linuxmark.org/programs/legal/trademark/sublicense-agreement. The 
terms of the Sublicense Agreement permit the use of the Linux trademark for 
derivative goods and services that deploy, document, facilitate the use of, or 
enhance Linux­-based goods.

WLinux does contain a bootable Linux kernel in a base image.  The criticism 
that 'WSL is not Linux' is because the kernel is not executed when the base 
image is installed and run from within the WSL layer on Windows 10. But WLinux 
can be used to patch and build the Linux kernel from sources to install on 
other devices, assist in deploying and configuring Linux on other devices, and 
can cross-compile software using standard Linux libraries, all when running on 
WSL. For more about how WSL works for those unfamiliar: 
https://github.com/sirredbeard/Awesome-WSL#overview. WLinux unquestionably 
contains derivations of the Linux kernel, relies on the WSL re-implementation 
of Linux kernel syscalls, and facilitates the use of and enhances Linux-based 
goods, all within the terms of the Linux Sublicense Agreement.

We obtained a valid Sublicense Agreement for the use of the Linux trademark 
from the Linux Foundation before launching WLinux. All of our intellectual 
property compliance disclosures are here: 
https://github.com/WhitewaterFoundry/WLinux/blob/master/LICENSE.md

Users who purchase WLinux from the Microsoft Store are supporting the Linux 
ecosystem and free software generally. Everyone working on WLinux are Windows 
and Linux users who are committed to making the Linux software ecosystem 
accessible to as many people as possible regardless of what device or operating 
system they are on. WLinux and WSL generally opens up new possibilities for 
bringing people to the Linux ecosystem, cross-platform development, and 
expanding access to free software and free software development tools. 

WLinux builds in a number of value-added enhancements and features, we provide 
end user support, and work with various developer communities and other open 
source companies to try to make it easy to get into the Linux ecosystem from 
Windows 10.  We make it easy to get up and running with Go, Ruby, other dev 
toolchains, soon Docker, install various editors, configure predictive text 
input for non-Latin input, and implement a handful of other tweaks to defaults. 
I personally do not believe a frontend dev stepping into Linux should have to 
know how to partition and dual-boot a system, or even have to learn Docker, to 
get started using node.js and trying different packages off npm. They will get 
to that.

Many WLinux users are going to end up working on traditional server Linux 
eventually, if they don't already, as many of our users seem to work in hybrid 
environments as it is. I imagine a few will end up trying and then switching to 
desktop Linux, again if they don't use it already. But desktop Linux is just 
one small part of Linux, WLinux is not here to replace it, and WSL is not 
capable of doing so in it's current limitations. Users are not being 'tricked'. 
Free upstream distros from Canonical, Debian, SuSE, and Kali are available 
where you can implement our tweaks and custom packages manually. Of the many 
copies we have sold we have only had two refund requests which we have promptly 
honored. Users always have the option of building WLinux from source using 
instructions we provide. WLinux is also heavily discounted or free in many less 
developed countries.

We turn the funds WLinux earns around to hire open source developers, sponsor 
bug and feature bounties, donate to upstream projects, and cover overhead. We 
are profitable and expect to pay out over $2,000 USD in bounties this month 
alone after being on the store for just six weeks. We are focused on building a 
sustainable commercial open source project that can direct our own development 
resources where we see fit to improve the Linux experience on WSL for us, the 
users of Linux on WSL. Microsoft has had absolutely zero input into how we have 
evolved WLinux besides open source code of theirs we have used.

Hayden Barnes
Whitewater Foundry, Ltd. Co.
hay...@whitewaterfoundry.com
https://www.whitewaterfoundry.com
https://twitter.com/WLinuxApp
https://github.com/sirredbeard
https://github.com/WhitewaterFoundry/WLinux

> In reading the news today, I stumbled across an article talking about a $20 
> "linux-based distro" app for Windows 10.
> This is just a bundled userspace for WSL, there is no actual Linux in this 
> thing, yet the trademarked Linux name is used throughout.
> Did Microsoft license the trademark or something?  Did I miss a memo? Does 
> their joining the Linux 

Re: [PATCH 2/9] arm64: defconfig: Drop ARM_BIG_LITTLE_CPUFREQ

[Viresh Kumar]

On 07-11-18, 21:54, Marc Gonzalez wrote:
> [ Add interested parties ]
> 
> On 07/11/2018 21:14, Marc Gonzalez wrote:
> 
> > Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
> > 
> > Signed-off-by: Marc Gonzalez 
> > ---
> >  arch/arm64/configs/defconfig | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index f786c95504d3..8d6878c1e794 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -107,7 +107,6 @@ CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
> >  CONFIG_CPUFREQ_DT=y
> >  CONFIG_ACPI_CPPC_CPUFREQ=m
> >  CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
> > -CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
> >  CONFIG_ARM_SCPI_CPUFREQ=y
> >  CONFIG_ARM_TEGRA186_CPUFREQ=y
> >  CONFIG_ARM_SCPI_PROTOCOL=y

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

[Sergey Senozhatsky]

On (11/07/18 16:19), Petr Mladek wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> > 
> > @@ -2421,18 +2458,20 @@ static void check_chain_key(struct task_struct 
> > *curr)
> >  print_usage_bug_scenario(struct held_lock *lock)
> >  {
> > struct lock_class *class = hlock_class(lock);
> > +   struct printk_buffer *buf = get_printk_buffer();
> >  
> > printk(" Possible unsafe locking scenario:\n\n");
> > printk("   CPU0\n");
> > printk("   \n");
> > -   printk("  lock(");
> > -   __print_lock_name(class);
> > -   printk(KERN_CONT ");\n");
> > +   printk_buffered(buf, "  lock(");
> > +   __print_lock_name(class, buf);
> > +   printk_buffered(buf, ");\n");
> > printk("  \n");
> > -   printk("lock(");
> > -   __print_lock_name(class);
> > -   printk(KERN_CONT ");\n");
> > +   printk_buffered(buf, "lock(");
> > +   __print_lock_name(class, buf);
> > +   printk_buffered(buf, ");\n");
> > printk("\n *** DEADLOCK ***\n\n");
> > +   put_printk_buffer(buf);
> >  }
> >  
> >  static int
> 
> I really hope that the maze of pr_cont() calls in lockdep.c is the most
> complicated one that we would meet.

Hmm... Yes, buffered/seq_buf printk looks like a hard-to-use API,
when it comes to real world cases like this.

So... here is a random and wild idea.

We actually already have an easy-to-use buffered printk. And it's per-CPU.
And it makes all printk-s on this CPU to behave like as if they were called
on UP system. And it cures pr_cont(). And it doesn't require anyone to learn
any new printk API names. And it doesn't require any additional maintenance
work. And it doesn't require any printk->buffered_printk conversions. And
it's already in the kernel. And we gave it a name. And it's printk_safe.

a) lockdep reporting path should be atomic. And it's not a hot path,
   so local_irq_save/local_irq_restore will not cause a lot of trouble
   there probably.

b) We already have some lockdep reports coming via printk_safe.
   All those
printk->console_driver->scheduler->lockdep
printk->console_driver->timekeeping->lockdep
etc.

   came via printk_safe path. So it's not a complete novelty.

c) printk_safe sections can nest.

d) No premature flushes. Everything looks the way it was supposed to
   look.

e) There are no out-of-line printk-s. We keep the actual order of events.

f) We flush it on panic.

g) Low maintenance costs.

So, can we just do the following? /* a sketch */

lockdep.c
printk_safe_enter_irqsave(flags);
lockdep_report();
printk_safe_exit_irqrestore(flags);

-ss

Re: [PATCH] cpufreq: s3c24xx: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Viresh Kumar]

On 07-11-18, 11:13, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Yangtao Li 
> ---
>  drivers/cpufreq/s3c24xx-cpufreq-debugfs.c | 46 +++
>  1 file changed, 6 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c24xx-cpufreq-debugfs.c 
> b/drivers/cpufreq/s3c24xx-cpufreq-debugfs.c
> index 4d976e8dbb2f..0df87b6480fe 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq-debugfs.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq-debugfs.c
> @@ -63,18 +63,7 @@ static int board_show(struct seq_file *seq, void *p)
>   return 0;
>  }
>  
> -static int fops_board_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, board_show, NULL);
> -}
> -
> -static const struct file_operations fops_board = {
> - .open   = fops_board_open,
> - .read   = seq_read,
> - .llseek = seq_lseek,
> - .release= single_release,
> - .owner  = THIS_MODULE,
> -};
> +DEFINE_SHOW_ATTRIBUTE(board);
>  
>  static int info_show(struct seq_file *seq, void *p)
>  {
> @@ -105,18 +94,7 @@ static int info_show(struct seq_file *seq, void *p)
>   return 0;
>  }
>  
> -static int fops_info_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, info_show, NULL);
> -}
> -
> -static const struct file_operations fops_info = {
> - .open   = fops_info_open,
> - .read   = seq_read,
> - .llseek = seq_lseek,
> - .release= single_release,
> - .owner  = THIS_MODULE,
> -};
> +DEFINE_SHOW_ATTRIBUTE(info);
>  
>  static int io_show(struct seq_file *seq, void *p)
>  {
> @@ -162,19 +140,7 @@ static int io_show(struct seq_file *seq, void *p)
>   return 0;
>  }
>  
> -static int fops_io_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, io_show, NULL);
> -}
> -
> -static const struct file_operations fops_io = {
> - .open   = fops_io_open,
> - .read   = seq_read,
> - .llseek = seq_lseek,
> - .release= single_release,
> - .owner  = THIS_MODULE,
> -};
> -
> +DEFINE_SHOW_ATTRIBUTE(io);
>  
>  static int __init s3c_freq_debugfs_init(void)
>  {
> @@ -185,13 +151,13 @@ static int __init s3c_freq_debugfs_init(void)
>   }
>  
>   dbgfs_file_io = debugfs_create_file("io-timing", S_IRUGO, dbgfs_root,
> - NULL, &fops_io);
> + NULL, &io_fops);
>  
>   dbgfs_file_info = debugfs_create_file("info", S_IRUGO, dbgfs_root,
> -   NULL, &fops_info);
> +   NULL, &info_fops);
>  
>   dbgfs_file_board = debugfs_create_file("board", S_IRUGO, dbgfs_root,
> -NULL, &fops_board);
> +NULL, &board_fops);
>  
>   return 0;
>  }

Acked-by: Viresh Kumar 

-- 
viresh

linux-next: stats (Was: Linux 4.20-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20181019 was the last linux-next before
the merge window opened.)

Commits in v4.20-rc1 (relative to v4.19):  12125
Commits in next-20181019:  11296
Commits with the same SHA1:10466
Commits with the same patch_id:  526 (1)
Commits with the same subject line:   56 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20181019: 11048 91%

Some breakdown of the list of extra commits (relative to next-20181019)
in -rc1:

Top ten first word of commit summary:

 86 net
 60 powerpc
 56 perf
 54 media
 36 drm
 33 pci
 32 thermal
 32 bpf
 23 ubifs
 21 selftests

Top ten authors:

 36 hans.verk...@cisco.com
 28 darrick.w...@oracle.com
 28 a...@redhat.com
 25 dhowe...@redhat.com
 24 s.ha...@pengutronix.de
 23 christophe.le...@c-s.fr
 21 kis...@ti.com
 21 da...@davemloft.net
 21 dan...@iogearbox.net
 21 bvanass...@acm.org

Top ten commiters:

161 da...@davemloft.net
 72 m...@ellerman.id.au
 65 a...@redhat.com
 54 mchehab+sams...@kernel.org
 41 edubez...@gmail.com
 33 lorenzo.pieral...@arm.com
 32 broo...@kernel.org
 31 h...@lst.de
 31 a...@kernel.org
 29 rich...@nod.at

There are also 250 commits in next-20181019 that didn't make it into
v4.20-rc1.

Top ten first word of commit summary:

 28 vfs
 21 mm
 18 leaking_addresses
 14 arm
 11 nfc
 10 interconnect
 10 btrfs
  9 xtensa
  7 arm-soc
  6 drm

Top ten authors:

 38 dhowe...@redhat.com
 19 a...@linux-foundation.org
 18 m...@tobin.cc
 11 a...@arndb.de
  9 jcmvb...@gmail.com
  9 georgi.dja...@linaro.org
  7 nbori...@suse.com
  6 han...@cmpxchg.org
  5 w...@csie.org
  5 s...@canb.auug.org.au

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

 75 s...@canb.auug.org.au
 40 dhowe...@redhat.com
 18 m...@tobin.cc
 13 georgi.dja...@linaro.org
 11 sa...@linux.intel.com
 10 dste...@suse.com
  9 sh...@kernel.org
  9 jcmvb...@gmail.com
  7 paul...@linux.vnet.ibm.com
  7 maxime.rip...@bootlin.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell


pgpMf2om4JnYW.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the block tree

[Jens Axboe]

On 11/7/18 8:31 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (sparc64 defconfig)
> produced this warning:
> 
> /home/sfr/next/next/drivers/block/sunvdc.c: In function 'init_queue':
> /home/sfr/next/next/drivers/block/sunvdc.c:788:6: warning: unused variable 
> 'ret' [-Wunused-variable]
>   int ret;
>   ^~~
> 
> Introduced by commit
> 
>   fa182a1fa97d ("sunvdc: convert to blk-mq")

Thanks, leftover from v2 of the conversion that switched to the
sq init queue helper. I'll fix it.

-- 
Jens Axboe

[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[Joel Fernandes (Google)]

Android uses ashmem for sharing memory regions. We are looking forward
to migrating all usecases of ashmem to memfd so that we can possibly
remove the ashmem driver in the future from staging while also
benefiting from using memfd and contributing to it. Note staging drivers
are also not ABI and generally can be removed at anytime.

One of the main usecases Android has is the ability to create a region
and mmap it as writeable, then add protection against making any
"future" writes while keeping the existing already mmap'ed
writeable-region active.  This allows us to implement a usecase where
receivers of the shared memory buffer can get a read-only view, while
the sender continues to write to the buffer.
See CursorWindow documentation in Android for more details:
https://developer.android.com/reference/android/database/CursorWindow

This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
which prevents any future mmap and write syscalls from succeeding while
keeping the existing mmap active. The following program shows the seal
working in action:

 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #define F_SEAL_FUTURE_WRITE 0x0010
 #define REGION_SIZE (5 * 1024 * 1024)

int memfd_create_region(const char *name, size_t size)
{
int ret;
int fd = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING);
if (fd < 0) return fd;
ret = ftruncate(fd, size);
if (ret < 0) { close(fd); return ret; }
return fd;
}

int main() {
int ret, fd;
void *addr, *addr2, *addr3, *addr1;
ret = memfd_create_region("test_region", REGION_SIZE);
printf("ret=%d\n", ret);
fd = ret;

// Create map
addr = mmap(0, REGION_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (addr == MAP_FAILED)
printf("map 0 failed\n");
else
printf("map 0 passed\n");

if ((ret = write(fd, "test", 4)) != 4)
printf("write failed even though no future-write seal "
   "(ret=%d errno =%d)\n", ret, errno);
else
printf("write passed\n");

addr1 = mmap(0, REGION_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (addr1 == MAP_FAILED)
perror("map 1 prot-write failed even though no seal\n");
else
printf("map 1 prot-write passed as expected\n");

ret = fcntl(fd, F_ADD_SEALS, F_SEAL_FUTURE_WRITE |
 F_SEAL_GROW |
 F_SEAL_SHRINK);
if (ret == -1)
printf("fcntl failed, errno: %d\n", errno);
else
printf("future-write seal now active\n");

if ((ret = write(fd, "test", 4)) != 4)
printf("write failed as expected due to future-write seal\n");
else
printf("write passed (unexpected)\n");

addr2 = mmap(0, REGION_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (addr2 == MAP_FAILED)
perror("map 2 prot-write failed as expected due to seal\n");
else
printf("map 2 passed\n");

addr3 = mmap(0, REGION_SIZE, PROT_READ, MAP_SHARED, fd, 0);
if (addr3 == MAP_FAILED)
perror("map 3 failed\n");
else
printf("map 3 prot-read passed as expected\n");
}

The output of running this program is as follows:
ret=3
map 0 passed
write passed
map 1 prot-write passed as expected
future-write seal now active
write failed as expected due to future-write seal
map 2 prot-write failed as expected due to seal
: Permission denied
map 3 prot-read passed as expected

Cc: jr...@google.com
Cc: john.stu...@linaro.org
Cc: tk...@google.com
Cc: gre...@linuxfoundation.org
Cc: h...@infradead.org
Reviewed-by: John Stultz 
Signed-off-by: Joel Fernandes (Google) 
---
v1->v2: No change, just added selftests to the series. manpages are
ready and I'll submit them once the patches are accepted.

v2->v3: Updated commit message to have more support code (John Stultz)
Renamed seal from F_SEAL_FS_WRITE to F_SEAL_FUTURE_WRITE
(Christoph Hellwig)
Allow for this seal only if grow/shrink seals are also
either previous set, or are requested along with this seal.
(Christoph Hellwig)
Added locking to synchronize access to file->f_mode.
(Christoph Hellwig)

 include/uapi/linux/fcntl.h |  1 +
 mm/memfd.c | 22 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 6448cdd9a350..a2f8658f1c55 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -41,6 +41,7 @@
 #define F_SEAL_SHRINK  0x0002  /* prevent file from shrinking */
 #define F_SEAL_GROW0x0004  /* prevent file from growing */
 #define F_SEAL_WRITE   0x0008  /* prevent writes */
+#define F_SEAL_FUTURE_WRITE   

[PATCH v3 resend 2/2] selftests/memfd: Add tests for F_SEAL_FUTURE_WRITE seal

[Joel Fernandes (Google)]

Add tests to verify sealing memfds with the F_SEAL_FUTURE_WRITE works as
expected.

Cc: dan...@google.com
Cc: minc...@kernel.org
Reviewed-by: John Stultz 
Signed-off-by: Joel Fernandes (Google) 
---
 tools/testing/selftests/memfd/memfd_test.c | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/tools/testing/selftests/memfd/memfd_test.c 
b/tools/testing/selftests/memfd/memfd_test.c
index 10baa1652fc2..32b207ca7372 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -692,6 +692,79 @@ static void test_seal_write(void)
close(fd);
 }
 
+/*
+ * Test SEAL_FUTURE_WRITE
+ * Test whether SEAL_FUTURE_WRITE actually prevents modifications.
+ */
+static void test_seal_future_write(void)
+{
+   int fd;
+   void *p;
+
+   printf("%s SEAL-FUTURE-WRITE\n", memfd_str);
+
+   fd = mfd_assert_new("kern_memfd_seal_future_write",
+   mfd_def_size,
+   MFD_CLOEXEC | MFD_ALLOW_SEALING);
+
+   p = mfd_assert_mmap_shared(fd);
+
+   mfd_assert_has_seals(fd, 0);
+   /* Not adding grow/shrink seals makes the future write
+* seal fail to get added
+*/
+   mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
+
+   mfd_assert_add_seals(fd, F_SEAL_GROW);
+   mfd_assert_has_seals(fd, F_SEAL_GROW);
+
+   /* Should still fail since shrink seal has
+* not yet been added
+*/
+   mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
+
+   mfd_assert_add_seals(fd, F_SEAL_SHRINK);
+   mfd_assert_has_seals(fd, F_SEAL_GROW |
+F_SEAL_SHRINK);
+
+   /* Now should succeed, also verifies that the seal
+* could be added with an existing writable mmap
+*/
+   mfd_assert_add_seals(fd, F_SEAL_FUTURE_WRITE);
+   mfd_assert_has_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+
+   /* read should pass, writes should fail */
+   mfd_assert_read(fd);
+   mfd_fail_write(fd);
+
+   munmap(p, mfd_def_size);
+   close(fd);
+
+   /* Test adding all seals (grow, shrink, future write) at once */
+   fd = mfd_assert_new("kern_memfd_seal_future_write2",
+   mfd_def_size,
+   MFD_CLOEXEC | MFD_ALLOW_SEALING);
+
+   p = mfd_assert_mmap_shared(fd);
+
+   mfd_assert_has_seals(fd, 0);
+   mfd_assert_add_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+   mfd_assert_has_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+
+   /* read should pass, writes should fail */
+   mfd_assert_read(fd);
+   mfd_fail_write(fd);
+
+   munmap(p, mfd_def_size);
+   close(fd);
+}
+
 /*
  * Test SEAL_SHRINK
  * Test whether SEAL_SHRINK actually prevents shrinking
@@ -945,6 +1018,7 @@ int main(int argc, char **argv)
test_basic();
 
test_seal_write();
+   test_seal_future_write();
test_seal_shrink();
test_seal_grow();
test_seal_resize();
-- 
2.19.1.930.g4563a0d9d0-goog

linux-next: Tree for Nov 8

[Stephen Rothwell]

Hi all,

Changes since 20181107:

The tip tree still had its build failure for which I applied a fix patch.

Non-merge commits (relative to Linus' tree): 1793
 1942 files changed, 81402 insertions(+), 84317 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 296 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (85758777c2a2 Merge tag 'hwmon-for-v4.20-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (02826a6ba301 kbuild: deb-pkg: fix bindeb-pkg 
breakage when O= is used)
Merging arc-current/for-curr (d94cf77e44d5 ARC: [plat-hsdk] Enable DW APB GPIO 
support)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject 
stand-alone CHAIN events for PMUv3)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (28c5bcf74fa0 KVM: PPC: Move and undef 
TRACE_INCLUDE_PATH/FILE)
Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and 
getsockname.)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (042cb5647815 net: phy: Allow BCM54616S PHY to setup 
internal TX/RX clock delay)
Merging bpf/master (ea53abfab960 bonding/802.3ad: fix link_failure_count 
tracking)
Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace)
Merging netfilter/master (a422757e8c32 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without 
CONFIG_LEDS_CLASS)
Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error 
paths for netlink)
Merging rdma-fixes/for-rc (651022382c7f Linux 4.20-rc1)
Merging sound-current/for-linus (5e93a125f521 ALSA: hda - Fix incorrect 
clearance of thinkpad_acpi hooks)
Merging sound-asoc-fixes/for-linus (bbb59292538e Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
Merging regulator-fixes/for-linus (651022382c7f Linux 4.20-rc1)
Merging spi-fixes/for-linus (40e5c5fa4d1b Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (651022382c7f Linux 4.20-rc1)
Merging driver-core.current/driver-core-linus (651022382c7f Linux 4.20-rc1)
Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on 
SCIFA/SCIFB variants with DMA)
Merging usb.current/usb-linus (f6501f491990 USB: misc: appledisplay: add 20" 
Apple Cinema Display)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (651022382c7f Linux 4.20-rc1)
Merging staging.current/staging-linus (c948c6915b62 staging: rtl8723bs: Fix

Re: [PATCH v3 1/4] dt-bindings: pinctrl: Add devicetree bindings for MT6797 SoC Pinctrl

[Manivannan Sadhasivam]

On Thu, Nov 08, 2018 at 10:11:12AM +0800, Yingjoe Chen wrote:
> On Wed, 2018-11-07 at 23:18 +0530, Manivannan Sadhasivam wrote:
> > Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
> > 
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  .../bindings/pinctrl/pinctrl-mt6797.txt   |   83 +
> >  include/dt-bindings/pinctrl/mt6797-pinfunc.h  | 1368 +
> >  2 files changed, 1451 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt
> >  create mode 100644 include/dt-bindings/pinctrl/mt6797-pinfunc.h
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt
> > new file mode 100644
> > index ..bd83401e6179
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt
> 
> Sorry if this is discussed.
> 
> What's the difference between this and
> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt?
> Should this be added to pinctrl-mt65xx.txt?
>

Currently there are 3 different pinctrl core's available for MediaTek
SoCs:

1. Legacy core - pinctrl-mtk-common.c
2. Moore core - pinctrl-moore.c pinctrl-mtk-common-v2.c
3. Paris core - pinctrl-paris.c pinctrl-mtk-common-v2.c

AFAIU pinctrl-mt65xx binding documents the SoC's based on MediaTek's legacy
pinctrl-mtk-common.c core. Whereas MT6797 is based on the MediaTek's Paris
core. There isn't any binding doc available for the Paris core SoC's yet.
That's why I have created a new bindings doc and expecting the remaining SoC's
of Paris family to be included in new pinctrl-mt6797.txt.

Hope this makes clear!

Thanks,
Mani

> Joe.C
> 
> 

Re: [PATCH v2] ext4: lost brelse in __ext4_read_dirblock()

[Theodore Y. Ts'o]

On Wed, Nov 07, 2018 at 08:30:17PM +0300, Vasily Averin wrote:
> Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
> Cc: sta...@kernel.org # 3.9
> 
> Signed-off-by: Vasily Averin 

Thanks, applied.  I used the commit description:

ext4: fix buffer leak in __ext4_read_dirblock() on error path

- Ted

linux-next: build warning after merge of the block tree

[Stephen Rothwell]

Hi Jens,

After merging the block tree, today's linux-next build (sparc64 defconfig)
produced this warning:

/home/sfr/next/next/drivers/block/sunvdc.c: In function 'init_queue':
/home/sfr/next/next/drivers/block/sunvdc.c:788:6: warning: unused variable 
'ret' [-Wunused-variable]
  int ret;
  ^~~

Introduced by commit

  fa182a1fa97d ("sunvdc: convert to blk-mq")

-- 
Cheers,
Stephen Rothwell


pgpcSA3bQNAS_.pgp
Description: OpenPGP digital signature

Re: [PATCH 7/7] ext4: lost brelse in ext4_expand_extra_isize_ea()

[Theodore Y. Ts'o]

On Wed, Oct 31, 2018 at 10:13:09PM +0300, Vasily Averin wrote:
> Fixes de05ca852679 ("ext4: move call to ext4_error() into ...") # 4.17
> 
> Signed-off-by: Vasily Averin 

Thanks, applied.  I used the commit description:

ext4: fix buffer leak in ext4_expand_extra_isize_ea() on error path

- Ted

[PATCH] x86/kvm/vmx: fix old-style function declaration

[Yi Wang]

The inline keyword which is not at the beginning of the function
declaration may trigger the following build warnings, so let's fix it:

arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]
arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]
arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]
arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]

Signed-off-by: Yi Wang 
---
 arch/x86/kvm/vmx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4555077..cd8355b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1306,7 +1306,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
 static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
u16 error_code);
 static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
-static void __always_inline vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
+static __always_inline void vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
  u32 msr, int type);
 
 static DEFINE_PER_CPU(struct vmcs *, vmxarea);
@@ -5944,7 +5944,7 @@ static void free_vpid(int vpid)
spin_unlock(&vmx_vpid_lock);
 }
 
-static void __always_inline vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
+static __always_inline void vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
  u32 msr, int type)
 {
int f = sizeof(unsigned long);
@@ -5982,7 +5982,7 @@ static void __always_inline 
vmx_disable_intercept_for_msr(unsigned long *msr_bit
}
 }
 
-static void __always_inline vmx_enable_intercept_for_msr(unsigned long 
*msr_bitmap,
+static __always_inline void vmx_enable_intercept_for_msr(unsigned long 
*msr_bitmap,
 u32 msr, int type)
 {
int f = sizeof(unsigned long);
@@ -6020,7 +6020,7 @@ static void __always_inline 
vmx_enable_intercept_for_msr(unsigned long *msr_bitm
}
 }
 
-static void __always_inline vmx_set_intercept_for_msr(unsigned long 
*msr_bitmap,
+static __always_inline void vmx_set_intercept_for_msr(unsigned long 
*msr_bitmap,
  u32 msr, int type, bool 
value)
 {
if (value)
-- 
1.8.3.1

Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check more robust"

[Brian Norris]

On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson  wrote:
> On Wed, Nov 7, 2018 at 1:07 PM Genki Sky  wrote:
> > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck  wrote:
> > > Ubuntu 16.04 ships with git version 2.7.4.
> >
> > Okay. I guess --no-optional-locks is a no-go then.
>
> In theory you could wrap it.  If passing git with
> "--no-optional-locks" doesn't work you could fall back to the old
> code?  That would mean only people with newer git would get your new
> feature and everyone else would stick with the pre-existing behavior.

+1, that's what I was going to suggest. Presumably older git would
give non-zero exit status for unknown flags, and we take that as
signal to try to the old way?

Re: [LKP] d50d82faa0 [ 33.671845] WARNING: possible circular locking dependency detected

[Andrew Morton]

On Wed, 7 Nov 2018 15:43:36 -0800 Andrew Morton  
wrote:

> On Tue, 23 Oct 2018 08:30:04 +0800 kernel test robot  
> wrote:
> 
> > Greetings,
> > 
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > 
> > commit d50d82faa0c964e31f7a946ba8aba7c715ca7ab0
> > Author: Mikulas Patocka 
> > AuthorDate: Wed Jun 27 23:26:09 2018 -0700
> > Commit: Linus Torvalds 
> > CommitDate: Thu Jun 28 11:16:44 2018 -0700
> > 
> > slub: fix failure when we delete and create a slab cache
> 
> This is ugly.  Is there an alternative way of fixing the race which
> Mikulas attempted to address?  Possibly cancel the work and reuse the
> existing sysfs file, or is that too stupid to live?
> 
> 3b7b314053d021 ("slub: make sysfs file removal asynchronous") was
> pretty lame, really.  As mentioned,
> 
> : It'd be the cleanest to deal with the issue by removing sysfs files
> : without holding slab_mutex before the rest of shutdown; however, given
> : the current code structure, it is pretty difficult to do so.
> 
> Would be a preferable approach.
> 
> > 
> > This uncovered a bug in the slub subsystem - if we delete a cache and
> > immediatelly create another cache with the same attributes, it fails
> > because of duplicate filename in /sys/kernel/slab/.  The slub subsystem
> > offloads freeing the cache to a workqueue - and if we create the new
> > cache before the workqueue runs, it complains because of duplicate
> > filename in sysfs.

Alternatively, could we flush the workqueue before attempting to
(re)create the sysfs file?  Extra points for only doing this if the
first (re)creation attempt returned -EEXIST?

RE: [PATCH V2] binder: ipc namespace support for android binder

[周威]

> -Original Message-
> From: Andrew Morton 
> Sent: Thursday, November 8, 2018 6:38 AM
> To: chouryzhou(周威) 
> Cc: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> d...@stgolabs.net; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V2] binder: ipc namespace support for android
> binder
> 
> On Wed, 7 Nov 2018 01:48:12 + chouryzhou(周威)
>  wrote:
> 
> > > > --- a/ipc/namespace.c
> > > > +++ b/ipc/namespace.c
> > > > @@ -56,6 +56,9 @@ static struct ipc_namespace *create_ipc_ns(struct
> > > user_namespace *user_ns,
> > > > ns->ucounts = ucounts;
> > > >
> > > > err = mq_init_ns(ns);
> > > > +   if (err)
> > > > +   goto fail_put;
> > > > +   err = binder_init_ns(ns);
> > > > if (err)
> > > > goto fail_put;
> > > >
> > >
> > > Don't we need an mq_put_mnt() if binder_init_ns() fails?
> > >
> > > free_ipc_ns() seems to have forgotten about that too.  In which case it
> > > must be madly leaking mounts so probably I'm wrong.  Confused.
> > >
> >
> > mq_init_ns will do clean job if it failed, and as do binder_init_ns.
> 
> My point is that if mq_init_ns() succeeds and binder_init_ns() fails,
> we don't undo the effects of mq_init_ns()?

Oh, mq_put_mnt is called in put_ipc_ns. We should invoke put_ipc_ns if 
binder_init_ns fails. I will update the patch soon. Thank you very much for 
pointing out the issue.

[PATCH v2] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[honghui.zhang]

From: Honghui Zhang 

Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
DT parser.

Signed-off-by: Honghui Zhang 
---
 drivers/pci/controller/pcie-mediatek.c | 98 +-
 1 file changed, 24 insertions(+), 74 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 2a1f97c..0590a93 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -197,11 +197,7 @@ struct mtk_pcie_port {
  * @dev: pointer to PCIe device
  * @base: IO mapped register base
  * @free_ck: free-run reference clock
- * @io: IO resource
- * @pio: PIO resource
  * @mem: non-prefetchable memory resource
- * @busn: bus range
- * @offset: IO / Memory offset
  * @ports: pointer to PCIe port information
  * @soc: pointer to SoC-dependent operations
  */
@@ -210,14 +206,7 @@ struct mtk_pcie {
void __iomem *base;
struct clk *free_ck;
 
-   struct resource io;
-   struct resource pio;
struct resource mem;
-   struct resource busn;
-   struct {
-   resource_size_t mem;
-   resource_size_t io;
-   } offset;
struct list_head ports;
const struct mtk_pcie_soc *soc;
 };
@@ -1045,55 +1034,43 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
 {
struct device *dev = pcie->dev;
struct device_node *node = dev->of_node, *child;
-   struct of_pci_range_parser parser;
-   struct of_pci_range range;
-   struct resource res;
struct mtk_pcie_port *port, *tmp;
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+   struct list_head *windows = &host->windows;
+   struct resource_entry *win, *tmp_win;
+   resource_size_t io_base;
int err;
 
-   if (of_pci_range_parser_init(&parser, node)) {
-   dev_err(dev, "missing \"ranges\" property\n");
-   return -EINVAL;
-   }
+   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   windows, &io_base);
+   if (err)
+   return err;
 
-   for_each_of_pci_range(&parser, &range) {
-   err = of_pci_range_to_resource(&range, node, &res);
-   if (err < 0)
-   return err;
+   err = devm_request_pci_bus_resources(dev, windows);
+   if (err < 0)
+   return err;
 
-   switch (res.flags & IORESOURCE_TYPE_BITS) {
+   /* Get the I/O and memory ranges from DT */
+   resource_list_for_each_entry_safe(win, tmp_win, windows) {
+   switch (resource_type(win->res)) {
case IORESOURCE_IO:
-   pcie->offset.io = res.start - range.pci_addr;
-
-   memcpy(&pcie->pio, &res, sizeof(res));
-   pcie->pio.name = node->full_name;
-
-   pcie->io.start = range.cpu_addr;
-   pcie->io.end = range.cpu_addr + range.size - 1;
-   pcie->io.flags = IORESOURCE_MEM;
-   pcie->io.name = "I/O";
-
-   memcpy(&res, &pcie->io, sizeof(res));
+   err = devm_pci_remap_iospace(dev, win->res, io_base);
+   if (err) {
+   dev_warn(dev, "error %d: failed to map resource 
%pR\n",
+err, win->res);
+   resource_list_destroy_entry(win);
+   }
break;
-
case IORESOURCE_MEM:
-   pcie->offset.mem = res.start - range.pci_addr;
-
-   memcpy(&pcie->mem, &res, sizeof(res));
+   memcpy(&pcie->mem, win->res, sizeof(*win->res));
pcie->mem.name = "non-prefetchable";
break;
+   case IORESOURCE_BUS:
+   host->busnr = win->res->start;
+   break;
}
}
 
-   err = of_pci_parse_bus_range(node, &pcie->busn);
-   if (err < 0) {
-   dev_err(dev, "failed to parse bus ranges property: %d\n", err);
-   pcie->busn.name = node->name;
-   pcie->busn.start = 0;
-   pcie->busn.end = 0xff;
-   pcie->busn.flags = IORESOURCE_BUS;
-   }
-
for_each_available_child_of_node(node, child) {
int slot;
 
@@ -1125,28 +1102,6 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
return 0;
 }
 
-static int mtk_pcie_request_resources(struct mtk_pcie *pcie)
-{
-   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
-   struct list_head *windows = &host->windows;
-   struct device *dev = pcie->dev;
-   int err;
-
-   pci_add_resource_offset(windows, &pcie->pio, pcie->offset.io);
-   pci_add_resource_offset(windows, &pcie->mem, pcie->offset.

Re: virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON discussion

[Wei Wang]

On 11/08/2018 10:50 AM, Michael S. Tsirkin wrote:

On Thu, Nov 08, 2018 at 10:49:20AM +0800, Wei Wang wrote:

On 11/07/2018 11:27 PM, Michael S. Tsirkin wrote:

+ LKML


On Wed, Nov 07, 2018 at 02:29:02PM +, Wang, Wei W wrote:

Hi Michael,


Thanks again for reviewing so many versions of patches, and I learnt a lot from
your comments.


While I’m writing the virtio-balloon spec patches, I’m thinking probably we
don’t need VIRTIO_BALLOON_F_PAGE_POISON to limit
VIRTIO_BALLOON_F_FREE_PAGE_HINT, because now the guest frees the allocated
pages after the migration is done (that is, the skipped free pages will be
poisoned when the guest is already on the destination machine).

The concern was this:

guest poisons the page by writing a non-0 pattern there
guest sends page to host
VM is migrated, page is unmapped
guest reads page, zero page is mapped

Not sure about this one: I think guest wouldn't read the page,
since they are held by balloon (balloon itself will also
not read it, the page just stays on a list waiting to be freed).
Please see the below example.


guest sees 0 in page and detects it as use after free

  - balloon collects (i.e. alloc) a free page X (now it
has 0xaa poison value) and reports X to host to be skipped in
migration;
  -  Now VM is migrated to the destination, and on the destination
 side, X is not mapped initially.
  -  Nobody will access X since it has been taken by balloon
 and stays on a list waiting to be freed. So the first chance
 that will get X mapped will be the moment that balloon
 returns X to mm via free(), as free() writes the
 poison value to X.


Best,
Wei


Oh I see, that was with the previous design where we bypassed alloc.
I think you are right, but better stress-test it.



Sure, will do.

Best,
Wei

Re: [PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Wed, 2018-11-07 at 12:03 +, Lorenzo Pieralisi wrote:
> On Thu, Oct 18, 2018 at 11:23:34AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 109 
> > +
> >  1 file changed, 29 insertions(+), 80 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 2a1f97c..6632d4e 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -197,29 +197,20 @@ struct mtk_pcie_port {
> >   * @dev: pointer to PCIe device
> >   * @base: IO mapped register base
> >   * @free_ck: free-run reference clock
> > - * @io: IO resource
> > - * @pio: PIO resource
> >   * @mem: non-prefetchable memory resource
> > - * @busn: bus range
> > - * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> >   * @soc: pointer to SoC-dependent operations
> > + * @busnr: root bus number
> >   */
> >  struct mtk_pcie {
> > struct device *dev;
> > void __iomem *base;
> > struct clk *free_ck;
> >  
> > -   struct resource io;
> > -   struct resource pio;
> > struct resource mem;
> > -   struct resource busn;
> > -   struct {
> > -   resource_size_t mem;
> > -   resource_size_t io;
> > -   } offset;
> > struct list_head ports;
> > const struct mtk_pcie_soc *soc;
> > +   int busnr;
> 
> If you move the code initializing and probing the pci_host_bridge into
> mtk_pcie_setup() (and rename that function) this variable becomes
> useless. It should be an unsigned int, by the way.

Yes, I can directly assign the busnr to host->busnr in the
mtk_pcie_setup and remove this variable.

Thanks.

> 
> >  };
> >  
> >  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> > @@ -1045,55 +1036,42 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > struct device_node *node = dev->of_node, *child;
> > -   struct of_pci_range_parser parser;
> > -   struct of_pci_range range;
> > -   struct resource res;
> > struct mtk_pcie_port *port, *tmp;
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = &host->windows;
> > +   struct resource_entry *win, *tmp_win;
> > +   resource_size_t io_base;
> > int err;
> >  
> > -   if (of_pci_range_parser_init(&parser, node)) {
> > -   dev_err(dev, "missing \"ranges\" property\n");
> > -   return -EINVAL;
> > -   }
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   windows, &io_base);
> > +   if (err)
> > +   return err;
> >  
> > -   for_each_of_pci_range(&parser, &range) {
> > -   err = of_pci_range_to_resource(&range, node, &res);
> > -   if (err < 0)
> > -   return err;
> > +   err = devm_request_pci_bus_resources(dev, windows);
> > +   if (err < 0)
> > +   return err;
> >  
> > -   switch (res.flags & IORESOURCE_TYPE_BITS) {
> > +   /* Get the I/O and memory ranges from DT */
> > +   resource_list_for_each_entry_safe(win, tmp_win, windows) {
> > +   switch (resource_type(win->res)) {
> > case IORESOURCE_IO:
> > -   pcie->offset.io = res.start - range.pci_addr;
> > -
> > -   memcpy(&pcie->pio, &res, sizeof(res));
> > -   pcie->pio.name = node->full_name;
> > -
> > -   pcie->io.start = range.cpu_addr;
> > -   pcie->io.end = range.cpu_addr + range.size - 1;
> > -   pcie->io.flags = IORESOURCE_MEM;
> > -   pcie->io.name = "I/O";
> > -
> > -   memcpy(&res, &pcie->io, sizeof(res));
> > -   break;
> > -
> > +   err = devm_pci_remap_iospace(dev, win->res, io_base);
> > +   if (err) {
> > +   dev_warn(dev, "error %d: failed to map resource 
> > %pR\n",
> > +err, win->res);
> > +   resource_list_destroy_entry(win);
> > +   }
> 
> Missing a break.

Thanks.
> 
> > case IORESOURCE_MEM:
> > -   pcie->offset.mem = res.start - range.pci_addr;
> > -
> > -   memcpy(&pcie->mem, &res, sizeof(res));
> > +   memcpy(&pcie->mem, win->res, sizeof(*win->res));
> > pcie->mem.name = "non-prefetchable";
> > break;
> > +   case IORESOURCE_BUS:
> > +   pcie->busnr = win->res->start;
> > +   break;
> > }
> > }
> >  
> > -   err = of_pci_parse_bus_range(node, &pcie->busn);
> > -   if (err < 0) {
> > -   dev_err(dev, "failed to pa

[PATCH net-next v3 1/6] net/ncsi: Don't enable all channels when HWA available

[Samuel Mendoza-Jonas]

NCSI hardware arbitration allows multiple packages to be enabled at once
and share the same wiring. If the NCSI driver recognises that HWA is
available it unconditionally enables all packages and channels; but that
is a configuration decision rather than something required by HWA.
Additionally the current implementation will not failover on link events
which can cause connectivity to be lost unless the interface is manually
bounced.

Retain basic HWA support but remove the separate configuration path to
enable all channels, leaving this to be handled by a later
implementation.

Signed-off-by: Samuel Mendoza-Jonas 
---
 net/ncsi/ncsi-aen.c|  3 +--
 net/ncsi/ncsi-manage.c | 50 --
 2 files changed, 5 insertions(+), 48 deletions(-)

diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 25e483e8278b..65f47a648be3 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -86,8 +86,7 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
!(state == NCSI_CHANNEL_ACTIVE && !(data & 0x1)))
return 0;
 
-   if (!(ndp->flags & NCSI_DEV_HWA) &&
-   state == NCSI_CHANNEL_ACTIVE)
+   if (state == NCSI_CHANNEL_ACTIVE)
ndp->flags |= NCSI_DEV_RESHUFFLE;
 
ncsi_stop_channel_monitor(nc);
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index bfc43b28c7a6..d4e6e0f99097 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -113,10 +113,8 @@ static void ncsi_channel_monitor(struct timer_list *t)
default:
netdev_err(ndp->ndev.dev, "NCSI Channel %d timed out!\n",
   nc->id);
-   if (!(ndp->flags & NCSI_DEV_HWA)) {
-   ncsi_report_link(ndp, true);
-   ndp->flags |= NCSI_DEV_RESHUFFLE;
-   }
+   ncsi_report_link(ndp, true);
+   ndp->flags |= NCSI_DEV_RESHUFFLE;
 
ncsi_stop_channel_monitor(nc);
 
@@ -1050,35 +1048,6 @@ static bool ncsi_check_hwa(struct ncsi_dev_priv *ndp)
return false;
 }
 
-static int ncsi_enable_hwa(struct ncsi_dev_priv *ndp)
-{
-   struct ncsi_package *np;
-   struct ncsi_channel *nc;
-   unsigned long flags;
-
-   /* Move all available channels to processing queue */
-   spin_lock_irqsave(&ndp->lock, flags);
-   NCSI_FOR_EACH_PACKAGE(ndp, np) {
-   NCSI_FOR_EACH_CHANNEL(np, nc) {
-   WARN_ON_ONCE(nc->state != NCSI_CHANNEL_INACTIVE ||
-!list_empty(&nc->link));
-   ncsi_stop_channel_monitor(nc);
-   list_add_tail_rcu(&nc->link, &ndp->channel_queue);
-   }
-   }
-   spin_unlock_irqrestore(&ndp->lock, flags);
-
-   /* We can have no channels in extremely case */
-   if (list_empty(&ndp->channel_queue)) {
-   netdev_err(ndp->ndev.dev,
-  "NCSI: No available channels for HWA\n");
-   ncsi_report_link(ndp, false);
-   return -ENOENT;
-   }
-
-   return ncsi_process_next_channel(ndp);
-}
-
 static void ncsi_probe_channel(struct ncsi_dev_priv *ndp)
 {
struct ncsi_dev *nd = &ndp->ndev;
@@ -1156,10 +1125,7 @@ static void ncsi_probe_channel(struct ncsi_dev_priv *ndp)
 */
if (!ndp->active_package) {
ndp->flags |= NCSI_DEV_PROBED;
-   if (ncsi_check_hwa(ndp))
-   ncsi_enable_hwa(ndp);
-   else
-   ncsi_choose_active_channel(ndp);
+   ncsi_choose_active_channel(ndp);
return;
}
 
@@ -1592,7 +1558,6 @@ EXPORT_SYMBOL_GPL(ncsi_register_dev);
 int ncsi_start_dev(struct ncsi_dev *nd)
 {
struct ncsi_dev_priv *ndp = TO_NCSI_DEV_PRIV(nd);
-   int ret;
 
if (nd->state != ncsi_dev_state_registered &&
nd->state != ncsi_dev_state_functional)
@@ -1604,14 +1569,7 @@ int ncsi_start_dev(struct ncsi_dev *nd)
return 0;
}
 
-   if (ndp->flags & NCSI_DEV_HWA) {
-   netdev_info(ndp->ndev.dev, "NCSI: Enabling HWA mode\n");
-   ret = ncsi_enable_hwa(ndp);
-   } else {
-   ret = ncsi_choose_active_channel(ndp);
-   }
-
-   return ret;
+   return ncsi_choose_active_channel(ndp);
 }
 EXPORT_SYMBOL_GPL(ncsi_start_dev);
 
-- 
2.19.1

Re: virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON discussion

[Michael S. Tsirkin]

On Thu, Nov 08, 2018 at 10:49:20AM +0800, Wei Wang wrote:
> On 11/07/2018 11:27 PM, Michael S. Tsirkin wrote:
> 
> + LKML
> 
> > On Wed, Nov 07, 2018 at 02:29:02PM +, Wang, Wei W wrote:
> > > Hi Michael,
> > > 
> > > 
> > > Thanks again for reviewing so many versions of patches, and I learnt a 
> > > lot from
> > > your comments.
> > > 
> > > 
> > > While I’m writing the virtio-balloon spec patches, I’m thinking probably 
> > > we
> > > don’t need VIRTIO_BALLOON_F_PAGE_POISON to limit
> > > VIRTIO_BALLOON_F_FREE_PAGE_HINT, because now the guest frees the allocated
> > > pages after the migration is done (that is, the skipped free pages will be
> > > poisoned when the guest is already on the destination machine).
> > The concern was this:
> > 
> > guest poisons the page by writing a non-0 pattern there
> > guest sends page to host
> > VM is migrated, page is unmapped
> > guest reads page, zero page is mapped
> 
> Not sure about this one: I think guest wouldn't read the page,
> since they are held by balloon (balloon itself will also
> not read it, the page just stays on a list waiting to be freed).
> Please see the below example.
> 
> > guest sees 0 in page and detects it as use after free
> 
>  - balloon collects (i.e. alloc) a free page X (now it
>has 0xaa poison value) and reports X to host to be skipped in
>migration;
>  -  Now VM is migrated to the destination, and on the destination
> side, X is not mapped initially.
>  -  Nobody will access X since it has been taken by balloon
> and stays on a list waiting to be freed. So the first chance
> that will get X mapped will be the moment that balloon
> returns X to mm via free(), as free() writes the
> poison value to X.
> 
> 
> Best,
> Wei


Oh I see, that was with the previous design where we bypassed alloc.
I think you are right, but better stress-test it.

-- 
MST

[PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup

[Brian Norris]

EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
reasons, and there are very few cases in which they should be treated as
wakeup interrupts (particularly, when a certain
MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
mainline cros_ec_sensor driver yet). Most of the time, they are benign
sensor readings. In any case, the top-level cros_ec device doesn't know
enough to determine that they should wake the system, and so it should
not report the event. This would be the job of the cros_ec_sensors
driver to parse.

This patch adds checks to cros_ec_get_next_event() such that it doesn't
signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.

This patch is particularly relevant on devices like Scarlet (Rockchip
RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
reports sensor events much more frequently. This was causing
/sys/power/wakeup_count to increase very frequently, often needlessly
interrupting our ability to suspend the system.

Signed-off-by: Brian Norris 
---
v1 -> v2:
 * no change
---
 drivers/platform/chrome/cros_ec_proto.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index fff67b389c87..cc7baf0ecb3c 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -575,6 +575,7 @@ static int get_keyboard_state_event(struct cros_ec_device 
*ec_dev)
 
 int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event)
 {
+   u8 event_type;
u32 host_event;
int ret;
 
@@ -594,11 +595,22 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
bool *wake_event)
return ret;
 
if (wake_event) {
+   event_type = ec_dev->event_data.event_type;
host_event = cros_ec_get_host_event(ec_dev);
 
-   /* Consider non-host_event as wake event */
-   *wake_event = !host_event ||
- !!(host_event & ec_dev->host_event_wake_mask);
+   /*
+* Sensor events need to be parsed by the sensor sub-device.
+* Defer them, and don't report the wakeup here.
+*/
+   if (event_type == EC_MKBP_EVENT_SENSOR_FIFO)
+   *wake_event = false;
+   /* Masked host-events should not count as wake events. */
+   else if (host_event &&
+!(host_event & ec_dev->host_event_wake_mask))
+   *wake_event = false;
+   /* Consider all other events as wake events. */
+   else
+   *wake_event = true;
}
 
return ret;
-- 
2.19.1.930.g4563a0d9d0-goog

[PATCH net-next v3 2/6] net/ncsi: Probe single packages to avoid conflict

[Samuel Mendoza-Jonas]

Currently the NCSI driver sends a select-package command to all possible
packages simultaneously to discover what packages are available. However
at this stage in the probe process the driver does not know if
hardware arbitration is available: if it isn't then this process could
cause collisions on the RMII bus when packages try to respond.

Update the probe loop to probe each package one by one, and once
complete check if HWA is universally supported.

Signed-off-by: Samuel Mendoza-Jonas 
---
 net/ncsi/internal.h|  1 +
 net/ncsi/ncsi-manage.c | 85 +++---
 2 files changed, 31 insertions(+), 55 deletions(-)

diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index 1dae77c54009..ec65778c41f3 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -292,6 +292,7 @@ struct ncsi_dev_priv {
 #if IS_ENABLED(CONFIG_IPV6)
unsigned intinet6_addr_num;  /* Number of IPv6 addresses   */
 #endif
+   unsigned intpackage_probe_id;/* Current ID during probe*/
unsigned intpackage_num; /* Number of packages */
struct list_headpackages;/* List of packages   */
struct ncsi_channel *hot_channel;/* Channel was ever active*/
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index d4e6e0f99097..02421d1a22c9 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1079,67 +1079,28 @@ static void ncsi_probe_channel(struct ncsi_dev_priv 
*ndp)
nd->state = ncsi_dev_state_probe_package;
break;
case ncsi_dev_state_probe_package:
-   ndp->pending_req_num = 16;
+   ndp->pending_req_num = 1;
 
-   /* Select all possible packages */
nca.type = NCSI_PKT_CMD_SP;
nca.bytes[0] = 1;
+   nca.package = ndp->package_probe_id;
nca.channel = NCSI_RESERVED_CHANNEL;
-   for (index = 0; index < 8; index++) {
-   nca.package = index;
-   ret = ncsi_xmit_cmd(&nca);
-   if (ret)
-   goto error;
-   }
-
-   /* Disable all possible packages */
-   nca.type = NCSI_PKT_CMD_DP;
-   for (index = 0; index < 8; index++) {
-   nca.package = index;
-   ret = ncsi_xmit_cmd(&nca);
-   if (ret)
-   goto error;
-   }
-
+   ret = ncsi_xmit_cmd(&nca);
+   if (ret)
+   goto error;
nd->state = ncsi_dev_state_probe_channel;
break;
case ncsi_dev_state_probe_channel:
-   if (!ndp->active_package)
-   ndp->active_package = list_first_or_null_rcu(
-   &ndp->packages, struct ncsi_package, node);
-   else if (list_is_last(&ndp->active_package->node,
- &ndp->packages))
-   ndp->active_package = NULL;
-   else
-   ndp->active_package = list_next_entry(
-   ndp->active_package, node);
-
-   /* All available packages and channels are enumerated. The
-* enumeration happens for once when the NCSI interface is
-* started. So we need continue to start the interface after
-* the enumeration.
-*
-* We have to choose an active channel before configuring it.
-* Note that we possibly don't have active channel in extreme
-* situation.
-*/
+   ndp->active_package = ncsi_find_package(ndp,
+   ndp->package_probe_id);
if (!ndp->active_package) {
-   ndp->flags |= NCSI_DEV_PROBED;
-   ncsi_choose_active_channel(ndp);
-   return;
+   /* No response */
+   nd->state = ncsi_dev_state_probe_dp;
+   schedule_work(&ndp->work);
+   break;
}
-
-   /* Select the active package */
-   ndp->pending_req_num = 1;
-   nca.type = NCSI_PKT_CMD_SP;
-   nca.bytes[0] = 1;
-   nca.package = ndp->active_package->id;
-   nca.channel = NCSI_RESERVED_CHANNEL;
-   ret = ncsi_xmit_cmd(&nca);
-   if (ret)
-   goto error;
-
nd->state = ncsi_dev_state_probe_cis;
+   schedule_work(&ndp->work);
break;
case ncsi_dev_state_probe_cis:
ndp->pending_req_num = NCSI_RESERVED_CHANNEL;
@@ -1188,22 +1149,35 @@ static void ncsi_probe_channel(struct ncsi_dev_priv 
*ndp)
  

[PATCH net-next v3 0/6] net/ncsi: Allow enabling multiple packages & channels

[Samuel Mendoza-Jonas]

This series extends the NCSI driver to configure multiple packages
and/or channels simultaneously. Since the RFC series this includes a few
extra changes to fix areas in the driver that either made this harder or
were roadblocks due to deviations from the NCSI specification.

Patches 1 & 2 fix two issues where the driver made assumptions about the
capabilities of the NCSI topology.
Patches 3 & 4 change some internal semantics slightly to make multi-mode
easier.
Patch 5 introduces a cleaner way of reconfiguring the NCSI configuration
and keeping track of channel states.
Patch 6 implements the main multi-package/multi-channel configuration,
configured via the Netlink interface.

Readers who have an interesting NCSI setup - especially multi-package
with HWA - please test! I think I've covered all permutations but I
don't have infinite hardware to test on.

Changes in v2:
- Updated use of the channel lock in ncsi_reset_dev(), making the
channel invisible and leaving the monitor check to
ncsi_stop_channel_monitor().
- Fixed ncsi_channel_is_tx() to consider the state of channels in other
packages.
Changes in v3:
- Fixed bisectability bug in patch 1
- Consider channels on all packages in a few places when multi-package
is enabled.
- Avoid doubling up reset operations, and check the current driver state
before reset to let any running operations complete.
- Reorganise the LSC handler slightly to avoid enabling Tx twice.

Samuel Mendoza-Jonas (6):
  net/ncsi: Don't enable all channels when HWA available
  net/ncsi: Probe single packages to avoid conflict
  net/ncsi: Don't deselect package in suspend if active
  net/ncsi: Don't mark configured channels inactive
  net/ncsi: Reset channel state in ncsi_start_dev()
  net/ncsi: Configure multi-package, multi-channel modes with failover

 include/uapi/linux/ncsi.h |  15 ++
 net/ncsi/internal.h   |  19 +-
 net/ncsi/ncsi-aen.c   |  72 --
 net/ncsi/ncsi-manage.c| 511 ++
 net/ncsi/ncsi-netlink.c   | 233 ++---
 net/ncsi/ncsi-rsp.c   |   2 +-
 6 files changed, 646 insertions(+), 206 deletions(-)

-- 
2.19.1

[PATCH net-next v3 4/6] net/ncsi: Don't mark configured channels inactive

[Samuel Mendoza-Jonas]

The concepts of a channel being 'active' and it having link are slightly
muddled in the NCSI driver. Tweak this slightly so that
NCSI_CHANNEL_ACTIVE represents a channel that has been configured and
enabled, and NCSI_CHANNEL_INACTIVE represents a de-configured channel.
This distinction is important because a channel can be 'active' but have
its link down; in this case the channel may still need to be configured
so that it may receive AEN link-state-change packets.

Signed-off-by: Samuel Mendoza-Jonas 
---
 net/ncsi/ncsi-aen.c| 17 +++--
 net/ncsi/ncsi-manage.c |  3 +--
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 65f47a648be3..57f77e5d381a 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -57,6 +57,7 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
int state;
unsigned long old_data, data;
unsigned long flags;
+   bool had_link, has_link;
 
/* Find the NCSI channel */
ncsi_find_package_and_channel(ndp, h->common.channel, NULL, &nc);
@@ -73,6 +74,9 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
ncm->data[2] = data;
ncm->data[4] = ntohl(lsc->oem_status);
 
+   had_link = !!(old_data & 0x1);
+   has_link = !!(data & 0x1);
+
netdev_dbg(ndp->ndev.dev, "NCSI: LSC AEN - channel %u state %s\n",
   nc->id, data & 0x1 ? "up" : "down");
 
@@ -80,15 +84,16 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
state = nc->state;
spin_unlock_irqrestore(&nc->lock, flags);
 
-   if (!((old_data ^ data) & 0x1) || chained)
-   return 0;
-   if (!(state == NCSI_CHANNEL_INACTIVE && (data & 0x1)) &&
-   !(state == NCSI_CHANNEL_ACTIVE && !(data & 0x1)))
+   if (state == NCSI_CHANNEL_INACTIVE)
+   netdev_warn(ndp->ndev.dev,
+   "NCSI: Inactive channel %u received AEN!\n",
+   nc->id);
+
+   if ((had_link == has_link) || chained)
return 0;
 
-   if (state == NCSI_CHANNEL_ACTIVE)
+   if (had_link)
ndp->flags |= NCSI_DEV_RESHUFFLE;
-
ncsi_stop_channel_monitor(nc);
spin_lock_irqsave(&ndp->lock, flags);
list_add_tail_rcu(&nc->link, &ndp->channel_queue);
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index b8b4e765a04c..b9de5b78c4e9 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -916,12 +916,11 @@ static void ncsi_configure_channel(struct ncsi_dev_priv 
*ndp)
break;
}
 
+   nc->state = NCSI_CHANNEL_ACTIVE;
if (nc->modes[NCSI_MODE_LINK].data[2] & 0x1) {
hot_nc = nc;
-   nc->state = NCSI_CHANNEL_ACTIVE;
} else {
hot_nc = NULL;
-   nc->state = NCSI_CHANNEL_INACTIVE;
netdev_dbg(ndp->ndev.dev,
   "NCSI: channel %u link down after config\n",
   nc->id);
-- 
2.19.1

[PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes

[Brian Norris]

cros_ec_get_next_event() is documented to return 0 for success and
negative for errors. It currently returns negative for some errors, and
non-negative (number of bytes received) for success (including some "no
data available" responses as zero). This mostly works out OK, because the
callers were more or less ignoring the documentation, and only treating
positive values as success (and indepdently checking the modification of
'wakeup').

Let's button this up by avoiding pretending to handle event/wakeup
distinctions when no event info was retrieved (i.e., returned 0 bytes).
And fix the documentation of cros_ec_get_host_event() and
cros_ec_get_next_event() to accurately describe their behavior.

Signed-off-by: Brian Norris 
---
v1 -> v2:
 * don't make as many changes to the API -- just fix the documentation
   and a few corner cases instead
---
 drivers/platform/chrome/cros_ec_proto.c | 4 ++--
 include/linux/mfd/cros_ec.h | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index b6fd4838f60f..fff67b389c87 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -580,7 +580,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
bool *wake_event)
 
if (!ec_dev->mkbp_event_supported) {
ret = get_keyboard_state_event(ec_dev);
-   if (ret < 0)
+   if (ret <= 0)
return ret;
 
if (wake_event)
@@ -590,7 +590,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
bool *wake_event)
}
 
ret = get_next_event(ec_dev);
-   if (ret < 0)
+   if (ret <= 0)
return ret;
 
if (wake_event) {
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index e44e3ec8a9c7..de8b588c8776 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -317,7 +317,9 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev);
  * @wake_event: Pointer to a bool set to true upon return if the event might be
  *  treated as a wake event. Ignored if null.
  *
- * Return: 0 on success or negative error code.
+ * Return: negative error code on errors; 0 for no data; or else number of
+ * bytes received (i.e., an event was retrieved successfully). Event types are
+ * written out to @ec_dev->event_data.event_type on success.
  */
 int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
 
@@ -329,7 +331,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
bool *wake_event);
  * events raised and call the functions in the ec notifier. This function
  * is a helper to know which events are raised.
  *
- * Return: 0 on success or negative error code.
+ * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
  */
 u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
 
-- 
2.19.1.930.g4563a0d9d0-goog

Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code

[Vincent Chen]

On Wed, Nov 07, 2018 at 07:45:52AM +0800, Palmer Dabbelt wrote:
> On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@andestech.com wrote:
> > On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
> >> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> >> > On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> >> > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen  
> >> > > wrote:
> >> > > >
> >> > > >   RISC-V permits each vendor to develop respective extension ISA 
> >> > > > based
> >> > > > on RISC-V standard ISA. This means that these vendor-specific 
> >> > > > features
> >> > > > may be compatible to their compiler and CPU. Therefore, each vendor 
> >> > > > may
> >> > > > be considered a sub-architecture of RISC-V. Currently, vendors do not
> >> > > > have the appropriate examples to add these specific features to the
> >> > > > kernel. In this RFC set, we propose an infrastructure that vendor can
> >> > > > easily hook their specific features into kernel. The first commit is
> >> > > > the main body of this infrastructure. In the second commit, we 
> >> > > > provide
> >> > > > a solution that allows dma_map_ops() to work without cache coherent
> >> > > > agent support. Cache coherent agent is unsupported for low-end CPUs 
> >> > > > in
> >> > > > the AndeStar RISC-V series. In order for Linux to run on these CPUs, 
> >> > > > we
> >> > > > need this solution to overcome the limitation of cache coherent agent
> >> > > > support. Hence, it also can be used as an example for the first 
> >> > > > commit.
> >> > > >
> >> > > >   I am glad to discuss any ideas, so if you have any idea, please 
> >> > > > give
> >> > > > me some feedback.
> >> > > >
> >> > > I agree that we need a place for vendor-specific ISA extensions and
> >> > > having vendor-specific directories is also good.
> >> > >
> >> > > What I don't support is the approach of having compile time selection
> >> > > of vendor-specific ISA extension.
> >> > >
> >> > > We should have runtime probing for compatible vendor-specific ISA
> >> > > extension. Also, it should be possible to link multiple vendor-specific
> >> > > SA extensions to same kernel image. This way we can have a single
> >> > > kernel image (along with various vendor-specific ISA extensions) which
> >> > > works on variety of targets/hosts.
> >> > >
> >> > > As an example or runtime probing you can look at how IRQCHIP or
> >> > > CLOCKSOURCE drivers are probed. The vendor-specific ISA extension
> >> > > hooks should called in similar fashion.
> >> >
> >> > Yes, I agree.  My biggest concern here is that we ensure that
> >> > one kernel can boot on implementations from all vendors.  I
> >> > haven't had a chance to look at the patches yet, but it should
> >> > be possible to:
> >> >
> >> > * Build a kernel that has vendor-specific code from multiple vendors.
> >> > * Detect the implementation an run time and select the correct extra
> >> >   code.
> >>
> >> From a distro point of view we definitely want to have one kernel
> >> image that is bootable everywhere.  Debian won't support any
> >> platform that requires a per-platform or per-vendor kernel, and I
> >> assume that the same will be true for Fedora and Suse.
> >>
> >> One thing that I have stumbled upon while looking at the patches
> >> is that they seem to assume that X-type ISA extensions are
> >> strictly per vendor.  Although that is probably true in the
> >> majority of cases, it doesn't necessarily have to be - I could
> >> e.g. imagine that the DSP extensions from the PULP cores might
> >> be used by multiple vendors.  If such an extension would have
> >> state that needs to be saved on context switch, it would need
> >> corresponding kernel support.  Using "PULP" (or any other
> >> open-source project) as the vendor in such a case leads to
> >> another potential issue: the patches base everything on a JEDEC
> >> vendor ID that is compared to the contents of the mvendorid CSR,
> >> but such a JEDEC vendor ID usually doesn't exist for open-source
> >> implementations; the majority of those have mvendorid set to
> >> zero.
> >>
> > Many thanks for kinds of comments. I quickly synthesize the comments and
> > list them as below.
> > 1. The kernel image shall include all vendor-specific code.
> > 2. This kernel image can only enable particular vendor-specific features
> >based on the CPU vendor in the running platform.
> >- The runtime probing mechanism can refer to arm32/arm64, powerpc,
> >  IRQCHIP driver or CLOCKSOURCE driver
> >- For some cases, such as open-source projects, using CSR $mvendorid
> >  to identify the compatibility is not appropriate.
> > I think the above requirements are reasonable, but I have questions about
> > the first requirement in practice. As far as I know, vendors are allowed
> > to add specific instructions and CSRs which are incompatible with other
> > vendors to their own ISA extensions. If I understand the first requirement
> >

Re: virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON discussion

[Wei Wang]

On 11/07/2018 11:27 PM, Michael S. Tsirkin wrote:

+ LKML


On Wed, Nov 07, 2018 at 02:29:02PM +, Wang, Wei W wrote:

Hi Michael,

  


Thanks again for reviewing so many versions of patches, and I learnt a lot from
your comments.

  


While I’m writing the virtio-balloon spec patches, I’m thinking probably we
don’t need VIRTIO_BALLOON_F_PAGE_POISON to limit
VIRTIO_BALLOON_F_FREE_PAGE_HINT, because now the guest frees the allocated
pages after the migration is done (that is, the skipped free pages will be
poisoned when the guest is already on the destination machine).

The concern was this:

guest poisons the page by writing a non-0 pattern there
guest sends page to host
VM is migrated, page is unmapped
guest reads page, zero page is mapped


Not sure about this one: I think guest wouldn't read the page,
since they are held by balloon (balloon itself will also
not read it, the page just stays on a list waiting to be freed).
Please see the below example.


guest sees 0 in page and detects it as use after free


 - balloon collects (i.e. alloc) a free page X (now it
   has 0xaa poison value) and reports X to host to be skipped in
   migration;
 -  Now VM is migrated to the destination, and on the destination
side, X is not mapped initially.
 -  Nobody will access X since it has been taken by balloon
and stays on a list waiting to be freed. So the first chance
that will get X mapped will be the moment that balloon
returns X to mm via free(), as free() writes the
poison value to X.


Best,
Wei

Re: [PATCH v3] driver-staging: vsoc.c: Add sysfs support for examining the permissions of regions.

[Greg Kroah-Hartman]

On Thu, Nov 08, 2018 at 08:49:41AM +0800, wahahab wrote:
> 
> > On 7 Nov 2018, at 5:15 PM, Greg Kroah-Hartman  wrote:
> > 
> > On Wed, Nov 07, 2018 at 10:30:43AM +0800, Jerry Lin wrote:
> >> Add a attribute called permissions under vsoc device node for examining
> >> current granted permissions in vsoc_device.
> >> 
> >> This file will display permissions in following format:
> >> begin_offset  end_offset  owner_offset  owned_value
> >>   %x  %x%x   %x
> >> 
> >> Signed-off-by: Jerry Lin 
> >> ---
> >> drivers/staging/android/vsoc.c | 48 
> >> +++---
> >> 1 file changed, 45 insertions(+), 3 deletions(-)
> > 
> > What changed from v2?  And where was v2?  What about v1?
> > 
> > You need a change log here of what you did different from the previous
> > patches.
> 
> Sorry for the mistakes I made, I shall read the document about patches more 
> carefully.
> Here is the change logs:
> 
> Changes in v2:
>   - Display permissions information in sysfs insureds of debufs.
> Changes in v3:
>   - Remove unnecessary null terminator after snprintf.
> 
> > 
> > And why ignore my response saying that this type of sysfs file is not ok
> > at all?
> > 
> 
> I didn’t mean to ignore it but I haven’t receive the response you described,
> May you send the response to me again so I can do further revision as well as
> change logs and resubmit the patch again?

You can not have multiple values in a single sysfs file.  sysfs is "one
value per file".  This needs to be individual files, if you really need
this.  And never a "header" for a sysfs file, that's never something
that should ever be in a sysfs file.

And finally, you need a Documentation/ABI/ update for any sysfs file
changes.

thanks,

greg k-h