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(>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 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(>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 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 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] 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 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/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 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 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 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 = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> };
> +
> +   speaker_amp: speaker_amp {
> +   compatible = "simple-audio-amplifier";
> +   enable-gpios = < 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.

> +   };
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
>  };
>
>   {
> @@ -267,6 +284,31 @@
> vcc-hdmi-supply = <_dldo1>;
>  };
>
> + {
> +   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 = <_analog>, <_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

> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pb_pins>;
> --
> 2.19.1
>

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 = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> };
> +
> +   speaker_amp: speaker_amp {
> +   compatible = "simple-audio-amplifier";
> +   enable-gpios = < 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.

> +   };
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
>  };
>
>   {
> @@ -267,6 +284,31 @@
> vcc-hdmi-supply = <_dldo1>;
>  };
>
> + {
> +   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 = <_analog>, <_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

> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_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 @@
> > };
> >  };
> >
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_analog {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > status = "okay";
> >  };
> > @@ -264,6 +276,22 @@
> > status = "disabled";
> >  };
> >
> > + {
> > +   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 */
> >   {
> > 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 @@
> > };
> >  };
> >
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_analog {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > status = "okay";
> >  };
> > @@ -164,6 +176,22 @@
> > vcc-hdmi-supply = <_dldo1>;
> >  };
> >
> > + {
> > +   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";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_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 @@
> > };
> >  };
> >
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_analog {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > status = "okay";
> >  };
> > @@ -264,6 +276,22 @@
> > status = "disabled";
> >  };
> >
> > + {
> > +   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 */
> >   {
> > 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 @@
> > };
> >  };
> >
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_analog {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > status = "okay";
> >  };
> > @@ -164,6 +176,22 @@
> > vcc-hdmi-supply = <_dldo1>;
> >  };
> >
> > + {
> > +   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";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_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] 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 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: [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(, new_node_page, NULL, 0,
>   MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> - if (ret)
> + if (ret) {
> + list_for_each_entry(page, , 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();
> + }
>   }
>  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: [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(, new_node_page, NULL, 0,
>   MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
> - if (ret)
> + if (ret) {
> + list_for_each_entry(page, , 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();
> + }
>   }
>  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(_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(_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(_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 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(_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(_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(_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 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 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -264,6 +276,22 @@
> status = "disabled";
>  };
>
> + {
> +   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 */
>   {
> 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 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -164,6 +176,22 @@
> vcc-hdmi-supply = <_dldo1>;
>  };
>
> + {
> +   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";
> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pb_pins>;
> --
> 2.19.1
>

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 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -264,6 +276,22 @@
> status = "disabled";
>  };
>
> + {
> +   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 */
>   {
> 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 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> +_analog {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -164,6 +176,22 @@
> vcc-hdmi-supply = <_dldo1>;
>  };
>
> + {
> +   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";
> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_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 = 
>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, 
);
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  
 _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

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 = 
>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, 
);
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  
 _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(_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(_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(_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

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(_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(_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(_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 = < RPM_SMD_LN_BB_CLK>,
+< GCC_USB_HS_PHY_CFG_AHB_CLK>,
+< GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "phy", "sleep";
+   resets = < GCC_USB_HS_PHY_CFG_AHB_BCR>,
+< GCC_USB2A_PHY_BCR>;
+   reset-names = "phy", "por";
+   vdd-supply = <_l4_1p2>;
+   vdda1p8-supply = <_l5_1p8>;
+   vdda3p3-supply = <_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:
+   

[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

[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 = < RPM_SMD_LN_BB_CLK>,
+< GCC_USB_HS_PHY_CFG_AHB_CLK>,
+< GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "phy", "sleep";
+   resets = < GCC_USB_HS_PHY_CFG_AHB_BCR>,
+< GCC_USB2A_PHY_BCR>;
+   reset-names = "phy", "por";
+   vdd-supply = <_l4_1p2>;
+   vdda1p8-supply = <_l5_1p8>;
+   vdda3p3-supply = <_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:
+   

[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 

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 

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 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 = <>;
> +   simple-audio-card,bitclock-master = <>;
> +   simple-audio-card,mclk-fs = <512>;
> +   simple-audio-card,aux-devs = <_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 = <>;
> +   };
> +
> +   link_codec: simple-audio-card,codec {
> +   sound-dai = <>;
> +   };
> +   };
> +
> 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 = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
> +   clock-names = "apb", "mod";
> +   resets = < RST_BUS_CODEC>;
> +   reset-names = "rst";
> +   dmas = < 15>, < 15>;
> +   dma-names = "rx", "tx";
> +   status = "disabled";
> +   };
> +
> +   codec: codec@1c22e00 {
> +   #sound-dai-cells = <0>;
> +   compatible = "allwinner,sun8i-a33-codec";
> +   reg = <0x01c22e00 0x600>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_CODEC>, < 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 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 = <>;
> +   simple-audio-card,bitclock-master = <>;
> +   simple-audio-card,mclk-fs = <512>;
> +   simple-audio-card,aux-devs = <_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 = <>;
> +   };
> +
> +   link_codec: simple-audio-card,codec {
> +   sound-dai = <>;
> +   };
> +   };
> +
> 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 = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
> +   clock-names = "apb", "mod";
> +   resets = < RST_BUS_CODEC>;
> +   reset-names = "rst";
> +   dmas = < 15>, < 15>;
> +   dma-names = "rx", "tx";
> +   status = "disabled";
> +   };
> +
> +   codec: codec@1c22e00 {
> +   #sound-dai-cells = <0>;
> +   compatible = "allwinner,sun8i-a33-codec";
> +   reg = <0x01c22e00 0x600>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_CODEC>, < 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] 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

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).

[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 = < HSEM>;
> + clock-names = "hwspinlock";
> + status = "disabled";
> + };
> +
>   rcc: rcc@5000 {
>   compatible = "st,stm32mp1-rcc", "syscon";
>   reg = <0x5000 0x1000>;
> -- 
> 2.15.0
> 

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 = < 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

[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 = < HSEM>;
> + clock-names = "hwspinlock";
> + };
> -- 
> 2.15.0
> 

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 = < 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: 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(>bank);
> + if (ret) {
> + dev_err(>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(>dev);
> +
> + return 0;
> +}

Regards,
Bjorn

[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(>bank);
> + if (ret) {
> + dev_err(>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(>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.

--

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 = <>;
+   simple-audio-card,bitclock-master = <>;
+   simple-audio-card,mclk-fs = <512>;
+   simple-audio-card,aux-devs = <_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 = <>;
+   };
+
+   link_codec: simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
+   compatible = "allwinner,sun50i-a64-codec-i2s";
+   reg = <0x01c22c00 0x200>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+   clock-names = "apb", "mod";
+   resets = < RST_BUS_CODEC>;
+   reset-names = "rst";
+   dmas = < 15>, < 15>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   codec: codec@1c22e00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun8i-a33-codec";
+   reg = <0x01c22e00 0x600>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < 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 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 = <>;
+   simple-audio-card,bitclock-master = <>;
+   simple-audio-card,mclk-fs = <512>;
+   simple-audio-card,aux-devs = <_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 = <>;
+   };
+
+   link_codec: simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
+   compatible = "allwinner,sun50i-a64-codec-i2s";
+   reg = <0x01c22c00 0x200>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+   clock-names = "apb", "mod";
+   resets = < RST_BUS_CODEC>;
+   reset-names = "rst";
+   dmas = < 15>, < 15>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   codec: codec@1c22e00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun8i-a33-codec";
+   reg = <0x01c22e00 0x600>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < 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 = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
+
+   speaker_amp: speaker_amp {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
 };
 
  {
@@ -267,6 +284,31 @@
vcc-hdmi-supply = <_dldo1>;
 };
 
+ {
+   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 = <_analog>, <_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";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_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 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -264,6 +276,22 @@
status = "disabled";
 };
 
+ {
+   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 */
  {
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 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -164,6 +176,22 @@
vcc-hdmi-supply = <_dldo1>;
 };
 
+ {
+   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";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
-- 
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 = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
+
+   speaker_amp: speaker_amp {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
 };
 
  {
@@ -267,6 +284,31 @@
vcc-hdmi-supply = <_dldo1>;
 };
 
+ {
+   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 = <_analog>, <_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";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_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 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -264,6 +276,22 @@
status = "disabled";
 };
 
+ {
+   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 */
  {
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 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_analog {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -164,6 +176,22 @@
vcc-hdmi-supply = <_dldo1>;
 };
 
+ {
+   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";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_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: 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: [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

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 = <>;
+   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 0x00
+   

[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 = <>;
+   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 0x00
+   

[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

[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