Re: general protection fault in blkcipher_walk_done (2)

[Eric Biggers]

On Wed, Jan 03, 2018 at 12:58:02AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 72bca2084a21edda74b802bc076083d5951f67b4
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9da652f470afd0313...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514967540.602:7): avc:  denied  { map } for
> pid=3499 comm="syzkaller241446" path="/root/syzkaller241446574"
> dev="sda1" ino=16481
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
> permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3499 Comm: syzkaller241446 Not tainted 4.15.0-rc5+ #173
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> RIP: 0010:scatterwalk_start include/crypto/scatterwalk.h:86 [inline]
> RIP: 0010:scatterwalk_pagedone include/crypto/scatterwalk.h:111 [inline]
> RIP: 0010:scatterwalk_done include/crypto/scatterwalk.h:119 [inline]
> RIP: 0010:blkcipher_walk_done+0x300/0xde0 crypto/blkcipher.c:124
> RSP: 0018:8801c027f340 EFLAGS: 00010202
> RAX:  RBX: a74a7bf1 RCX: 0001
> RDX: dc00 RSI: 0400 RDI: 0008
> RBP: 8801c027f390 R08: f8f8 R09: 
> R10: 0003 R11:  R12: 8801c027f640
> R13: 8801c027f4f0 R14: 8801c027f538 R15: 8801c027f518
> FS:  01046880() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 201c9000 CR3: 0001c09f5005 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  glue_ctr_crypt_128bit+0x597/0xc20 arch/x86/crypto/glue_helper.c:289
>  ctr_crypt+0x34/0x40 arch/x86/crypto/serpent_avx2_glue.c:168
>  __ablk_encrypt+0x1d1/0x2d0 crypto/ablk_helper.c:64
>  ablk_encrypt+0x23e/0x2c0 crypto/ablk_helper.c:84
>  skcipher_crypt_ablkcipher crypto/skcipher.c:712 [inline]
>  skcipher_decrypt_ablkcipher+0x312/0x420 crypto/skcipher.c:730
>  crypto_skcipher_decrypt include/crypto/skcipher.h:463 [inline]
>  chacha_decrypt crypto/chacha20poly1305.c:152 [inline]
>  poly_tail_continue+0x42a/0x6b0 crypto/chacha20poly1305.c:167
>  poly_tail+0x40f/0x520 crypto/chacha20poly1305.c:201
>  poly_cipherpad+0x33e/0x470 crypto/chacha20poly1305.c:231
>  poly_cipher+0x303/0x440 crypto/chacha20poly1305.c:262
>  poly_adpad+0x347/0x480 crypto/chacha20poly1305.c:292
>  poly_ad+0x25c/0x300 crypto/chacha20poly1305.c:316
>  poly_setkey+0x2fc/0x3e0 crypto/chacha20poly1305.c:343
>  poly_init+0x16c/0x1d0 crypto/chacha20poly1305.c:366
>  poly_genkey+0x422/0x590 crypto/chacha20poly1305.c:406
>  chachapoly_decrypt+0x73/0x90 crypto/chacha20poly1305.c:488
>  crypto_aead_decrypt include/crypto/aead.h:362 [inline]
>  _aead_recvmsg crypto/algif_aead.c:314 [inline]
>  aead_recvmsg+0x154a/0x1cf0 crypto/algif_aead.c:335
>  sock_recvmsg_nosec net/socket.c:801 [inline]
>  sock_recvmsg+0xc9/0x110 net/socket.c:808
>  ___sys_recvmsg+0x2a4/0x640 net/socket.c:2177
>  __sys_recvmsg+0xe2/0x210 net/socket.c:
>  SYSC_recvmsg net/socket.c:2234 [inline]
>  SyS_recvmsg+0x2d/0x50 net/socket.c:2229
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x43ff19
> RSP: 002b:7ffce23dfc18 EFLAGS: 0217 ORIG_RAX: 002f
> RAX: ffda RBX:  RCX: 0043ff19
> RDX:  RSI: 20318fc8 RDI: 0004
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0217 R12: 00401880
> R13: 00401910 R14:  R15: 
> Code: 00 fc ff df 48 c1 e9 03 80 3c 11 00 0f 85 7a 09 00 00 48 8d 78
> 08 48 ba 00 00 00 00 00 fc ff df 49 89 45 20 48 89 f9 48 c1 e9 03
> <0f> b6 14 11 84 d2 74 09 80 fa 03 0f 8e 3e 09 00 00 4c 89 f9 8b
> RIP: scatterwalk_start include/crypto/scatterwalk.h:86 [inline] RSP:
> 8801c027f340
> RIP: scatterwalk_pagedone include/crypto/scatterwalk.h:111 [inline]
> RSP: 8801c027f340
> RIP: scatterwalk_done include/crypto/scatterwalk.h:119 [inline] RSP:
> 8801c027f340
> RIP: blkcipher_walk_done+0x300/0xde0 crypto/blkcipher.c:124 RSP:
> 8801c027f340
> 

Re: general protection fault in blkcipher_walk_done (2)

[Eric Biggers]

On Wed, Jan 03, 2018 at 12:58:02AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 72bca2084a21edda74b802bc076083d5951f67b4
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9da652f470afd0313...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514967540.602:7): avc:  denied  { map } for
> pid=3499 comm="syzkaller241446" path="/root/syzkaller241446574"
> dev="sda1" ino=16481
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
> permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3499 Comm: syzkaller241446 Not tainted 4.15.0-rc5+ #173
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> RIP: 0010:scatterwalk_start include/crypto/scatterwalk.h:86 [inline]
> RIP: 0010:scatterwalk_pagedone include/crypto/scatterwalk.h:111 [inline]
> RIP: 0010:scatterwalk_done include/crypto/scatterwalk.h:119 [inline]
> RIP: 0010:blkcipher_walk_done+0x300/0xde0 crypto/blkcipher.c:124
> RSP: 0018:8801c027f340 EFLAGS: 00010202
> RAX:  RBX: a74a7bf1 RCX: 0001
> RDX: dc00 RSI: 0400 RDI: 0008
> RBP: 8801c027f390 R08: f8f8 R09: 
> R10: 0003 R11:  R12: 8801c027f640
> R13: 8801c027f4f0 R14: 8801c027f538 R15: 8801c027f518
> FS:  01046880() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 201c9000 CR3: 0001c09f5005 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  glue_ctr_crypt_128bit+0x597/0xc20 arch/x86/crypto/glue_helper.c:289
>  ctr_crypt+0x34/0x40 arch/x86/crypto/serpent_avx2_glue.c:168
>  __ablk_encrypt+0x1d1/0x2d0 crypto/ablk_helper.c:64
>  ablk_encrypt+0x23e/0x2c0 crypto/ablk_helper.c:84
>  skcipher_crypt_ablkcipher crypto/skcipher.c:712 [inline]
>  skcipher_decrypt_ablkcipher+0x312/0x420 crypto/skcipher.c:730
>  crypto_skcipher_decrypt include/crypto/skcipher.h:463 [inline]
>  chacha_decrypt crypto/chacha20poly1305.c:152 [inline]
>  poly_tail_continue+0x42a/0x6b0 crypto/chacha20poly1305.c:167
>  poly_tail+0x40f/0x520 crypto/chacha20poly1305.c:201
>  poly_cipherpad+0x33e/0x470 crypto/chacha20poly1305.c:231
>  poly_cipher+0x303/0x440 crypto/chacha20poly1305.c:262
>  poly_adpad+0x347/0x480 crypto/chacha20poly1305.c:292
>  poly_ad+0x25c/0x300 crypto/chacha20poly1305.c:316
>  poly_setkey+0x2fc/0x3e0 crypto/chacha20poly1305.c:343
>  poly_init+0x16c/0x1d0 crypto/chacha20poly1305.c:366
>  poly_genkey+0x422/0x590 crypto/chacha20poly1305.c:406
>  chachapoly_decrypt+0x73/0x90 crypto/chacha20poly1305.c:488
>  crypto_aead_decrypt include/crypto/aead.h:362 [inline]
>  _aead_recvmsg crypto/algif_aead.c:314 [inline]
>  aead_recvmsg+0x154a/0x1cf0 crypto/algif_aead.c:335
>  sock_recvmsg_nosec net/socket.c:801 [inline]
>  sock_recvmsg+0xc9/0x110 net/socket.c:808
>  ___sys_recvmsg+0x2a4/0x640 net/socket.c:2177
>  __sys_recvmsg+0xe2/0x210 net/socket.c:
>  SYSC_recvmsg net/socket.c:2234 [inline]
>  SyS_recvmsg+0x2d/0x50 net/socket.c:2229
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x43ff19
> RSP: 002b:7ffce23dfc18 EFLAGS: 0217 ORIG_RAX: 002f
> RAX: ffda RBX:  RCX: 0043ff19
> RDX:  RSI: 20318fc8 RDI: 0004
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0217 R12: 00401880
> R13: 00401910 R14:  R15: 
> Code: 00 fc ff df 48 c1 e9 03 80 3c 11 00 0f 85 7a 09 00 00 48 8d 78
> 08 48 ba 00 00 00 00 00 fc ff df 49 89 45 20 48 89 f9 48 c1 e9 03
> <0f> b6 14 11 84 d2 74 09 80 fa 03 0f 8e 3e 09 00 00 4c 89 f9 8b
> RIP: scatterwalk_start include/crypto/scatterwalk.h:86 [inline] RSP:
> 8801c027f340
> RIP: scatterwalk_pagedone include/crypto/scatterwalk.h:111 [inline]
> RSP: 8801c027f340
> RIP: scatterwalk_done include/crypto/scatterwalk.h:119 [inline] RSP:
> 8801c027f340
> RIP: blkcipher_walk_done+0x300/0xde0 crypto/blkcipher.c:124 RSP:
> 8801c027f340
> 

Re: [PATCH v2] dt: psci: Update DT bindings to support hierarchical PSCI states

[Rob Herring]

On Thu, Dec 28, 2017 at 03:40:37PM +0100, Ulf Hansson wrote:
> From: Lina Iyer 
> 
> Update DT bindings to represent hierarchical CPU and CPU domain idle states
> for PSCI. Also update the PSCI examples to clearly show how flattened and
> hierarchical idle states can be represented in DT.
> 
> Signed-off-by: Lina Iyer 
> Signed-off-by: Ulf Hansson 
> ---
> 
> Changes in v2:
>   - Addressed comments from Rob.
>   - Updated some labels in the examples to get more consistency.
> 
> For your information, I have picked up the work from Lina Iyer around the so
> called CPU cluster idling series [1,2] and I working on new versions. However,
> I decided to post the updates to the PSCI DT bindings first, as they will be
> needed to be agreed upon before further changes can be done to the PSCI 
> firmware
> driver.
> 
> Note, these bindings have been discussed over and over again, at LKML, but
> especially also at various Linux conferences, like LPC and Linaro Connect. We
> finally came to a conclusion and the changes we agreed upon, should be 
> reflected
> in this update.
> 
> Of course, it's a while ago since the latest discussions, but hopefully people
> don't have too hard time to remember.
> 
> Kind regards
> Uffe
> 
> [1]
> https://www.spinics.net/lists/arm-kernel/msg566200.html
> 
> [2]
> https://lwn.net/Articles/716300/
> 
> ---
>  Documentation/devicetree/bindings/arm/psci.txt | 152 
> +
>  1 file changed, 152 insertions(+)

Reviewed-by: Rob Herring 

I'd like to see some R-by by some of the ARM folks too.

Rob

Re: [PATCH v2] dt: psci: Update DT bindings to support hierarchical PSCI states

[Rob Herring]

On Thu, Dec 28, 2017 at 03:40:37PM +0100, Ulf Hansson wrote:
> From: Lina Iyer 
> 
> Update DT bindings to represent hierarchical CPU and CPU domain idle states
> for PSCI. Also update the PSCI examples to clearly show how flattened and
> hierarchical idle states can be represented in DT.
> 
> Signed-off-by: Lina Iyer 
> Signed-off-by: Ulf Hansson 
> ---
> 
> Changes in v2:
>   - Addressed comments from Rob.
>   - Updated some labels in the examples to get more consistency.
> 
> For your information, I have picked up the work from Lina Iyer around the so
> called CPU cluster idling series [1,2] and I working on new versions. However,
> I decided to post the updates to the PSCI DT bindings first, as they will be
> needed to be agreed upon before further changes can be done to the PSCI 
> firmware
> driver.
> 
> Note, these bindings have been discussed over and over again, at LKML, but
> especially also at various Linux conferences, like LPC and Linaro Connect. We
> finally came to a conclusion and the changes we agreed upon, should be 
> reflected
> in this update.
> 
> Of course, it's a while ago since the latest discussions, but hopefully people
> don't have too hard time to remember.
> 
> Kind regards
> Uffe
> 
> [1]
> https://www.spinics.net/lists/arm-kernel/msg566200.html
> 
> [2]
> https://lwn.net/Articles/716300/
> 
> ---
>  Documentation/devicetree/bindings/arm/psci.txt | 152 
> +
>  1 file changed, 152 insertions(+)

Reviewed-by: Rob Herring 

I'd like to see some R-by by some of the ARM folks too.

Rob

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Stephen Boyd]

On 01/03, Srinivas Kandagatla wrote:
> Thanks for your review comments,
> 
> On 03/01/18 17:20, Stephen Boyd wrote:
> >>+
> >>+   return ret;
> >>+}
> >>+
> >>+static int msm_snd_apq8096_probe(struct platform_device *pdev)
> >>+{
> >>+   int ret;
> >>+   struct snd_soc_card *card;
> >>+
> >>+   card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
> >>+   if (!card)
> >>+   return -ENOMEM;
> >>+
> >>+   card->dev = >dev;
> >>+
> >>+   ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> >
> >Why do we need to do this? Can you add some sort of comment in the code
> >about why?
> 
> Even though dsp supports 64 bit addresses, but the sid sits at
> offset of 32, which brings this restriction of supporting only 32
> bit iova.
> 

Doesn't the dsp have an iommu in place to make the address
translation from 64 to 32 bits transparent? I thought this was
what dma-ranges and iommu binding was for, but I'm not well
versed on all the details here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Stephen Boyd]

On 01/03, Srinivas Kandagatla wrote:
> Thanks for your review comments,
> 
> On 03/01/18 17:20, Stephen Boyd wrote:
> >>+
> >>+   return ret;
> >>+}
> >>+
> >>+static int msm_snd_apq8096_probe(struct platform_device *pdev)
> >>+{
> >>+   int ret;
> >>+   struct snd_soc_card *card;
> >>+
> >>+   card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
> >>+   if (!card)
> >>+   return -ENOMEM;
> >>+
> >>+   card->dev = >dev;
> >>+
> >>+   ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> >
> >Why do we need to do this? Can you add some sort of comment in the code
> >about why?
> 
> Even though dsp supports 64 bit addresses, but the sid sits at
> offset of 32, which brings this restriction of supporting only 32
> bit iova.
> 

Doesn't the dsp have an iommu in place to make the address
translation from 64 to 32 bits transparent? I thought this was
what dma-ranges and iommu binding was for, but I'm not well
versed on all the details here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors

[Tim Mouraveiko]

On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>AMD processors are not subject to the types of attacks that the kernel page 
>table isolation 
feature protects against.

There is no doubt this is a serious flaw. This thread reminded me - about a 
year ago we 
discovered a software code that bricked an Intel CPU. The software code was 
executed and 
the processor seized. The Motherboard was reset via the reset button, but the 
processor 
never came back. It was rather dead - the CPU did not even draw any power. We 
contacted 
Intel and one of their personnel suggested that they were aware of it. I never 
quite 
understood if it was a processor feature or a flaw.

Tim

Re: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors

[Tim Mouraveiko]

On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>AMD processors are not subject to the types of attacks that the kernel page 
>table isolation 
feature protects against.

There is no doubt this is a serious flaw. This thread reminded me - about a 
year ago we 
discovered a software code that bricked an Intel CPU. The software code was 
executed and 
the processor seized. The Motherboard was reset via the reset button, but the 
processor 
never came back. It was rather dead - the CPU did not even draw any power. We 
contacted 
Intel and one of their personnel suggested that they were aware of it. I never 
quite 
understood if it was a processor feature or a flaw.

Tim

Re: [RESEND PATCH v2 07/15] ASoC: qcom: q6asm: Add support to memory map and unmap

[Bjorn Andersson]

On Wed 03 Jan 08:26 PST 2018, Srinivas Kandagatla wrote:

> Thanks for your review comments.
> 
> On 02/01/18 05:48, Bjorn Andersson wrote:
> > On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:
[..]
> > > +int q6asm_unmap_memory_regions(unsigned int dir, struct audio_client *ac)
> > > +{
> > > + struct audio_port_data *port;
> > > + int cnt = 0;
> > > + int rc = 0;
> > > +
> > > + mutex_lock(>cmd_lock);
> > > + port = >port[dir];
> > > + if (!port->buf) {
> > > + mutex_unlock(>cmd_lock);
> > > + return 0;
> > 
> > Put a label right before the mutex_unlock below and return rc instead of
> > 0, then you can replace these two lines with "goto unlock"
> > 
> > > + }
> > > + cnt = port->max_buf_cnt - 1;
> > 
> > What if we mapped 1 period? Why shouldn't we enter the unmap path?
> > 
> It would enter into unmap path, as cnt  would be 0 for 1 period.
> 

You're right, I missed the = in the comparison, but I don't see a reason
to subtract 1. It seems like the max_buf_cnt might have been used
differently in the past?

I suggest that you drop the - 1 and change the comparison to cnt > 0, if
nothing else to not confuse me if I read this code again ;)

> > > + if (cnt >= 0) {
[..]
> > > +int q6asm_map_memory_regions(unsigned int dir, struct audio_client *ac,
> > > +  dma_addr_t phys,
> > > +  unsigned int period_sz, unsigned int periods)
[..]
> > > + ac->port[dir].max_buf_cnt = 0;
> > > + kfree(buf);
> > > + ac->port[dir].buf = NULL;
> > 
> > These operations are done without holding cmd_lock.
> > 
> I will revisit such instances where the buf is not protected.
> 

NB. I got the impression that cmd_lock was actually the port_lock in
most places.

Regards,
Bjorn

Re: [RESEND PATCH v2 07/15] ASoC: qcom: q6asm: Add support to memory map and unmap

[Bjorn Andersson]

On Wed 03 Jan 08:26 PST 2018, Srinivas Kandagatla wrote:

> Thanks for your review comments.
> 
> On 02/01/18 05:48, Bjorn Andersson wrote:
> > On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:
[..]
> > > +int q6asm_unmap_memory_regions(unsigned int dir, struct audio_client *ac)
> > > +{
> > > + struct audio_port_data *port;
> > > + int cnt = 0;
> > > + int rc = 0;
> > > +
> > > + mutex_lock(>cmd_lock);
> > > + port = >port[dir];
> > > + if (!port->buf) {
> > > + mutex_unlock(>cmd_lock);
> > > + return 0;
> > 
> > Put a label right before the mutex_unlock below and return rc instead of
> > 0, then you can replace these two lines with "goto unlock"
> > 
> > > + }
> > > + cnt = port->max_buf_cnt - 1;
> > 
> > What if we mapped 1 period? Why shouldn't we enter the unmap path?
> > 
> It would enter into unmap path, as cnt  would be 0 for 1 period.
> 

You're right, I missed the = in the comparison, but I don't see a reason
to subtract 1. It seems like the max_buf_cnt might have been used
differently in the past?

I suggest that you drop the - 1 and change the comparison to cnt > 0, if
nothing else to not confuse me if I read this code again ;)

> > > + if (cnt >= 0) {
[..]
> > > +int q6asm_map_memory_regions(unsigned int dir, struct audio_client *ac,
> > > +  dma_addr_t phys,
> > > +  unsigned int period_sz, unsigned int periods)
[..]
> > > + ac->port[dir].max_buf_cnt = 0;
> > > + kfree(buf);
> > > + ac->port[dir].buf = NULL;
> > 
> > These operations are done without holding cmd_lock.
> > 
> I will revisit such instances where the buf is not protected.
> 

NB. I got the impression that cmd_lock was actually the port_lock in
most places.

Regards,
Bjorn

Re: [PATCH] tty: fix data race in n_tty_receive_buf_common

[Alan Cox]

On Wed,  3 Jan 2018 19:18:52 +0530
Gaurav Kohli  wrote:

> There can be a race, if receive_buf call comes before
> tty initialization completes in n_tty_open and tty->disc_data
> may be NULL.


This makes no sense. If the race exists then the check you do isn't good
enough because the ldsic dsta isn't valid even after the initial
assignment of tty->disc_data.

More to the point no ldisc receive method should ever be getting called
during the ldisc open.  Likewise we must avoid hitting the window of the
old one closing (potentialyl stale disc_data from the old ldisc)

Any change to the ldisc is supposed to occur under tty->ldisc_sem and the
code does an ldisc_ref before invoking the ldisc method.

The only cases I can see where we set an ldisc are

1. tty_set_ldisc

This correctly takes an ldisc_ref so cannot run in parallel with
tty_port_default_receive_buf.

2. tty_init_dev when we set up a new tty

At that point the tty is not supposed to be receiving data and sure
enough we don't call tty->ops->open until it has finished the ldisc set
up, nor do we tty_init_dev a port that is already running.

So given we don't activate the port until tty->ops->open() calls
tty_port_open calls the port activation routine I don't see a bug.

3. tty_release()

Here we take the locks in tty_ldisc_release so that is ok

4. hangup

Again we take the ldisc lock



So unless your driver is stuffing bytes into the tty either before it's
been told too or after it's been told to shut up I don't see a bug. And
if you driver is doing either of those then it's broken. Even then
port->tty ought to be NULL.

What does a full (all CPU) trace of the bug look like and what tty driver
are you using when you capture the trace ?

Alan

Re: [PATCH] tty: fix data race in n_tty_receive_buf_common

[Alan Cox]

On Wed,  3 Jan 2018 19:18:52 +0530
Gaurav Kohli  wrote:

> There can be a race, if receive_buf call comes before
> tty initialization completes in n_tty_open and tty->disc_data
> may be NULL.


This makes no sense. If the race exists then the check you do isn't good
enough because the ldsic dsta isn't valid even after the initial
assignment of tty->disc_data.

More to the point no ldisc receive method should ever be getting called
during the ldisc open.  Likewise we must avoid hitting the window of the
old one closing (potentialyl stale disc_data from the old ldisc)

Any change to the ldisc is supposed to occur under tty->ldisc_sem and the
code does an ldisc_ref before invoking the ldisc method.

The only cases I can see where we set an ldisc are

1. tty_set_ldisc

This correctly takes an ldisc_ref so cannot run in parallel with
tty_port_default_receive_buf.

2. tty_init_dev when we set up a new tty

At that point the tty is not supposed to be receiving data and sure
enough we don't call tty->ops->open until it has finished the ldisc set
up, nor do we tty_init_dev a port that is already running.

So given we don't activate the port until tty->ops->open() calls
tty_port_open calls the port activation routine I don't see a bug.

3. tty_release()

Here we take the locks in tty_ldisc_release so that is ok

4. hangup

Again we take the ldisc lock



So unless your driver is stuffing bytes into the tty either before it's
been told too or after it's been told to shut up I don't see a bug. And
if you driver is doing either of those then it's broken. Even then
port->tty ought to be NULL.

What does a full (all CPU) trace of the bug look like and what tty driver
are you using when you capture the trace ?

Alan

Re: [PATCH v2 9/9] media: i2c: tw9910: Remove soc_camera dependencies

[jacopo mondi]

Hi Fabio,

On Wed, Jan 03, 2018 at 04:14:35PM -0200, Fabio Estevam wrote:
> On Wed, Jan 3, 2018 at 3:37 PM, jacopo mondi  wrote:
>
> >> Initially the rest GPIO was doing:
> >>
> >> -   gpio_set_value(GPIO_PTT3, 0);
> >> -   mdelay(10);
> >> -   gpio_set_value(GPIO_PTT3, 1);
> >> -   mdelay(10); /* wait to let chip come out of reset */
> >
> > And that's what my driver code does :)
>
> No, on 5/9 you converted the original code to:
>
> GPIO_LOOKUP("sh7722_pfc", GPIO_PTT3, "rstb", GPIO_ACTIVE_HIGH)
>
> It should be GPIO_ACTIVE_LOW instead.
>
> > My point is that if I read the manual and I see an active low gpio (0
> > is reset state) then the driver code uses it as and active high one (1
> > is the reset state), that would be weird to me.
>
> Then on this patch you should do:
>
> gpiod_set_value(priv->rstb_gpio, 1);  ---> This tells the GPIO to go
> to its active state (In this case active == logic level 0)
> usleep_range(500, 1000);
> gpiod_set_value(priv->rstb_gpio, 0); ---> This tells the GPIO to go to
> its inactive state (In this case inactive == logic level 1)
>
> You can also look at Documentation/gpio/consumer.txt where the usage
> of the gpiod_xxx API is described.
>
> It seems you are confusing it with the legacy gpio_set_value() API
> (Documentation/gpio/gpio-legacy.txt)

It took you 3 email messages, but maybe I finally got it.

So, 1 and 0 do not actually represent the line level but the active
or inactive states, that's fine. This seems to me a bit inconsistent with
the existence of flags like GPIOD_OUT_HIGH/LOW meant to be used at gpiod_get()
time, where the actual line level has to be used instead, but that's a
discussion surely not pertinent to this series.

Thanks for your patience.
j


>
> Hope this helps.

Re: [PATCH v2 9/9] media: i2c: tw9910: Remove soc_camera dependencies

[jacopo mondi]

Hi Fabio,

On Wed, Jan 03, 2018 at 04:14:35PM -0200, Fabio Estevam wrote:
> On Wed, Jan 3, 2018 at 3:37 PM, jacopo mondi  wrote:
>
> >> Initially the rest GPIO was doing:
> >>
> >> -   gpio_set_value(GPIO_PTT3, 0);
> >> -   mdelay(10);
> >> -   gpio_set_value(GPIO_PTT3, 1);
> >> -   mdelay(10); /* wait to let chip come out of reset */
> >
> > And that's what my driver code does :)
>
> No, on 5/9 you converted the original code to:
>
> GPIO_LOOKUP("sh7722_pfc", GPIO_PTT3, "rstb", GPIO_ACTIVE_HIGH)
>
> It should be GPIO_ACTIVE_LOW instead.
>
> > My point is that if I read the manual and I see an active low gpio (0
> > is reset state) then the driver code uses it as and active high one (1
> > is the reset state), that would be weird to me.
>
> Then on this patch you should do:
>
> gpiod_set_value(priv->rstb_gpio, 1);  ---> This tells the GPIO to go
> to its active state (In this case active == logic level 0)
> usleep_range(500, 1000);
> gpiod_set_value(priv->rstb_gpio, 0); ---> This tells the GPIO to go to
> its inactive state (In this case inactive == logic level 1)
>
> You can also look at Documentation/gpio/consumer.txt where the usage
> of the gpiod_xxx API is described.
>
> It seems you are confusing it with the legacy gpio_set_value() API
> (Documentation/gpio/gpio-legacy.txt)

It took you 3 email messages, but maybe I finally got it.

So, 1 and 0 do not actually represent the line level but the active
or inactive states, that's fine. This seems to me a bit inconsistent with
the existence of flags like GPIOD_OUT_HIGH/LOW meant to be used at gpiod_get()
time, where the actual line level has to be used instead, but that's a
discussion surely not pertinent to this series.

Thanks for your patience.
j


>
> Hope this helps.

[PATCH v3] ARM: dts: imx6: RDU2: disable internal watchdog

[Andrey Smirnov]

From: Lucas Stach 

The system has an external watchdog in the environment processor
so the internal watchdog is of no use.

Cc: Sascha Hauer 
Cc: Fabio Estevam 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Reviewed-by: Fabio Estevam 
Signed-off-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---

Changes since [v2]:

 - Collected Reviewed-by from Fabio

 - Moved wdog to be after audmux

Changes since [v1]:

 - Submission updated to have correct "From" field.

[v2] lkml.kernel.org/r/20180101212451.11516-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20171227035656.4941-2-andrew.smir...@gmail.com


 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 881c3ee71016..199fda67f84f 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -859,6 +859,10 @@
};
 };
 
+ {
+   status = "disabled";
+};
+
  {
pinctrl_accel: accelgrp {
fsl,pins = <
-- 
2.14.3

[PATCH v3] ARM: dts: imx6: RDU2: disable internal watchdog

[Andrey Smirnov]

From: Lucas Stach 

The system has an external watchdog in the environment processor
so the internal watchdog is of no use.

Cc: Sascha Hauer 
Cc: Fabio Estevam 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Reviewed-by: Fabio Estevam 
Signed-off-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---

Changes since [v2]:

 - Collected Reviewed-by from Fabio

 - Moved wdog to be after audmux

Changes since [v1]:

 - Submission updated to have correct "From" field.

[v2] lkml.kernel.org/r/20180101212451.11516-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20171227035656.4941-2-andrew.smir...@gmail.com


 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 881c3ee71016..199fda67f84f 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -859,6 +859,10 @@
};
 };
 
+ {
+   status = "disabled";
+};
+
  {
pinctrl_accel: accelgrp {
fsl,pins = <
-- 
2.14.3

Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()

[महेश बंडेवार]

On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring
 wrote:
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>> What is the issue with this message?
>
> * Is it redundant?
>
> * Would a Linux allocation failure report be already sufficient here?
>
If you see 8 out of 9 call sites in this file ignore the return value.
This message in the log could give a clue when debugging. Unless it's
spamming it's not harmful, or is it?

> Regards,
> Markus

Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()

[महेश बंडेवार]

On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring
 wrote:
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>> What is the issue with this message?
>
> * Is it redundant?
>
> * Would a Linux allocation failure report be already sufficient here?
>
If you see 8 out of 9 call sites in this file ignore the return value.
This message in the log could give a clue when debugging. Unless it's
spamming it's not harmful, or is it?

> Regards,
> Markus

Re: correct section for cpu_tss_rw?

[Thomas Gleixner]

On Tue, 2 Jan 2018, Nick Desaulniers wrote:
> (emailing the folks listed from running `./scripts/get_maintainer.pl
> -f` on arch/x86/kernel/process.c, arch/x86/include/asm/processor.h,
> and include/linux/percpu-defs.h)
> 
> Clang emits the following warning:
> 
> arch/x86/kernel/process.c:50:11: warning: section does not match
> previous declaration [-Wsection]
> __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss_rw) = {
>   ^
> ./include/linux/percpu-defs.h:144:2: note: expanded from macro
> 'DEFINE_PER_CPU_SHARED_ALIGNED'
> DEFINE_PER_CPU_SECTION(type, name, PER_CPU_SHARED_ALIGNED_SECTION) \
> ^
> ./include/linux/percpu-defs.h:104:2: note: expanded from macro
> 'DEFINE_PER_CPU_SECTION'
> __PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES\
> ^
> ./include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
> __percpu __attribute__((section(PER_CPU_BASE_SECTION sec))) \
> ^
> ./arch/x86/include/asm/processor.h:365:1: note: previous attribute is here
> DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss_rw);
> ^
> ./include/linux/percpu-defs.h:159:2: note: expanded from macro
> 'DECLARE_PER_CPU_PAGE_ALIGNED'
> DECLARE_PER_CPU_SECTION(type, name, "..page_aligned")   \
> ^
> ./include/linux/percpu-defs.h:101:9: note: expanded from macro
> 'DECLARE_PER_CPU_SECTION'
> extern __PCPU_ATTRS(sec) __typeof__(type) name
>^
> ./include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
> __percpu __attribute__((section(PER_CPU_BASE_SECTION sec))) \
> ^
> 
> it seems that from commit c482feefe1a ("x86/entry/64: Make
> cpu_entry_area.tss read-only") that cpu_tss_rw is declared but then
> defined in two different sections. (Though, it looks like this issue
> predates that commit).
>
> It seems that cpu_tss_rw is defined as SHARED_ALIGNED, but then
> declared as PAGE_ALIGNED.  Should be an easy fix (that I'm happy to
> author), but what section *should* cpu_tss_rw be in (SHARED_ALIGNED or
> PAGE_ALIGNED)?  That affects whether I fix the declaration or
> definition (and thus the .h or the .c file).
> 
> >From the comment in arch/x86/kernel/process.c#50:
>  43 /*
>  44  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
>  45  * no more per-task TSS's. The TSS size is kept cacheline-aligned
>  46  * so they are allowed to end up in the .data..cacheline_aligned
>  47  * section. Since TSS's are completely CPU-local, we want them
>  48  * on exact cacheline boundaries, to eliminate cacheline
> ping-pong.
>  49  */
>  50 __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss_rw) = {
> 
> I suspect that cache-line alignment is stricter than page alignment,
> so the declaration should be fixed, but I was not sure and wanted to
> check?

It must be page aligned.

Thanks,

tglx

Re: correct section for cpu_tss_rw?

[Thomas Gleixner]

On Tue, 2 Jan 2018, Nick Desaulniers wrote:
> (emailing the folks listed from running `./scripts/get_maintainer.pl
> -f` on arch/x86/kernel/process.c, arch/x86/include/asm/processor.h,
> and include/linux/percpu-defs.h)
> 
> Clang emits the following warning:
> 
> arch/x86/kernel/process.c:50:11: warning: section does not match
> previous declaration [-Wsection]
> __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss_rw) = {
>   ^
> ./include/linux/percpu-defs.h:144:2: note: expanded from macro
> 'DEFINE_PER_CPU_SHARED_ALIGNED'
> DEFINE_PER_CPU_SECTION(type, name, PER_CPU_SHARED_ALIGNED_SECTION) \
> ^
> ./include/linux/percpu-defs.h:104:2: note: expanded from macro
> 'DEFINE_PER_CPU_SECTION'
> __PCPU_ATTRS(sec) PER_CPU_DEF_ATTRIBUTES\
> ^
> ./include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
> __percpu __attribute__((section(PER_CPU_BASE_SECTION sec))) \
> ^
> ./arch/x86/include/asm/processor.h:365:1: note: previous attribute is here
> DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss_rw);
> ^
> ./include/linux/percpu-defs.h:159:2: note: expanded from macro
> 'DECLARE_PER_CPU_PAGE_ALIGNED'
> DECLARE_PER_CPU_SECTION(type, name, "..page_aligned")   \
> ^
> ./include/linux/percpu-defs.h:101:9: note: expanded from macro
> 'DECLARE_PER_CPU_SECTION'
> extern __PCPU_ATTRS(sec) __typeof__(type) name
>^
> ./include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
> __percpu __attribute__((section(PER_CPU_BASE_SECTION sec))) \
> ^
> 
> it seems that from commit c482feefe1a ("x86/entry/64: Make
> cpu_entry_area.tss read-only") that cpu_tss_rw is declared but then
> defined in two different sections. (Though, it looks like this issue
> predates that commit).
>
> It seems that cpu_tss_rw is defined as SHARED_ALIGNED, but then
> declared as PAGE_ALIGNED.  Should be an easy fix (that I'm happy to
> author), but what section *should* cpu_tss_rw be in (SHARED_ALIGNED or
> PAGE_ALIGNED)?  That affects whether I fix the declaration or
> definition (and thus the .h or the .c file).
> 
> >From the comment in arch/x86/kernel/process.c#50:
>  43 /*
>  44  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
>  45  * no more per-task TSS's. The TSS size is kept cacheline-aligned
>  46  * so they are allowed to end up in the .data..cacheline_aligned
>  47  * section. Since TSS's are completely CPU-local, we want them
>  48  * on exact cacheline boundaries, to eliminate cacheline
> ping-pong.
>  49  */
>  50 __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss_rw) = {
> 
> I suspect that cache-line alignment is stricter than page alignment,
> so the declaration should be fixed, but I was not sure and wanted to
> check?

It must be page aligned.

Thanks,

tglx

Re: CONFIG_PAGE_TABLE_ISOLATION=y on x86_64 causes gcc to segfault when building x86_32 binaries

[Thomas Gleixner]

On Wed, 3 Jan 2018, Thomas Gleixner wrote:

> On Wed, 3 Jan 2018, Lars Wendler wrote:
> > Am Wed, 3 Jan 2018 13:05:38 +0100 (CET)
> > schrieb Thomas Gleixner :
> > > Also can you please try Linus v4.15-rc6 with PTI enabled so we can see
> > > whether that's a backport issue or a general one?
> > 
> > Same problem with 4.15-rc6. So I suppose that means it's a general
> > issue.
> 
> Just a shot in the dark as I just decoded another issue on a AMD CPU. Can
> you please try the patch below?

Ok. Found the real issue. This is a problem on AMD boxen.

Fix below.

Can Xen folks please have a look at that as well?

Thanks,

tglx

8<---

arch/x86/entry/entry_64_compat.S |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -190,8 +190,13 @@ ENTRY(entry_SYSCALL_compat)
/* Interrupts are off on entry. */
swapgs
 
-   /* Stash user ESP and switch to the kernel stack. */
+   /* Stash user ESP */
movl%esp, %r8d
+
+   /* Use %rsp as scratch reg. User ESP is stashed in r8 */
+   SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
+   
+   /* Switch to the kernel stack */
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
/* Construct struct pt_regs on stack */
@@ -220,12 +225,6 @@ GLOBAL(entry_SYSCALL_compat_after_hwfram
pushq   $0  /* pt_regs->r15 = 0 */
 
/*
-* We just saved %rdi so it is safe to clobber.  It is not
-* preserved during the C calls inside TRACE_IRQS_OFF anyway.
-*/
-   SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
-
-   /*
 * User mode is traced as though IRQs are on, and SYSENTER
 * turned them off.
 */

Re: CONFIG_PAGE_TABLE_ISOLATION=y on x86_64 causes gcc to segfault when building x86_32 binaries

[Thomas Gleixner]

On Wed, 3 Jan 2018, Thomas Gleixner wrote:

> On Wed, 3 Jan 2018, Lars Wendler wrote:
> > Am Wed, 3 Jan 2018 13:05:38 +0100 (CET)
> > schrieb Thomas Gleixner :
> > > Also can you please try Linus v4.15-rc6 with PTI enabled so we can see
> > > whether that's a backport issue or a general one?
> > 
> > Same problem with 4.15-rc6. So I suppose that means it's a general
> > issue.
> 
> Just a shot in the dark as I just decoded another issue on a AMD CPU. Can
> you please try the patch below?

Ok. Found the real issue. This is a problem on AMD boxen.

Fix below.

Can Xen folks please have a look at that as well?

Thanks,

tglx

8<---

arch/x86/entry/entry_64_compat.S |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -190,8 +190,13 @@ ENTRY(entry_SYSCALL_compat)
/* Interrupts are off on entry. */
swapgs
 
-   /* Stash user ESP and switch to the kernel stack. */
+   /* Stash user ESP */
movl%esp, %r8d
+
+   /* Use %rsp as scratch reg. User ESP is stashed in r8 */
+   SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
+   
+   /* Switch to the kernel stack */
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
/* Construct struct pt_regs on stack */
@@ -220,12 +225,6 @@ GLOBAL(entry_SYSCALL_compat_after_hwfram
pushq   $0  /* pt_regs->r15 = 0 */
 
/*
-* We just saved %rdi so it is safe to clobber.  It is not
-* preserved during the C calls inside TRACE_IRQS_OFF anyway.
-*/
-   SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
-
-   /*
 * User mode is traced as though IRQs are on, and SYSENTER
 * turned them off.
 */

Re: [PATCH v2 9/9] ASoC: Intel: kconfig: add some comments for if symbols

[Randy Dunlap]

On 01/03/2018 08:50 AM, Pierre-Louis Bossart wrote:
> From: Vinod Koul 
> 
> Helps in finding if endings

That partial sentence is confusing. I couldn't decode it without
reading the entire patch.  That shouldn't be necessary.

How about:

Help in finding (matching) if/endif pairs.
or
Help in finding matching "if" endings by commenting the "endif".

> 
> Signed-off-by: Vinod Koul 
> Signed-off-by: Pierre-Louis Bossart 
> ---
>  sound/soc/intel/Kconfig| 10 
>  sound/soc/intel/boards/Kconfig | 52 
> +-
>  2 files changed, 31 insertions(+), 31 deletions(-)
> 
> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> index b75fa5f59b96..801b205662df 100644
> --- a/sound/soc/intel/Kconfig
> +++ b/sound/soc/intel/Kconfig
> @@ -47,7 +47,7 @@ config SND_SOC_INTEL_SST_FIRMWARE
>   # when these platforms are enabled
>  
>  config SND_SOC_INTEL_HASWELL
> - tristate "Intel ASoC SST driver for Haswell/Broadwell"
> + tristate "Haswell/Broadwell Platforms"
>   depends on SND_DMA_SGBUF
>   depends on DMADEVICES && ACPI
>   select SND_SOC_INTEL_SST
> @@ -60,7 +60,7 @@ config SND_SOC_INTEL_HASWELL
> typically used for Chromebooks. This is a recommended option.
>  
>  config SND_SOC_INTEL_BAYTRAIL
> - tristate "Intel ASoC SST driver for Baytrail (legacy)"
> + tristate "Baytrail (legacy) Platforms"
>   depends on DMADEVICES && ACPI
>   select SND_SOC_INTEL_SST
>   select SND_SOC_INTEL_SST_ACPI
> @@ -73,7 +73,7 @@ config SND_SOC_INTEL_BAYTRAIL
> not recommended, use SND_SST_ATOM_HIFI2_PLATFORM instead.
>  
>  config SND_SST_ATOM_HIFI2_PLATFORM_PCI
> - tristate "Intel ASoC SST driver for PCI HiFi2 platforms (Medfield, 
> Merrifield)"
> + tristate "PCI HiFi2 platforms (Medfield, Merrifield) platforms"
>   depends on X86 && PCI
>   select SND_SST_IPC_PCI
>   select SND_SOC_COMPRESS
> @@ -87,7 +87,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI
> is not in the standard firmware tree
>  
>  config SND_SST_ATOM_HIFI2_PLATFORM
> - tristate "Intel ASoC SST driver for ACPI HiFi2 platforms (Baytrail, 
> Cherrytrail)"
> + tristate "ACPI HiFi2 platforms (Baytrail, Cherrytrail) Platforms"
>   depends on X86 && ACPI
>   select SND_SST_IPC_ACPI
>   select IOSF_MBI
> @@ -99,7 +99,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM
> recommended option
>  
>  config SND_SOC_INTEL_SKYLAKE
> - tristate "Intel ASoC SST driver for SKL/BXT/KBL/GLK/CNL"
> + tristate "SKL/BXT/KBL/GLK/CNL... Platforms"
>   depends on PCI && ACPI
>   select SND_HDA_EXT_CORE
>   select SND_HDA_DSP_LOADER
> diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig
> index 6a10df882a88..89a73e3d9d2d 100644
> --- a/sound/soc/intel/boards/Kconfig
> +++ b/sound/soc/intel/boards/Kconfig
> @@ -15,7 +15,7 @@ if SND_SOC_INTEL_MACH
>  if SND_SST_ATOM_HIFI2_PLATFORM_PCI
>  
>  config SND_MFLD_MACHINE
> - tristate "SOC Machine Audio driver for Intel Medfield MID platform"
> + tristate "Intel Medfield MID"
>   depends on INTEL_SCU_IPC
>   select SND_SOC_SN95031
>   help
> @@ -24,12 +24,12 @@ config SND_MFLD_MACHINE
>Say Y if you have such a device.
>If unsure select "N".
>  
> -endif
> +endif ## SND_SST_ATOM_HIFI2_PLATFORM_PCI
>  
>  if SND_SOC_INTEL_HASWELL
>  
>  config SND_SOC_INTEL_HASWELL_MACH
> - tristate "ASoC Audio DSP support for Intel Haswell Lynxpoint"
> + tristate "Haswell Lynxpoint"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM
>   select SND_SOC_RT5640
>   help
> @@ -39,7 +39,7 @@ config SND_SOC_INTEL_HASWELL_MACH
> If unsure select "N".
>  
>  config SND_SOC_INTEL_BDW_RT5677_MACH
> - tristate "ASoC Audio driver for Intel Broadwell with RT5677 codec"
> + tristate "Broadwell with RT5677 codec"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM && GPIOLIB
>   select SND_SOC_RT5677
>   help
> @@ -49,7 +49,7 @@ config SND_SOC_INTEL_BDW_RT5677_MACH
> If unsure select "N".
>  
>  config SND_SOC_INTEL_BROADWELL_MACH
> - tristate "ASoC Audio DSP support for Intel Broadwell Wildcatpoint"
> + tristate "Intel Broadwell Wildcatpoint"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM
>   select SND_SOC_RT286
>   help
> @@ -57,12 +57,12 @@ config SND_SOC_INTEL_BROADWELL_MACH
> Ultrabook platforms.
> Say Y or m if you have such a device. This is a recommended option.
> If unsure select "N".
> -endif
> +endif ## SND_SOC_INTEL_HASWELL
>  
>  if SND_SOC_INTEL_BAYTRAIL
>  
>  config SND_SOC_INTEL_BYT_MAX98090_MACH
> - tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec"
> + tristate "Baytrail with MAX98090 codec"
>   depends on X86_INTEL_LPSS && I2C
>   select SND_SOC_MAX98090
>   help

Re: [PATCH v2 9/9] ASoC: Intel: kconfig: add some comments for if symbols

[Randy Dunlap]

On 01/03/2018 08:50 AM, Pierre-Louis Bossart wrote:
> From: Vinod Koul 
> 
> Helps in finding if endings

That partial sentence is confusing. I couldn't decode it without
reading the entire patch.  That shouldn't be necessary.

How about:

Help in finding (matching) if/endif pairs.
or
Help in finding matching "if" endings by commenting the "endif".

> 
> Signed-off-by: Vinod Koul 
> Signed-off-by: Pierre-Louis Bossart 
> ---
>  sound/soc/intel/Kconfig| 10 
>  sound/soc/intel/boards/Kconfig | 52 
> +-
>  2 files changed, 31 insertions(+), 31 deletions(-)
> 
> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> index b75fa5f59b96..801b205662df 100644
> --- a/sound/soc/intel/Kconfig
> +++ b/sound/soc/intel/Kconfig
> @@ -47,7 +47,7 @@ config SND_SOC_INTEL_SST_FIRMWARE
>   # when these platforms are enabled
>  
>  config SND_SOC_INTEL_HASWELL
> - tristate "Intel ASoC SST driver for Haswell/Broadwell"
> + tristate "Haswell/Broadwell Platforms"
>   depends on SND_DMA_SGBUF
>   depends on DMADEVICES && ACPI
>   select SND_SOC_INTEL_SST
> @@ -60,7 +60,7 @@ config SND_SOC_INTEL_HASWELL
> typically used for Chromebooks. This is a recommended option.
>  
>  config SND_SOC_INTEL_BAYTRAIL
> - tristate "Intel ASoC SST driver for Baytrail (legacy)"
> + tristate "Baytrail (legacy) Platforms"
>   depends on DMADEVICES && ACPI
>   select SND_SOC_INTEL_SST
>   select SND_SOC_INTEL_SST_ACPI
> @@ -73,7 +73,7 @@ config SND_SOC_INTEL_BAYTRAIL
> not recommended, use SND_SST_ATOM_HIFI2_PLATFORM instead.
>  
>  config SND_SST_ATOM_HIFI2_PLATFORM_PCI
> - tristate "Intel ASoC SST driver for PCI HiFi2 platforms (Medfield, 
> Merrifield)"
> + tristate "PCI HiFi2 platforms (Medfield, Merrifield) platforms"
>   depends on X86 && PCI
>   select SND_SST_IPC_PCI
>   select SND_SOC_COMPRESS
> @@ -87,7 +87,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI
> is not in the standard firmware tree
>  
>  config SND_SST_ATOM_HIFI2_PLATFORM
> - tristate "Intel ASoC SST driver for ACPI HiFi2 platforms (Baytrail, 
> Cherrytrail)"
> + tristate "ACPI HiFi2 platforms (Baytrail, Cherrytrail) Platforms"
>   depends on X86 && ACPI
>   select SND_SST_IPC_ACPI
>   select IOSF_MBI
> @@ -99,7 +99,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM
> recommended option
>  
>  config SND_SOC_INTEL_SKYLAKE
> - tristate "Intel ASoC SST driver for SKL/BXT/KBL/GLK/CNL"
> + tristate "SKL/BXT/KBL/GLK/CNL... Platforms"
>   depends on PCI && ACPI
>   select SND_HDA_EXT_CORE
>   select SND_HDA_DSP_LOADER
> diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig
> index 6a10df882a88..89a73e3d9d2d 100644
> --- a/sound/soc/intel/boards/Kconfig
> +++ b/sound/soc/intel/boards/Kconfig
> @@ -15,7 +15,7 @@ if SND_SOC_INTEL_MACH
>  if SND_SST_ATOM_HIFI2_PLATFORM_PCI
>  
>  config SND_MFLD_MACHINE
> - tristate "SOC Machine Audio driver for Intel Medfield MID platform"
> + tristate "Intel Medfield MID"
>   depends on INTEL_SCU_IPC
>   select SND_SOC_SN95031
>   help
> @@ -24,12 +24,12 @@ config SND_MFLD_MACHINE
>Say Y if you have such a device.
>If unsure select "N".
>  
> -endif
> +endif ## SND_SST_ATOM_HIFI2_PLATFORM_PCI
>  
>  if SND_SOC_INTEL_HASWELL
>  
>  config SND_SOC_INTEL_HASWELL_MACH
> - tristate "ASoC Audio DSP support for Intel Haswell Lynxpoint"
> + tristate "Haswell Lynxpoint"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM
>   select SND_SOC_RT5640
>   help
> @@ -39,7 +39,7 @@ config SND_SOC_INTEL_HASWELL_MACH
> If unsure select "N".
>  
>  config SND_SOC_INTEL_BDW_RT5677_MACH
> - tristate "ASoC Audio driver for Intel Broadwell with RT5677 codec"
> + tristate "Broadwell with RT5677 codec"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM && GPIOLIB
>   select SND_SOC_RT5677
>   help
> @@ -49,7 +49,7 @@ config SND_SOC_INTEL_BDW_RT5677_MACH
> If unsure select "N".
>  
>  config SND_SOC_INTEL_BROADWELL_MACH
> - tristate "ASoC Audio DSP support for Intel Broadwell Wildcatpoint"
> + tristate "Intel Broadwell Wildcatpoint"
>   depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM
>   select SND_SOC_RT286
>   help
> @@ -57,12 +57,12 @@ config SND_SOC_INTEL_BROADWELL_MACH
> Ultrabook platforms.
> Say Y or m if you have such a device. This is a recommended option.
> If unsure select "N".
> -endif
> +endif ## SND_SOC_INTEL_HASWELL
>  
>  if SND_SOC_INTEL_BAYTRAIL
>  
>  config SND_SOC_INTEL_BYT_MAX98090_MACH
> - tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec"
> + tristate "Baytrail with MAX98090 codec"
>   depends on X86_INTEL_LPSS && I2C
>   select SND_SOC_MAX98090
>   help
> @@ -72,7 +72,7 @@ config SND_SOC_INTEL_BYT_MAX98090_MACH
> 

page table isolation alternative mechanism

[Albert Cahalan]

We got into the current situation for performance reasons, avoiding the costly
reload of CR3 that a hardware task switch would cause. It seems we'll be
loading CR3 now anyway, so it might be time to reconsider hardware
task switches.

The recent patches leave kernel entry/exit code mapped. Hardware task switches
wouldn't need that. All they need is a single entry in a reduced-size
IDT, for the
doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That
then gets you a proper IDT and GDT because those are virtually mapped.
Not a single byte of kernel code would need to be mapped while user code runs.

page table isolation alternative mechanism

[Albert Cahalan]

We got into the current situation for performance reasons, avoiding the costly
reload of CR3 that a hardware task switch would cause. It seems we'll be
loading CR3 now anyway, so it might be time to reconsider hardware
task switches.

The recent patches leave kernel entry/exit code mapped. Hardware task switches
wouldn't need that. All they need is a single entry in a reduced-size
IDT, for the
doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That
then gets you a proper IDT and GDT because those are virtually mapped.
Not a single byte of kernel code would need to be mapped while user code runs.

Re: [PATCH v2 0/9] ASoC: Intel: Kconfig+acpi fixes

[Andy Shevchenko]

On Wed, 2018-01-03 at 12:52 -0600, Pierre-Louis Bossart wrote:
> 
> On 01/03/2018 11:09 AM, Andy Shevchenko wrote:
> > On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:

> > Couple of nitpicks and seems patch 9 missed some (all?) comments to
> > be
> > addressed.
> > 
> > So, after fixing them:
> > 
> > Reviewed-by: Andy Shevchenko 
> 
> Thanks Andy for the quick review. the last patch is new and indeed
> could 
> be cleaned-up further, will send a v3.

You are welcome!

It wasn't quick if you sum all time spend to review previous iterations.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v2 0/9] ASoC: Intel: Kconfig+acpi fixes

[Andy Shevchenko]

On Wed, 2018-01-03 at 12:52 -0600, Pierre-Louis Bossart wrote:
> 
> On 01/03/2018 11:09 AM, Andy Shevchenko wrote:
> > On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:

> > Couple of nitpicks and seems patch 9 missed some (all?) comments to
> > be
> > addressed.
> > 
> > So, after fixing them:
> > 
> > Reviewed-by: Andy Shevchenko 
> 
> Thanks Andy for the quick review. the last patch is new and indeed
> could 
> be cleaned-up further, will send a v3.

You are welcome!

It wasn't quick if you sum all time spend to review previous iterations.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v5 26/39] nds32: Device tree support

[Rob Herring]

On Tue, Jan 2, 2018 at 2:24 AM, Greentime Hu  wrote:
> From: Greentime Hu 
>
> This patch adds support for device tree.
>
> Signed-off-by: Vincent Chen 
> Signed-off-by: Greentime Hu 
> ---
>  arch/nds32/boot/dts/Makefile  |8 +
>  arch/nds32/boot/dts/ae3xx.dts |   73 
> +
>  arch/nds32/kernel/devtree.c   |   19 +++
>  3 files changed, 100 insertions(+)
>  create mode 100644 arch/nds32/boot/dts/Makefile
>  create mode 100644 arch/nds32/boot/dts/ae3xx.dts
>  create mode 100644 arch/nds32/kernel/devtree.c
>
> diff --git a/arch/nds32/boot/dts/Makefile b/arch/nds32/boot/dts/Makefile
> new file mode 100644
> index 000..d31faa8
> --- /dev/null
> +++ b/arch/nds32/boot/dts/Makefile
> @@ -0,0 +1,8 @@
> +ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""'
> +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_NDS32_BUILTIN_DTB)).dtb.o
> +else
> +BUILTIN_DTB :=
> +endif
> +obj-$(CONFIG_OF) += $(BUILTIN_DTB)
> +
> +clean-files := *.dtb *.dtb.S
> diff --git a/arch/nds32/boot/dts/ae3xx.dts b/arch/nds32/boot/dts/ae3xx.dts
> new file mode 100644
> index 000..6b23d60
> --- /dev/null
> +++ b/arch/nds32/boot/dts/ae3xx.dts
> @@ -0,0 +1,73 @@
> +/dts-v1/;
> +/ {
> +   compatible = "andestech,ae3xx";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   interrupt-parent = <>;
> +
> +   chosen {
> +   stdout-path = 
> +   };
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x 0x4000>;
> +   };
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   cpu@0 {
> +   device_type = "cpu";
> +   compatible = "andestech,n13", "andestech,nds32v3";
> +   reg = <0>;
> +   clock-frequency = <6000>;
> +   next-level-cache = <>;
> +   };
> +   };
> +
> +   L2: l2-cache@e050 {
> +   compatible = "andestech,atl2c";
> +   reg = <0xe050 0x1000>;
> +   cache-unified;
> +   cache-level = <2>;
> +   };
> +
> +   apb: clk@0 {

unit address without reg is not valid. Drop the "@0".

> +   #clock-cells = <0>;
> +   compatible = "fixed-clock";
> +   clock-frequency = <3000>;
> +   };
> +
> +
> +   intc: interrupt-controller {
> +   compatible = "andestech,ativic32";
> +   #interrupt-cells = <1>;
> +   interrupt-controller;
> +   };
> +
> +   serial0: serial@f030 {

All the memory mapped peripherals should be under at least one simple-bus node.

> +   compatible = "andestech,uart16550", "ns16550a";
> +   reg = <0xf030 0x1000>;
> +   interrupts = <8>;
> +   clock-frequency = <14745600>;
> +   reg-shift = <2>;
> +   reg-offset = <32>;
> +   no-loopback-test = <1>;
> +   };
> +
> +   timer0: timer@f040 {
> +   compatible = "andestech,atcpit100";
> +   reg = <0xf040 0x1000>;
> +   interrupts = <2>;
> +   clocks = <>;
> +   clock-names = "PCLK";
> +   };
> +
> +   mac0: mac@e010 {

ethernet@...

> +   compatible = "andestech,atmac100";
> +   reg = <0xe010 0x1000>;
> +   interrupts = <18>;
> +   };
> +
> +};
> diff --git a/arch/nds32/kernel/devtree.c b/arch/nds32/kernel/devtree.c
> new file mode 100644
> index 000..bdce0fe
> --- /dev/null
> +++ b/arch/nds32/kernel/devtree.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2005-2017 Andes Technology Corporation
> +
> +#include 
> +#include 
> +#include 
> +
> +void __init early_init_devtree(void *params)
> +{
> +   if (!params || !early_init_dt_scan(params)) {
> +   pr_crit("\n"
> +   "Error: invalid device tree blob at (virtual address 
> 0x%p)\n"
> +   "\nPlease check your bootloader.", params);
> +
> +   BUG_ON(1);
> +   }
> +
> +   dump_stack_set_arch_desc("%s (DT)", of_flat_dt_get_machine_name());
> +}
> --
> 1.7.9.5
>

Re: [PATCH v5 26/39] nds32: Device tree support

[Rob Herring]

On Tue, Jan 2, 2018 at 2:24 AM, Greentime Hu  wrote:
> From: Greentime Hu 
>
> This patch adds support for device tree.
>
> Signed-off-by: Vincent Chen 
> Signed-off-by: Greentime Hu 
> ---
>  arch/nds32/boot/dts/Makefile  |8 +
>  arch/nds32/boot/dts/ae3xx.dts |   73 
> +
>  arch/nds32/kernel/devtree.c   |   19 +++
>  3 files changed, 100 insertions(+)
>  create mode 100644 arch/nds32/boot/dts/Makefile
>  create mode 100644 arch/nds32/boot/dts/ae3xx.dts
>  create mode 100644 arch/nds32/kernel/devtree.c
>
> diff --git a/arch/nds32/boot/dts/Makefile b/arch/nds32/boot/dts/Makefile
> new file mode 100644
> index 000..d31faa8
> --- /dev/null
> +++ b/arch/nds32/boot/dts/Makefile
> @@ -0,0 +1,8 @@
> +ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""'
> +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_NDS32_BUILTIN_DTB)).dtb.o
> +else
> +BUILTIN_DTB :=
> +endif
> +obj-$(CONFIG_OF) += $(BUILTIN_DTB)
> +
> +clean-files := *.dtb *.dtb.S
> diff --git a/arch/nds32/boot/dts/ae3xx.dts b/arch/nds32/boot/dts/ae3xx.dts
> new file mode 100644
> index 000..6b23d60
> --- /dev/null
> +++ b/arch/nds32/boot/dts/ae3xx.dts
> @@ -0,0 +1,73 @@
> +/dts-v1/;
> +/ {
> +   compatible = "andestech,ae3xx";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   interrupt-parent = <>;
> +
> +   chosen {
> +   stdout-path = 
> +   };
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x 0x4000>;
> +   };
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   cpu@0 {
> +   device_type = "cpu";
> +   compatible = "andestech,n13", "andestech,nds32v3";
> +   reg = <0>;
> +   clock-frequency = <6000>;
> +   next-level-cache = <>;
> +   };
> +   };
> +
> +   L2: l2-cache@e050 {
> +   compatible = "andestech,atl2c";
> +   reg = <0xe050 0x1000>;
> +   cache-unified;
> +   cache-level = <2>;
> +   };
> +
> +   apb: clk@0 {

unit address without reg is not valid. Drop the "@0".

> +   #clock-cells = <0>;
> +   compatible = "fixed-clock";
> +   clock-frequency = <3000>;
> +   };
> +
> +
> +   intc: interrupt-controller {
> +   compatible = "andestech,ativic32";
> +   #interrupt-cells = <1>;
> +   interrupt-controller;
> +   };
> +
> +   serial0: serial@f030 {

All the memory mapped peripherals should be under at least one simple-bus node.

> +   compatible = "andestech,uart16550", "ns16550a";
> +   reg = <0xf030 0x1000>;
> +   interrupts = <8>;
> +   clock-frequency = <14745600>;
> +   reg-shift = <2>;
> +   reg-offset = <32>;
> +   no-loopback-test = <1>;
> +   };
> +
> +   timer0: timer@f040 {
> +   compatible = "andestech,atcpit100";
> +   reg = <0xf040 0x1000>;
> +   interrupts = <2>;
> +   clocks = <>;
> +   clock-names = "PCLK";
> +   };
> +
> +   mac0: mac@e010 {

ethernet@...

> +   compatible = "andestech,atmac100";
> +   reg = <0xe010 0x1000>;
> +   interrupts = <18>;
> +   };
> +
> +};
> diff --git a/arch/nds32/kernel/devtree.c b/arch/nds32/kernel/devtree.c
> new file mode 100644
> index 000..bdce0fe
> --- /dev/null
> +++ b/arch/nds32/kernel/devtree.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2005-2017 Andes Technology Corporation
> +
> +#include 
> +#include 
> +#include 
> +
> +void __init early_init_devtree(void *params)
> +{
> +   if (!params || !early_init_dt_scan(params)) {
> +   pr_crit("\n"
> +   "Error: invalid device tree blob at (virtual address 
> 0x%p)\n"
> +   "\nPlease check your bootloader.", params);
> +
> +   BUG_ON(1);
> +   }
> +
> +   dump_stack_set_arch_desc("%s (DT)", of_flat_dt_get_machine_name());
> +}
> --
> 1.7.9.5
>

Re: [PATCH v3] gpio: winbond: add driver

[Andy Shevchenko]

On Sat, 2017-12-30 at 22:02 +0100, Maciej S. Szmigiero wrote:
> This commit adds GPIO driver for Winbond Super I/Os.
> 
> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is
> supported but in the future a support for other Winbond models, too,
> can
> be added to the driver.
> 
> A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit
> 0 is
> GPIO1, bit 1 is GPIO2, etc.).
> One should be careful which ports one tinkers with since some might be
> managed by the firmware (for functions like powering on and off,
> sleeping,
> BIOS recovery, etc.) and some of GPIO port pins are physically shared
> with
> other devices included in the Super I/O chip.
> 

Thanks for an update.
My comments below.

First of all, looking more at this driver, why don't we create a
gpiochip per real "port" during actual configuration?

And I still have filing that this one suitable for MFD.

Anyone, does it make sense?

> +#define WB_SIO_REG_G1MF_G2PP 7
> +#define WB_SIO_REG_G1MF_G1PP 6

Forgot to swap.

> +#define wb_sio_notice(...) pr_notice(WB_GPIO_DRIVER_NAME ": "
> __VA_ARGS__)
> +#define wb_sio_warn(...) pr_warn(WB_GPIO_DRIVER_NAME ": "
> __VA_ARGS__)
> +#define wb_sio_err(...) pr_err(WB_GPIO_DRIVER_NAME ": " __VA_ARGS__)

What I meant is to

#define pr_fmt(x) ...

Look at the kernel sources, there are a lot of examples.

> +/* returns whether changing a pin is allowed */
> +static bool winbond_gpio_get_info(unsigned int *gpio_num,
> +   const struct winbond_gpio_info
> **info)
> +{
> + bool allow_changing = true;
> + unsigned long i;
> +
> + for_each_set_bit(i, , sizeof(gpios)) {
> + if (*gpio_num < 8)
> + break;
> +
> + *gpio_num -= 8;
> + }

Why not hweight() here?

unsigned int shift = hweight_long(gpios) * 8;
unsigned int index = fls_long(gpios); // AFAIU

*offset -= *offset >= shift ? shift : shift - 8;
*info = _gpio_infos[index];

...

> +
> + *info = _gpio_infos[i];
> +
> + /*
> +  * GPIO2 (the second port) shares some pins with a basic PC
> +  * functionality, which is very likely controlled by the
> firmware.
> +  * Don't allow changing these pins by default.
> +  */
> + if (i == 1) {
> + if (*gpio_num == 0 && !pledgpio)
> + allow_changing = false;
> + else if (*gpio_num == 1 && !beepgpio)
> + allow_changing = false;
> + else if ((*gpio_num == 5 || *gpio_num == 6) &&
> !i2cgpio)
> + allow_changing = false;
> + }
> +
> + return allow_changing;
> +}

> +static int winbond_gpio_configure(unsigned long base)
> +{
> + unsigned long i;
> +
> + for_each_set_bit(i, , sizeof(gpios))
> + if (!winbond_gpio_configure_port(base, i))
> + gpios &= ~BIT(i);

> +
> + if (!gpios) {
> + wb_sio_err("please use 'gpios' module parameter to
> select some active GPIO ports to enable\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> 

> +static int winbond_gpio_imatch(struct device *dev, unsigned int id)
> +{
> + int ret;
> +

> + if (gpios & ~GENMASK(ARRAY_SIZE(winbond_gpio_infos) - 1, 0))
> {
> + wb_sio_err("unknown ports enabled in GPIO ports
> bitmask\n");
> + return 0;
> + }

Do we care? Perhaps just enforce mask based on the size and leave
garbage out.

> + /*
> +  * if the 'base' module parameter is unset probe two chip
> default
> +  * I/O port bases
> +  */
> + baseparam = WB_SIO_BASE;
> + ret = winbond_gpio_check_chip(baseparam);
> + if (ret == 0)
> + return 1;

> + else if (ret != -ENODEV && ret != -EBUSY)

Redundant 'else'.

> + return 0;
> +
> + baseparam = WB_SIO_BASE_HIGH;
> + return winbond_gpio_check_chip(baseparam) == 0;
> +}
> +
> +static int winbond_gpio_iprobe(struct device *dev, unsigned int id)
> +{
> + int ret;
> +
> + if (baseparam == 0)
> + return -EINVAL;
> +
> + ret = winbond_sio_enter(baseparam);
> + if (ret)
> + return ret;
> +
> + ret = winbond_gpio_configure(baseparam);

...like registering MFD children in that call directly?

> +
> + winbond_sio_leave(baseparam);
> +
> + if (ret)
> + return ret;
> +
> + /*
> +  * Add 8 gpios for every GPIO port that was enabled in gpios
> +  * module parameter (that wasn't disabled earlier in
> +  * winbond_gpio_configure() & co. due to, for example, a pin
> conflict).
> +  */

> + winbond_gpio_chip.ngpio = hweight_long(gpios) * 8;
> +
> + /*
> +  * GPIO6 port has only 5 pins, so if it is enabled we have to
> adjust
> +  * the total count appropriately
> +  */
> + if (gpios & BIT(5))
> + winbond_gpio_chip.ngpio -= (8 - 5);

So, if we still are going use this, taking into consideration above
proposal, it would make 

Re: [PATCH v3] gpio: winbond: add driver

[Andy Shevchenko]

On Sat, 2017-12-30 at 22:02 +0100, Maciej S. Szmigiero wrote:
> This commit adds GPIO driver for Winbond Super I/Os.
> 
> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is
> supported but in the future a support for other Winbond models, too,
> can
> be added to the driver.
> 
> A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit
> 0 is
> GPIO1, bit 1 is GPIO2, etc.).
> One should be careful which ports one tinkers with since some might be
> managed by the firmware (for functions like powering on and off,
> sleeping,
> BIOS recovery, etc.) and some of GPIO port pins are physically shared
> with
> other devices included in the Super I/O chip.
> 

Thanks for an update.
My comments below.

First of all, looking more at this driver, why don't we create a
gpiochip per real "port" during actual configuration?

And I still have filing that this one suitable for MFD.

Anyone, does it make sense?

> +#define WB_SIO_REG_G1MF_G2PP 7
> +#define WB_SIO_REG_G1MF_G1PP 6

Forgot to swap.

> +#define wb_sio_notice(...) pr_notice(WB_GPIO_DRIVER_NAME ": "
> __VA_ARGS__)
> +#define wb_sio_warn(...) pr_warn(WB_GPIO_DRIVER_NAME ": "
> __VA_ARGS__)
> +#define wb_sio_err(...) pr_err(WB_GPIO_DRIVER_NAME ": " __VA_ARGS__)

What I meant is to

#define pr_fmt(x) ...

Look at the kernel sources, there are a lot of examples.

> +/* returns whether changing a pin is allowed */
> +static bool winbond_gpio_get_info(unsigned int *gpio_num,
> +   const struct winbond_gpio_info
> **info)
> +{
> + bool allow_changing = true;
> + unsigned long i;
> +
> + for_each_set_bit(i, , sizeof(gpios)) {
> + if (*gpio_num < 8)
> + break;
> +
> + *gpio_num -= 8;
> + }

Why not hweight() here?

unsigned int shift = hweight_long(gpios) * 8;
unsigned int index = fls_long(gpios); // AFAIU

*offset -= *offset >= shift ? shift : shift - 8;
*info = _gpio_infos[index];

...

> +
> + *info = _gpio_infos[i];
> +
> + /*
> +  * GPIO2 (the second port) shares some pins with a basic PC
> +  * functionality, which is very likely controlled by the
> firmware.
> +  * Don't allow changing these pins by default.
> +  */
> + if (i == 1) {
> + if (*gpio_num == 0 && !pledgpio)
> + allow_changing = false;
> + else if (*gpio_num == 1 && !beepgpio)
> + allow_changing = false;
> + else if ((*gpio_num == 5 || *gpio_num == 6) &&
> !i2cgpio)
> + allow_changing = false;
> + }
> +
> + return allow_changing;
> +}

> +static int winbond_gpio_configure(unsigned long base)
> +{
> + unsigned long i;
> +
> + for_each_set_bit(i, , sizeof(gpios))
> + if (!winbond_gpio_configure_port(base, i))
> + gpios &= ~BIT(i);

> +
> + if (!gpios) {
> + wb_sio_err("please use 'gpios' module parameter to
> select some active GPIO ports to enable\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> 

> +static int winbond_gpio_imatch(struct device *dev, unsigned int id)
> +{
> + int ret;
> +

> + if (gpios & ~GENMASK(ARRAY_SIZE(winbond_gpio_infos) - 1, 0))
> {
> + wb_sio_err("unknown ports enabled in GPIO ports
> bitmask\n");
> + return 0;
> + }

Do we care? Perhaps just enforce mask based on the size and leave
garbage out.

> + /*
> +  * if the 'base' module parameter is unset probe two chip
> default
> +  * I/O port bases
> +  */
> + baseparam = WB_SIO_BASE;
> + ret = winbond_gpio_check_chip(baseparam);
> + if (ret == 0)
> + return 1;

> + else if (ret != -ENODEV && ret != -EBUSY)

Redundant 'else'.

> + return 0;
> +
> + baseparam = WB_SIO_BASE_HIGH;
> + return winbond_gpio_check_chip(baseparam) == 0;
> +}
> +
> +static int winbond_gpio_iprobe(struct device *dev, unsigned int id)
> +{
> + int ret;
> +
> + if (baseparam == 0)
> + return -EINVAL;
> +
> + ret = winbond_sio_enter(baseparam);
> + if (ret)
> + return ret;
> +
> + ret = winbond_gpio_configure(baseparam);

...like registering MFD children in that call directly?

> +
> + winbond_sio_leave(baseparam);
> +
> + if (ret)
> + return ret;
> +
> + /*
> +  * Add 8 gpios for every GPIO port that was enabled in gpios
> +  * module parameter (that wasn't disabled earlier in
> +  * winbond_gpio_configure() & co. due to, for example, a pin
> conflict).
> +  */

> + winbond_gpio_chip.ngpio = hweight_long(gpios) * 8;
> +
> + /*
> +  * GPIO6 port has only 5 pins, so if it is enabled we have to
> adjust
> +  * the total count appropriately
> +  */
> + if (gpios & BIT(5))
> + winbond_gpio_chip.ngpio -= (8 - 5);

So, if we still are going use this, taking into consideration above
proposal, it would make 

Re: [PATCH] exec: Weaken dumpability for secureexec

[Tom Horsley]

On Wed, 3 Jan 2018 09:21:16 -0800
Kees Cook wrote:

> The more interesting thing here is that secureexec is set for a
> process that ISN'T actually setuid. (ptrace of a setuid process). I
> think tha'ts the real bug, but not something I'm going to be able to
> fix quickly. So, for now, I want to revert this, then try to fix the
> weird case, and see if that breaks anyone, then fix this back to
> secureexec.

Certainly a program file that has capabilities attached to it
via "setcap" is intended to be treated just like setuid if
the capabilities it has are a superset of the capabilities
of the debugger. (I don't know if that is a useful info in this
case, but I thought I'd mention it :-).

Re: [PATCH] exec: Weaken dumpability for secureexec

[Tom Horsley]

On Wed, 3 Jan 2018 09:21:16 -0800
Kees Cook wrote:

> The more interesting thing here is that secureexec is set for a
> process that ISN'T actually setuid. (ptrace of a setuid process). I
> think tha'ts the real bug, but not something I'm going to be able to
> fix quickly. So, for now, I want to revert this, then try to fix the
> weird case, and see if that breaks anyone, then fix this back to
> secureexec.

Certainly a program file that has capabilities attached to it
via "setcap" is intended to be treated just like setuid if
the capabilities it has are a superset of the capabilities
of the debugger. (I don't know if that is a useful info in this
case, but I thought I'd mention it :-).

Re: [f2fs-dev] [PATCH v5] f2fs: add reserved blocks for root user

[Jaegeuk Kim]

On 01/03, Chao Yu wrote:
> On 2018/1/3 10:21, Jaegeuk Kim wrote:
> > This patch allows root to reserve some blocks via mount option.
> > 
> > "-o reserve_root=N" means N x 4KB-sized blocks for root only.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> > 
> > Change log from v4:
> >  - fix f_bfree in statfs
> 
> Could you fix f_bfree calculation issue in another patch prior to this
> patch? That will be better for history tracking of patches or git bisect
> when backtracking issues.

I've sent out a new series for this.

> 
> One more thing, should we move reserve_root_limit check to parse_option?

No, since we don't have sbi yet.

> now, it looks that during remount we can set root_reserved_blocks exceeding
> our defined limitation.

Oh, I missed the changelog that it won't be changed once getting the flag set.

Thanks,

> 
> Thanks,
> 
> > 
> >  fs/f2fs/f2fs.h  | 26 ++
> >  fs/f2fs/super.c | 34 +-
> >  fs/f2fs/sysfs.c |  3 ++-
> >  3 files changed, 53 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 07e03990420b..a0e8eec23125 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -95,6 +95,7 @@ extern char *fault_name[FAULT_MAX];
> >  #define F2FS_MOUNT_PRJQUOTA0x0020
> >  #define F2FS_MOUNT_QUOTA   0x0040
> >  #define F2FS_MOUNT_INLINE_XATTR_SIZE   0x0080
> > +#define F2FS_MOUNT_RESERVE_ROOT0x0100
> >  
> >  #define clear_opt(sbi, option) ((sbi)->mount_opt.opt &= 
> > ~F2FS_MOUNT_##option)
> >  #define set_opt(sbi, option)   ((sbi)->mount_opt.opt |= 
> > F2FS_MOUNT_##option)
> > @@ -1105,6 +1106,7 @@ struct f2fs_sb_info {
> > block_t last_valid_block_count; /* for recovery */
> > block_t reserved_blocks;/* configurable reserved blocks 
> > */
> > block_t current_reserved_blocks;/* current reserved blocks */
> > +   block_t root_reserved_blocks;   /* root reserved blocks */
> >  
> > unsigned int nquota_files;  /* # of quota sysfile */
> >  
> > @@ -1554,6 +1556,12 @@ static inline bool f2fs_has_xattr_block(unsigned int 
> > ofs)
> > return ofs == XATTR_NODE_OFFSET;
> >  }
> >  
> > +static inline block_t reserve_root_limit(struct f2fs_sb_info *sbi)
> > +{
> > +   /* limit is 0.2% */
> > +   return (sbi->user_block_count << 1) / 1000;
> > +}
> > +
> >  static inline void f2fs_i_blocks_write(struct inode *, block_t, bool, 
> > bool);
> >  static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
> >  struct inode *inode, blkcnt_t *count)
> > @@ -1583,11 +1591,17 @@ static inline int inc_valid_block_count(struct 
> > f2fs_sb_info *sbi,
> > sbi->total_valid_block_count += (block_t)(*count);
> > avail_user_block_count = sbi->user_block_count -
> > sbi->current_reserved_blocks;
> > +
> > +   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
> > +   avail_user_block_count -= sbi->root_reserved_blocks;
> > +
> > if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
> > diff = sbi->total_valid_block_count - avail_user_block_count;
> > +   if (diff > *count)
> > +   diff = *count;
> > *count -= diff;
> > release = diff;
> > -   sbi->total_valid_block_count = avail_user_block_count;
> > +   sbi->total_valid_block_count -= diff;
> > if (!*count) {
> > spin_unlock(>stat_lock);
> > percpu_counter_sub(>alloc_valid_block_count, diff);
> > @@ -1776,9 +1790,13 @@ static inline int inc_valid_node_count(struct 
> > f2fs_sb_info *sbi,
> >  
> > spin_lock(>stat_lock);
> >  
> > -   valid_block_count = sbi->total_valid_block_count + 1;
> > -   if (unlikely(valid_block_count + sbi->current_reserved_blocks >
> > -   sbi->user_block_count)) {
> > +   valid_block_count = sbi->total_valid_block_count +
> > +   sbi->current_reserved_blocks + 1;
> > +
> > +   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
> > +   valid_block_count += sbi->root_reserved_blocks;
> > +
> > +   if (unlikely(valid_block_count > sbi->user_block_count)) {
> > spin_unlock(>stat_lock);
> > goto enospc;
> > }
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 5c6a02b558f0..e814340bc2f0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -107,6 +107,7 @@ enum {
> > Opt_noextent_cache,
> > Opt_noinline_data,
> > Opt_data_flush,
> > +   Opt_reserve_root,
> > Opt_mode,
> > Opt_io_size_bits,
> > Opt_fault_injection,
> > @@ -157,6 +158,7 @@ static match_table_t f2fs_tokens = {
> > {Opt_noextent_cache, "noextent_cache"},
> > {Opt_noinline_data, "noinline_data"},
> > 

Re: [f2fs-dev] [PATCH v5] f2fs: add reserved blocks for root user

[Jaegeuk Kim]

On 01/03, Chao Yu wrote:
> On 2018/1/3 10:21, Jaegeuk Kim wrote:
> > This patch allows root to reserve some blocks via mount option.
> > 
> > "-o reserve_root=N" means N x 4KB-sized blocks for root only.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> > 
> > Change log from v4:
> >  - fix f_bfree in statfs
> 
> Could you fix f_bfree calculation issue in another patch prior to this
> patch? That will be better for history tracking of patches or git bisect
> when backtracking issues.

I've sent out a new series for this.

> 
> One more thing, should we move reserve_root_limit check to parse_option?

No, since we don't have sbi yet.

> now, it looks that during remount we can set root_reserved_blocks exceeding
> our defined limitation.

Oh, I missed the changelog that it won't be changed once getting the flag set.

Thanks,

> 
> Thanks,
> 
> > 
> >  fs/f2fs/f2fs.h  | 26 ++
> >  fs/f2fs/super.c | 34 +-
> >  fs/f2fs/sysfs.c |  3 ++-
> >  3 files changed, 53 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 07e03990420b..a0e8eec23125 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -95,6 +95,7 @@ extern char *fault_name[FAULT_MAX];
> >  #define F2FS_MOUNT_PRJQUOTA0x0020
> >  #define F2FS_MOUNT_QUOTA   0x0040
> >  #define F2FS_MOUNT_INLINE_XATTR_SIZE   0x0080
> > +#define F2FS_MOUNT_RESERVE_ROOT0x0100
> >  
> >  #define clear_opt(sbi, option) ((sbi)->mount_opt.opt &= 
> > ~F2FS_MOUNT_##option)
> >  #define set_opt(sbi, option)   ((sbi)->mount_opt.opt |= 
> > F2FS_MOUNT_##option)
> > @@ -1105,6 +1106,7 @@ struct f2fs_sb_info {
> > block_t last_valid_block_count; /* for recovery */
> > block_t reserved_blocks;/* configurable reserved blocks 
> > */
> > block_t current_reserved_blocks;/* current reserved blocks */
> > +   block_t root_reserved_blocks;   /* root reserved blocks */
> >  
> > unsigned int nquota_files;  /* # of quota sysfile */
> >  
> > @@ -1554,6 +1556,12 @@ static inline bool f2fs_has_xattr_block(unsigned int 
> > ofs)
> > return ofs == XATTR_NODE_OFFSET;
> >  }
> >  
> > +static inline block_t reserve_root_limit(struct f2fs_sb_info *sbi)
> > +{
> > +   /* limit is 0.2% */
> > +   return (sbi->user_block_count << 1) / 1000;
> > +}
> > +
> >  static inline void f2fs_i_blocks_write(struct inode *, block_t, bool, 
> > bool);
> >  static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
> >  struct inode *inode, blkcnt_t *count)
> > @@ -1583,11 +1591,17 @@ static inline int inc_valid_block_count(struct 
> > f2fs_sb_info *sbi,
> > sbi->total_valid_block_count += (block_t)(*count);
> > avail_user_block_count = sbi->user_block_count -
> > sbi->current_reserved_blocks;
> > +
> > +   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
> > +   avail_user_block_count -= sbi->root_reserved_blocks;
> > +
> > if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
> > diff = sbi->total_valid_block_count - avail_user_block_count;
> > +   if (diff > *count)
> > +   diff = *count;
> > *count -= diff;
> > release = diff;
> > -   sbi->total_valid_block_count = avail_user_block_count;
> > +   sbi->total_valid_block_count -= diff;
> > if (!*count) {
> > spin_unlock(>stat_lock);
> > percpu_counter_sub(>alloc_valid_block_count, diff);
> > @@ -1776,9 +1790,13 @@ static inline int inc_valid_node_count(struct 
> > f2fs_sb_info *sbi,
> >  
> > spin_lock(>stat_lock);
> >  
> > -   valid_block_count = sbi->total_valid_block_count + 1;
> > -   if (unlikely(valid_block_count + sbi->current_reserved_blocks >
> > -   sbi->user_block_count)) {
> > +   valid_block_count = sbi->total_valid_block_count +
> > +   sbi->current_reserved_blocks + 1;
> > +
> > +   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
> > +   valid_block_count += sbi->root_reserved_blocks;
> > +
> > +   if (unlikely(valid_block_count > sbi->user_block_count)) {
> > spin_unlock(>stat_lock);
> > goto enospc;
> > }
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 5c6a02b558f0..e814340bc2f0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -107,6 +107,7 @@ enum {
> > Opt_noextent_cache,
> > Opt_noinline_data,
> > Opt_data_flush,
> > +   Opt_reserve_root,
> > Opt_mode,
> > Opt_io_size_bits,
> > Opt_fault_injection,
> > @@ -157,6 +158,7 @@ static match_table_t f2fs_tokens = {
> > {Opt_noextent_cache, "noextent_cache"},
> > {Opt_noinline_data, "noinline_data"},
> > {Opt_data_flush, 

Re: WARNING in rds_cmsg_rdma_args

[Santosh Shilimkar]

On 1/3/2018 10:51 AM, Mohamed Ghannam wrote:
The fix  : https://patchwork.ozlabs.org/patch/854723/ 


Cool. Thanks Mohamed for following it up.

Regards,
Santosh

Re: WARNING in rds_cmsg_rdma_args

[Santosh Shilimkar]

On 1/3/2018 10:51 AM, Mohamed Ghannam wrote:
The fix  : https://patchwork.ozlabs.org/patch/854723/ 


Cool. Thanks Mohamed for following it up.

Regards,
Santosh

Re: [PATCH v3] f2fs: add an ioctl to disable GC for specific file

[Jaegeuk Kim]

On 01/03, Chao Yu wrote:
> On 2018/1/3 11:21, Jaegeuk Kim wrote:
> > This patch gives a flag to disable GC on given file, which would be useful, 
> > when
> > user wants to keep its block map. It also conducts in-place-update for 
> > dontmove
> > file.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> > 
> > Change log from v2:
> >  - modify ioctl to allow users unpin the file
> > 
> >  fs/f2fs/data.c  |  2 ++
> >  fs/f2fs/f2fs.h  | 28 +-
> >  fs/f2fs/file.c  | 64 
> > +
> >  fs/f2fs/gc.c| 11 +
> >  fs/f2fs/gc.h|  2 ++
> >  fs/f2fs/sysfs.c |  2 ++
> >  include/linux/f2fs_fs.h |  9 ++-
> >  7 files changed, 116 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 449b0aaa3905..45f65a5b9871 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -1395,6 +1395,8 @@ static inline bool need_inplace_update(struct 
> > f2fs_io_info *fio)
> >  {
> > struct inode *inode = fio->page->mapping->host;
> >  
> > +   if (f2fs_is_pinned_file(inode))
> > +   return true;
> > if (S_ISDIR(inode->i_mode) || f2fs_is_atomic_file(inode))
> > return false;
> > if (is_cold_data(fio->page))
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index a0e8eec23125..f4b7d73695a7 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -350,6 +350,7 @@ static inline bool __has_cursum_space(struct 
> > f2fs_journal *journal,
> >  #define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11,  
> > \
> > struct f2fs_gc_range)
> >  #define F2FS_IOC_GET_FEATURES  _IOR(F2FS_IOCTL_MAGIC, 12, 
> > __u32)
> > +#define F2FS_IOC_SET_PIN_FILE  _IOW(F2FS_IOCTL_MAGIC, 13, 
> > __u32)
> >  
> >  #define F2FS_IOC_SET_ENCRYPTION_POLICY FS_IOC_SET_ENCRYPTION_POLICY
> >  #define F2FS_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
> > @@ -587,7 +588,10 @@ struct f2fs_inode_info {
> > unsigned long i_flags;  /* keep an inode flags for ioctl */
> > unsigned char i_advise; /* use to give file attribute hints */
> > unsigned char i_dir_level;  /* use for dentry level for large dir */
> > -   unsigned int i_current_depth;   /* use only in directory structure */
> > +   union {
> > +   unsigned int i_current_depth;   /* only for directory depth */
> > +   unsigned short i_gc_failures;   /* only for regular file */
> > +   };
> > unsigned int i_pino;/* parent inode number */
> > umode_t i_acl_mode; /* keep file acl mode temporarily */
> >  
> > @@ -1133,6 +1137,9 @@ struct f2fs_sb_info {
> > /* threshold for converting bg victims for fg */
> > u64 fggc_threshold;
> >  
> > +   /* threshold for gc trials on pinned files */
> > +   u64 gc_pin_file_threshold;
> > +
> > /* maximum # of trials to find a victim segment for SSR and GC */
> > unsigned int max_victim_search;
> >  
> > @@ -2124,6 +2131,7 @@ enum {
> > FI_HOT_DATA,/* indicate file is hot */
> > FI_EXTRA_ATTR,  /* indicate file has extra attribute */
> > FI_PROJ_INHERIT,/* indicate file inherits projectid */
> > +   FI_PIN_FILE,/* indicate file should not be gced */
> >  };
> >  
> >  static inline void __mark_inode_dirty_flag(struct inode *inode,
> > @@ -2137,6 +2145,7 @@ static inline void __mark_inode_dirty_flag(struct 
> > inode *inode,
> > return;
> > case FI_DATA_EXIST:
> > case FI_INLINE_DOTS:
> > +   case FI_PIN_FILE:
> > f2fs_mark_inode_dirty_sync(inode, true);
> > }
> >  }
> > @@ -2217,6 +2226,13 @@ static inline void f2fs_i_depth_write(struct inode 
> > *inode, unsigned int depth)
> > f2fs_mark_inode_dirty_sync(inode, true);
> >  }
> >  
> > +static inline void f2fs_i_gc_failures_write(struct inode *inode,
> > +   unsigned int count)
> > +{
> > +   F2FS_I(inode)->i_gc_failures = count;
> > +   f2fs_mark_inode_dirty_sync(inode, true);
> > +}
> > +
> >  static inline void f2fs_i_xnid_write(struct inode *inode, nid_t xnid)
> >  {
> > F2FS_I(inode)->i_xattr_nid = xnid;
> > @@ -2245,6 +2261,8 @@ static inline void get_inline_info(struct inode 
> > *inode, struct f2fs_inode *ri)
> > set_bit(FI_INLINE_DOTS, >flags);
> > if (ri->i_inline & F2FS_EXTRA_ATTR)
> > set_bit(FI_EXTRA_ATTR, >flags);
> > +   if (ri->i_inline & F2FS_PIN_FILE)
> > +   set_bit(FI_PIN_FILE, >flags);
> >  }
> >  
> >  static inline void set_raw_inline(struct inode *inode, struct f2fs_inode 
> > *ri)
> > @@ -2263,6 +2281,8 @@ static inline void set_raw_inline(struct inode 
> > *inode, struct f2fs_inode *ri)
> > ri->i_inline |= F2FS_INLINE_DOTS;
> > if (is_inode_flag_set(inode, FI_EXTRA_ATTR))
> > ri->i_inline |= 

Re: [PATCH v3] f2fs: add an ioctl to disable GC for specific file

[Jaegeuk Kim]

On 01/03, Chao Yu wrote:
> On 2018/1/3 11:21, Jaegeuk Kim wrote:
> > This patch gives a flag to disable GC on given file, which would be useful, 
> > when
> > user wants to keep its block map. It also conducts in-place-update for 
> > dontmove
> > file.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> > 
> > Change log from v2:
> >  - modify ioctl to allow users unpin the file
> > 
> >  fs/f2fs/data.c  |  2 ++
> >  fs/f2fs/f2fs.h  | 28 +-
> >  fs/f2fs/file.c  | 64 
> > +
> >  fs/f2fs/gc.c| 11 +
> >  fs/f2fs/gc.h|  2 ++
> >  fs/f2fs/sysfs.c |  2 ++
> >  include/linux/f2fs_fs.h |  9 ++-
> >  7 files changed, 116 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 449b0aaa3905..45f65a5b9871 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -1395,6 +1395,8 @@ static inline bool need_inplace_update(struct 
> > f2fs_io_info *fio)
> >  {
> > struct inode *inode = fio->page->mapping->host;
> >  
> > +   if (f2fs_is_pinned_file(inode))
> > +   return true;
> > if (S_ISDIR(inode->i_mode) || f2fs_is_atomic_file(inode))
> > return false;
> > if (is_cold_data(fio->page))
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index a0e8eec23125..f4b7d73695a7 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -350,6 +350,7 @@ static inline bool __has_cursum_space(struct 
> > f2fs_journal *journal,
> >  #define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11,  
> > \
> > struct f2fs_gc_range)
> >  #define F2FS_IOC_GET_FEATURES  _IOR(F2FS_IOCTL_MAGIC, 12, 
> > __u32)
> > +#define F2FS_IOC_SET_PIN_FILE  _IOW(F2FS_IOCTL_MAGIC, 13, 
> > __u32)
> >  
> >  #define F2FS_IOC_SET_ENCRYPTION_POLICY FS_IOC_SET_ENCRYPTION_POLICY
> >  #define F2FS_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
> > @@ -587,7 +588,10 @@ struct f2fs_inode_info {
> > unsigned long i_flags;  /* keep an inode flags for ioctl */
> > unsigned char i_advise; /* use to give file attribute hints */
> > unsigned char i_dir_level;  /* use for dentry level for large dir */
> > -   unsigned int i_current_depth;   /* use only in directory structure */
> > +   union {
> > +   unsigned int i_current_depth;   /* only for directory depth */
> > +   unsigned short i_gc_failures;   /* only for regular file */
> > +   };
> > unsigned int i_pino;/* parent inode number */
> > umode_t i_acl_mode; /* keep file acl mode temporarily */
> >  
> > @@ -1133,6 +1137,9 @@ struct f2fs_sb_info {
> > /* threshold for converting bg victims for fg */
> > u64 fggc_threshold;
> >  
> > +   /* threshold for gc trials on pinned files */
> > +   u64 gc_pin_file_threshold;
> > +
> > /* maximum # of trials to find a victim segment for SSR and GC */
> > unsigned int max_victim_search;
> >  
> > @@ -2124,6 +2131,7 @@ enum {
> > FI_HOT_DATA,/* indicate file is hot */
> > FI_EXTRA_ATTR,  /* indicate file has extra attribute */
> > FI_PROJ_INHERIT,/* indicate file inherits projectid */
> > +   FI_PIN_FILE,/* indicate file should not be gced */
> >  };
> >  
> >  static inline void __mark_inode_dirty_flag(struct inode *inode,
> > @@ -2137,6 +2145,7 @@ static inline void __mark_inode_dirty_flag(struct 
> > inode *inode,
> > return;
> > case FI_DATA_EXIST:
> > case FI_INLINE_DOTS:
> > +   case FI_PIN_FILE:
> > f2fs_mark_inode_dirty_sync(inode, true);
> > }
> >  }
> > @@ -2217,6 +2226,13 @@ static inline void f2fs_i_depth_write(struct inode 
> > *inode, unsigned int depth)
> > f2fs_mark_inode_dirty_sync(inode, true);
> >  }
> >  
> > +static inline void f2fs_i_gc_failures_write(struct inode *inode,
> > +   unsigned int count)
> > +{
> > +   F2FS_I(inode)->i_gc_failures = count;
> > +   f2fs_mark_inode_dirty_sync(inode, true);
> > +}
> > +
> >  static inline void f2fs_i_xnid_write(struct inode *inode, nid_t xnid)
> >  {
> > F2FS_I(inode)->i_xattr_nid = xnid;
> > @@ -2245,6 +2261,8 @@ static inline void get_inline_info(struct inode 
> > *inode, struct f2fs_inode *ri)
> > set_bit(FI_INLINE_DOTS, >flags);
> > if (ri->i_inline & F2FS_EXTRA_ATTR)
> > set_bit(FI_EXTRA_ATTR, >flags);
> > +   if (ri->i_inline & F2FS_PIN_FILE)
> > +   set_bit(FI_PIN_FILE, >flags);
> >  }
> >  
> >  static inline void set_raw_inline(struct inode *inode, struct f2fs_inode 
> > *ri)
> > @@ -2263,6 +2281,8 @@ static inline void set_raw_inline(struct inode 
> > *inode, struct f2fs_inode *ri)
> > ri->i_inline |= F2FS_INLINE_DOTS;
> > if (is_inode_flag_set(inode, FI_EXTRA_ATTR))
> > ri->i_inline |= F2FS_EXTRA_ATTR;
> > 

[PATCH 1/2] f2fs: show precise # of blocks that user/root can use

[Jaegeuk Kim]

Let's show precise # of blocks that user/root can use through bavail and bfree
respectively.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/super.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 0a820ba55b10..4c1c99cf54ef 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1005,9 +1005,9 @@ static int f2fs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
buf->f_bsize = sbi->blocksize;
 
buf->f_blocks = total_count - start_count;
-   buf->f_bfree = user_block_count - valid_user_blocks(sbi) + ovp_count;
-   buf->f_bavail = user_block_count - valid_user_blocks(sbi) -
+   buf->f_bfree = user_block_count - valid_user_blocks(sbi) -
sbi->current_reserved_blocks;
+   buf->f_bavail = buf->f_bfree;
 
avail_node_count = sbi->total_node_count - sbi->nquota_files -
F2FS_RESERVED_NODE_NUM;
-- 
2.15.0.531.g2ccb3012c9-goog

[PATCH 1/2] f2fs: show precise # of blocks that user/root can use

[Jaegeuk Kim]

Let's show precise # of blocks that user/root can use through bavail and bfree
respectively.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/super.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 0a820ba55b10..4c1c99cf54ef 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1005,9 +1005,9 @@ static int f2fs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
buf->f_bsize = sbi->blocksize;
 
buf->f_blocks = total_count - start_count;
-   buf->f_bfree = user_block_count - valid_user_blocks(sbi) + ovp_count;
-   buf->f_bavail = user_block_count - valid_user_blocks(sbi) -
+   buf->f_bfree = user_block_count - valid_user_blocks(sbi) -
sbi->current_reserved_blocks;
+   buf->f_bavail = buf->f_bfree;
 
avail_node_count = sbi->total_node_count - sbi->nquota_files -
F2FS_RESERVED_NODE_NUM;
-- 
2.15.0.531.g2ccb3012c9-goog

[PATCH 2/2] f2fs: add reserved blocks for root user

[Jaegeuk Kim]

This patch allows root to reserve some blocks via mount option.

"-o reserve_root=N" means N x 4KB-sized blocks for root only.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 26 ++
 fs/f2fs/super.c | 29 ++---
 fs/f2fs/sysfs.c |  3 ++-
 3 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 369607b1e776..fb98b51f7376 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -95,6 +95,7 @@ extern char *fault_name[FAULT_MAX];
 #define F2FS_MOUNT_PRJQUOTA0x0020
 #define F2FS_MOUNT_QUOTA   0x0040
 #define F2FS_MOUNT_INLINE_XATTR_SIZE   0x0080
+#define F2FS_MOUNT_RESERVE_ROOT0x0100
 
 #define clear_opt(sbi, option) ((sbi)->mount_opt.opt &= ~F2FS_MOUNT_##option)
 #define set_opt(sbi, option)   ((sbi)->mount_opt.opt |= F2FS_MOUNT_##option)
@@ -1109,6 +1110,7 @@ struct f2fs_sb_info {
block_t last_valid_block_count; /* for recovery */
block_t reserved_blocks;/* configurable reserved blocks 
*/
block_t current_reserved_blocks;/* current reserved blocks */
+   block_t root_reserved_blocks;   /* root reserved blocks */
 
unsigned int nquota_files;  /* # of quota sysfile */
 
@@ -1561,6 +1563,12 @@ static inline bool f2fs_has_xattr_block(unsigned int ofs)
return ofs == XATTR_NODE_OFFSET;
 }
 
+static inline block_t reserve_root_limit(struct f2fs_sb_info *sbi)
+{
+   /* limit is 0.2% */
+   return (sbi->user_block_count << 1) / 1000;
+}
+
 static inline void f2fs_i_blocks_write(struct inode *, block_t, bool, bool);
 static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
 struct inode *inode, blkcnt_t *count)
@@ -1590,11 +1598,17 @@ static inline int inc_valid_block_count(struct 
f2fs_sb_info *sbi,
sbi->total_valid_block_count += (block_t)(*count);
avail_user_block_count = sbi->user_block_count -
sbi->current_reserved_blocks;
+
+   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
+   avail_user_block_count -= sbi->root_reserved_blocks;
+
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
+   if (diff > *count)
+   diff = *count;
*count -= diff;
release = diff;
-   sbi->total_valid_block_count = avail_user_block_count;
+   sbi->total_valid_block_count -= diff;
if (!*count) {
spin_unlock(>stat_lock);
percpu_counter_sub(>alloc_valid_block_count, diff);
@@ -1783,9 +1797,13 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
 
spin_lock(>stat_lock);
 
-   valid_block_count = sbi->total_valid_block_count + 1;
-   if (unlikely(valid_block_count + sbi->current_reserved_blocks >
-   sbi->user_block_count)) {
+   valid_block_count = sbi->total_valid_block_count +
+   sbi->current_reserved_blocks + 1;
+
+   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
+   valid_block_count += sbi->root_reserved_blocks;
+
+   if (unlikely(valid_block_count > sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
}
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 4c1c99cf54ef..56b3caeec1ea 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -107,6 +107,7 @@ enum {
Opt_noextent_cache,
Opt_noinline_data,
Opt_data_flush,
+   Opt_reserve_root,
Opt_mode,
Opt_io_size_bits,
Opt_fault_injection,
@@ -157,6 +158,7 @@ static match_table_t f2fs_tokens = {
{Opt_noextent_cache, "noextent_cache"},
{Opt_noinline_data, "noinline_data"},
{Opt_data_flush, "data_flush"},
+   {Opt_reserve_root, "reserve_root=%u"},
{Opt_mode, "mode=%s"},
{Opt_io_size_bits, "io_bits=%u"},
{Opt_fault_injection, "fault_injection=%u"},
@@ -488,6 +490,18 @@ static int parse_options(struct super_block *sb, char 
*options)
case Opt_data_flush:
set_opt(sbi, DATA_FLUSH);
break;
+   case Opt_reserve_root:
+   if (args->from && match_int(args, ))
+   return -EINVAL;
+   if (test_opt(sbi, RESERVE_ROOT)) {
+   f2fs_msg(sb, KERN_INFO,
+   "Preserve previous reserve_root=%u",
+   sbi->root_reserved_blocks);
+   } else {
+   sbi->root_reserved_blocks = arg;
+ 

[PATCH 2/2] f2fs: add reserved blocks for root user

[Jaegeuk Kim]

This patch allows root to reserve some blocks via mount option.

"-o reserve_root=N" means N x 4KB-sized blocks for root only.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 26 ++
 fs/f2fs/super.c | 29 ++---
 fs/f2fs/sysfs.c |  3 ++-
 3 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 369607b1e776..fb98b51f7376 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -95,6 +95,7 @@ extern char *fault_name[FAULT_MAX];
 #define F2FS_MOUNT_PRJQUOTA0x0020
 #define F2FS_MOUNT_QUOTA   0x0040
 #define F2FS_MOUNT_INLINE_XATTR_SIZE   0x0080
+#define F2FS_MOUNT_RESERVE_ROOT0x0100
 
 #define clear_opt(sbi, option) ((sbi)->mount_opt.opt &= ~F2FS_MOUNT_##option)
 #define set_opt(sbi, option)   ((sbi)->mount_opt.opt |= F2FS_MOUNT_##option)
@@ -1109,6 +1110,7 @@ struct f2fs_sb_info {
block_t last_valid_block_count; /* for recovery */
block_t reserved_blocks;/* configurable reserved blocks 
*/
block_t current_reserved_blocks;/* current reserved blocks */
+   block_t root_reserved_blocks;   /* root reserved blocks */
 
unsigned int nquota_files;  /* # of quota sysfile */
 
@@ -1561,6 +1563,12 @@ static inline bool f2fs_has_xattr_block(unsigned int ofs)
return ofs == XATTR_NODE_OFFSET;
 }
 
+static inline block_t reserve_root_limit(struct f2fs_sb_info *sbi)
+{
+   /* limit is 0.2% */
+   return (sbi->user_block_count << 1) / 1000;
+}
+
 static inline void f2fs_i_blocks_write(struct inode *, block_t, bool, bool);
 static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
 struct inode *inode, blkcnt_t *count)
@@ -1590,11 +1598,17 @@ static inline int inc_valid_block_count(struct 
f2fs_sb_info *sbi,
sbi->total_valid_block_count += (block_t)(*count);
avail_user_block_count = sbi->user_block_count -
sbi->current_reserved_blocks;
+
+   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
+   avail_user_block_count -= sbi->root_reserved_blocks;
+
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
+   if (diff > *count)
+   diff = *count;
*count -= diff;
release = diff;
-   sbi->total_valid_block_count = avail_user_block_count;
+   sbi->total_valid_block_count -= diff;
if (!*count) {
spin_unlock(>stat_lock);
percpu_counter_sub(>alloc_valid_block_count, diff);
@@ -1783,9 +1797,13 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
 
spin_lock(>stat_lock);
 
-   valid_block_count = sbi->total_valid_block_count + 1;
-   if (unlikely(valid_block_count + sbi->current_reserved_blocks >
-   sbi->user_block_count)) {
+   valid_block_count = sbi->total_valid_block_count +
+   sbi->current_reserved_blocks + 1;
+
+   if (!(test_opt(sbi, RESERVE_ROOT) && capable(CAP_SYS_RESOURCE)))
+   valid_block_count += sbi->root_reserved_blocks;
+
+   if (unlikely(valid_block_count > sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
}
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 4c1c99cf54ef..56b3caeec1ea 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -107,6 +107,7 @@ enum {
Opt_noextent_cache,
Opt_noinline_data,
Opt_data_flush,
+   Opt_reserve_root,
Opt_mode,
Opt_io_size_bits,
Opt_fault_injection,
@@ -157,6 +158,7 @@ static match_table_t f2fs_tokens = {
{Opt_noextent_cache, "noextent_cache"},
{Opt_noinline_data, "noinline_data"},
{Opt_data_flush, "data_flush"},
+   {Opt_reserve_root, "reserve_root=%u"},
{Opt_mode, "mode=%s"},
{Opt_io_size_bits, "io_bits=%u"},
{Opt_fault_injection, "fault_injection=%u"},
@@ -488,6 +490,18 @@ static int parse_options(struct super_block *sb, char 
*options)
case Opt_data_flush:
set_opt(sbi, DATA_FLUSH);
break;
+   case Opt_reserve_root:
+   if (args->from && match_int(args, ))
+   return -EINVAL;
+   if (test_opt(sbi, RESERVE_ROOT)) {
+   f2fs_msg(sb, KERN_INFO,
+   "Preserve previous reserve_root=%u",
+   sbi->root_reserved_blocks);
+   } else {
+   sbi->root_reserved_blocks = arg;
+ 

[PATCH -mm] proc: fixup comment

[Alexey Dobriyan]

Document what ->pde_unload_lock actually does.

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/internal.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -38,7 +38,8 @@ struct proc_dir_entry {
atomic_t in_use;
atomic_t count; /* use count */
struct list_head pde_openers;   /* who did ->open, but not ->release */
-   spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
+   /* protects ->pde_openers and all struct pde_opener instances */
+   spinlock_t pde_unload_lock;
struct completion *pde_unload_completion;
const struct inode_operations *proc_iops;
const struct file_operations *proc_fops;

[PATCH -mm] proc: fixup comment

[Alexey Dobriyan]

Document what ->pde_unload_lock actually does.

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/internal.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -38,7 +38,8 @@ struct proc_dir_entry {
atomic_t in_use;
atomic_t count; /* use count */
struct list_head pde_openers;   /* who did ->open, but not ->release */
-   spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
+   /* protects ->pde_openers and all struct pde_opener instances */
+   spinlock_t pde_unload_lock;
struct completion *pde_unload_completion;
const struct inode_operations *proc_iops;
const struct file_operations *proc_fops;

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

[Cong Wang]

On Tue, Jan 2, 2018 at 3:58 PM, syzbot
 wrote:
> Hello,
>
> syzkaller hit the following crash on
> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
> cookies.  Check SNMP counters.
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
> net/ipv6/tcp_ipv6.c:1144
> Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
>
> CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144


tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
to this bug. I guess IPv6 is not supported for TLS? If so, need
a check on proto in tls_init()...




>  tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>  cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>  tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>  tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>  tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>  ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>  dst_input include/net/dst.h:466 [inline]
>  ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>  __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>  process_backlog+0x203/0x740 net/core/dev.c:5205
>  napi_poll net/core/dev.c:5603 [inline]
>  net_rx_action+0x792/0x1910 net/core/dev.c:5669
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>  
>  do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>  do_softirq kernel/softirq.c:177 [inline]
>  __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>  ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>  ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>  NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>  ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>  dst_output include/net/dst.h:460 [inline]
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>  __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>  tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>  tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
>  sock_release+0x8d/0x1e0 net/socket.c:600
>  sock_close+0x16/0x20 net/socket.c:1129
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  get_signal+0x73f/0x16c0 kernel/signal.c:2335
>  do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
>  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x4456e9
> RSP: 002b:7fb4de631da8 EFLAGS: 0246 ORIG_RAX: 

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

[Cong Wang]

On Tue, Jan 2, 2018 at 3:58 PM, syzbot
 wrote:
> Hello,
>
> syzkaller hit the following crash on
> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
> cookies.  Check SNMP counters.
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
> net/ipv6/tcp_ipv6.c:1144
> Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
>
> CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144


tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
to this bug. I guess IPv6 is not supported for TLS? If so, need
a check on proto in tls_init()...




>  tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>  cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>  tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>  tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>  tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>  ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>  dst_input include/net/dst.h:466 [inline]
>  ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>  __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>  process_backlog+0x203/0x740 net/core/dev.c:5205
>  napi_poll net/core/dev.c:5603 [inline]
>  net_rx_action+0x792/0x1910 net/core/dev.c:5669
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>  
>  do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>  do_softirq kernel/softirq.c:177 [inline]
>  __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>  ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>  ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>  NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>  ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>  dst_output include/net/dst.h:460 [inline]
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>  __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>  tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>  tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
>  sock_release+0x8d/0x1e0 net/socket.c:600
>  sock_close+0x16/0x20 net/socket.c:1129
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  get_signal+0x73f/0x16c0 kernel/signal.c:2335
>  do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
>  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x4456e9
> RSP: 002b:7fb4de631da8 EFLAGS: 0246 ORIG_RAX: 00ca
> RAX: fe00 RBX: 

Re: [PATCH v2 0/9] ASoC: Intel: Kconfig+acpi fixes

[Pierre-Louis Bossart]

On 01/03/2018 11:09 AM, Andy Shevchenko wrote:

On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:

The first patch solves issues reported by 0day with non-ACPI platforms

The second patch implements what Linus, Takashi and Mark
requested: a top-level selector defaulting to 'y' to easily filter all
other options and with no impact on code generation. There should be
no
functionality change and will avoid breaking audio for people using
make oldnoconfig.

The rest of the patch series does a more in-depth cleanup. It was
tested
on Baytrail/Cherrytrail/Skylake platforms with no regressions
observed and no reports of any compilation issues with 0-day or
randconfig.

The 5th patch is really the most important one, there were nested
configs which made no sense to me. I don't know the history which led
to such complicated stuff but simpler is better.

Patches 6..7 are just clean-ups of the machine driver configs,
for some reason there is no consistency in the settings so I tried to
apply common sense and use the same rules. At Andy Shevchenko's
suggestion,
I also replaced the broken dependency on X86_INTEL_LPSS by
MFD_INTEL_LPSS
for Skylake+ machines. No regressions were identified with this
change.

Patch 9 is new in this series and are just cosmetic changes (comments
and text simplification).

Thanks to Vinod Koul for his contributions and comments.

Couple of nitpicks and seems patch 9 missed some (all?) comments to be
addressed.

So, after fixing them:

Reviewed-by: Andy Shevchenko 


Thanks Andy for the quick review. the last patch is new and indeed could 
be cleaned-up further, will send a v3.



Changes since v1:
  fixed more 0-day warnings for e.g. s390 non-ACPI compilation
  fixed use of depends
  fixed use of CONFIG_
  fixed indentations as needed
  simplified text and comments
  
Changes since RFCv2:

  Moved machine drivers to submenu
  Dropped SND_SOC_INTEL_COMMON since it was not needed
  Added more comments for if/endif
  Simplified text for options (dropped "ASoC Intel driver")
  Fixed one 0-day warning
  
Changes since initial RFC:

  Removed default n
  Added help text for HASWELL, BAYTRAIL (legacy) and SKYLAKE options
  Made top level machine driver selection dependent on
INTEL_SST_TOPLEVEL.
  Added help text for PCI and HIFI2 platforms
  Replaced X86_INTEL_LPSS by MFD_INTEL_LPSS for Skylake+ devices
  Fixed a couple of indentation issues

Pierre-Louis Bossart (8):
   ASoC: acpi: add missing includes for non-ACPI platforms
   ASoC: Intel: Fix Kconfig with top-level selector
   ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies
   ASoC: Intel: document what Kconfig options do
   ASoC: Intel: Fix nested/unnecessary Kconfig dependencies
   ASoC: Intel: boards: align Kconfig dependencies for
Haswell/Broadwell
   ASoC: Intel: boards: align Kconfig configurations for HiFi2
   ASoC: Intel: boards: align/fix SKL/BXT/KBL Kconfigs

Vinod Koul (1):
   ASoC: Intel: kconfig: add some comments for if symbols

  include/sound/soc-acpi-intel-match.h |   1 +
  include/sound/soc-acpi.h |   1 +
  sound/soc/intel/Kconfig  | 116 +++--
  sound/soc/intel/Makefile |   2 +-
  sound/soc/intel/boards/Kconfig   | 191 ++--
---
  5 files changed, 186 insertions(+), 125 deletions(-)

Re: [PATCH v2 0/9] ASoC: Intel: Kconfig+acpi fixes

[Pierre-Louis Bossart]

On 01/03/2018 11:09 AM, Andy Shevchenko wrote:

On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:

The first patch solves issues reported by 0day with non-ACPI platforms

The second patch implements what Linus, Takashi and Mark
requested: a top-level selector defaulting to 'y' to easily filter all
other options and with no impact on code generation. There should be
no
functionality change and will avoid breaking audio for people using
make oldnoconfig.

The rest of the patch series does a more in-depth cleanup. It was
tested
on Baytrail/Cherrytrail/Skylake platforms with no regressions
observed and no reports of any compilation issues with 0-day or
randconfig.

The 5th patch is really the most important one, there were nested
configs which made no sense to me. I don't know the history which led
to such complicated stuff but simpler is better.

Patches 6..7 are just clean-ups of the machine driver configs,
for some reason there is no consistency in the settings so I tried to
apply common sense and use the same rules. At Andy Shevchenko's
suggestion,
I also replaced the broken dependency on X86_INTEL_LPSS by
MFD_INTEL_LPSS
for Skylake+ machines. No regressions were identified with this
change.

Patch 9 is new in this series and are just cosmetic changes (comments
and text simplification).

Thanks to Vinod Koul for his contributions and comments.

Couple of nitpicks and seems patch 9 missed some (all?) comments to be
addressed.

So, after fixing them:

Reviewed-by: Andy Shevchenko 


Thanks Andy for the quick review. the last patch is new and indeed could 
be cleaned-up further, will send a v3.



Changes since v1:
  fixed more 0-day warnings for e.g. s390 non-ACPI compilation
  fixed use of depends
  fixed use of CONFIG_
  fixed indentations as needed
  simplified text and comments
  
Changes since RFCv2:

  Moved machine drivers to submenu
  Dropped SND_SOC_INTEL_COMMON since it was not needed
  Added more comments for if/endif
  Simplified text for options (dropped "ASoC Intel driver")
  Fixed one 0-day warning
  
Changes since initial RFC:

  Removed default n
  Added help text for HASWELL, BAYTRAIL (legacy) and SKYLAKE options
  Made top level machine driver selection dependent on
INTEL_SST_TOPLEVEL.
  Added help text for PCI and HIFI2 platforms
  Replaced X86_INTEL_LPSS by MFD_INTEL_LPSS for Skylake+ devices
  Fixed a couple of indentation issues

Pierre-Louis Bossart (8):
   ASoC: acpi: add missing includes for non-ACPI platforms
   ASoC: Intel: Fix Kconfig with top-level selector
   ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies
   ASoC: Intel: document what Kconfig options do
   ASoC: Intel: Fix nested/unnecessary Kconfig dependencies
   ASoC: Intel: boards: align Kconfig dependencies for
Haswell/Broadwell
   ASoC: Intel: boards: align Kconfig configurations for HiFi2
   ASoC: Intel: boards: align/fix SKL/BXT/KBL Kconfigs

Vinod Koul (1):
   ASoC: Intel: kconfig: add some comments for if symbols

  include/sound/soc-acpi-intel-match.h |   1 +
  include/sound/soc-acpi.h |   1 +
  sound/soc/intel/Kconfig  | 116 +++--
  sound/soc/intel/Makefile |   2 +-
  sound/soc/intel/boards/Kconfig   | 191 ++--
---
  5 files changed, 186 insertions(+), 125 deletions(-)

Re: general protection fault in fib6_add (2)

[Wei Wang]

On Wed, Jan 3, 2018 at 8:16 AM, David Ahern  wrote:
> [ +wei...@google.com ]
>
> On 1/2/18 3:58 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+0693adff3f83403dc...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1514594846.496:7): avc:  denied  { map } for
>> pid=3201 comm="syzkaller001778" path="/root/syzkaller001778299"
>> dev="sda1" ino=16481
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
>> IPv6: Can't replace route, no match found
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 3201 Comm: syzkaller001778 Not tainted 4.15.0-rc5+ #151
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244

pn could be NULL if fib6_add_1() failed. Will submit a fix for this.

>> RSP: 0018:8801c7626a70 EFLAGS: 00010202
>> RAX: dc00 RBX: 0020 RCX: 84794465
>> RDX: 0004 RSI: 8801d38935f0 RDI: 0282
>> RBP: 8801c7626da0 R08: 110038ec4c35 R09: 
>> R10: 8801c7626c68 R11:  R12: fffe
>> R13:  R14:  R15: 0009
>> FS:  () GS:8801db20(0063)
>> knlGS:09b70840
>> CS:  0010 DS: 002b ES: 002b CR0: 80050033
>> CR2: 20be1000 CR3: 0001d585a006 CR4: 001606f0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1006
>>  ip6_route_multipath_add+0xd14/0x16c0 net/ipv6/route.c:3833
>>  inet6_rtm_newroute+0xdc/0x160 net/ipv6/route.c:3957
>>  rtnetlink_rcv_msg+0x733/0x1020 net/core/rtnetlink.c:4411
>>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
>>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4423
>>  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
>>  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
>>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
>>  sock_sendmsg_nosec net/socket.c:636 [inline]
>>  sock_sendmsg+0xca/0x110 net/socket.c:646
>>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
>>  call_write_iter include/linux/fs.h:1772 [inline]
>>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>>  do_iter_write+0x154/0x540 fs/read_write.c:932
>>  compat_writev+0x225/0x420 fs/read_write.c:1246
>>  do_compat_writev+0x115/0x220 fs/read_write.c:1267
>>  C_SYSC_writev fs/read_write.c:1278 [inline]
>>  compat_SyS_writev+0x26/0x30 fs/read_write.c:1274
>>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>>  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:125
>> RIP: 0023:0xf7f1fc79
>> RSP: 002b:ffb61bfc EFLAGS: 0203 ORIG_RAX: 0092
>> RAX: ffda RBX: 0003 RCX: 204aaff0
>> RDX: 0001 RSI: 0167 RDI: 0010
>> RBP: 0003 R08:  R09: 
>> R10:  R11:  R12: 
>> R13:  R14:  R15: 
>> Code: f1 a9 f6 fc e8 2c f2 e2 fc 85 c0 0f 85 d5 03 00 00 49 8d 5e 20 e8
>> db a9 f6 fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
>> 02 00 0f 85 5a 0c 00 00 4d 39 ee 4d 8b 7e 20 0f 95 c0 4c
>> RIP: fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244 RSP: 8801c7626a70
>> ---[ end trace 956c65133fcfff88 ]---
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the 

Re: general protection fault in fib6_add (2)

[Wei Wang]

On Wed, Jan 3, 2018 at 8:16 AM, David Ahern  wrote:
> [ +wei...@google.com ]
>
> On 1/2/18 3:58 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+0693adff3f83403dc...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1514594846.496:7): avc:  denied  { map } for
>> pid=3201 comm="syzkaller001778" path="/root/syzkaller001778299"
>> dev="sda1" ino=16481
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
>> IPv6: Can't replace route, no match found
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 3201 Comm: syzkaller001778 Not tainted 4.15.0-rc5+ #151
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244

pn could be NULL if fib6_add_1() failed. Will submit a fix for this.

>> RSP: 0018:8801c7626a70 EFLAGS: 00010202
>> RAX: dc00 RBX: 0020 RCX: 84794465
>> RDX: 0004 RSI: 8801d38935f0 RDI: 0282
>> RBP: 8801c7626da0 R08: 110038ec4c35 R09: 
>> R10: 8801c7626c68 R11:  R12: fffe
>> R13:  R14:  R15: 0009
>> FS:  () GS:8801db20(0063)
>> knlGS:09b70840
>> CS:  0010 DS: 002b ES: 002b CR0: 80050033
>> CR2: 20be1000 CR3: 0001d585a006 CR4: 001606f0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1006
>>  ip6_route_multipath_add+0xd14/0x16c0 net/ipv6/route.c:3833
>>  inet6_rtm_newroute+0xdc/0x160 net/ipv6/route.c:3957
>>  rtnetlink_rcv_msg+0x733/0x1020 net/core/rtnetlink.c:4411
>>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
>>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4423
>>  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
>>  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
>>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
>>  sock_sendmsg_nosec net/socket.c:636 [inline]
>>  sock_sendmsg+0xca/0x110 net/socket.c:646
>>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
>>  call_write_iter include/linux/fs.h:1772 [inline]
>>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>>  do_iter_write+0x154/0x540 fs/read_write.c:932
>>  compat_writev+0x225/0x420 fs/read_write.c:1246
>>  do_compat_writev+0x115/0x220 fs/read_write.c:1267
>>  C_SYSC_writev fs/read_write.c:1278 [inline]
>>  compat_SyS_writev+0x26/0x30 fs/read_write.c:1274
>>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>>  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:125
>> RIP: 0023:0xf7f1fc79
>> RSP: 002b:ffb61bfc EFLAGS: 0203 ORIG_RAX: 0092
>> RAX: ffda RBX: 0003 RCX: 204aaff0
>> RDX: 0001 RSI: 0167 RDI: 0010
>> RBP: 0003 R08:  R09: 
>> R10:  R11:  R12: 
>> R13:  R14:  R15: 
>> Code: f1 a9 f6 fc e8 2c f2 e2 fc 85 c0 0f 85 d5 03 00 00 49 8d 5e 20 e8
>> db a9 f6 fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
>> 02 00 0f 85 5a 0c 00 00 4d 39 ee 4d 8b 7e 20 0f 95 c0 4c
>> RIP: fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244 RSP: 8801c7626a70
>> ---[ end trace 956c65133fcfff88 ]---
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an 

[PATCH] proc: spread __ro_after_init

[Alexey Dobriyan]

/proc/self inode numbers, value of proc_inode_cache and st_nlink of
/proc/$TGID are fixed constants.

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/base.c|5 +++--
 fs/proc/inode.c   |3 ++-
 fs/proc/self.c|3 ++-
 fs/proc/thread_self.c |3 ++-
 4 files changed, 9 insertions(+), 5 deletions(-)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,8 +113,8 @@
  * in /proc for a task before it execs a suid executable.
  */
 
-static u8 nlink_tid;
-static u8 nlink_tgid;
+static u8 nlink_tid __ro_after_init;
+static u8 nlink_tgid __ro_after_init;
 
 struct pid_entry {
const char *name;
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -5,6 +5,7 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -52,7 +53,7 @@ static void proc_evict_inode(struct inode *inode)
}
 }
 
-static struct kmem_cache * proc_inode_cachep;
+static struct kmem_cache *proc_inode_cachep __ro_after_init;
 
 static struct inode *proc_alloc_inode(struct super_block *sb)
 {
--- a/fs/proc/self.c
+++ b/fs/proc/self.c
@@ -1,4 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,7 @@ static const struct inode_operations 
proc_self_inode_operations = {
.get_link   = proc_self_get_link,
 };
 
-static unsigned self_inum;
+static unsigned self_inum __ro_after_init;
 
 int proc_setup_self(struct super_block *s)
 {
--- a/fs/proc/thread_self.c
+++ b/fs/proc/thread_self.c
@@ -1,4 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,7 @@ static const struct inode_operations 
proc_thread_self_inode_operations = {
.get_link   = proc_thread_self_get_link,
 };
 
-static unsigned thread_self_inum;
+static unsigned thread_self_inum __ro_after_init;
 
 int proc_setup_thread_self(struct super_block *s)
 {

[PATCH] proc: spread __ro_after_init

[Alexey Dobriyan]

/proc/self inode numbers, value of proc_inode_cache and st_nlink of
/proc/$TGID are fixed constants.

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/base.c|5 +++--
 fs/proc/inode.c   |3 ++-
 fs/proc/self.c|3 ++-
 fs/proc/thread_self.c |3 ++-
 4 files changed, 9 insertions(+), 5 deletions(-)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,8 +113,8 @@
  * in /proc for a task before it execs a suid executable.
  */
 
-static u8 nlink_tid;
-static u8 nlink_tgid;
+static u8 nlink_tid __ro_after_init;
+static u8 nlink_tgid __ro_after_init;
 
 struct pid_entry {
const char *name;
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -5,6 +5,7 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -52,7 +53,7 @@ static void proc_evict_inode(struct inode *inode)
}
 }
 
-static struct kmem_cache * proc_inode_cachep;
+static struct kmem_cache *proc_inode_cachep __ro_after_init;
 
 static struct inode *proc_alloc_inode(struct super_block *sb)
 {
--- a/fs/proc/self.c
+++ b/fs/proc/self.c
@@ -1,4 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,7 @@ static const struct inode_operations 
proc_self_inode_operations = {
.get_link   = proc_self_get_link,
 };
 
-static unsigned self_inum;
+static unsigned self_inum __ro_after_init;
 
 int proc_setup_self(struct super_block *s)
 {
--- a/fs/proc/thread_self.c
+++ b/fs/proc/thread_self.c
@@ -1,4 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,7 @@ static const struct inode_operations 
proc_thread_self_inode_operations = {
.get_link   = proc_thread_self_get_link,
 };
 
-static unsigned thread_self_inum;
+static unsigned thread_self_inum __ro_after_init;
 
 int proc_setup_thread_self(struct super_block *s)
 {

Re: WARNING in rds_cmsg_rdma_args

[Santosh Shilimkar]

On 1/3/2018 12:58 AM, syzbot wrote:

Hello,

syzkaller hit the following crash on 
ad036b63ee57df9ab802a4eb20cbbbec66aa4520

git://git.cmpxchg.org/linux-mmots.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See 




for information about syzkaller reproducers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ef175b5825285531e...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for 
details.

If you forward the report, please keep this part and the footer.

audit: type=1400 audit(1514947982.760:7): avc:  denied  { map } for  
pid=3468 comm="syzkaller284818" path="/root/syzkaller284818499" 
dev="sda1" ino=16481 
scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
WARNING: CPU: 1 PID: 3468 at net/rds/rdma.c:617 
rds_cmsg_rdma_args+0xe96/0x1360 net/rds/rdma.c:617

Kernel panic - not syncing: panic_on_warn set ...


+Mohamed Ghannam, who was discussing similar issue and was going
to post fix for it. Checking args->nr_local against 0 upfront would
address this issue as well.

Regards,
Santosh

Re: WARNING in rds_cmsg_rdma_args

[Santosh Shilimkar]

On 1/3/2018 12:58 AM, syzbot wrote:

Hello,

syzkaller hit the following crash on 
ad036b63ee57df9ab802a4eb20cbbbec66aa4520

git://git.cmpxchg.org/linux-mmots.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See 




for information about syzkaller reproducers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ef175b5825285531e...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for 
details.

If you forward the report, please keep this part and the footer.

audit: type=1400 audit(1514947982.760:7): avc:  denied  { map } for  
pid=3468 comm="syzkaller284818" path="/root/syzkaller284818499" 
dev="sda1" ino=16481 
scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
WARNING: CPU: 1 PID: 3468 at net/rds/rdma.c:617 
rds_cmsg_rdma_args+0xe96/0x1360 net/rds/rdma.c:617

Kernel panic - not syncing: panic_on_warn set ...


+Mohamed Ghannam, who was discussing similar issue and was going
to post fix for it. Checking args->nr_local against 0 upfront would
address this issue as well.

Regards,
Santosh

[V3 2/2] ASoC: max98373: Added Amplifier Driver

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
Changes since v2:
* Splitted dt bindings to the separated patch
* Changed 'interelave-mode' device property from u32 to boolean

Changes since v1:
* Removed 'codec' from 'max98373_priv' structure
: Now 'max98373_set_clock' function use 'dai->codec.dev' 
instead of using 'max98373->codec.dev'.
* Removed 'max98373_dai_set_sysclk' function
: This function is not necessary. Removed 'sysclk' from 
'max98373_priv' as well.
* Removed 'iface' from 'max98373_priv' structure
: There is no function who refer max98373->iface variable.
* Added SPDX-License-Identifier

 sound/soc/codecs/Kconfig|   5 +
 sound/soc/codecs/Makefile   |   2 +
 sound/soc/codecs/max98373.c | 971 
 sound/soc/codecs/max98373.h | 212 ++
 4 files changed, 1190 insertions(+)
 create mode 100644 sound/soc/codecs/max98373.c
 create mode 100644 sound/soc/codecs/max98373.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 8b02bc8..9af2588 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -95,6 +95,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
select SND_SOC_MAX98927 if I2C
+   select SND_SOC_MAX98373 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
@@ -626,6 +627,10 @@ config SND_SOC_MAX98927
tristate "Maxim Integrated MAX98927 Speaker Amplifier"
depends on I2C
 
+config SND_SOC_MAX98373
+   tristate "Maxim Integrated MAX98373 Speaker Amplifier"
+   depends on I2C
+
 config SND_SOC_MAX9850
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 0977349..49db8e9 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -90,6 +90,7 @@ snd-soc-max9867-objs := max9867.o
 snd-soc-max98925-objs := max98925.o
 snd-soc-max98926-objs := max98926.o
 snd-soc-max98927-objs := max98927.o
+snd-soc-max98373-objs := max98373.o
 snd-soc-max9850-objs := max9850.o
 snd-soc-max9860-objs := max9860.o
 snd-soc-mc13783-objs := mc13783.o
@@ -334,6 +335,7 @@ obj-$(CONFIG_SND_SOC_MAX9867)   += snd-soc-max9867.o
 obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
 obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
 obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
+obj-$(CONFIG_SND_SOC_MAX98373) += snd-soc-max98373.o
 obj-$(CONFIG_SND_SOC_MAX9850)  += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MAX9860)  += snd-soc-max9860.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
new file mode 100644
index 000..9af0d98
--- /dev/null
+++ b/sound/soc/codecs/max98373.c
@@ -0,0 +1,971 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017, Maxim Integrated */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "max98373.h"
+
+static struct reg_default max98373_reg[] = {
+   {MAX98373_R2000_SW_RESET, 0x00},
+   {MAX98373_R2001_INT_RAW1, 0x00},
+   {MAX98373_R2002_INT_RAW2, 0x00},
+   {MAX98373_R2003_INT_RAW3, 0x00},
+   {MAX98373_R2004_INT_STATE1, 0x00},
+   {MAX98373_R2005_INT_STATE2, 0x00},
+   {MAX98373_R2006_INT_STATE3, 0x00},
+   {MAX98373_R2007_INT_FLAG1, 0x00},
+   {MAX98373_R2008_INT_FLAG2, 0x00},
+   {MAX98373_R2009_INT_FLAG3, 0x00},
+   {MAX98373_R200A_INT_EN1, 0x00},
+   {MAX98373_R200B_INT_EN2, 0x00},
+   {MAX98373_R200C_INT_EN3, 0x00},
+   {MAX98373_R200D_INT_FLAG_CLR1, 0x00},
+   {MAX98373_R200E_INT_FLAG_CLR2, 0x00},
+   {MAX98373_R200F_INT_FLAG_CLR3, 0x00},
+   {MAX98373_R2010_IRQ_CTRL, 0x00},
+   {MAX98373_R2014_THERM_WARN_THRESH, 0x10},
+   {MAX98373_R2015_THERM_SHDN_THRESH, 0x27},
+   {MAX98373_R2016_THERM_HYSTERESIS, 0x01},
+   {MAX98373_R2017_THERM_FOLDBACK_SET, 0xC0},
+   {MAX98373_R2018_THERM_FOLDBACK_EN, 0x00},
+   {MAX98373_R201E_PIN_DRIVE_STRENGTH, 0x55},
+   {MAX98373_R2020_PCM_TX_HIZ_EN_1, 0xFE},
+   {MAX98373_R2021_PCM_TX_HIZ_EN_2, 0xFF},
+   {MAX98373_R2022_PCM_TX_SRC_1, 0x00},
+   {MAX98373_R2023_PCM_TX_SRC_2, 0x00},
+   {MAX98373_R2024_PCM_DATA_FMT_CFG, 0xC0},
+   {MAX98373_R2025_AUDIO_IF_MODE, 0x00},
+   {MAX98373_R2026_PCM_CLOCK_RATIO, 0x04},
+   {MAX98373_R2027_PCM_SR_SETUP_1, 0x08},
+   {MAX98373_R2028_PCM_SR_SETUP_2, 0x88},
+   {MAX98373_R2029_PCM_TO_SPK_MONO_MIX_1, 0x00},
+   {MAX98373_R202A_PCM_TO_SPK_MONO_MIX_2, 0x00},
+   {MAX98373_R202B_PCM_RX_EN, 0x00},
+   {MAX98373_R202C_PCM_TX_EN, 0x00},
+   {MAX98373_R202E_ICC_RX_CH_EN_1, 0x00},
+   {MAX98373_R202F_ICC_RX_CH_EN_2, 0x00},
+   {MAX98373_R2030_ICC_TX_HIZ_EN_1, 0xFF},
+   

[V3 2/2] ASoC: max98373: Added Amplifier Driver

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
Changes since v2:
* Splitted dt bindings to the separated patch
* Changed 'interelave-mode' device property from u32 to boolean

Changes since v1:
* Removed 'codec' from 'max98373_priv' structure
: Now 'max98373_set_clock' function use 'dai->codec.dev' 
instead of using 'max98373->codec.dev'.
* Removed 'max98373_dai_set_sysclk' function
: This function is not necessary. Removed 'sysclk' from 
'max98373_priv' as well.
* Removed 'iface' from 'max98373_priv' structure
: There is no function who refer max98373->iface variable.
* Added SPDX-License-Identifier

 sound/soc/codecs/Kconfig|   5 +
 sound/soc/codecs/Makefile   |   2 +
 sound/soc/codecs/max98373.c | 971 
 sound/soc/codecs/max98373.h | 212 ++
 4 files changed, 1190 insertions(+)
 create mode 100644 sound/soc/codecs/max98373.c
 create mode 100644 sound/soc/codecs/max98373.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 8b02bc8..9af2588 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -95,6 +95,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
select SND_SOC_MAX98927 if I2C
+   select SND_SOC_MAX98373 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
@@ -626,6 +627,10 @@ config SND_SOC_MAX98927
tristate "Maxim Integrated MAX98927 Speaker Amplifier"
depends on I2C
 
+config SND_SOC_MAX98373
+   tristate "Maxim Integrated MAX98373 Speaker Amplifier"
+   depends on I2C
+
 config SND_SOC_MAX9850
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 0977349..49db8e9 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -90,6 +90,7 @@ snd-soc-max9867-objs := max9867.o
 snd-soc-max98925-objs := max98925.o
 snd-soc-max98926-objs := max98926.o
 snd-soc-max98927-objs := max98927.o
+snd-soc-max98373-objs := max98373.o
 snd-soc-max9850-objs := max9850.o
 snd-soc-max9860-objs := max9860.o
 snd-soc-mc13783-objs := mc13783.o
@@ -334,6 +335,7 @@ obj-$(CONFIG_SND_SOC_MAX9867)   += snd-soc-max9867.o
 obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
 obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
 obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
+obj-$(CONFIG_SND_SOC_MAX98373) += snd-soc-max98373.o
 obj-$(CONFIG_SND_SOC_MAX9850)  += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MAX9860)  += snd-soc-max9860.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
new file mode 100644
index 000..9af0d98
--- /dev/null
+++ b/sound/soc/codecs/max98373.c
@@ -0,0 +1,971 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017, Maxim Integrated */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "max98373.h"
+
+static struct reg_default max98373_reg[] = {
+   {MAX98373_R2000_SW_RESET, 0x00},
+   {MAX98373_R2001_INT_RAW1, 0x00},
+   {MAX98373_R2002_INT_RAW2, 0x00},
+   {MAX98373_R2003_INT_RAW3, 0x00},
+   {MAX98373_R2004_INT_STATE1, 0x00},
+   {MAX98373_R2005_INT_STATE2, 0x00},
+   {MAX98373_R2006_INT_STATE3, 0x00},
+   {MAX98373_R2007_INT_FLAG1, 0x00},
+   {MAX98373_R2008_INT_FLAG2, 0x00},
+   {MAX98373_R2009_INT_FLAG3, 0x00},
+   {MAX98373_R200A_INT_EN1, 0x00},
+   {MAX98373_R200B_INT_EN2, 0x00},
+   {MAX98373_R200C_INT_EN3, 0x00},
+   {MAX98373_R200D_INT_FLAG_CLR1, 0x00},
+   {MAX98373_R200E_INT_FLAG_CLR2, 0x00},
+   {MAX98373_R200F_INT_FLAG_CLR3, 0x00},
+   {MAX98373_R2010_IRQ_CTRL, 0x00},
+   {MAX98373_R2014_THERM_WARN_THRESH, 0x10},
+   {MAX98373_R2015_THERM_SHDN_THRESH, 0x27},
+   {MAX98373_R2016_THERM_HYSTERESIS, 0x01},
+   {MAX98373_R2017_THERM_FOLDBACK_SET, 0xC0},
+   {MAX98373_R2018_THERM_FOLDBACK_EN, 0x00},
+   {MAX98373_R201E_PIN_DRIVE_STRENGTH, 0x55},
+   {MAX98373_R2020_PCM_TX_HIZ_EN_1, 0xFE},
+   {MAX98373_R2021_PCM_TX_HIZ_EN_2, 0xFF},
+   {MAX98373_R2022_PCM_TX_SRC_1, 0x00},
+   {MAX98373_R2023_PCM_TX_SRC_2, 0x00},
+   {MAX98373_R2024_PCM_DATA_FMT_CFG, 0xC0},
+   {MAX98373_R2025_AUDIO_IF_MODE, 0x00},
+   {MAX98373_R2026_PCM_CLOCK_RATIO, 0x04},
+   {MAX98373_R2027_PCM_SR_SETUP_1, 0x08},
+   {MAX98373_R2028_PCM_SR_SETUP_2, 0x88},
+   {MAX98373_R2029_PCM_TO_SPK_MONO_MIX_1, 0x00},
+   {MAX98373_R202A_PCM_TO_SPK_MONO_MIX_2, 0x00},
+   {MAX98373_R202B_PCM_RX_EN, 0x00},
+   {MAX98373_R202C_PCM_TX_EN, 0x00},
+   {MAX98373_R202E_ICC_RX_CH_EN_1, 0x00},
+   {MAX98373_R202F_ICC_RX_CH_EN_2, 0x00},
+   {MAX98373_R2030_ICC_TX_HIZ_EN_1, 0xFF},
+   {MAX98373_R2031_ICC_TX_HIZ_EN_2, 

[V3 1/2] dt-bindings: Added device tree binding for max98373 amplifier

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
Changes since v2:
* Splitted dt bindings to the separated patch
* Changed 'interelave-mode' device property from u32 to boolean

 .../devicetree/bindings/sound/max98373.txt | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/max98373.txt

diff --git a/Documentation/devicetree/bindings/sound/max98373.txt 
b/Documentation/devicetree/bindings/sound/max98373.txt
new file mode 100644
index 000..456cb1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98373.txt
@@ -0,0 +1,40 @@
+Maxim Integrated MAX98373 Speaker Amplifier
+
+This device supports I2C.
+
+Required properties:
+
+ - compatible : "maxim,max98373"
+
+ - reg : the I2C address of the device.
+
+Optional properties:
+
+  - maxim,vmon-slot-no : slot number used to send voltage information
+   or in inteleave mode this will be used as
+   interleave slot.
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,imon-slot-no : slot number used to send current information
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,spkfb-slot-no : slot number used to send speaker feedback information
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,interleave-mode : For cases where a single combined channel
+  for the I/V sense data is not sufficient, the device can 
also be configured
+  to share a single data output channel on alternating frames.
+  In this configuration, the current and voltage data will be 
frame interleaved
+  on a single output channel.
+   Boolean, define to enable the interleave mode, Default : 
false
+
+Example:
+
+codec: max98373@31 {
+   compatible = "maxim,max98373";
+   reg = <0x31>;
+   maxim,vmon-slot-no = <0>;
+   maxim,imon-slot-no = <1>;
+   maxim,spkfb-slot-no = <2>;
+   maxim,interleave-mode;
+};
-- 
2.7.4

[V3 1/2] dt-bindings: Added device tree binding for max98373 amplifier

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
Changes since v2:
* Splitted dt bindings to the separated patch
* Changed 'interelave-mode' device property from u32 to boolean

 .../devicetree/bindings/sound/max98373.txt | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/max98373.txt

diff --git a/Documentation/devicetree/bindings/sound/max98373.txt 
b/Documentation/devicetree/bindings/sound/max98373.txt
new file mode 100644
index 000..456cb1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98373.txt
@@ -0,0 +1,40 @@
+Maxim Integrated MAX98373 Speaker Amplifier
+
+This device supports I2C.
+
+Required properties:
+
+ - compatible : "maxim,max98373"
+
+ - reg : the I2C address of the device.
+
+Optional properties:
+
+  - maxim,vmon-slot-no : slot number used to send voltage information
+   or in inteleave mode this will be used as
+   interleave slot.
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,imon-slot-no : slot number used to send current information
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,spkfb-slot-no : slot number used to send speaker feedback information
+   slot range : 0 ~ 15,  Default : 0
+
+  - maxim,interleave-mode : For cases where a single combined channel
+  for the I/V sense data is not sufficient, the device can 
also be configured
+  to share a single data output channel on alternating frames.
+  In this configuration, the current and voltage data will be 
frame interleaved
+  on a single output channel.
+   Boolean, define to enable the interleave mode, Default : 
false
+
+Example:
+
+codec: max98373@31 {
+   compatible = "maxim,max98373";
+   reg = <0x31>;
+   maxim,vmon-slot-no = <0>;
+   maxim,imon-slot-no = <1>;
+   maxim,spkfb-slot-no = <2>;
+   maxim,interleave-mode;
+};
-- 
2.7.4

RE: [v2] ASoC: max98373: Added Amplifier Driver

[Ryan Lee]

>-Original Message-
>From: Rob Herring [mailto:r...@kernel.org]
>Sent: Tuesday, December 26, 2017 3:33 PM
>To: Ryan Lee 
>Cc: lgirdw...@gmail.com; broo...@kernel.org; mark.rutl...@arm.com;
>pe...@perex.cz; ti...@suse.com; a...@arndb.de; a...@ti.com;
>robert.jarz...@free.fr; supercraig0...@gmail.com; jbru...@baylibre.com;
>dannenb...@ti.com; romain.per...@collabora.com;
>bryce.fergu...@rockwellcollins.com; kuninori.morimoto...@renesas.com; m-
>steckl...@ti.com; alsa-de...@alsa-project.org; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; ryan.lee.ma...@gmail.com
>Subject: Re: [v2] ASoC: max98373: Added Amplifier Driver
>
>EXTERNAL EMAIL
>
>
>
>On Mon, Dec 25, 2017 at 07:10:10AM -0800, Ryan Lee wrote:
>
>Needs a commit message.
>
>> Signed-off-by: Ryan Lee 
>> ---
>>
>> Changes since v1:
>>   * Removed 'codec' from 'max98373_priv' structure
>>   : Now 'max98373_set_clock' function use 'dai->codec.dev' 
>> instead of
>using 'max98373->codec.dev'.
>>   * Removed 'max98373_dai_set_sysclk' function
>>   : This function is not necessary. Removed 'sysclk' from
>'max98373_priv' as well.
>>   * Removed 'iface' from 'max98373_priv' structure
>>   : There is no function who refer max98373->iface variable.
>>   * Added SPDX-License-Identifier
>>
>>  .../devicetree/bindings/sound/max98373.txt |  43 +
>
>Please split bindings to separate patch.
Thank you for the feedback.
I will split it.

>
>>  sound/soc/codecs/Kconfig   |   5 +
>>  sound/soc/codecs/Makefile  |   2 +
>>  sound/soc/codecs/max98373.c| 974
>+
>>  sound/soc/codecs/max98373.h| 212 +
>>  5 files changed, 1236 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/sound/max98373.txt
>>  create mode 100644 sound/soc/codecs/max98373.c  create mode 100644
>> sound/soc/codecs/max98373.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/max98373.txt
>> b/Documentation/devicetree/bindings/sound/max98373.txt
>> new file mode 100644
>> index 000..22cd259
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/max98373.txt
>> @@ -0,0 +1,43 @@
>> +Maxim Integrated MAX98373 Speaker Amplifier
>> +
>> +This device supports I2C.
>> +
>> +Required properties:
>> +
>> +  - compatible : should be one of the following
>> +- "maxim,max98373"
>> +
>> +  - reg : the I2C address of the device.
>> +
>> +Optional properties:
>> +
>> +  - maxim,vmon-slot-no : slot number used to send voltage information
>> +   or in inteleave mode this will be used as
>> +   interleave slot.
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,imon-slot-no : slot number used to send current information
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,spkfb-slot-no : slot number used to send speaker feedback
>information
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,interleave-mode : When using two MAX98373 in a system it is
>> +   possible to create ADC data that that will
>> +   overflow the frame size. Digital Audio Interleave
>> +   mode provides a means to output VMON and IMON data
>> +   from two devices on a single DOUT line when running
>> +   smaller frames sizes such as 32 BCLKS per LRCLK or
>> +   48 BCLKS per LRCLK.
>> +   Range : 0 (off), 1 (on),  Default : 0
>
>This can be boolean instead.
I will change this to boolean type.
>
>> +
>> +Example:
>> +
>> +codec: max98373@31 {
>> +   compatible = "maxim,max98373";
>> +   reg = <0x31>;
>> +   maxim,vmon-slot-no = <0>;
>> +   maxim,imon-slot-no = <1>;
>> +   maxim,spkfb-slot-no = <2>;
>> +   maxim,interleave-mode = <0>;
>> +};

RE: [v2] ASoC: max98373: Added Amplifier Driver

[Ryan Lee]

>-Original Message-
>From: Rob Herring [mailto:r...@kernel.org]
>Sent: Tuesday, December 26, 2017 3:33 PM
>To: Ryan Lee 
>Cc: lgirdw...@gmail.com; broo...@kernel.org; mark.rutl...@arm.com;
>pe...@perex.cz; ti...@suse.com; a...@arndb.de; a...@ti.com;
>robert.jarz...@free.fr; supercraig0...@gmail.com; jbru...@baylibre.com;
>dannenb...@ti.com; romain.per...@collabora.com;
>bryce.fergu...@rockwellcollins.com; kuninori.morimoto...@renesas.com; m-
>steckl...@ti.com; alsa-de...@alsa-project.org; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; ryan.lee.ma...@gmail.com
>Subject: Re: [v2] ASoC: max98373: Added Amplifier Driver
>
>EXTERNAL EMAIL
>
>
>
>On Mon, Dec 25, 2017 at 07:10:10AM -0800, Ryan Lee wrote:
>
>Needs a commit message.
>
>> Signed-off-by: Ryan Lee 
>> ---
>>
>> Changes since v1:
>>   * Removed 'codec' from 'max98373_priv' structure
>>   : Now 'max98373_set_clock' function use 'dai->codec.dev' 
>> instead of
>using 'max98373->codec.dev'.
>>   * Removed 'max98373_dai_set_sysclk' function
>>   : This function is not necessary. Removed 'sysclk' from
>'max98373_priv' as well.
>>   * Removed 'iface' from 'max98373_priv' structure
>>   : There is no function who refer max98373->iface variable.
>>   * Added SPDX-License-Identifier
>>
>>  .../devicetree/bindings/sound/max98373.txt |  43 +
>
>Please split bindings to separate patch.
Thank you for the feedback.
I will split it.

>
>>  sound/soc/codecs/Kconfig   |   5 +
>>  sound/soc/codecs/Makefile  |   2 +
>>  sound/soc/codecs/max98373.c| 974
>+
>>  sound/soc/codecs/max98373.h| 212 +
>>  5 files changed, 1236 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/sound/max98373.txt
>>  create mode 100644 sound/soc/codecs/max98373.c  create mode 100644
>> sound/soc/codecs/max98373.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/max98373.txt
>> b/Documentation/devicetree/bindings/sound/max98373.txt
>> new file mode 100644
>> index 000..22cd259
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/max98373.txt
>> @@ -0,0 +1,43 @@
>> +Maxim Integrated MAX98373 Speaker Amplifier
>> +
>> +This device supports I2C.
>> +
>> +Required properties:
>> +
>> +  - compatible : should be one of the following
>> +- "maxim,max98373"
>> +
>> +  - reg : the I2C address of the device.
>> +
>> +Optional properties:
>> +
>> +  - maxim,vmon-slot-no : slot number used to send voltage information
>> +   or in inteleave mode this will be used as
>> +   interleave slot.
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,imon-slot-no : slot number used to send current information
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,spkfb-slot-no : slot number used to send speaker feedback
>information
>> +   slot range : 0 ~ 15,  Default : 0
>> +
>> +  - maxim,interleave-mode : When using two MAX98373 in a system it is
>> +   possible to create ADC data that that will
>> +   overflow the frame size. Digital Audio Interleave
>> +   mode provides a means to output VMON and IMON data
>> +   from two devices on a single DOUT line when running
>> +   smaller frames sizes such as 32 BCLKS per LRCLK or
>> +   48 BCLKS per LRCLK.
>> +   Range : 0 (off), 1 (on),  Default : 0
>
>This can be boolean instead.
I will change this to boolean type.
>
>> +
>> +Example:
>> +
>> +codec: max98373@31 {
>> +   compatible = "maxim,max98373";
>> +   reg = <0x31>;
>> +   maxim,vmon-slot-no = <0>;
>> +   maxim,imon-slot-no = <1>;
>> +   maxim,spkfb-slot-no = <2>;
>> +   maxim,interleave-mode = <0>;
>> +};

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Srinivas Kandagatla]

Thanks for your review comments,

On 03/01/18 17:20, Stephen Boyd wrote:

On 12/14/2017 09:34 AM, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 




diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
new file mode 100644
index ..5b2036317f71
--- /dev/null
+++ b/sound/soc/qcom/apq8096.c
@@ -0,0 +1,124 @@



+ */
+#include 


No clk usage though?

Will remove it in next version.




+#include 
+#include 
+#include 
+#include 

[...]



+static int apq8096_sbc_parse_of(struct snd_soc_card *card)
+{
+   struct device *dev = card->dev;
+   int ret;
+
+   ret = snd_soc_of_parse_card_name(card, "qcom,model");
+   if (ret)
+   dev_err(dev, "Error parsing card name: %d\n", ret);


So this prints an error, and the caller also prints an error when it
fails. Double error messages?



looks redundant, will remove it.

+
+   return ret;
+}
+
+static int msm_snd_apq8096_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct snd_soc_card *card;
+
+   card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
+   if (!card)
+   return -ENOMEM;
+
+   card->dev = >dev;
+
+   ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));


Why do we need to do this? Can you add some sort of comment in the code
about why?


Even though dsp supports 64 bit addresses, but the sid sits at offset of 
32, which brings this restriction of supporting only 32 bit iova.


thanks,
srini

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Srinivas Kandagatla]

Thanks for your review comments,

On 03/01/18 17:20, Stephen Boyd wrote:

On 12/14/2017 09:34 AM, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 




diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
new file mode 100644
index ..5b2036317f71
--- /dev/null
+++ b/sound/soc/qcom/apq8096.c
@@ -0,0 +1,124 @@



+ */
+#include 


No clk usage though?

Will remove it in next version.




+#include 
+#include 
+#include 
+#include 

[...]



+static int apq8096_sbc_parse_of(struct snd_soc_card *card)
+{
+   struct device *dev = card->dev;
+   int ret;
+
+   ret = snd_soc_of_parse_card_name(card, "qcom,model");
+   if (ret)
+   dev_err(dev, "Error parsing card name: %d\n", ret);


So this prints an error, and the caller also prints an error when it
fails. Double error messages?



looks redundant, will remove it.

+
+   return ret;
+}
+
+static int msm_snd_apq8096_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct snd_soc_card *card;
+
+   card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
+   if (!card)
+   return -ENOMEM;
+
+   card->dev = >dev;
+
+   ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));


Why do we need to do this? Can you add some sort of comment in the code
about why?


Even though dsp supports 64 bit addresses, but the sid sits at offset of 
32, which brings this restriction of supporting only 32 bit iova.


thanks,
srini

Re: perf test BPF failing on 4.15.0-rc6

[Arnaldo Carvalho de Melo]

Em Wed, Jan 03, 2018 at 03:27:01PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Continuing investigation...
> 
> After applying the fallback patch to allow new tools to work with older
> kernels:
> 
> [root@felicio ~]# perf test bpf
> 39: BPF filter:
> 39.1: Basic BPF filtering : Ok
> 39.2: BPF pinning : Ok
> 39.3: BPF prologue generation : Ok
> 39.4: BPF relocation checker  : Ok
> [root@felicio ~]# uname -a
> Linux felicio.ghostprotocols.net 4.13.0-rc7+ #1 SMP Mon Sep 11 13:56:18 -03 
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@felicio ~]# rpm -q glibc
> glibc-2.17-157.el7_3.2.x86_64
> [root@felicio ~]#
> 
> After applying the patch below I get to, which is what I am trying to
> fix now:
> 
> [root@jouet ~]# perf test bpf
> 39: BPF filter:
> 39.1: Basic BPF filtering : Ok
> 39.2: BPF pinning : Ok
> 39.3: BPF prologue generation : FAILED!
> 39.4: BPF relocation checker  : Skip
> [root@jouet ~]# 

Update the patch to the one at the end of this message to make it work
with older glibcs, so that we ask for epoll_pwait() and hook into that
as well().

Now checking why 39.3 fails...

- Arnaldo

diff --git a/tools/perf/tests/bpf-script-example.c 
b/tools/perf/tests/bpf-script-example.c
index 268e5f8e4aa2..d1e67e271675 100644
--- a/tools/perf/tests/bpf-script-example.c
+++ b/tools/perf/tests/bpf-script-example.c
@@ -31,7 +31,7 @@ struct bpf_map_def SEC("maps") flip_table = {
.max_entries = 1,
 };
 
-SEC("func=SyS_epoll_wait")
+SEC("func=SyS_epoll_pwait")
 int bpf_func__SyS_epoll_wait(void *ctx)
 {
int ind =0;
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 0512f1b5bfdb..7c04e2d5b60b 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -25,7 +25,7 @@ static int epoll_wait_loop(void)
 
/* Should fail NR_ITERS times */
for (i = 0; i < NR_ITERS; i++)
-   epoll_wait(-(i + 1), NULL, 0, 0);
+   epoll_pwait(-(i + 1), NULL, 0, 0, NULL);
return 0;
 }
 

Re: perf test BPF failing on 4.15.0-rc6

[Arnaldo Carvalho de Melo]

Em Wed, Jan 03, 2018 at 03:27:01PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Continuing investigation...
> 
> After applying the fallback patch to allow new tools to work with older
> kernels:
> 
> [root@felicio ~]# perf test bpf
> 39: BPF filter:
> 39.1: Basic BPF filtering : Ok
> 39.2: BPF pinning : Ok
> 39.3: BPF prologue generation : Ok
> 39.4: BPF relocation checker  : Ok
> [root@felicio ~]# uname -a
> Linux felicio.ghostprotocols.net 4.13.0-rc7+ #1 SMP Mon Sep 11 13:56:18 -03 
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@felicio ~]# rpm -q glibc
> glibc-2.17-157.el7_3.2.x86_64
> [root@felicio ~]#
> 
> After applying the patch below I get to, which is what I am trying to
> fix now:
> 
> [root@jouet ~]# perf test bpf
> 39: BPF filter:
> 39.1: Basic BPF filtering : Ok
> 39.2: BPF pinning : Ok
> 39.3: BPF prologue generation : FAILED!
> 39.4: BPF relocation checker  : Skip
> [root@jouet ~]# 

Update the patch to the one at the end of this message to make it work
with older glibcs, so that we ask for epoll_pwait() and hook into that
as well().

Now checking why 39.3 fails...

- Arnaldo

diff --git a/tools/perf/tests/bpf-script-example.c 
b/tools/perf/tests/bpf-script-example.c
index 268e5f8e4aa2..d1e67e271675 100644
--- a/tools/perf/tests/bpf-script-example.c
+++ b/tools/perf/tests/bpf-script-example.c
@@ -31,7 +31,7 @@ struct bpf_map_def SEC("maps") flip_table = {
.max_entries = 1,
 };
 
-SEC("func=SyS_epoll_wait")
+SEC("func=SyS_epoll_pwait")
 int bpf_func__SyS_epoll_wait(void *ctx)
 {
int ind =0;
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 0512f1b5bfdb..7c04e2d5b60b 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -25,7 +25,7 @@ static int epoll_wait_loop(void)
 
/* Should fail NR_ITERS times */
for (i = 0; i < NR_ITERS; i++)
-   epoll_wait(-(i + 1), NULL, 0, 0);
+   epoll_pwait(-(i + 1), NULL, 0, 0, NULL);
return 0;
 }
 

Re: perf test BPF failing on 4.15.0-rc6

[Arnaldo Carvalho de Melo]

Em Wed, Jan 03, 2018 at 01:58:44PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Jan 03, 2018 at 12:58:26PM +0800, Wangnan (F) escreveu:
> > And please check if the kprobe created by
> > 
> >  $ perf probe -v SyS_epoll_wait
> 
> [root@seventh ~]# perf probe -v SyS_epoll_wait
> probe-definition(0): SyS_epoll_wait 
> symbol:SyS_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Looking at the vmlinux_path (8 entries long)
> Using /usr/lib/debug/lib/modules/4.14.8-300.fc27.x86_64/vmlinux for symbols
> Open Debuginfo file: /usr/lib/debug/lib/modules/4.14.8-300.fc27.x86_64/vmlinux
> Try to find probe point from debuginfo.
> Matched function: SyS_epoll_wait [314b563]
> found inline addr: 0x812d8087
> Probe point found: compat_SyS_epoll_pwait+151
> found inline addr: 0x812d7e5a
> Probe point found: SyS_epoll_pwait+138
> found inline addr: 0x812d7cf0
> Probe point found: SyS_epoll_wait+0
> Found 3 probe_trace_events.
> Opening /sys/kernel/debug/tracing//kprobe_events write=1
> Writing event: p:probe/SyS_epoll_wait _text+2982023
> Writing event: p:probe/SyS_epoll_wait_1 _text+2981466
> Writing event: p:probe/SyS_epoll_wait_2 _text+2981104
> Added new events:
>   probe:SyS_epoll_wait (on SyS_epoll_wait)
>   probe:SyS_epoll_wait_1 (on SyS_epoll_wait)
>   probe:SyS_epoll_wait_2 (on SyS_epoll_wait)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe:SyS_epoll_wait_2 -aR sleep 1
> 
> [root@seventh ~]#
> 
> Then, with your proggie, it seems its glibc that now maps epoll_wait()
> to a different syscall than in older systems:
> 
> [root@seventh ~]# trace -e probe:SyS_epoll_wait* ~acme/epoll
>  0.018 ( 0.001 ms): epoll/20444 brk(  
> ) = 0x260
>  0.029 ( 0.004 ms): epoll/20444 access(filename: 0xe874ec0, mode: R   
> ) = -1 ENOENT No such file or directory
>  0.035 ( 0.003 ms): epoll/20444 openat(dfd: CWD, filename: 0xe872726, 
> flags: CLOEXEC  ) = 3
>  0.040 ( 0.002 ms): epoll/20444 fstat(fd: 3, statbuf: 0x7fffcc37b830  
> ) = 0
>  0.042 ( 0.002 ms): epoll/20444 mmap(len: 109538, prot: READ, flags: 
> PRIVATE, fd: 3   ) = 0x7fc50ea5d000
>  0.045 ( 0.001 ms): epoll/20444 close(fd: 3   
> ) = 0
>  0.052 ( 0.003 ms): epoll/20444 openat(dfd: CWD, filename: 0xea7ace0, 
> flags: CLOEXEC  ) = 3
>  0.056 ( 0.001 ms): epoll/20444 read(fd: 3, buf: 0x7fffcc37b9f8, count: 
> 832   ) = 832
>  0.059 ( 0.001 ms): epoll/20444 fstat(fd: 3, statbuf: 0x7fffcc37b890  
> ) = 0
>  0.060 ( 0.002 ms): epoll/20444 mmap(len: 8192, prot: READ|WRITE, flags: 
> PRIVATE|ANONYMOUS, fd: -1) = 0x7fc50ea5b000
>  0.065 ( 0.003 ms): epoll/20444 mmap(len: 4074112, prot: EXEC|READ, 
> flags: PRIVATE|DENYWRITE, fd: 3   ) = 0x7fc50e46e000
>  0.068 ( 0.004 ms): epoll/20444 mprotect(start: 0x7fc50e648000, len: 
> 2093056  ) = 0
>  0.073 ( 0.004 ms): epoll/20444 mmap(addr: 0x7fc50e847000, len: 24576, 
> prot: READ|WRITE, flags: PRIVATE|DENYWRITE|FIXED, fd: 3, off: 1937408) = 
> 0x7fc50e847000
>  0.079 ( 0.002 ms): epoll/20444 mmap(addr: 0x7fc50e84d000, len: 14976, 
> prot: READ|WRITE, flags: PRIVATE|ANONYMOUS|FIXED, fd: -1) = 0x7fc50e84d000
>  0.085 ( 0.001 ms): epoll/20444 close(fd: 3   
> ) = 0
>  0.093 ( 0.001 ms): epoll/20444 arch_prctl(option: 4098, arg2: 
> 140484331029696) = 0
>  0.128 ( 0.003 ms): epoll/20444 mprotect(start: 0x7fc50e847000, len: 
> 16384, prot: READ) = 0
>  0.133 ( 0.002 ms): epoll/20444 mprotect(start: 0x60, len: 4096, 
> prot: READ   ) = 0
>  0.137 ( 0.002 ms): epoll/20444 mprotect(start: 0x7fc50ea78000, len: 
> 4096, prot: READ ) = 0
>  0.140 ( 0.005 ms): epoll/20444 munmap(addr: 0x7fc50ea5d000, len: 109538  
> ) = 0
>  0.159 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -1, sigsetsize: 8   
> ) = -22
>  0.160 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -2, sigsetsize: 8   
> ) = -22
>  0.162 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -3, sigsetsize: 8   
> ) = -22
>  0.163 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -4, sigsetsize: 8   
> ) = -22
>  0.165 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -5, sigsetsize: 8   
> ) = -22
> 
>  0.279 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -85, sigsetsize: 8  
> ) = -22
>  0.280 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -86, sigsetsize: 8 

RE: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Stefan Chulski]

> Sorry, I find this very confusing.
> 
> It seems we have some people telling me that when there's no PHY described
> in DT, we use this link interrupt, and have a functional network interface
> (presumably at whatever speed.)

I give you couple of examples when we have functional network interface with
link interrupt:

1) 10G XLG mode without PHY - since XLG doesn't have auto negation mechanism
2) SGMII with in-band  auto negation
3) RGMII with auto negation done previously by boot loader or by change default 
fixed
speed same as speed on cable.

Of course correct way to do it in RGMII mode is use values provided by 
phylink/phylib.

Stefan.

> 
> I can't see this working from what you describe - what you describe basically
> tells me that when in-band autonegotiation is disabled, and we have no PHY in
> the kernel, then effectively we are in fixed-link mode - since we need to know
> what speed, duplex and flow control settings to use.
> 
> So, this means that mvpp2 should be enforcing the presence of a fixed-link
> description in DT if there is no PHY node at the moment, but it doesn't.
> 
> Instead, it looks to me like the speed and duplex settings are inherited from 
> the
> boot loader or whatever was running before - I can't find anything that
> configures MVPP2_GMAC_AUTONEG_CONFIG in this case.  That seems quite a
> mess.
> 
> Maybe I'm missing something, but I don't see how mvpp2 can be converted to
> phylink given this without causing some kind of regression, unless someone can
> be much clearer about exactly what kinds of link mvpp2 supports and how they
> work (which is basically what I asked back in
> October.)
> 
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: perf test BPF failing on 4.15.0-rc6

[Arnaldo Carvalho de Melo]

Em Wed, Jan 03, 2018 at 01:58:44PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Jan 03, 2018 at 12:58:26PM +0800, Wangnan (F) escreveu:
> > And please check if the kprobe created by
> > 
> >  $ perf probe -v SyS_epoll_wait
> 
> [root@seventh ~]# perf probe -v SyS_epoll_wait
> probe-definition(0): SyS_epoll_wait 
> symbol:SyS_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Looking at the vmlinux_path (8 entries long)
> Using /usr/lib/debug/lib/modules/4.14.8-300.fc27.x86_64/vmlinux for symbols
> Open Debuginfo file: /usr/lib/debug/lib/modules/4.14.8-300.fc27.x86_64/vmlinux
> Try to find probe point from debuginfo.
> Matched function: SyS_epoll_wait [314b563]
> found inline addr: 0x812d8087
> Probe point found: compat_SyS_epoll_pwait+151
> found inline addr: 0x812d7e5a
> Probe point found: SyS_epoll_pwait+138
> found inline addr: 0x812d7cf0
> Probe point found: SyS_epoll_wait+0
> Found 3 probe_trace_events.
> Opening /sys/kernel/debug/tracing//kprobe_events write=1
> Writing event: p:probe/SyS_epoll_wait _text+2982023
> Writing event: p:probe/SyS_epoll_wait_1 _text+2981466
> Writing event: p:probe/SyS_epoll_wait_2 _text+2981104
> Added new events:
>   probe:SyS_epoll_wait (on SyS_epoll_wait)
>   probe:SyS_epoll_wait_1 (on SyS_epoll_wait)
>   probe:SyS_epoll_wait_2 (on SyS_epoll_wait)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe:SyS_epoll_wait_2 -aR sleep 1
> 
> [root@seventh ~]#
> 
> Then, with your proggie, it seems its glibc that now maps epoll_wait()
> to a different syscall than in older systems:
> 
> [root@seventh ~]# trace -e probe:SyS_epoll_wait* ~acme/epoll
>  0.018 ( 0.001 ms): epoll/20444 brk(  
> ) = 0x260
>  0.029 ( 0.004 ms): epoll/20444 access(filename: 0xe874ec0, mode: R   
> ) = -1 ENOENT No such file or directory
>  0.035 ( 0.003 ms): epoll/20444 openat(dfd: CWD, filename: 0xe872726, 
> flags: CLOEXEC  ) = 3
>  0.040 ( 0.002 ms): epoll/20444 fstat(fd: 3, statbuf: 0x7fffcc37b830  
> ) = 0
>  0.042 ( 0.002 ms): epoll/20444 mmap(len: 109538, prot: READ, flags: 
> PRIVATE, fd: 3   ) = 0x7fc50ea5d000
>  0.045 ( 0.001 ms): epoll/20444 close(fd: 3   
> ) = 0
>  0.052 ( 0.003 ms): epoll/20444 openat(dfd: CWD, filename: 0xea7ace0, 
> flags: CLOEXEC  ) = 3
>  0.056 ( 0.001 ms): epoll/20444 read(fd: 3, buf: 0x7fffcc37b9f8, count: 
> 832   ) = 832
>  0.059 ( 0.001 ms): epoll/20444 fstat(fd: 3, statbuf: 0x7fffcc37b890  
> ) = 0
>  0.060 ( 0.002 ms): epoll/20444 mmap(len: 8192, prot: READ|WRITE, flags: 
> PRIVATE|ANONYMOUS, fd: -1) = 0x7fc50ea5b000
>  0.065 ( 0.003 ms): epoll/20444 mmap(len: 4074112, prot: EXEC|READ, 
> flags: PRIVATE|DENYWRITE, fd: 3   ) = 0x7fc50e46e000
>  0.068 ( 0.004 ms): epoll/20444 mprotect(start: 0x7fc50e648000, len: 
> 2093056  ) = 0
>  0.073 ( 0.004 ms): epoll/20444 mmap(addr: 0x7fc50e847000, len: 24576, 
> prot: READ|WRITE, flags: PRIVATE|DENYWRITE|FIXED, fd: 3, off: 1937408) = 
> 0x7fc50e847000
>  0.079 ( 0.002 ms): epoll/20444 mmap(addr: 0x7fc50e84d000, len: 14976, 
> prot: READ|WRITE, flags: PRIVATE|ANONYMOUS|FIXED, fd: -1) = 0x7fc50e84d000
>  0.085 ( 0.001 ms): epoll/20444 close(fd: 3   
> ) = 0
>  0.093 ( 0.001 ms): epoll/20444 arch_prctl(option: 4098, arg2: 
> 140484331029696) = 0
>  0.128 ( 0.003 ms): epoll/20444 mprotect(start: 0x7fc50e847000, len: 
> 16384, prot: READ) = 0
>  0.133 ( 0.002 ms): epoll/20444 mprotect(start: 0x60, len: 4096, 
> prot: READ   ) = 0
>  0.137 ( 0.002 ms): epoll/20444 mprotect(start: 0x7fc50ea78000, len: 
> 4096, prot: READ ) = 0
>  0.140 ( 0.005 ms): epoll/20444 munmap(addr: 0x7fc50ea5d000, len: 109538  
> ) = 0
>  0.159 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -1, sigsetsize: 8   
> ) = -22
>  0.160 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -2, sigsetsize: 8   
> ) = -22
>  0.162 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -3, sigsetsize: 8   
> ) = -22
>  0.163 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -4, sigsetsize: 8   
> ) = -22
>  0.165 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -5, sigsetsize: 8   
> ) = -22
> 
>  0.279 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -85, sigsetsize: 8  
> ) = -22
>  0.280 ( 0.001 ms): epoll/20444 epoll_pwait(epfd: -86, sigsetsize: 8 

RE: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Stefan Chulski]

> Sorry, I find this very confusing.
> 
> It seems we have some people telling me that when there's no PHY described
> in DT, we use this link interrupt, and have a functional network interface
> (presumably at whatever speed.)

I give you couple of examples when we have functional network interface with
link interrupt:

1) 10G XLG mode without PHY - since XLG doesn't have auto negation mechanism
2) SGMII with in-band  auto negation
3) RGMII with auto negation done previously by boot loader or by change default 
fixed
speed same as speed on cable.

Of course correct way to do it in RGMII mode is use values provided by 
phylink/phylib.

Stefan.

> 
> I can't see this working from what you describe - what you describe basically
> tells me that when in-band autonegotiation is disabled, and we have no PHY in
> the kernel, then effectively we are in fixed-link mode - since we need to know
> what speed, duplex and flow control settings to use.
> 
> So, this means that mvpp2 should be enforcing the presence of a fixed-link
> description in DT if there is no PHY node at the moment, but it doesn't.
> 
> Instead, it looks to me like the speed and duplex settings are inherited from 
> the
> boot loader or whatever was running before - I can't find anything that
> configures MVPP2_GMAC_AUTONEG_CONFIG in this case.  That seems quite a
> mess.
> 
> Maybe I'm missing something, but I don't see how mvpp2 can be converted to
> phylink given this without causing some kind of regression, unless someone can
> be much clearer about exactly what kinds of link mvpp2 supports and how they
> work (which is basically what I asked back in
> October.)
> 
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH 04/12] PCI: qcom: account for const type of of_device_id.data

[Lorenzo Pieralisi]

On Wed, Jan 03, 2018 at 01:38:27PM +0100, Julia Lawall wrote:
> 
> 
> On Wed, 3 Jan 2018, Lorenzo Pieralisi wrote:
> 
> > On Tue, Jan 02, 2018 at 02:28:00PM +0100, Julia Lawall wrote:
> > > This driver creates various const structures that it stores in the
> > > data field of an of_device_id array.
> > >
> > > Adding const to the declaration of the location that receives the
> > > const value from the data field ensures that the compiler will
> > > continue to check that the value is not modified.  Furthermore, the
> > > const-discarding cast on the extraction from the data field is no
> > > longer needed.
> > >
> > > Done using Coccinelle.
> > >
> > > Signed-off-by: Julia Lawall 
> > >
> > > ---
> > >  drivers/pci/dwc/pcie-qcom.c |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Hi Julia,
> >
> > I am happy to take this patch through the PCI tree unless you see a
> > problem with that, please let me know.
> 
> Please take it.  Thanks.

Applied to pci/dwc for v4.16, thanks.

Lorenzo

> julia
> 
> >
> > Thanks,
> > Lorenzo
> >
> > > diff -u -p a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> > > --- a/drivers/pci/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/dwc/pcie-qcom.c
> > > @@ -171,7 +171,7 @@ struct qcom_pcie {
> > >   union qcom_pcie_resources res;
> > >   struct phy *phy;
> > >   struct gpio_desc *reset;
> > > - struct qcom_pcie_ops *ops;
> > > + const struct qcom_pcie_ops *ops;
> > >  };
> > >
> > >  #define to_qcom_pcie(x)  dev_get_drvdata((x)->dev)
> > > @@ -1234,7 +1234,7 @@ static int qcom_pcie_probe(struct platfo
> > >
> > >   pcie->pci = pci;
> > >
> > > - pcie->ops = (struct qcom_pcie_ops *)of_device_get_match_data(dev);
> > > + pcie->ops = of_device_get_match_data(dev);
> > >
> > >   pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW);
> > >   if (IS_ERR(pcie->reset))
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 
> > in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Re: [PATCH 04/12] PCI: qcom: account for const type of of_device_id.data

[Lorenzo Pieralisi]

On Wed, Jan 03, 2018 at 01:38:27PM +0100, Julia Lawall wrote:
> 
> 
> On Wed, 3 Jan 2018, Lorenzo Pieralisi wrote:
> 
> > On Tue, Jan 02, 2018 at 02:28:00PM +0100, Julia Lawall wrote:
> > > This driver creates various const structures that it stores in the
> > > data field of an of_device_id array.
> > >
> > > Adding const to the declaration of the location that receives the
> > > const value from the data field ensures that the compiler will
> > > continue to check that the value is not modified.  Furthermore, the
> > > const-discarding cast on the extraction from the data field is no
> > > longer needed.
> > >
> > > Done using Coccinelle.
> > >
> > > Signed-off-by: Julia Lawall 
> > >
> > > ---
> > >  drivers/pci/dwc/pcie-qcom.c |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Hi Julia,
> >
> > I am happy to take this patch through the PCI tree unless you see a
> > problem with that, please let me know.
> 
> Please take it.  Thanks.

Applied to pci/dwc for v4.16, thanks.

Lorenzo

> julia
> 
> >
> > Thanks,
> > Lorenzo
> >
> > > diff -u -p a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> > > --- a/drivers/pci/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/dwc/pcie-qcom.c
> > > @@ -171,7 +171,7 @@ struct qcom_pcie {
> > >   union qcom_pcie_resources res;
> > >   struct phy *phy;
> > >   struct gpio_desc *reset;
> > > - struct qcom_pcie_ops *ops;
> > > + const struct qcom_pcie_ops *ops;
> > >  };
> > >
> > >  #define to_qcom_pcie(x)  dev_get_drvdata((x)->dev)
> > > @@ -1234,7 +1234,7 @@ static int qcom_pcie_probe(struct platfo
> > >
> > >   pcie->pci = pci;
> > >
> > > - pcie->ops = (struct qcom_pcie_ops *)of_device_get_match_data(dev);
> > > + pcie->ops = of_device_get_match_data(dev);
> > >
> > >   pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW);
> > >   if (IS_ERR(pcie->reset))
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 
> > in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

[Marc Zyngier]

On 03/01/18 18:13, Ganapatrao Kulkarni wrote:
> On Wed, Jan 3, 2018 at 5:06 PM, Marc Zyngier  wrote:
>> On 03/01/18 11:20, Ganapatrao Kulkarni wrote:
>>> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier  wrote:
 On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier  wrote:
>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved across node collections on ThunderX2
>>
>> node collections?
>
> ok, i will rephrase it.
>  i was intended to say cross NUMA node collection/cpu affinity change.
>
>>
>>> multi Socket platform, an interrupt stops routed to new collection
>>> and results in loss of interrupts.
>>>
>>> Adding workaround to issue INV after MOVI for cross-node collection
>>> move to flush out the cached entry.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  Documentation/arm64/silicon-errata.txt |  1 +
>>>  arch/arm64/Kconfig | 11 +++
>>>  drivers/irqchip/irq-gic-v3-its.c   | 24 
>>>  3 files changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.txt 
>>> b/Documentation/arm64/silicon-errata.txt
>>> index fc1c884..fb27cb5 100644
>>> --- a/Documentation/arm64/silicon-errata.txt
>>> +++ b/Documentation/arm64/silicon-errata.txt
>>> @@ -63,6 +63,7 @@ stable kernels.
>>>  | Cavium | ThunderX Core   | #27456  | 
>>> CAVIUM_ERRATUM_27456|
>>>  | Cavium | ThunderX Core   | #30115  | 
>>> CAVIUM_ERRATUM_30115|
>>>  | Cavium | ThunderX SMMUv2 | #27704  | N/A 
>>> |
>>> +| Cavium | ThunderX2 ITS   | #174| 
>>> CAVIUM_ERRATUM_174  |
>>>  | Cavium | ThunderX2 SMMUv3| #74 | N/A 
>>> |
>>>  | Cavium | ThunderX2 SMMUv3| #126| N/A 
>>> |
>>>  || | | 
>>> |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index c9a7e9e..71a7e30 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>
>>> If unsure, say Y.
>>>
>>> +config CAVIUM_ERRATUM_174
>>> + bool "Cavium ThunderX2 erratum 174"
>>> + depends on NUMA
>>
>> Why? This system will be affected no matter whether NUMA is selected or 
>> not.
>
> it does not makes sense to enable on non-NUMA/single socket platforms.
> By default NUMA is enabled on ThunderX2 dual socket platforms.

 
 config ARCH_THUNDER2
 bool "Cavium ThunderX2 Server Processors"
 select GPIOLIB
 help
   This enables support for Cavium's ThunderX2 CN99XX family of
   server processors.
 

 Do you see any NUMA here? I can perfectly compile a kernel with both
 sockets, and not using NUMA. NUMA has to do with memory, and not 
 interrupts.
>>>
>>> ok,  i will remote it.

>
>>
>>> + default y
>>> + help
>>> +   LPI stops routed to redistributors after inter node collection
>>> +   move in ITS. Enable workaround to invalidate ITS entry after
>>> +   inter-node collection move.
>>
>> That's a very terse description. Nobody knows what an LPI, a
>> redistributor or a collection is. Please explain what the erratum is in
>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>> affinity change) so that people understand whether or not they are 
>> affected.
>
> ok, i will rephrase it in next version.
>>
>>> +
>>> +   If unsure, say Y.
>>> +
>>>  config CAVIUM_ERRATUM_22375
>>>   bool "Cavium erratum 22375, 24313"
>>>   default y
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>>> b/drivers/irqchip/irq-gic-v3-its.c
>>> index 06f025f..d8b9c96 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -46,6 +46,7 @@
>>>  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174  (1ULL << 3)
>>>
>>>  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1 << 0)
>>>
>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, 
>>> const struct cpumask *mask_val,
>>>   if (cpu != its_dev->event_map.col_map[id]) {
>>>   

Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

[Marc Zyngier]

On 03/01/18 18:13, Ganapatrao Kulkarni wrote:
> On Wed, Jan 3, 2018 at 5:06 PM, Marc Zyngier  wrote:
>> On 03/01/18 11:20, Ganapatrao Kulkarni wrote:
>>> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier  wrote:
 On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier  wrote:
>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved across node collections on ThunderX2
>>
>> node collections?
>
> ok, i will rephrase it.
>  i was intended to say cross NUMA node collection/cpu affinity change.
>
>>
>>> multi Socket platform, an interrupt stops routed to new collection
>>> and results in loss of interrupts.
>>>
>>> Adding workaround to issue INV after MOVI for cross-node collection
>>> move to flush out the cached entry.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  Documentation/arm64/silicon-errata.txt |  1 +
>>>  arch/arm64/Kconfig | 11 +++
>>>  drivers/irqchip/irq-gic-v3-its.c   | 24 
>>>  3 files changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.txt 
>>> b/Documentation/arm64/silicon-errata.txt
>>> index fc1c884..fb27cb5 100644
>>> --- a/Documentation/arm64/silicon-errata.txt
>>> +++ b/Documentation/arm64/silicon-errata.txt
>>> @@ -63,6 +63,7 @@ stable kernels.
>>>  | Cavium | ThunderX Core   | #27456  | 
>>> CAVIUM_ERRATUM_27456|
>>>  | Cavium | ThunderX Core   | #30115  | 
>>> CAVIUM_ERRATUM_30115|
>>>  | Cavium | ThunderX SMMUv2 | #27704  | N/A 
>>> |
>>> +| Cavium | ThunderX2 ITS   | #174| 
>>> CAVIUM_ERRATUM_174  |
>>>  | Cavium | ThunderX2 SMMUv3| #74 | N/A 
>>> |
>>>  | Cavium | ThunderX2 SMMUv3| #126| N/A 
>>> |
>>>  || | | 
>>> |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index c9a7e9e..71a7e30 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>
>>> If unsure, say Y.
>>>
>>> +config CAVIUM_ERRATUM_174
>>> + bool "Cavium ThunderX2 erratum 174"
>>> + depends on NUMA
>>
>> Why? This system will be affected no matter whether NUMA is selected or 
>> not.
>
> it does not makes sense to enable on non-NUMA/single socket platforms.
> By default NUMA is enabled on ThunderX2 dual socket platforms.

 
 config ARCH_THUNDER2
 bool "Cavium ThunderX2 Server Processors"
 select GPIOLIB
 help
   This enables support for Cavium's ThunderX2 CN99XX family of
   server processors.
 

 Do you see any NUMA here? I can perfectly compile a kernel with both
 sockets, and not using NUMA. NUMA has to do with memory, and not 
 interrupts.
>>>
>>> ok,  i will remote it.

>
>>
>>> + default y
>>> + help
>>> +   LPI stops routed to redistributors after inter node collection
>>> +   move in ITS. Enable workaround to invalidate ITS entry after
>>> +   inter-node collection move.
>>
>> That's a very terse description. Nobody knows what an LPI, a
>> redistributor or a collection is. Please explain what the erratum is in
>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>> affinity change) so that people understand whether or not they are 
>> affected.
>
> ok, i will rephrase it in next version.
>>
>>> +
>>> +   If unsure, say Y.
>>> +
>>>  config CAVIUM_ERRATUM_22375
>>>   bool "Cavium erratum 22375, 24313"
>>>   default y
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>>> b/drivers/irqchip/irq-gic-v3-its.c
>>> index 06f025f..d8b9c96 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -46,6 +46,7 @@
>>>  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174  (1ULL << 3)
>>>
>>>  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1 << 0)
>>>
>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, 
>>> const struct cpumask *mask_val,
>>>   if (cpu != its_dev->event_map.col_map[id]) {
>>>   target_col = _dev->its->collections[cpu];
>>>   its_send_movi(its_dev, 

[PATCH] tty: n_gsm: Allow ADM response in addition to UA for control dlci

[Tony Lindgren]

Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:

# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: : f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: : f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT

Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.

The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":

  This issue is most commonly observed in GSM networks where in UE sends
  SABM and expects network to send UA response but it ends up receiving
  DM response from the network. SABM stands for Set asynchronous balanced
  mode, UA stands for Unnumbered Acknowledge and DA stands for
  Disconnected Mode.

  An RLP entity can be in one of two modes:
  - Asynchronous Balanced Mode (ABM)
  - Asynchronous Disconnected Mode (ADM)

Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.

Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.

Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.

Cc: linux-ser...@vger.kernel.org
Cc: Alan Cox 
Cc: Jiri Prchal 
Cc: Jiri Slaby 
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Peter Hurley 
Cc: Russ Gorby 
Cc: Sascha Hauer 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/tty/n_gsm.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1451,6 +1451,10 @@ static void gsm_dlci_open(struct gsm_dlci *dlci)
  * in which case an opening port goes back to closed and a closing port
  * is simply put into closed state (any further frames from the other
  * end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
  */
 
 static void gsm_dlci_t1(struct timer_list *t)
@@ -1464,8 +1468,15 @@ static void gsm_dlci_t1(struct timer_list *t)
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(>t1, jiffies + gsm->t1 * HZ / 100);
-   } else
+   } else if (!dlci->addr && gsm->control == (DM | PF)) {
+   if (debug & 8)
+   pr_info("DLCI %d opening in ADM mode.\n",
+   dlci->addr);
+   gsm_dlci_open(dlci);
+   } else {
gsm_dlci_close(dlci);
+   }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1483,8 +1494,8 @@ static void gsm_dlci_t1(struct timer_list *t)
  * @dlci: DLCI to open
  *
  * Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
  * running off timers and the responses.
  */
 
-- 
2.15.0

[PATCH] tty: n_gsm: Allow ADM response in addition to UA for control dlci

[Tony Lindgren]

Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:

# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: : f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: : f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT

Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.

The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":

  This issue is most commonly observed in GSM networks where in UE sends
  SABM and expects network to send UA response but it ends up receiving
  DM response from the network. SABM stands for Set asynchronous balanced
  mode, UA stands for Unnumbered Acknowledge and DA stands for
  Disconnected Mode.

  An RLP entity can be in one of two modes:
  - Asynchronous Balanced Mode (ABM)
  - Asynchronous Disconnected Mode (ADM)

Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.

Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.

Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.

Cc: linux-ser...@vger.kernel.org
Cc: Alan Cox 
Cc: Jiri Prchal 
Cc: Jiri Slaby 
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Peter Hurley 
Cc: Russ Gorby 
Cc: Sascha Hauer 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/tty/n_gsm.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1451,6 +1451,10 @@ static void gsm_dlci_open(struct gsm_dlci *dlci)
  * in which case an opening port goes back to closed and a closing port
  * is simply put into closed state (any further frames from the other
  * end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
  */
 
 static void gsm_dlci_t1(struct timer_list *t)
@@ -1464,8 +1468,15 @@ static void gsm_dlci_t1(struct timer_list *t)
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(>t1, jiffies + gsm->t1 * HZ / 100);
-   } else
+   } else if (!dlci->addr && gsm->control == (DM | PF)) {
+   if (debug & 8)
+   pr_info("DLCI %d opening in ADM mode.\n",
+   dlci->addr);
+   gsm_dlci_open(dlci);
+   } else {
gsm_dlci_close(dlci);
+   }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1483,8 +1494,8 @@ static void gsm_dlci_t1(struct timer_list *t)
  * @dlci: DLCI to open
  *
  * Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
  * running off timers and the responses.
  */
 
-- 
2.15.0

Re: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Marcin Wojtas]

Russell,

2018-01-03 18:54 GMT+01:00 Russell King - ARM Linux :
> On Wed, Jan 03, 2018 at 05:00:47PM +, Stefan Chulski wrote:
>> > > > -Original Message-
>> > > > Hi Russell,
>> > > >
>> > > > Indeed. RGMII MAC behaves same way, although it shouldn't be named
>> > > > as 'in- band' to be on par with the specifications. Anyway - this
>> > > > one is rather a stub for being able to work with ACPI, so once the
>> > > > MDIO bus works there, this will be out of any concerns.
>> > >
>> > > Hi Marcin,
>> > >
>> > > This is correct.
>> > > "in-band" supported only for SGMII mode.
>> > > IRQ link interrupt depend on "in-band"' auto negation only if "in-band"'
>> > enabled.
>> > > But IRQ link interrupt could be triggered with "in-band", "out-band" or 
>> > > with
>> > specific fixed speed/duplex/flow_contol.
>> >
>> > Hi Stefan,
>> >
>> > How does this work in RGMII mode - is this handled by the PP2 polling the 
>> > PHY
>> > to get the speed, duplex and flow control settings?
>> >
>>
>> IRQ interrupt doesn't handled speed, duplex and flow control settings.
>> It's just raised if number of criterions met:
>> 1) Physical signal detected by MAC
>> 2) MAC auto negotiation succeeded(valid only auto negotiation enabled in MAC 
>> and "in-band" bypass disabled)
>>
>> So if auto negotiation mechanism disabled in MAC or bypassed, link status 
>> would changes to up and IRQ interrupt be triggered.
>>
>> In case of RGMII mode obviously we don't have "in-band" auto negotiation and 
>> "out-band" cannot be used in Kernel(due to missed locks).
>> So auto negotiation should be disabled on MAC level and 
>> speed/duplex/flow_contol would be negotiate by PHY.
>> phylink/phylib infrastructure should provide speed/duplex/flow_contol(that 
>> were agreed between PHY's) to ppv2 driver.
>
> Sorry, I find this very confusing.
>
> It seems we have some people telling me that when there's no PHY
> described in DT, we use this link interrupt, and have a functional
> network interface (presumably at whatever speed.)
>
> I can't see this working from what you describe - what you describe
> basically tells me that when in-band autonegotiation is disabled, and we
> have no PHY in the kernel, then effectively we are in fixed-link mode -
> since we need to know what speed, duplex and flow control settings to
> use.
>
> So, this means that mvpp2 should be enforcing the presence of a
> fixed-link description in DT if there is no PHY node at the moment, but
> it doesn't.
>
> Instead, it looks to me like the speed and duplex settings are inherited
> from the boot loader or whatever was running before - I can't find
> anything that configures MVPP2_GMAC_AUTONEG_CONFIG in this case.  That
> seems quite a mess.

Just 3 cents from me about the RGMII + link IRQ, which is only a
temporary solution for ACPI. It works basing on the results of UEFI HW
PHY polling and inherited GMAC settings. Once this MDIO bus / PHY
handling lands, this configuration will be out of any question and
usage in the pp2 driver.

Marcin

>
> Maybe I'm missing something, but I don't see how mvpp2 can be converted
> to phylink given this without causing some kind of regression, unless
> someone can be much clearer about exactly what kinds of link mvpp2
> supports and how they work (which is basically what I asked back in
> October.)
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Marcin Wojtas]

Russell,

2018-01-03 18:54 GMT+01:00 Russell King - ARM Linux :
> On Wed, Jan 03, 2018 at 05:00:47PM +, Stefan Chulski wrote:
>> > > > -Original Message-
>> > > > Hi Russell,
>> > > >
>> > > > Indeed. RGMII MAC behaves same way, although it shouldn't be named
>> > > > as 'in- band' to be on par with the specifications. Anyway - this
>> > > > one is rather a stub for being able to work with ACPI, so once the
>> > > > MDIO bus works there, this will be out of any concerns.
>> > >
>> > > Hi Marcin,
>> > >
>> > > This is correct.
>> > > "in-band" supported only for SGMII mode.
>> > > IRQ link interrupt depend on "in-band"' auto negation only if "in-band"'
>> > enabled.
>> > > But IRQ link interrupt could be triggered with "in-band", "out-band" or 
>> > > with
>> > specific fixed speed/duplex/flow_contol.
>> >
>> > Hi Stefan,
>> >
>> > How does this work in RGMII mode - is this handled by the PP2 polling the 
>> > PHY
>> > to get the speed, duplex and flow control settings?
>> >
>>
>> IRQ interrupt doesn't handled speed, duplex and flow control settings.
>> It's just raised if number of criterions met:
>> 1) Physical signal detected by MAC
>> 2) MAC auto negotiation succeeded(valid only auto negotiation enabled in MAC 
>> and "in-band" bypass disabled)
>>
>> So if auto negotiation mechanism disabled in MAC or bypassed, link status 
>> would changes to up and IRQ interrupt be triggered.
>>
>> In case of RGMII mode obviously we don't have "in-band" auto negotiation and 
>> "out-band" cannot be used in Kernel(due to missed locks).
>> So auto negotiation should be disabled on MAC level and 
>> speed/duplex/flow_contol would be negotiate by PHY.
>> phylink/phylib infrastructure should provide speed/duplex/flow_contol(that 
>> were agreed between PHY's) to ppv2 driver.
>
> Sorry, I find this very confusing.
>
> It seems we have some people telling me that when there's no PHY
> described in DT, we use this link interrupt, and have a functional
> network interface (presumably at whatever speed.)
>
> I can't see this working from what you describe - what you describe
> basically tells me that when in-band autonegotiation is disabled, and we
> have no PHY in the kernel, then effectively we are in fixed-link mode -
> since we need to know what speed, duplex and flow control settings to
> use.
>
> So, this means that mvpp2 should be enforcing the presence of a
> fixed-link description in DT if there is no PHY node at the moment, but
> it doesn't.
>
> Instead, it looks to me like the speed and duplex settings are inherited
> from the boot loader or whatever was running before - I can't find
> anything that configures MVPP2_GMAC_AUTONEG_CONFIG in this case.  That
> seems quite a mess.

Just 3 cents from me about the RGMII + link IRQ, which is only a
temporary solution for ACPI. It works basing on the results of UEFI HW
PHY polling and inherited GMAC settings. Once this MDIO bus / PHY
handling lands, this configuration will be out of any question and
usage in the pp2 driver.

Marcin

>
> Maybe I'm missing something, but I don't see how mvpp2 can be converted
> to phylink given this without causing some kind of regression, unless
> someone can be much clearer about exactly what kinds of link mvpp2
> supports and how they work (which is basically what I asked back in
> October.)
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH v2 9/9] media: i2c: tw9910: Remove soc_camera dependencies

[Fabio Estevam]

On Wed, Jan 3, 2018 at 3:37 PM, jacopo mondi  wrote:

>> Initially the rest GPIO was doing:
>>
>> -   gpio_set_value(GPIO_PTT3, 0);
>> -   mdelay(10);
>> -   gpio_set_value(GPIO_PTT3, 1);
>> -   mdelay(10); /* wait to let chip come out of reset */
>
> And that's what my driver code does :)

No, on 5/9 you converted the original code to:

GPIO_LOOKUP("sh7722_pfc", GPIO_PTT3, "rstb", GPIO_ACTIVE_HIGH)

It should be GPIO_ACTIVE_LOW instead.

> My point is that if I read the manual and I see an active low gpio (0
> is reset state) then the driver code uses it as and active high one (1
> is the reset state), that would be weird to me.

Then on this patch you should do:

gpiod_set_value(priv->rstb_gpio, 1);  ---> This tells the GPIO to go
to its active state (In this case active == logic level 0)
usleep_range(500, 1000);
gpiod_set_value(priv->rstb_gpio, 0); ---> This tells the GPIO to go to
its inactive state (In this case inactive == logic level 1)

You can also look at Documentation/gpio/consumer.txt where the usage
of the gpiod_xxx API is described.

It seems you are confusing it with the legacy gpio_set_value() API
(Documentation/gpio/gpio-legacy.txt)

Hope this helps.

Re: [PATCH v2 9/9] media: i2c: tw9910: Remove soc_camera dependencies

[Fabio Estevam]

On Wed, Jan 3, 2018 at 3:37 PM, jacopo mondi  wrote:

>> Initially the rest GPIO was doing:
>>
>> -   gpio_set_value(GPIO_PTT3, 0);
>> -   mdelay(10);
>> -   gpio_set_value(GPIO_PTT3, 1);
>> -   mdelay(10); /* wait to let chip come out of reset */
>
> And that's what my driver code does :)

No, on 5/9 you converted the original code to:

GPIO_LOOKUP("sh7722_pfc", GPIO_PTT3, "rstb", GPIO_ACTIVE_HIGH)

It should be GPIO_ACTIVE_LOW instead.

> My point is that if I read the manual and I see an active low gpio (0
> is reset state) then the driver code uses it as and active high one (1
> is the reset state), that would be weird to me.

Then on this patch you should do:

gpiod_set_value(priv->rstb_gpio, 1);  ---> This tells the GPIO to go
to its active state (In this case active == logic level 0)
usleep_range(500, 1000);
gpiod_set_value(priv->rstb_gpio, 0); ---> This tells the GPIO to go to
its inactive state (In this case inactive == logic level 1)

You can also look at Documentation/gpio/consumer.txt where the usage
of the gpiod_xxx API is described.

It seems you are confusing it with the legacy gpio_set_value() API
(Documentation/gpio/gpio-legacy.txt)

Hope this helps.

Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

[Ganapatrao Kulkarni]

On Wed, Jan 3, 2018 at 5:06 PM, Marc Zyngier  wrote:
> On 03/01/18 11:20, Ganapatrao Kulkarni wrote:
>> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier  wrote:
>>> On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
 Hi Marc,

 On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier  wrote:
> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>> When an interrupt is moved across node collections on ThunderX2
>
> node collections?

 ok, i will rephrase it.
  i was intended to say cross NUMA node collection/cpu affinity change.

>
>> multi Socket platform, an interrupt stops routed to new collection
>> and results in loss of interrupts.
>>
>> Adding workaround to issue INV after MOVI for cross-node collection
>> move to flush out the cached entry.
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  Documentation/arm64/silicon-errata.txt |  1 +
>>  arch/arm64/Kconfig | 11 +++
>>  drivers/irqchip/irq-gic-v3-its.c   | 24 
>>  3 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/arm64/silicon-errata.txt 
>> b/Documentation/arm64/silicon-errata.txt
>> index fc1c884..fb27cb5 100644
>> --- a/Documentation/arm64/silicon-errata.txt
>> +++ b/Documentation/arm64/silicon-errata.txt
>> @@ -63,6 +63,7 @@ stable kernels.
>>  | Cavium | ThunderX Core   | #27456  | 
>> CAVIUM_ERRATUM_27456|
>>  | Cavium | ThunderX Core   | #30115  | 
>> CAVIUM_ERRATUM_30115|
>>  | Cavium | ThunderX SMMUv2 | #27704  | N/A  
>>|
>> +| Cavium | ThunderX2 ITS   | #174| 
>> CAVIUM_ERRATUM_174  |
>>  | Cavium | ThunderX2 SMMUv3| #74 | N/A  
>>|
>>  | Cavium | ThunderX2 SMMUv3| #126| N/A  
>>|
>>  || | |  
>>|
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c9a7e9e..71a7e30 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>
>> If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_174
>> + bool "Cavium ThunderX2 erratum 174"
>> + depends on NUMA
>
> Why? This system will be affected no matter whether NUMA is selected or 
> not.

 it does not makes sense to enable on non-NUMA/single socket platforms.
 By default NUMA is enabled on ThunderX2 dual socket platforms.
>>>
>>> 
>>> config ARCH_THUNDER2
>>> bool "Cavium ThunderX2 Server Processors"
>>> select GPIOLIB
>>> help
>>>   This enables support for Cavium's ThunderX2 CN99XX family of
>>>   server processors.
>>> 
>>>
>>> Do you see any NUMA here? I can perfectly compile a kernel with both
>>> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
>>
>> ok,  i will remote it.
>>>

>
>> + default y
>> + help
>> +   LPI stops routed to redistributors after inter node collection
>> +   move in ITS. Enable workaround to invalidate ITS entry after
>> +   inter-node collection move.
>
> That's a very terse description. Nobody knows what an LPI, a
> redistributor or a collection is. Please explain what the erratum is in
> layman's terms (Cavium ThunderX2 systems may loose interrupts on
> affinity change) so that people understand whether or not they are 
> affected.

 ok, i will rephrase it in next version.
>
>> +
>> +   If unsure, say Y.
>> +
>>  config CAVIUM_ERRATUM_22375
>>   bool "Cavium erratum 22375, 24313"
>>   default y
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d8b9c96 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -46,6 +46,7 @@
>>  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174  (1ULL << 3)
>>
>>  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1 << 0)
>>
>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, 
>> const struct cpumask *mask_val,
>>   if (cpu != its_dev->event_map.col_map[id]) {
>>   target_col = _dev->its->collections[cpu];
>>   its_send_movi(its_dev, target_col, id);
>> + if (its_dev->its->flags & 

Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

[Ganapatrao Kulkarni]

On Wed, Jan 3, 2018 at 5:06 PM, Marc Zyngier  wrote:
> On 03/01/18 11:20, Ganapatrao Kulkarni wrote:
>> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier  wrote:
>>> On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
 Hi Marc,

 On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier  wrote:
> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>> When an interrupt is moved across node collections on ThunderX2
>
> node collections?

 ok, i will rephrase it.
  i was intended to say cross NUMA node collection/cpu affinity change.

>
>> multi Socket platform, an interrupt stops routed to new collection
>> and results in loss of interrupts.
>>
>> Adding workaround to issue INV after MOVI for cross-node collection
>> move to flush out the cached entry.
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  Documentation/arm64/silicon-errata.txt |  1 +
>>  arch/arm64/Kconfig | 11 +++
>>  drivers/irqchip/irq-gic-v3-its.c   | 24 
>>  3 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/arm64/silicon-errata.txt 
>> b/Documentation/arm64/silicon-errata.txt
>> index fc1c884..fb27cb5 100644
>> --- a/Documentation/arm64/silicon-errata.txt
>> +++ b/Documentation/arm64/silicon-errata.txt
>> @@ -63,6 +63,7 @@ stable kernels.
>>  | Cavium | ThunderX Core   | #27456  | 
>> CAVIUM_ERRATUM_27456|
>>  | Cavium | ThunderX Core   | #30115  | 
>> CAVIUM_ERRATUM_30115|
>>  | Cavium | ThunderX SMMUv2 | #27704  | N/A  
>>|
>> +| Cavium | ThunderX2 ITS   | #174| 
>> CAVIUM_ERRATUM_174  |
>>  | Cavium | ThunderX2 SMMUv3| #74 | N/A  
>>|
>>  | Cavium | ThunderX2 SMMUv3| #126| N/A  
>>|
>>  || | |  
>>|
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c9a7e9e..71a7e30 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>
>> If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_174
>> + bool "Cavium ThunderX2 erratum 174"
>> + depends on NUMA
>
> Why? This system will be affected no matter whether NUMA is selected or 
> not.

 it does not makes sense to enable on non-NUMA/single socket platforms.
 By default NUMA is enabled on ThunderX2 dual socket platforms.
>>>
>>> 
>>> config ARCH_THUNDER2
>>> bool "Cavium ThunderX2 Server Processors"
>>> select GPIOLIB
>>> help
>>>   This enables support for Cavium's ThunderX2 CN99XX family of
>>>   server processors.
>>> 
>>>
>>> Do you see any NUMA here? I can perfectly compile a kernel with both
>>> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
>>
>> ok,  i will remote it.
>>>

>
>> + default y
>> + help
>> +   LPI stops routed to redistributors after inter node collection
>> +   move in ITS. Enable workaround to invalidate ITS entry after
>> +   inter-node collection move.
>
> That's a very terse description. Nobody knows what an LPI, a
> redistributor or a collection is. Please explain what the erratum is in
> layman's terms (Cavium ThunderX2 systems may loose interrupts on
> affinity change) so that people understand whether or not they are 
> affected.

 ok, i will rephrase it in next version.
>
>> +
>> +   If unsure, say Y.
>> +
>>  config CAVIUM_ERRATUM_22375
>>   bool "Cavium erratum 22375, 24313"
>>   default y
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d8b9c96 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -46,6 +46,7 @@
>>  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
>>  #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174  (1ULL << 3)
>>
>>  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1 << 0)
>>
>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, 
>> const struct cpumask *mask_val,
>>   if (cpu != its_dev->event_map.col_map[id]) {
>>   target_col = _dev->its->collections[cpu];
>>   its_send_movi(its_dev, target_col, id);
>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) 
>> {
>> + /* Issue INV for cross node collection move. 

Re: [PATCH v2 5/9] ASoC: Intel: Fix nested/unnecessary Kconfig dependencies

[Andy Shevchenko]

On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:
> This patch fixes a number of issues:
> 1. IOSF_MBI is only needed for byt-cr detection, which is only
> supported
> on Baytrail/Cherrytrail, move to HiFi2 config
> 

>   tristate "Intel ASoC SST driver for ACPI HiFi2 platforms
> (Baytrail, Cherrytrail)"
>   depends on X86 && ACPI
>   select SND_SST_IPC_ACPI
> + select IOSF_MBI
>   select SND_SOC_COMPRESS
>   select SND_SOC_ACPI_INTEL_MATCH
>   help

A nitpick: Perhaps not to split SND_* options and thus put IOSF_MBI as
last one in the list?

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v2 5/9] ASoC: Intel: Fix nested/unnecessary Kconfig dependencies

[Andy Shevchenko]

On Wed, 2018-01-03 at 10:50 -0600, Pierre-Louis Bossart wrote:
> This patch fixes a number of issues:
> 1. IOSF_MBI is only needed for byt-cr detection, which is only
> supported
> on Baytrail/Cherrytrail, move to HiFi2 config
> 

>   tristate "Intel ASoC SST driver for ACPI HiFi2 platforms
> (Baytrail, Cherrytrail)"
>   depends on X86 && ACPI
>   select SND_SST_IPC_ACPI
> + select IOSF_MBI
>   select SND_SOC_COMPRESS
>   select SND_SOC_ACPI_INTEL_MATCH
>   help

A nitpick: Perhaps not to split SND_* options and thus put IOSF_MBI as
last one in the list?

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [GIT PULL rcu/next] RCU commits for 4.15

[Paul E. McKenney]

On Wed, Jan 03, 2018 at 02:17:17PM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:

[ . . . ]

> Assuming that the subject line wanted to say v4.16, not v4.15 (which would be 
> really scary set of changes so late in the v4.15 cycle), I have pulled these 
> into 
> tip:core/rcu, thanks Paul!

You are correct, it is for the upcoming merge window, not for current
mainline.

Hmmm...  Maybe this is why I have thus far succeeded in writing 2018
rather than 2017?  ;-)

Thanx, Paul

Re: [GIT PULL rcu/next] RCU commits for 4.15

[Paul E. McKenney]

On Wed, Jan 03, 2018 at 02:17:17PM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:

[ . . . ]

> Assuming that the subject line wanted to say v4.16, not v4.15 (which would be 
> really scary set of changes so late in the v4.15 cycle), I have pulled these 
> into 
> tip:core/rcu, thanks Paul!

You are correct, it is for the upcoming merge window, not for current
mainline.

Hmmm...  Maybe this is why I have thus far succeeded in writing 2018
rather than 2017?  ;-)

Thanx, Paul

[PATCH v9 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

[Logan Gunthorpe]

Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.

Signed-off-by: Logan Gunthorpe 
Cc: Jon Mason 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index afe8ed6f3b23..53d3a34cddf3 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_DESCRIPTION("Microsemi Switchtec(tm) NTB Driver");
 MODULE_VERSION("0.1");
@@ -35,35 +36,6 @@ module_param(use_lut_mws, bool, 0644);
 MODULE_PARM_DESC(use_lut_mws,
 "Enable the use of the LUT based memory windows");
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 #define SWITCHTEC_NTB_MAGIC 0x45CC0001
 #define MAX_MWS 128
 
-- 
2.11.0

[PATCH v9 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

[Logan Gunthorpe]

Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.

Signed-off-by: Logan Gunthorpe 
Cc: Jon Mason 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index afe8ed6f3b23..53d3a34cddf3 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_DESCRIPTION("Microsemi Switchtec(tm) NTB Driver");
 MODULE_VERSION("0.1");
@@ -35,35 +36,6 @@ module_param(use_lut_mws, bool, 0644);
 MODULE_PARM_DESC(use_lut_mws,
 "Enable the use of the LUT based memory windows");
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 #define SWITCHTEC_NTB_MAGIC 0x45CC0001
 #define MAX_MWS 128
 
-- 
2.11.0

[PATCH v9 4/8] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.

These functions are only defined if readq and writeq are defined. If
they are not, then the wrappers that always use non-atomic operations
from include/linux/io-64-nonatomic*.h will be used.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: Suresh Warrier 
Cc: Nicholas Piggin 
---
 arch/powerpc/include/asm/io.h |   2 +
 include/asm-generic/iomap.h   |  26 +++--
 lib/iomap.c   | 132 ++
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index af074923d598..4cc420cfaa78 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size);
 
 #define mmio_read16be(addr)readw_be(addr)
 #define mmio_read32be(addr)readl_be(addr)
+#define mmio_read64be(addr)readq_be(addr)
 #define mmio_write16be(val, addr)  writew_be(val, addr)
 #define mmio_write32be(val, addr)  writel_be(val, addr)
+#define mmio_write64be(val, addr)  writeq_be(val, addr)
 #define mmio_insb(addr, dst, count)readsb(addr, dst, count)
 #define mmio_insw(addr, dst, count)readsw(addr, dst, count)
 #define mmio_insl(addr, dst, count)readsl(addr, dst, count)
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 5b63b94ef6b5..5a4af0199b32 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -31,9 +31,16 @@ extern unsigned int ioread16(void __iomem *);
 extern unsigned int ioread16be(void __iomem *);
 extern unsigned int ioread32(void __iomem *);
 extern unsigned int ioread32be(void __iomem *);
-#ifdef CONFIG_64BIT
-extern u64 ioread64(void __iomem *);
-extern u64 ioread64be(void __iomem *);
+
+#ifdef readq
+#define ioread64_lo_hi ioread64_lo_hi
+#define ioread64_hi_lo ioread64_hi_lo
+#define ioread64be_lo_hi ioread64be_lo_hi
+#define ioread64be_hi_lo ioread64be_hi_lo
+extern u64 ioread64_lo_hi(void __iomem *addr);
+extern u64 ioread64_hi_lo(void __iomem *addr);
+extern u64 ioread64be_lo_hi(void __iomem *addr);
+extern u64 ioread64be_hi_lo(void __iomem *addr);
 #endif
 
 extern void iowrite8(u8, void __iomem *);
@@ -41,9 +48,16 @@ extern void iowrite16(u16, void __iomem *);
 extern void iowrite16be(u16, void __iomem *);
 extern void iowrite32(u32, void __iomem *);
 extern void iowrite32be(u32, void __iomem *);
-#ifdef CONFIG_64BIT
-extern void iowrite64(u64, void __iomem *);
-extern void iowrite64be(u64, void __iomem *);
+
+#ifdef writeq
+#define iowrite64_lo_hi iowrite64_lo_hi
+#define iowrite64_hi_lo iowrite64_hi_lo
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+extern void iowrite64_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64_hi_lo(u64 val, void __iomem *addr);
+extern void iowrite64be_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64be_hi_lo(u64 val, void __iomem *addr);
 #endif
 
 /*
diff --git a/lib/iomap.c b/lib/iomap.c
index 541d926da95e..d324b6c013af 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -67,6 +67,7 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #ifndef mmio_read16be
 #define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
 #define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read64be(addr) be64_to_cpu(__raw_readq(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -100,6 +101,80 @@ EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
 
+#ifdef readq
+static u64 pio_read64_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = inl(port);
+   hi = inl(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = inl(port + sizeof(u32));
+   lo = inl(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = pio_read32be(port + sizeof(u32));
+   hi = pio_read32be(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = pio_read32be(port);
+   lo = pio_read32be(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr));
+   return 0xULL;
+}
+

[PATCH v9 4/8] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.

These functions are only defined if readq and writeq are defined. If
they are not, then the wrappers that always use non-atomic operations
from include/linux/io-64-nonatomic*.h will be used.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: Suresh Warrier 
Cc: Nicholas Piggin 
---
 arch/powerpc/include/asm/io.h |   2 +
 include/asm-generic/iomap.h   |  26 +++--
 lib/iomap.c   | 132 ++
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index af074923d598..4cc420cfaa78 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size);
 
 #define mmio_read16be(addr)readw_be(addr)
 #define mmio_read32be(addr)readl_be(addr)
+#define mmio_read64be(addr)readq_be(addr)
 #define mmio_write16be(val, addr)  writew_be(val, addr)
 #define mmio_write32be(val, addr)  writel_be(val, addr)
+#define mmio_write64be(val, addr)  writeq_be(val, addr)
 #define mmio_insb(addr, dst, count)readsb(addr, dst, count)
 #define mmio_insw(addr, dst, count)readsw(addr, dst, count)
 #define mmio_insl(addr, dst, count)readsl(addr, dst, count)
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 5b63b94ef6b5..5a4af0199b32 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -31,9 +31,16 @@ extern unsigned int ioread16(void __iomem *);
 extern unsigned int ioread16be(void __iomem *);
 extern unsigned int ioread32(void __iomem *);
 extern unsigned int ioread32be(void __iomem *);
-#ifdef CONFIG_64BIT
-extern u64 ioread64(void __iomem *);
-extern u64 ioread64be(void __iomem *);
+
+#ifdef readq
+#define ioread64_lo_hi ioread64_lo_hi
+#define ioread64_hi_lo ioread64_hi_lo
+#define ioread64be_lo_hi ioread64be_lo_hi
+#define ioread64be_hi_lo ioread64be_hi_lo
+extern u64 ioread64_lo_hi(void __iomem *addr);
+extern u64 ioread64_hi_lo(void __iomem *addr);
+extern u64 ioread64be_lo_hi(void __iomem *addr);
+extern u64 ioread64be_hi_lo(void __iomem *addr);
 #endif
 
 extern void iowrite8(u8, void __iomem *);
@@ -41,9 +48,16 @@ extern void iowrite16(u16, void __iomem *);
 extern void iowrite16be(u16, void __iomem *);
 extern void iowrite32(u32, void __iomem *);
 extern void iowrite32be(u32, void __iomem *);
-#ifdef CONFIG_64BIT
-extern void iowrite64(u64, void __iomem *);
-extern void iowrite64be(u64, void __iomem *);
+
+#ifdef writeq
+#define iowrite64_lo_hi iowrite64_lo_hi
+#define iowrite64_hi_lo iowrite64_hi_lo
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+extern void iowrite64_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64_hi_lo(u64 val, void __iomem *addr);
+extern void iowrite64be_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64be_hi_lo(u64 val, void __iomem *addr);
 #endif
 
 /*
diff --git a/lib/iomap.c b/lib/iomap.c
index 541d926da95e..d324b6c013af 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -67,6 +67,7 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #ifndef mmio_read16be
 #define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
 #define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read64be(addr) be64_to_cpu(__raw_readq(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -100,6 +101,80 @@ EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
 
+#ifdef readq
+static u64 pio_read64_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = inl(port);
+   hi = inl(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = inl(port + sizeof(u32));
+   lo = inl(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = pio_read32be(port + sizeof(u32));
+   hi = pio_read32be(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = pio_read32be(port);
+   lo = pio_read32be(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr));
+   return 0xULL;
+}
+
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   IO_COND(addr, return pio_read64_hi_lo(port), return readq(addr));
+   return 0xULL;
+}
+
+u64 

[PATCH v9 2/8] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Logan Gunthorpe]

Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.

Signed-off-by: Logan Gunthorpe 
Acked-by: Michael Ellerman 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Suresh Warrier 
Cc: "Oliver O'Halloran" 
---
 arch/powerpc/include/asm/io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 422f99cf9924..af074923d598 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -33,8 +33,6 @@ extern struct pci_dev *isa_bridge_pcidev;
 #include 
 #include 

-#include 
-
 #ifdef CONFIG_PPC64
 #include 
 #endif
@@ -663,6 +661,8 @@ static inline void name at  
\
 #define writel_relaxed(v, addr)writel(v, addr)
 #define writeq_relaxed(v, addr)writeq(v, addr)

+#include 
+
 #ifdef CONFIG_PPC32
 #define mmiowb()
 #else
--
2.11.0

[PATCH v9 2/8] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Logan Gunthorpe]

Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.

Signed-off-by: Logan Gunthorpe 
Acked-by: Michael Ellerman 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Suresh Warrier 
Cc: "Oliver O'Halloran" 
---
 arch/powerpc/include/asm/io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 422f99cf9924..af074923d598 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -33,8 +33,6 @@ extern struct pci_dev *isa_bridge_pcidev;
 #include 
 #include 

-#include 
-
 #ifdef CONFIG_PPC64
 #include 
 #endif
@@ -663,6 +661,8 @@ static inline void name at  
\
 #define writel_relaxed(v, addr)writel(v, addr)
 #define writeq_relaxed(v, addr)writeq(v, addr)

+#include 
+
 #ifdef CONFIG_PPC32
 #define mmiowb()
 #else
--
2.11.0

Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support

[Antoine Tenart]

Hi Andrew,

On Wed, Jan 03, 2018 at 04:53:11PM +0100, Andrew Lunn wrote:
> On Wed, Jan 03, 2018 at 04:32:27PM +0100, Antoine Tenart wrote:
> > On Wed, Jan 03, 2018 at 04:20:36PM +0100, Andrew Lunn wrote:
> > > > @@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port 
> > > > *port)
> > > > case PHY_INTERFACE_MODE_1000BASEX:
> > > > mode = PHY_MODE_SGMII;
> > > > break;
> > > > +   case PHY_INTERFACE_MODE_2500BASEX:
> > > > +   mode = PHY_MODE_2500SGMII;
> > > > +   break;
> > > 
> > > I think this is the source of confusion with linux/phy.h and
> > > linux/phy/phy.h.
> > > 
> > > What would PHY_INTERFACE_MODE_2500SGMII use?
> > > 
> > > Where is this all getting confused? Should the caller to
> > > mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
> > > What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
> > 
> > PHY_INTERFACE_MODE_2500BASEX is the PHY mode whereas PHY_MODE_2500SGMII
> > is the mode used by the common PHY driver (i.e. the one configuring the
> > serdes lanes).
> 
> > There's no PHY_INTERFACE_MODE_2500SGMII mode.
> 
> At the moment there is no PHY_INTERFACE_MODE_2500SGMII. However,
> there are some devices which can do 2.5G SGMII. So it will appear
> sometime. This piece of code then looks even stranger.

True. As said by Stefan the Marvell common PHY configures the serdes
lanes to a given mode, regardless of the actual use of the lanes by the
physical layer. So these modes are valid:

PPv2 (SGMII) - COMPHY (SGMII)
PPv2 (1000BaseX) - COMPHY (SGMII)
PPv2 (2500BaseX) - COMPHY (2500SGMII)

> > Sure, I can add a comment to state this function is a translation
> > between the net PHY mode and the generic PHY mode (it's a n-to-1
> > translation).
> 
> I think from an API design point of view, passing PHY_MODE_2500BASEX
> to comphy makes more sense. That is what the MAC wants to do. How the
> comphy achieves that should be internal to the comphy.

I though about that. The reason I did not is I wanted to use the
existing generic PHY framework helpers. They take a generic PHY mode in
input. I also wanted to avoid having a custom callback between the PPv2
driver and the COMPHY driver as phy_set_mode() seems to perfectly fit
the need.

The issue really is there are two PHY frameworks, one for network
devices and one for the other ones. The COMPHY is used by network
controllers, but also by SATA or USB ones.

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support

[Antoine Tenart]

Hi Andrew,

On Wed, Jan 03, 2018 at 04:53:11PM +0100, Andrew Lunn wrote:
> On Wed, Jan 03, 2018 at 04:32:27PM +0100, Antoine Tenart wrote:
> > On Wed, Jan 03, 2018 at 04:20:36PM +0100, Andrew Lunn wrote:
> > > > @@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port 
> > > > *port)
> > > > case PHY_INTERFACE_MODE_1000BASEX:
> > > > mode = PHY_MODE_SGMII;
> > > > break;
> > > > +   case PHY_INTERFACE_MODE_2500BASEX:
> > > > +   mode = PHY_MODE_2500SGMII;
> > > > +   break;
> > > 
> > > I think this is the source of confusion with linux/phy.h and
> > > linux/phy/phy.h.
> > > 
> > > What would PHY_INTERFACE_MODE_2500SGMII use?
> > > 
> > > Where is this all getting confused? Should the caller to
> > > mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
> > > What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
> > 
> > PHY_INTERFACE_MODE_2500BASEX is the PHY mode whereas PHY_MODE_2500SGMII
> > is the mode used by the common PHY driver (i.e. the one configuring the
> > serdes lanes).
> 
> > There's no PHY_INTERFACE_MODE_2500SGMII mode.
> 
> At the moment there is no PHY_INTERFACE_MODE_2500SGMII. However,
> there are some devices which can do 2.5G SGMII. So it will appear
> sometime. This piece of code then looks even stranger.

True. As said by Stefan the Marvell common PHY configures the serdes
lanes to a given mode, regardless of the actual use of the lanes by the
physical layer. So these modes are valid:

PPv2 (SGMII) - COMPHY (SGMII)
PPv2 (1000BaseX) - COMPHY (SGMII)
PPv2 (2500BaseX) - COMPHY (2500SGMII)

> > Sure, I can add a comment to state this function is a translation
> > between the net PHY mode and the generic PHY mode (it's a n-to-1
> > translation).
> 
> I think from an API design point of view, passing PHY_MODE_2500BASEX
> to comphy makes more sense. That is what the MAC wants to do. How the
> comphy achieves that should be internal to the comphy.

I though about that. The reason I did not is I wanted to use the
existing generic PHY framework helpers. They take a generic PHY mode in
input. I also wanted to avoid having a custom callback between the PPv2
driver and the COMPHY driver as phy_set_mode() seems to perfectly fit
the need.

The issue really is there are two PHY frameworks, one for network
devices and one for the other ones. The COMPHY is used by network
controllers, but also by SATA or USB ones.

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v9 5/8] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Logan Gunthorpe]

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).

The patch also points io{read|write}64[be] to the variant specified by the
header name.

This is because new drivers are encouraged to use ioreadXX, et al instead
of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.

[1] LDD3: section 9.4.2

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Cc: Christoph Hellwig 
Cc: Arnd Bergmann 
Cc: Alan Cox 
Cc: Greg Kroah-Hartman 
---
 include/linux/io-64-nonatomic-hi-lo.h | 64 +++
 include/linux/io-64-nonatomic-lo-hi.h | 64 +++
 2 files changed, 128 insertions(+)

diff --git a/include/linux/io-64-nonatomic-hi-lo.h 
b/include/linux/io-64-nonatomic-hi-lo.h
index 862d786a904f..ae21b72cce85 100644
--- a/include/linux/io-64-nonatomic-hi-lo.h
+++ b/include/linux/io-64-nonatomic-hi-lo.h
@@ -55,4 +55,68 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed hi_lo_writeq_relaxed
 #endif
 
+#ifndef ioread64_hi_lo
+#define ioread64_hi_lo ioread64_hi_lo
+static inline u64 ioread64_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32(addr + sizeof(u32));
+   low = ioread32(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_hi_lo
+#define iowrite64_hi_lo iowrite64_hi_lo
+static inline void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32(val >> 32, addr + sizeof(u32));
+   iowrite32(val, addr);
+}
+#endif
+
+#ifndef ioread64be_hi_lo
+#define ioread64be_hi_lo ioread64be_hi_lo
+static inline u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32be(addr);
+   low = ioread32be(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_hi_lo
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+static inline void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32be(val >> 32, addr);
+   iowrite32be(val, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_hi_lo
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_hi_lo
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_hi_lo
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_hi_lo
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_HI_LO_H_ */
diff --git a/include/linux/io-64-nonatomic-lo-hi.h 
b/include/linux/io-64-nonatomic-lo-hi.h
index d042e7bb5adb..faaa842dbdb9 100644
--- a/include/linux/io-64-nonatomic-lo-hi.h
+++ b/include/linux/io-64-nonatomic-lo-hi.h
@@ -55,4 +55,68 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed lo_hi_writeq_relaxed
 #endif
 
+#ifndef ioread64_lo_hi
+#define ioread64_lo_hi ioread64_lo_hi
+static inline u64 ioread64_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_lo_hi
+#define iowrite64_lo_hi iowrite64_lo_hi
+static inline void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32(val, addr);
+   iowrite32(val >> 32, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64be_lo_hi
+#define ioread64be_lo_hi ioread64be_lo_hi
+static inline u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_lo_hi
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+static inline void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32be(val, addr + sizeof(u32));
+   iowrite32be(val >> 32, addr);
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_lo_hi
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_lo_hi
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_lo_hi
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_lo_hi
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_LO_HI_H_ */
-- 
2.11.0

[PATCH v9 5/8] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Logan Gunthorpe]

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).

The patch also points io{read|write}64[be] to the variant specified by the
header name.

This is because new drivers are encouraged to use ioreadXX, et al instead
of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.

[1] LDD3: section 9.4.2

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Cc: Christoph Hellwig 
Cc: Arnd Bergmann 
Cc: Alan Cox 
Cc: Greg Kroah-Hartman 
---
 include/linux/io-64-nonatomic-hi-lo.h | 64 +++
 include/linux/io-64-nonatomic-lo-hi.h | 64 +++
 2 files changed, 128 insertions(+)

diff --git a/include/linux/io-64-nonatomic-hi-lo.h 
b/include/linux/io-64-nonatomic-hi-lo.h
index 862d786a904f..ae21b72cce85 100644
--- a/include/linux/io-64-nonatomic-hi-lo.h
+++ b/include/linux/io-64-nonatomic-hi-lo.h
@@ -55,4 +55,68 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed hi_lo_writeq_relaxed
 #endif
 
+#ifndef ioread64_hi_lo
+#define ioread64_hi_lo ioread64_hi_lo
+static inline u64 ioread64_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32(addr + sizeof(u32));
+   low = ioread32(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_hi_lo
+#define iowrite64_hi_lo iowrite64_hi_lo
+static inline void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32(val >> 32, addr + sizeof(u32));
+   iowrite32(val, addr);
+}
+#endif
+
+#ifndef ioread64be_hi_lo
+#define ioread64be_hi_lo ioread64be_hi_lo
+static inline u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32be(addr);
+   low = ioread32be(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_hi_lo
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+static inline void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32be(val >> 32, addr);
+   iowrite32be(val, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_hi_lo
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_hi_lo
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_hi_lo
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_hi_lo
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_HI_LO_H_ */
diff --git a/include/linux/io-64-nonatomic-lo-hi.h 
b/include/linux/io-64-nonatomic-lo-hi.h
index d042e7bb5adb..faaa842dbdb9 100644
--- a/include/linux/io-64-nonatomic-lo-hi.h
+++ b/include/linux/io-64-nonatomic-lo-hi.h
@@ -55,4 +55,68 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed lo_hi_writeq_relaxed
 #endif
 
+#ifndef ioread64_lo_hi
+#define ioread64_lo_hi ioread64_lo_hi
+static inline u64 ioread64_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_lo_hi
+#define iowrite64_lo_hi iowrite64_lo_hi
+static inline void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32(val, addr);
+   iowrite32(val >> 32, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64be_lo_hi
+#define ioread64be_lo_hi ioread64be_lo_hi
+static inline u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_lo_hi
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+static inline void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32be(val, addr + sizeof(u32));
+   iowrite32be(val >> 32, addr);
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_lo_hi
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_lo_hi
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_lo_hi
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_lo_hi
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_LO_HI_H_ */
-- 
2.11.0

[PATCH v9 6/8] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Acked-by: Dave Jiang 
Acked-by: Allen Hubbe 
Acked-by: Jon Mason 

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:  Mon Jun 19 12:18:31 2017 -0600
#
# interactive rebase in progress; onto ae64f9bd1d36
# Last commands done (6 commands done):
#pick cf3e4dab2173 io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} 
macros
#r 79b4c4b8490c ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver 
hacks
# Next commands to do (2 remaining commands):
#r 19b6c1f3b15d crypto: caam: cleanup CONFIG_64BIT ifdefs when using 
io{read|write}64
#r f3c8723446ef ntb_hw_switchtec: Cleanup 64bit IO defines to use the 
common header
# You are currently editing a commit while rebasing branch 'io64_v9' on 
'ae64f9bd1d36'.
#
# Changes to be committed:
#   modified:   drivers/ntb/hw/intel/ntb_hw_intel.c
#
---
 drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index 4de074a86073..119cfc45617e 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ntb_hw_intel.h"
 
@@ -155,35 +156,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
 static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd);
 static int xeon_init_isr(struct intel_ntb_dev *ndev);
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 static inline int pdev_is_atom(struct pci_dev *pdev)
 {
switch (pdev->device) {
-- 
2.11.0

[PATCH v9 3/8] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.

Signed-off-by: Logan Gunthorpe 
Tested-by: Horia Geantă 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
---
 arch/powerpc/kernel/iomap.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index aab456ed2a00..5ac84efc6ede 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -45,12 +45,32 @@ u64 ioread64(void __iomem *addr)
 {
return readq(addr);
 }
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   return readq(addr);
+}
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   return readq(addr);
+}
 u64 ioread64be(void __iomem *addr)
 {
return readq_be(addr);
 }
+u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   return readq_be(addr);
+}
+u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   return readq_be(addr);
+}
 EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(ioread64_lo_hi);
+EXPORT_SYMBOL(ioread64_hi_lo);
 EXPORT_SYMBOL(ioread64be);
+EXPORT_SYMBOL(ioread64be_lo_hi);
+EXPORT_SYMBOL(ioread64be_hi_lo);
 #endif /* __powerpc64__ */
 
 void iowrite8(u8 val, void __iomem *addr)
@@ -83,12 +103,32 @@ void iowrite64(u64 val, void __iomem *addr)
 {
writeq(val, addr);
 }
+void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
+void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
 void iowrite64be(u64 val, void __iomem *addr)
 {
writeq_be(val, addr);
 }
+void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
+void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
 EXPORT_SYMBOL(iowrite64);
+EXPORT_SYMBOL(iowrite64_lo_hi);
+EXPORT_SYMBOL(iowrite64_hi_lo);
 EXPORT_SYMBOL(iowrite64be);
+EXPORT_SYMBOL(iowrite64be_lo_hi);
+EXPORT_SYMBOL(iowrite64be_hi_lo);
 #endif /* __powerpc64__ */
 
 /*
-- 
2.11.0

[PATCH v9 6/8] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Andy Shevchenko 
Acked-by: Dave Jiang 
Acked-by: Allen Hubbe 
Acked-by: Jon Mason 

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:  Mon Jun 19 12:18:31 2017 -0600
#
# interactive rebase in progress; onto ae64f9bd1d36
# Last commands done (6 commands done):
#pick cf3e4dab2173 io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} 
macros
#r 79b4c4b8490c ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver 
hacks
# Next commands to do (2 remaining commands):
#r 19b6c1f3b15d crypto: caam: cleanup CONFIG_64BIT ifdefs when using 
io{read|write}64
#r f3c8723446ef ntb_hw_switchtec: Cleanup 64bit IO defines to use the 
common header
# You are currently editing a commit while rebasing branch 'io64_v9' on 
'ae64f9bd1d36'.
#
# Changes to be committed:
#   modified:   drivers/ntb/hw/intel/ntb_hw_intel.c
#
---
 drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index 4de074a86073..119cfc45617e 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ntb_hw_intel.h"
 
@@ -155,35 +156,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
 static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd);
 static int xeon_init_isr(struct intel_ntb_dev *ndev);
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 static inline int pdev_is_atom(struct pci_dev *pdev)
 {
switch (pdev->device) {
-- 
2.11.0

[PATCH v9 3/8] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.

Signed-off-by: Logan Gunthorpe 
Tested-by: Horia Geantă 
Reviewed-by: Andy Shevchenko 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
---
 arch/powerpc/kernel/iomap.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index aab456ed2a00..5ac84efc6ede 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -45,12 +45,32 @@ u64 ioread64(void __iomem *addr)
 {
return readq(addr);
 }
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   return readq(addr);
+}
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   return readq(addr);
+}
 u64 ioread64be(void __iomem *addr)
 {
return readq_be(addr);
 }
+u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   return readq_be(addr);
+}
+u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   return readq_be(addr);
+}
 EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(ioread64_lo_hi);
+EXPORT_SYMBOL(ioread64_hi_lo);
 EXPORT_SYMBOL(ioread64be);
+EXPORT_SYMBOL(ioread64be_lo_hi);
+EXPORT_SYMBOL(ioread64be_hi_lo);
 #endif /* __powerpc64__ */
 
 void iowrite8(u8 val, void __iomem *addr)
@@ -83,12 +103,32 @@ void iowrite64(u64 val, void __iomem *addr)
 {
writeq(val, addr);
 }
+void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
+void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
 void iowrite64be(u64 val, void __iomem *addr)
 {
writeq_be(val, addr);
 }
+void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
+void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
 EXPORT_SYMBOL(iowrite64);
+EXPORT_SYMBOL(iowrite64_lo_hi);
+EXPORT_SYMBOL(iowrite64_hi_lo);
 EXPORT_SYMBOL(iowrite64be);
+EXPORT_SYMBOL(iowrite64be_lo_hi);
+EXPORT_SYMBOL(iowrite64be_hi_lo);
 #endif /* __powerpc64__ */
 
 /*
-- 
2.11.0