RE: [PATCH v2 1/5] ramoops: use persistent_ram_free() instead of kfree() for freeing prz

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, July 29, 2016 4:35 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 1/5] ramoops: use persistent_ram_free() instead of
> kfree() for freeing prz
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > persistent_ram_zone(=prz) structures are allocated by
> > persistent_ram_new(), which includes vmap() or ioremap(). But they are
> > currently freed by kfree(). This uses persistent_ram_free() for correct
> this asymmetry usage.
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> 
> Oh, yes, oops. I may extract this patch and get it into v4.8, since this
> is an explicit bug fix. Thanks!
> 
> -Kees

Thanks. Please pickup this commit as bug fix.
And if you have a time, please review other patches in this patch series.

Best regards,
  Nobuhiro 

> 
> > ---
> >  fs/pstore/ram.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index bd9812e..22416c0
> > 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -567,11 +567,11 @@ fail_buf:
> > kfree(cxt->pstore.buf);
> >  fail_clear:
> > cxt->pstore.bufsize = 0;
> > -   kfree(cxt->mprz);
> > +   persistent_ram_free(cxt->mprz);
> >  fail_init_mprz:
> > -   kfree(cxt->fprz);
> > +   persistent_ram_free(cxt->fprz);
> >  fail_init_fprz:
> > -   kfree(cxt->cprz);
> > +   persistent_ram_free(cxt->cprz);
> >  fail_init_cprz:
> > ramoops_free_przs(cxt);
> >  fail_out:
> > --
> > 2.8.1
> >
> >
> 
> 
> 
> --
> Kees Cook
> Chrome OS & Brillo Security

RE: [PATCH v2 1/5] ramoops: use persistent_ram_free() instead of kfree() for freeing prz

[岩松信洋 / IWAMATSU，NOBUHIRO]

Hi,

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Friday, July 29, 2016 4:35 AM
> To: 岩松信洋 / IWAMATSU，NOBUHIRO
> Cc: Anton Vorontsov; Colin Cross; Tony Luck; LKML; Hiraku Toyooka; Mark
> Salyzyn; 阿口誠司 / AGUCHI，SEIJI
> Subject: Re: [PATCH v2 1/5] ramoops: use persistent_ram_free() instead of
> kfree() for freeing prz
> 
> On Sun, Jul 24, 2016 at 8:56 PM, Nobuhiro Iwamatsu
>  wrote:
> > From: Hiraku Toyooka 
> >
> > persistent_ram_zone(=prz) structures are allocated by
> > persistent_ram_new(), which includes vmap() or ioremap(). But they are
> > currently freed by kfree(). This uses persistent_ram_free() for correct
> this asymmetry usage.
> >
> > Signed-off-by: Hiraku Toyooka 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > Cc: Mark Salyzyn 
> > Cc: Seiji Aguchi 
> 
> Oh, yes, oops. I may extract this patch and get it into v4.8, since this
> is an explicit bug fix. Thanks!
> 
> -Kees

Thanks. Please pickup this commit as bug fix.
And if you have a time, please review other patches in this patch series.

Best regards,
  Nobuhiro 

> 
> > ---
> >  fs/pstore/ram.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index bd9812e..22416c0
> > 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -567,11 +567,11 @@ fail_buf:
> > kfree(cxt->pstore.buf);
> >  fail_clear:
> > cxt->pstore.bufsize = 0;
> > -   kfree(cxt->mprz);
> > +   persistent_ram_free(cxt->mprz);
> >  fail_init_mprz:
> > -   kfree(cxt->fprz);
> > +   persistent_ram_free(cxt->fprz);
> >  fail_init_fprz:
> > -   kfree(cxt->cprz);
> > +   persistent_ram_free(cxt->cprz);
> >  fail_init_cprz:
> > ramoops_free_przs(cxt);
> >  fail_out:
> > --
> > 2.8.1
> >
> >
> 
> 
> 
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH] regulator: axp20x: support AXP813 variant

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:19:44 +0200
Maxime Ripard  wrote:

> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
> >  drivers/mfd/axp20x-rsb.c |  1 +
> >  drivers/mfd/axp20x.c |  3 +
> >  drivers/regulator/axp20x-regulator.c | 82 
> > +++-
> >  include/linux/mfd/axp20x.h   | 38 +++
> >  5 files changed, 153 insertions(+), 3 deletions(-)
> 
> And this needs to be split per logical changes.

There is only one logical change: support the AXP813.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] regulator: axp20x: support AXP813 variant

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:19:44 +0200
Maxime Ripard  wrote:

> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
> >  drivers/mfd/axp20x-rsb.c |  1 +
> >  drivers/mfd/axp20x.c |  3 +
> >  drivers/regulator/axp20x-regulator.c | 82 
> > +++-
> >  include/linux/mfd/axp20x.h   | 38 +++
> >  5 files changed, 153 insertions(+), 3 deletions(-)
> 
> And this needs to be split per logical changes.

There is only one logical change: support the AXP813.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard  wrote:

> > > Let me know what you think,
> > 
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
> 
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
> 
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.

The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard  wrote:

> > > Let me know what you think,
> > 
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
> 
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
> 
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.

The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: Build failure in linux mainline when building arcv2 images

[Vineet Gupta]

Hi Guenter,

On 07/28/2016 08:23 PM, Guenter Roeck wrote:
> Hi Vineet,
> 
> Mainline fails to build arcv2 images with the following error.
> 
> {standard input}: Assembler messages:
> {standard input}:19174: Error: Instruction with long immediate data in delay 
> slot
> make[2]: *** [block/cfq-iosched.o] Error 1
> 
> Bisect points to commit 9a7f38c42c2 ("cfq-iosched: Convert from jiffies to
> nanoseconds"),
> but I don't really hold it responsible. It looks more like a compiler / 
> binutils
> problem
> to me.

Indeed - triggers a latent bug in ARC gcc !

> I am using a toolchain built with buildroot (gcc 4.8.3). Is there a more 
> recent
> toolchain
> than the one in buildroot available, by any chance ? If yes, where do I find 
> it ?

Yeah there's a 4.8.5 based one (referred to as GNU 2016.03) - will prebuilt
toolchain suffice or would you prefer building on your own. Prebuilt could be
found below.

https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03

For building on your own, Alexey can point to upstream buildroot which enabled
2016.03 tools.

Thx,
-Vineet

Re: Build failure in linux mainline when building arcv2 images

[Vineet Gupta]

Hi Guenter,

On 07/28/2016 08:23 PM, Guenter Roeck wrote:
> Hi Vineet,
> 
> Mainline fails to build arcv2 images with the following error.
> 
> {standard input}: Assembler messages:
> {standard input}:19174: Error: Instruction with long immediate data in delay 
> slot
> make[2]: *** [block/cfq-iosched.o] Error 1
> 
> Bisect points to commit 9a7f38c42c2 ("cfq-iosched: Convert from jiffies to
> nanoseconds"),
> but I don't really hold it responsible. It looks more like a compiler / 
> binutils
> problem
> to me.

Indeed - triggers a latent bug in ARC gcc !

> I am using a toolchain built with buildroot (gcc 4.8.3). Is there a more 
> recent
> toolchain
> than the one in buildroot available, by any chance ? If yes, where do I find 
> it ?

Yeah there's a 4.8.5 based one (referred to as GNU 2016.03) - will prebuilt
toolchain suffice or would you prefer building on your own. Prebuilt could be
found below.

https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03

For building on your own, Alexey can point to upstream buildroot which enabled
2016.03 tools.

Thx,
-Vineet

Re: [PATCH v2 4/4] ARM: OMAP2+: omap_device: fix crash on omap_device removal

[Peter Ujfalusi]

On 07/28/16 20:50, Grygorii Strashko wrote:
> Below call chain causes system crash when OMAP device is
> removed by calling of_platform_depopulate()/device_del():

Should you swap 3 <-> 4 in the series?
Currently patch 3 will introduce the crash you are fixing in patch 4...

> 
> device_del()
> - blocking_notifier_call_chain(>bus->p->bus_notifier,
>BUS_NOTIFY_DEL_DEVICE, dev);
>   - _omap_device_notifier_call()
> - omap_device_delete()
>   - od->pdev->archdata.od = NULL;
>   kfree(od->hwmods);
>   kfree(od);
>   - bus_remove_device()
> - device_release_driver()
>   - __device_release_driver()
>   - pm_runtime_get_sync()
>  - _od_runtime_resume()
>- omap_hwmod_enable() <- OOPS od's delted already
> 
> Backtrace:
> Unable to handle kernel NULL pointer dereference at virtual address 000d
> pgd = eb10
> [000d] *pgd=ad6e1831, *pte=, *ppte=
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty 
> #68
> Hardware name: Generic DRA74X (Flattened Device Tree)
> task: eb1ee800 ti: ec962000 task.ti: ec962000
> PC is at omap_device_enable+0x10/0x90
> LR is at _od_runtime_resume+0x10/0x24
> [...]
> [] (omap_device_enable) from [] 
> (_od_runtime_resume+0x10/0x24)
> [] (_od_runtime_resume) from [] (__rpm_callback+0x20/0x34)
> [] (__rpm_callback) from [] (rpm_callback+0x20/0x80)
> [] (rpm_callback) from [] (rpm_resume+0x48c/0x964)
> [] (rpm_resume) from [] (__pm_runtime_resume+0x60/0x88)
> [] (__pm_runtime_resume) from [] 
> (__device_release_driver+0x30/0x100)
> [] (__device_release_driver) from [] 
> (device_release_driver+0x1c/0x28)
> [] (device_release_driver) from [] 
> (bus_remove_device+0xec/0x144)
> [] (bus_remove_device) from [] (device_del+0x10c/0x210)
> [] (device_del) from [] (platform_device_del+0x18/0x84)
> [] (platform_device_del) from [] 
> (platform_device_unregister+0xc/0x20)
> [] (platform_device_unregister) from [] 
> (of_platform_device_destroy+0x8c/0x90)
> [] (of_platform_device_destroy) from [] 
> (device_for_each_child+0x4c/0x78)
> [] (device_for_each_child) from [] 
> (of_platform_depopulate+0x30/0x44)
> [] (of_platform_depopulate) from [] 
> (cpsw_remove+0x68/0xf4 [ti_cpsw])
> [] (cpsw_remove [ti_cpsw]) from [] 
> (platform_drv_remove+0x24/0x3c)
> [] (platform_drv_remove) from [] 
> (__device_release_driver+0x84/0x100)
> [] (__device_release_driver) from [] 
> (driver_detach+0xac/0xb0)
> [] (driver_detach) from [] (bus_remove_driver+0x60/0xd4)
> [] (bus_remove_driver) from [] 
> (SyS_delete_module+0x184/0x20c)
> [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x1c)
> Code: e350 e92d4070 1590630c 01a06000 (e5d6300d)
> 
> Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device
> deletion which is sent when DD has finished processing of device
> deletion.
> 
> Cc: Tony Lindgren 
> Cc: Tero Kristo 
> Signed-off-by: Grygorii Strashko 
> ---
>  arch/arm/mach-omap2/omap_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_device.c 
> b/arch/arm/mach-omap2/omap_device.c
> index f7ff3b9..208f115 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -194,7 +194,7 @@ static int _omap_device_notifier_call(struct 
> notifier_block *nb,
>   int err;
>  
>   switch (event) {
> - case BUS_NOTIFY_DEL_DEVICE:
> + case BUS_NOTIFY_REMOVED_DEVICE:
>   if (pdev->archdata.od)
>   omap_device_delete(pdev->archdata.od);
>   break;
> 


-- 
Péter

Re: [PATCH v2 4/4] ARM: OMAP2+: omap_device: fix crash on omap_device removal

[Peter Ujfalusi]

On 07/28/16 20:50, Grygorii Strashko wrote:
> Below call chain causes system crash when OMAP device is
> removed by calling of_platform_depopulate()/device_del():

Should you swap 3 <-> 4 in the series?
Currently patch 3 will introduce the crash you are fixing in patch 4...

> 
> device_del()
> - blocking_notifier_call_chain(>bus->p->bus_notifier,
>BUS_NOTIFY_DEL_DEVICE, dev);
>   - _omap_device_notifier_call()
> - omap_device_delete()
>   - od->pdev->archdata.od = NULL;
>   kfree(od->hwmods);
>   kfree(od);
>   - bus_remove_device()
> - device_release_driver()
>   - __device_release_driver()
>   - pm_runtime_get_sync()
>  - _od_runtime_resume()
>- omap_hwmod_enable() <- OOPS od's delted already
> 
> Backtrace:
> Unable to handle kernel NULL pointer dereference at virtual address 000d
> pgd = eb10
> [000d] *pgd=ad6e1831, *pte=, *ppte=
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty 
> #68
> Hardware name: Generic DRA74X (Flattened Device Tree)
> task: eb1ee800 ti: ec962000 task.ti: ec962000
> PC is at omap_device_enable+0x10/0x90
> LR is at _od_runtime_resume+0x10/0x24
> [...]
> [] (omap_device_enable) from [] 
> (_od_runtime_resume+0x10/0x24)
> [] (_od_runtime_resume) from [] (__rpm_callback+0x20/0x34)
> [] (__rpm_callback) from [] (rpm_callback+0x20/0x80)
> [] (rpm_callback) from [] (rpm_resume+0x48c/0x964)
> [] (rpm_resume) from [] (__pm_runtime_resume+0x60/0x88)
> [] (__pm_runtime_resume) from [] 
> (__device_release_driver+0x30/0x100)
> [] (__device_release_driver) from [] 
> (device_release_driver+0x1c/0x28)
> [] (device_release_driver) from [] 
> (bus_remove_device+0xec/0x144)
> [] (bus_remove_device) from [] (device_del+0x10c/0x210)
> [] (device_del) from [] (platform_device_del+0x18/0x84)
> [] (platform_device_del) from [] 
> (platform_device_unregister+0xc/0x20)
> [] (platform_device_unregister) from [] 
> (of_platform_device_destroy+0x8c/0x90)
> [] (of_platform_device_destroy) from [] 
> (device_for_each_child+0x4c/0x78)
> [] (device_for_each_child) from [] 
> (of_platform_depopulate+0x30/0x44)
> [] (of_platform_depopulate) from [] 
> (cpsw_remove+0x68/0xf4 [ti_cpsw])
> [] (cpsw_remove [ti_cpsw]) from [] 
> (platform_drv_remove+0x24/0x3c)
> [] (platform_drv_remove) from [] 
> (__device_release_driver+0x84/0x100)
> [] (__device_release_driver) from [] 
> (driver_detach+0xac/0xb0)
> [] (driver_detach) from [] (bus_remove_driver+0x60/0xd4)
> [] (bus_remove_driver) from [] 
> (SyS_delete_module+0x184/0x20c)
> [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x1c)
> Code: e350 e92d4070 1590630c 01a06000 (e5d6300d)
> 
> Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device
> deletion which is sent when DD has finished processing of device
> deletion.
> 
> Cc: Tony Lindgren 
> Cc: Tero Kristo 
> Signed-off-by: Grygorii Strashko 
> ---
>  arch/arm/mach-omap2/omap_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_device.c 
> b/arch/arm/mach-omap2/omap_device.c
> index f7ff3b9..208f115 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -194,7 +194,7 @@ static int _omap_device_notifier_call(struct 
> notifier_block *nb,
>   int err;
>  
>   switch (event) {
> - case BUS_NOTIFY_DEL_DEVICE:
> + case BUS_NOTIFY_REMOVED_DEVICE:
>   if (pdev->archdata.od)
>   omap_device_delete(pdev->archdata.od);
>   break;
> 


-- 
Péter

linux-next: Tree for Jul 29

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160728:

The vfs tree gained a build failure due to an interaction with Linus'
tree.  I applied a merge fix patch.

The drm tree gained a conflict against Linus' tree.

The kbuild tree lost its build failure.

The akpm-current tree gained a conflict against the tip tree.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 5788
 5096 files changed, 220273 insertions(+), 89980 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (884316deb4c9 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging fixes/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (344e3c7734d5 sparc: serial: sunhv: fix a double lock bug)
Merging net/master (6a492b0f23d2 Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging ipsec/master (7677c7560c3e xfrm: get rid of another incorrect WARN)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (0984d159c8ad sound: oss: Use 
kernel_read_file_from_path() for mod_firmware_load())
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (64ec6ccb76e6 crypto: marvell - Update cache with 
input sg only when it is unmapped)
Merging ide/master (d4f8c2e0f827 ide: mis

linux-next: Tree for Jul 29

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160728:

The vfs tree gained a build failure due to an interaction with Linus'
tree.  I applied a merge fix patch.

The drm tree gained a conflict against Linus' tree.

The kbuild tree lost its build failure.

The akpm-current tree gained a conflict against the tip tree.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 5788
 5096 files changed, 220273 insertions(+), 89980 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (884316deb4c9 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging fixes/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (344e3c7734d5 sparc: serial: sunhv: fix a double lock bug)
Merging net/master (6a492b0f23d2 Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging ipsec/master (7677c7560c3e xfrm: get rid of another incorrect WARN)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (0984d159c8ad sound: oss: Use 
kernel_read_file_from_path() for mod_firmware_load())
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (64ec6ccb76e6 crypto: marvell - Update cache with 
input sg only when it is unmapped)
Merging ide/master (d4f8c2e0f827 ide: mis

RE: [PATCH] ACPICA: cleanup method properly on error

[Zheng, Lv]

Hi, Vegard

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Vegard Nossum
> Subject: [PATCH] ACPICA: cleanup method properly on error
> 
> If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> walk state push done by acpi_ds_create_walk_state(). Otherwise, the new
> walk state (which has just been freed) will remain on the thread's
> walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
> to get the new state.
[Lv Zheng] 
I haven't looked into the detail.
Let me first ask simple questions and present simple concerns in order to move 
this discussion on.

> 
> You can observe this when reading e.g.
> 
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
[Lv Zheng] 
Do you mean you have real issues related to this?
If so, could provide the .config and dmesg for us?

> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vegard Nossum 
> ---
>  drivers/acpi/acpica/dsmethod.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c
> index 47c7b52..44b50a6 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -596,6 +596,8 @@ cleanup:
>   /* On error, we must terminate the method properly */
> 
>   acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> + if (thread)
> + acpi_ds_pop_walk_state(thread);
>   acpi_ds_delete_walk_state(next_walk_state);
[Lv Zheng] 
It seems, if acpi_ds_create_walk_state() fails, acpi_ds_delete_walk_state() 
will be invoked.
So they are paired. Fixing this in acpi_ds_delete_walk_state() could help to 
fix all of them.
Given the fix is useful, why don't you do this in acpi_ds_delete_walk_state()?

Thanks and best regards
-Lv

RE: [PATCH] ACPICA: cleanup method properly on error

[Zheng, Lv]

Hi, Vegard

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Vegard Nossum
> Subject: [PATCH] ACPICA: cleanup method properly on error
> 
> If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> walk state push done by acpi_ds_create_walk_state(). Otherwise, the new
> walk state (which has just been freed) will remain on the thread's
> walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
> to get the new state.
[Lv Zheng] 
I haven't looked into the detail.
Let me first ask simple questions and present simple concerns in order to move 
this discussion on.

> 
> You can observe this when reading e.g.
> 
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
[Lv Zheng] 
Do you mean you have real issues related to this?
If so, could provide the .config and dmesg for us?

> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vegard Nossum 
> ---
>  drivers/acpi/acpica/dsmethod.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c
> index 47c7b52..44b50a6 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -596,6 +596,8 @@ cleanup:
>   /* On error, we must terminate the method properly */
> 
>   acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> + if (thread)
> + acpi_ds_pop_walk_state(thread);
>   acpi_ds_delete_walk_state(next_walk_state);
[Lv Zheng] 
It seems, if acpi_ds_create_walk_state() fails, acpi_ds_delete_walk_state() 
will be invoked.
So they are paired. Fixing this in acpi_ds_delete_walk_state() could help to 
fix all of them.
Given the fix is useful, why don't you do this in acpi_ds_delete_walk_state()?

Thanks and best regards
-Lv

Re: [PATCH] sparc64 mm: Fix base TSB sizing when hugetlb pages are used

[David Miller]

From: Mike Kravetz 
Date: Fri, 15 Jul 2016 13:08:42 -0700

> do_sparc64_fault() calculates both the base and huge page RSS sizes and
> uses this information in calls to tsb_grow().  The calculation for base
> page TSB size is not correct if the task uses hugetlb pages.  hugetlb
> pages are not accounted for in RSS, therefore the call to get_mm_rss(mm)
> does not include hugetlb pages.  However, the number of pages based on
> huge_pte_count (which does include hugetlb pages) is subtracted from
> this value.  This will result in an artificially small and often negative
> RSS calculation.  The base TSB size is then often set to max_tsb_size
> as the passed RSS is unsigned, so a negative value looks really big.
> 
> THP pages are also accounted for in huge_pte_count, and THP pages are
> accounted for in RSS so the calculation in do_sparc64_fault() is correct
> if a task only uses THP pages.
> 
> A single huge_pte_count is not sufficient for TSB sizing if both hugetlb
> and THP pages can be used.  Instead of a single counter, use two:  one
> for hugetlb and one for THP.
> 
> Signed-off-by: Mike Kravetz 

Great catch, applied and queued up for -stable.

Thanks.

Re: [PATCH] sparc64 mm: Fix base TSB sizing when hugetlb pages are used

[David Miller]

From: Mike Kravetz 
Date: Fri, 15 Jul 2016 13:08:42 -0700

> do_sparc64_fault() calculates both the base and huge page RSS sizes and
> uses this information in calls to tsb_grow().  The calculation for base
> page TSB size is not correct if the task uses hugetlb pages.  hugetlb
> pages are not accounted for in RSS, therefore the call to get_mm_rss(mm)
> does not include hugetlb pages.  However, the number of pages based on
> huge_pte_count (which does include hugetlb pages) is subtracted from
> this value.  This will result in an artificially small and often negative
> RSS calculation.  The base TSB size is then often set to max_tsb_size
> as the passed RSS is unsigned, so a negative value looks really big.
> 
> THP pages are also accounted for in huge_pte_count, and THP pages are
> accounted for in RSS so the calculation in do_sparc64_fault() is correct
> if a task only uses THP pages.
> 
> A single huge_pte_count is not sufficient for TSB sizing if both hugetlb
> and THP pages can be used.  Instead of a single counter, use two:  one
> for hugetlb and one for THP.
> 
> Signed-off-by: Mike Kravetz 

Great catch, applied and queued up for -stable.

Thanks.

[PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code

[Calvin Owens]

With the exception of a single call to wait_for_doorbell_int(), all
this conditional sleeping code is dead. So delete it.

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 241 +--
 drivers/scsi/mpt3sas/mpt3sas_base.h  |   6 +-
 drivers/scsi/mpt3sas/mpt3sas_config.c|   3 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  15 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |  21 +--
 drivers/scsi/mpt3sas/mpt3sas_transport.c |  12 +-
 6 files changed, 120 insertions(+), 178 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 751f13e..0956183 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -98,7 +98,7 @@ MODULE_PARM_DESC(mpt3sas_fwfault_debug,
" enable detection of firmware fault and halt firmware - (default=0)");
 
 static int
-_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc);
 
 /**
  * _scsih_set_fwfault_debug - global setting of ioc->fwfault_debug.
@@ -218,8 +218,7 @@ _base_fault_reset_work(struct work_struct *work)
ioc->non_operational_loop = 0;
 
if ((doorbell & MPI2_IOC_STATE_MASK) != MPI2_IOC_STATE_OPERATIONAL) {
-   rc = mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
-   FORCE_BIG_HAMMER);
+   rc = mpt3sas_base_hard_reset_handler(ioc, FORCE_BIG_HAMMER);
pr_warn(MPT3SAS_FMT "%s: hard reset: %s\n", ioc->name,
__func__, (rc == 0) ? "success" : "failed");
doorbell = mpt3sas_base_get_iocstate(ioc, 0);
@@ -2145,7 +2144,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
 
_base_mask_interrupts(ioc);
 
-   r = _base_get_ioc_facts(ioc, CAN_SLEEP);
+   r = _base_get_ioc_facts(ioc);
if (r)
goto out_fail;
 
@@ -3172,12 +3171,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 /**
  * _base_allocate_memory_pools - allocate start of day memory pools
  * @ioc: per adapter object
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 success, anything else error
  */
 static int
-_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,  int sleep_flag)
+_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 {
struct mpt3sas_facts *facts;
u16 max_sge_elements;
@@ -3647,29 +3645,25 @@ mpt3sas_base_get_iocstate(struct MPT3SAS_ADAPTER *ioc, 
int cooked)
  * _base_wait_on_iocstate - waiting on a particular ioc state
  * @ioc_state: controller state { READY, OPERATIONAL, or RESET }
  * @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 for success, non-zero for failure.
  */
 static int
-_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int timeout,
-   int sleep_flag)
+_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int timeout)
 {
u32 count, cntdn;
u32 current_state;
 
count = 0;
-   cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+   cntdn = 1000 * timeout;
do {
current_state = mpt3sas_base_get_iocstate(ioc, 1);
if (current_state == ioc_state)
return 0;
if (count && current_state == MPI2_IOC_STATE_FAULT)
break;
-   if (sleep_flag == CAN_SLEEP)
-   usleep_range(1000, 1500);
-   else
-   udelay(500);
+
+   usleep_range(1000, 1500);
count++;
} while (--cntdn);
 
@@ -3681,24 +3675,22 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 
ioc_state, int timeout,
  * a write to the doorbell)
  * @ioc: per adapter object
  * @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 for success, non-zero for failure.
  *
  * Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to doorbell.
  */
 static int
-_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc);
 
 static int
-_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
-   int sleep_flag)
+_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout)
 {
u32 cntdn, count;
u32 int_status;
 
count = 0;
-   cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+   cntdn = 1000 * timeout;
do {
int_status = readl(>chip->HostInterruptStatus);
if (int_status & MPI2_HIS_IOC2SYS_DB_STATUS) {
@@ -3707,10 +3699,35 @@ _base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER 
*ioc, int timeout,
ioc->name, __func__, count, timeout));
return 0;
}
-   if (sleep_flag == CAN_SLEEP)
-   usleep_range(1000, 1500);
-   

[PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code

[Calvin Owens]

With the exception of a single call to wait_for_doorbell_int(), all
this conditional sleeping code is dead. So delete it.

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 241 +--
 drivers/scsi/mpt3sas/mpt3sas_base.h  |   6 +-
 drivers/scsi/mpt3sas/mpt3sas_config.c|   3 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  15 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |  21 +--
 drivers/scsi/mpt3sas/mpt3sas_transport.c |  12 +-
 6 files changed, 120 insertions(+), 178 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 751f13e..0956183 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -98,7 +98,7 @@ MODULE_PARM_DESC(mpt3sas_fwfault_debug,
" enable detection of firmware fault and halt firmware - (default=0)");
 
 static int
-_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc);
 
 /**
  * _scsih_set_fwfault_debug - global setting of ioc->fwfault_debug.
@@ -218,8 +218,7 @@ _base_fault_reset_work(struct work_struct *work)
ioc->non_operational_loop = 0;
 
if ((doorbell & MPI2_IOC_STATE_MASK) != MPI2_IOC_STATE_OPERATIONAL) {
-   rc = mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
-   FORCE_BIG_HAMMER);
+   rc = mpt3sas_base_hard_reset_handler(ioc, FORCE_BIG_HAMMER);
pr_warn(MPT3SAS_FMT "%s: hard reset: %s\n", ioc->name,
__func__, (rc == 0) ? "success" : "failed");
doorbell = mpt3sas_base_get_iocstate(ioc, 0);
@@ -2145,7 +2144,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
 
_base_mask_interrupts(ioc);
 
-   r = _base_get_ioc_facts(ioc, CAN_SLEEP);
+   r = _base_get_ioc_facts(ioc);
if (r)
goto out_fail;
 
@@ -3172,12 +3171,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 /**
  * _base_allocate_memory_pools - allocate start of day memory pools
  * @ioc: per adapter object
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 success, anything else error
  */
 static int
-_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,  int sleep_flag)
+_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 {
struct mpt3sas_facts *facts;
u16 max_sge_elements;
@@ -3647,29 +3645,25 @@ mpt3sas_base_get_iocstate(struct MPT3SAS_ADAPTER *ioc, 
int cooked)
  * _base_wait_on_iocstate - waiting on a particular ioc state
  * @ioc_state: controller state { READY, OPERATIONAL, or RESET }
  * @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 for success, non-zero for failure.
  */
 static int
-_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int timeout,
-   int sleep_flag)
+_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int timeout)
 {
u32 count, cntdn;
u32 current_state;
 
count = 0;
-   cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+   cntdn = 1000 * timeout;
do {
current_state = mpt3sas_base_get_iocstate(ioc, 1);
if (current_state == ioc_state)
return 0;
if (count && current_state == MPI2_IOC_STATE_FAULT)
break;
-   if (sleep_flag == CAN_SLEEP)
-   usleep_range(1000, 1500);
-   else
-   udelay(500);
+
+   usleep_range(1000, 1500);
count++;
} while (--cntdn);
 
@@ -3681,24 +3675,22 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 
ioc_state, int timeout,
  * a write to the doorbell)
  * @ioc: per adapter object
  * @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
  *
  * Returns 0 for success, non-zero for failure.
  *
  * Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to doorbell.
  */
 static int
-_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc);
 
 static int
-_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
-   int sleep_flag)
+_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout)
 {
u32 cntdn, count;
u32 int_status;
 
count = 0;
-   cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+   cntdn = 1000 * timeout;
do {
int_status = readl(>chip->HostInterruptStatus);
if (int_status & MPI2_HIS_IOC2SYS_DB_STATUS) {
@@ -3707,10 +3699,35 @@ _base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER 
*ioc, int timeout,
ioc->name, __func__, count, timeout));
return 0;
}
-   if (sleep_flag == CAN_SLEEP)
-   usleep_range(1000, 1500);
-   else
-   

[PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()

[Calvin Owens]

This flag that conditionally acquires the mutex is confusing and prone
to bugginess: refactor it into two separate function calls, and make
the unlocked one complain if it's called outside the mutex.

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 16 +++--
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  5 ++-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 66 +---
 3 files changed, 38 insertions(+), 49 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index eb7f5b0..f0baafd 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -794,16 +794,6 @@ struct reply_post_struct {
dma_addr_t  reply_post_free_dma;
 };
 
-/**
- * enum mutex_type - task management mutex type
- * @TM_MUTEX_OFF: mutex is not required becuase calling function is acquiring 
it
- * @TM_MUTEX_ON: mutex is required
- */
-enum mutex_type {
-   TM_MUTEX_OFF = 0,
-   TM_MUTEX_ON = 1,
-};
-
 typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct MPT3SAS_ADAPTER *ioc);
 /**
  * struct MPT3SAS_ADAPTER - per adapter struct
@@ -1291,7 +1281,11 @@ void mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER 
*ioc, int reset_phase);
 
 int mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
uint channel, uint id, uint lun, u8 type, u16 smid_task,
-   ulong timeout, enum mutex_type m_type);
+   ulong timeout);
+int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
+   uint channel, uint id, uint lun, u8 type, u16 smid_task,
+   ulong timeout);
+
 void mpt3sas_scsih_set_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
 void mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
 void mpt3sas_expander_remove(struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 7d00f09..75ae533 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1001,10 +1001,9 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct 
mpt3_ioctl_command karg,
ioc->name,
le16_to_cpu(mpi_request->FunctionDependent1));
mpt3sas_halt_firmware(ioc);
-   mpt3sas_scsih_issue_tm(ioc,
+   mpt3sas_scsih_issue_locked_tm(ioc,
le16_to_cpu(mpi_request->FunctionDependent1), 0, 0,
-   0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0, 30,
-   TM_MUTEX_ON);
+   0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0, 30);
} else
mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index acabe48..c93a7ba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2201,7 +2201,6 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, 
u16 handle)
  * @type: MPI2_SCSITASKMGMT_TASKTYPE__XXX (defined in mpi2_init.h)
  * @smid_task: smid assigned to the task
  * @timeout: timeout in seconds
- * @m_type: TM_MUTEX_ON or TM_MUTEX_OFF
  * Context: user
  *
  * A generic API for sending task management requests to firmware.
@@ -2212,8 +2211,7 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, 
u16 handle)
  */
 int
 mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint channel,
-   uint id, uint lun, u8 type, u16 smid_task, ulong timeout,
-   enum mutex_type m_type)
+   uint id, uint lun, u8 type, u16 smid_task, ulong timeout)
 {
Mpi2SCSITaskManagementRequest_t *mpi_request;
Mpi2SCSITaskManagementReply_t *mpi_reply;
@@ -2224,21 +,19 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 
handle, uint channel,
int rc;
u16 msix_task = 0;
 
-   if (m_type == TM_MUTEX_ON)
-   mutex_lock(>tm_cmds.mutex);
+   lockdep_assert_held(>tm_cmds.mutex);
+
if (ioc->tm_cmds.status != MPT3_CMD_NOT_USED) {
pr_info(MPT3SAS_FMT "%s: tm_cmd busy!!!\n",
__func__, ioc->name);
-   rc = FAILED;
-   goto err_out;
+   return FAILED;
}
 
if (ioc->shost_recovery || ioc->remove_host ||
ioc->pci_error_recovery) {
pr_info(MPT3SAS_FMT "%s: host reset in progress!\n",
__func__, ioc->name);
-   rc = FAILED;
-   goto err_out;
+   return FAILED;
}
 
ioc_state = mpt3sas_base_get_iocstate(ioc, 0);
@@ -2247,8 +2243,7 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 
handle, uint channel,
"unexpected doorbell active!\n", ioc->name));
  

[PATCH 3/3] mpt3sas: Fix warnings exposed by W=1

[Calvin Owens]

Trivial non-functional changes for a couple annoying things:

  1) Functions local to files are not declared static, which is
  frustrating when reading the code because it's non-obvious at first
  glance what's actually called from other files.

  2) Set-but-unused variables abound, presumably to mask -Wunused-result
  errors in the past. None of these are flagged today though (with one
  exception noted below), so remove them.

Fixing (2) exposed the fact that we improperly ignore the return value of
scsi_device_reprobe() in _scsih_reprobe_lun(). Fixing the calling code to
deal with the potential error is non-trivial, so for now just WARN().

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 18 +++-
 drivers/scsi/mpt3sas/mpt3sas_config.c|  4 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 29 ++---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 70 +++-
 drivers/scsi/mpt3sas/mpt3sas_transport.c | 16 ++--
 5 files changed, 56 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0956183..df95d1a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2039,7 +2039,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
  * mpt3sas_base_unmap_resources - free controller resources
  * @ioc: per adapter object
  */
-void
+static void
 mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
 {
struct pci_dev *pdev = ioc->pdev;
@@ -3884,7 +3884,6 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER 
*ioc, int request_bytes,
MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
int i;
u8 failed;
-   u16 dummy;
__le32 *mfp;
 
/* make sure doorbell is not in use */
@@ -3964,7 +3963,7 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER 
*ioc, int request_bytes,
return -EFAULT;
}
if (i >=  reply_bytes/2) /* overflow case */
-   dummy = readl(>chip->Doorbell);
+   readl(>chip->Doorbell);
else
reply[i] = le16_to_cpu(readl(>chip->Doorbell)
& MPI2_DOORBELL_DATA_MASK);
@@ -4009,7 +4008,6 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER 
*ioc,
 {
u16 smid;
u32 ioc_state;
-   unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4062,7 +4060,7 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER 
*ioc,
ioc->ioc_link_reset_in_progress = 1;
init_completion(>base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>base_cmds.done,
+   wait_for_completion_timeout(>base_cmds.done,
msecs_to_jiffies(1));
if ((mpi_request->Operation == MPI2_SAS_OP_PHY_HARD_RESET ||
mpi_request->Operation == MPI2_SAS_OP_PHY_LINK_RESET) &&
@@ -4112,7 +4110,6 @@ mpt3sas_base_scsi_enclosure_processor(struct 
MPT3SAS_ADAPTER *ioc,
 {
u16 smid;
u32 ioc_state;
-   unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4163,7 +4160,7 @@ mpt3sas_base_scsi_enclosure_processor(struct 
MPT3SAS_ADAPTER *ioc,
memcpy(request, mpi_request, sizeof(Mpi2SepReply_t));
init_completion(>base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>base_cmds.done,
+   wait_for_completion_timeout(>base_cmds.done,
msecs_to_jiffies(1));
if (!(ioc->base_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
@@ -4548,7 +4545,6 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
 {
Mpi2PortEnableRequest_t *mpi_request;
Mpi2PortEnableReply_t *mpi_reply;
-   unsigned long timeleft;
int r = 0;
u16 smid;
u16 ioc_status;
@@ -4576,8 +4572,7 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
 
init_completion(>port_enable_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>port_enable_cmds.done,
-   300*HZ);
+   wait_for_completion_timeout(>port_enable_cmds.done, 300*HZ);
if (!(ioc->port_enable_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
ioc->name, __func__);
@@ -4728,7 +4723,6 @@ static int
 _base_event_notification(struct MPT3SAS_ADAPTER *ioc)
 {
Mpi2EventNotificationRequest_t *mpi_request;
-   unsigned long timeleft;
u16 smid;
int r = 0;
int i;
@@ -4760,7 +4754,7 @@ _base_event_notification(struct MPT3SAS_ADAPTER *ioc)
cpu_to_le32(ioc->event_masks[i]);
init_completion(>base_cmds.done);

[PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()

[Calvin Owens]

This flag that conditionally acquires the mutex is confusing and prone
to bugginess: refactor it into two separate function calls, and make
the unlocked one complain if it's called outside the mutex.

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 16 +++--
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  5 ++-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 66 +---
 3 files changed, 38 insertions(+), 49 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index eb7f5b0..f0baafd 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -794,16 +794,6 @@ struct reply_post_struct {
dma_addr_t  reply_post_free_dma;
 };
 
-/**
- * enum mutex_type - task management mutex type
- * @TM_MUTEX_OFF: mutex is not required becuase calling function is acquiring 
it
- * @TM_MUTEX_ON: mutex is required
- */
-enum mutex_type {
-   TM_MUTEX_OFF = 0,
-   TM_MUTEX_ON = 1,
-};
-
 typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct MPT3SAS_ADAPTER *ioc);
 /**
  * struct MPT3SAS_ADAPTER - per adapter struct
@@ -1291,7 +1281,11 @@ void mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER 
*ioc, int reset_phase);
 
 int mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
uint channel, uint id, uint lun, u8 type, u16 smid_task,
-   ulong timeout, enum mutex_type m_type);
+   ulong timeout);
+int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
+   uint channel, uint id, uint lun, u8 type, u16 smid_task,
+   ulong timeout);
+
 void mpt3sas_scsih_set_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
 void mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
 void mpt3sas_expander_remove(struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 7d00f09..75ae533 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1001,10 +1001,9 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct 
mpt3_ioctl_command karg,
ioc->name,
le16_to_cpu(mpi_request->FunctionDependent1));
mpt3sas_halt_firmware(ioc);
-   mpt3sas_scsih_issue_tm(ioc,
+   mpt3sas_scsih_issue_locked_tm(ioc,
le16_to_cpu(mpi_request->FunctionDependent1), 0, 0,
-   0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0, 30,
-   TM_MUTEX_ON);
+   0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0, 30);
} else
mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index acabe48..c93a7ba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2201,7 +2201,6 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, 
u16 handle)
  * @type: MPI2_SCSITASKMGMT_TASKTYPE__XXX (defined in mpi2_init.h)
  * @smid_task: smid assigned to the task
  * @timeout: timeout in seconds
- * @m_type: TM_MUTEX_ON or TM_MUTEX_OFF
  * Context: user
  *
  * A generic API for sending task management requests to firmware.
@@ -2212,8 +2211,7 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, 
u16 handle)
  */
 int
 mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint channel,
-   uint id, uint lun, u8 type, u16 smid_task, ulong timeout,
-   enum mutex_type m_type)
+   uint id, uint lun, u8 type, u16 smid_task, ulong timeout)
 {
Mpi2SCSITaskManagementRequest_t *mpi_request;
Mpi2SCSITaskManagementReply_t *mpi_reply;
@@ -2224,21 +,19 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 
handle, uint channel,
int rc;
u16 msix_task = 0;
 
-   if (m_type == TM_MUTEX_ON)
-   mutex_lock(>tm_cmds.mutex);
+   lockdep_assert_held(>tm_cmds.mutex);
+
if (ioc->tm_cmds.status != MPT3_CMD_NOT_USED) {
pr_info(MPT3SAS_FMT "%s: tm_cmd busy!!!\n",
__func__, ioc->name);
-   rc = FAILED;
-   goto err_out;
+   return FAILED;
}
 
if (ioc->shost_recovery || ioc->remove_host ||
ioc->pci_error_recovery) {
pr_info(MPT3SAS_FMT "%s: host reset in progress!\n",
__func__, ioc->name);
-   rc = FAILED;
-   goto err_out;
+   return FAILED;
}
 
ioc_state = mpt3sas_base_get_iocstate(ioc, 0);
@@ -2247,8 +2243,7 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 
handle, uint channel,
"unexpected doorbell active!\n", ioc->name));
rc = 

[PATCH 3/3] mpt3sas: Fix warnings exposed by W=1

[Calvin Owens]

Trivial non-functional changes for a couple annoying things:

  1) Functions local to files are not declared static, which is
  frustrating when reading the code because it's non-obvious at first
  glance what's actually called from other files.

  2) Set-but-unused variables abound, presumably to mask -Wunused-result
  errors in the past. None of these are flagged today though (with one
  exception noted below), so remove them.

Fixing (2) exposed the fact that we improperly ignore the return value of
scsi_device_reprobe() in _scsih_reprobe_lun(). Fixing the calling code to
deal with the potential error is non-trivial, so for now just WARN().

Signed-off-by: Calvin Owens 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 18 +++-
 drivers/scsi/mpt3sas/mpt3sas_config.c|  4 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 29 ++---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 70 +++-
 drivers/scsi/mpt3sas/mpt3sas_transport.c | 16 ++--
 5 files changed, 56 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0956183..df95d1a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2039,7 +2039,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
  * mpt3sas_base_unmap_resources - free controller resources
  * @ioc: per adapter object
  */
-void
+static void
 mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
 {
struct pci_dev *pdev = ioc->pdev;
@@ -3884,7 +3884,6 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER 
*ioc, int request_bytes,
MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
int i;
u8 failed;
-   u16 dummy;
__le32 *mfp;
 
/* make sure doorbell is not in use */
@@ -3964,7 +3963,7 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER 
*ioc, int request_bytes,
return -EFAULT;
}
if (i >=  reply_bytes/2) /* overflow case */
-   dummy = readl(>chip->Doorbell);
+   readl(>chip->Doorbell);
else
reply[i] = le16_to_cpu(readl(>chip->Doorbell)
& MPI2_DOORBELL_DATA_MASK);
@@ -4009,7 +4008,6 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER 
*ioc,
 {
u16 smid;
u32 ioc_state;
-   unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4062,7 +4060,7 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER 
*ioc,
ioc->ioc_link_reset_in_progress = 1;
init_completion(>base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>base_cmds.done,
+   wait_for_completion_timeout(>base_cmds.done,
msecs_to_jiffies(1));
if ((mpi_request->Operation == MPI2_SAS_OP_PHY_HARD_RESET ||
mpi_request->Operation == MPI2_SAS_OP_PHY_LINK_RESET) &&
@@ -4112,7 +4110,6 @@ mpt3sas_base_scsi_enclosure_processor(struct 
MPT3SAS_ADAPTER *ioc,
 {
u16 smid;
u32 ioc_state;
-   unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4163,7 +4160,7 @@ mpt3sas_base_scsi_enclosure_processor(struct 
MPT3SAS_ADAPTER *ioc,
memcpy(request, mpi_request, sizeof(Mpi2SepReply_t));
init_completion(>base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>base_cmds.done,
+   wait_for_completion_timeout(>base_cmds.done,
msecs_to_jiffies(1));
if (!(ioc->base_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
@@ -4548,7 +4545,6 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
 {
Mpi2PortEnableRequest_t *mpi_request;
Mpi2PortEnableReply_t *mpi_reply;
-   unsigned long timeleft;
int r = 0;
u16 smid;
u16 ioc_status;
@@ -4576,8 +4572,7 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
 
init_completion(>port_enable_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
-   timeleft = wait_for_completion_timeout(>port_enable_cmds.done,
-   300*HZ);
+   wait_for_completion_timeout(>port_enable_cmds.done, 300*HZ);
if (!(ioc->port_enable_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
ioc->name, __func__);
@@ -4728,7 +4723,6 @@ static int
 _base_event_notification(struct MPT3SAS_ADAPTER *ioc)
 {
Mpi2EventNotificationRequest_t *mpi_request;
-   unsigned long timeleft;
u16 smid;
int r = 0;
int i;
@@ -4760,7 +4754,7 @@ _base_event_notification(struct MPT3SAS_ADAPTER *ioc)
cpu_to_le32(ioc->event_masks[i]);
init_completion(>base_cmds.done);

RE: [PATCH] ACPI / button: remove pointer to old lid_sysfs on unbind

[Zheng, Lv]

Hi, Benjamin

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Benjamin Tissoires
> Subject: [PATCH] ACPI / button: remove pointer to old lid_sysfs on unbind
> 
> When we removed the procfs dir on error or if the driver is
> unbound, the two variables acpi_lid_dir and acpi_button_dir
> were not reset. On the next rebind, those static variables
> were not null and we couldn't re-register the device again.
> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/acpi/button.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 5c3b091..e413599 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -188,9 +188,11 @@ done:
[Lv Zheng] 
I have a concern here for acpi_button_add_fs().
It looks like that this function doesn't support 2 lid devices.
So why do we need /proc/acpi/button/lid/LID0 folder?

>  remove_dev_dir:
>   remove_proc_entry(acpi_device_bid(device),
> acpi_lid_dir);
> + acpi_lid_dir = NULL;
>   acpi_device_dir(device) = NULL;
>  remove_lid_dir:
>   remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID,
> acpi_button_dir);
[Lv Zheng] 
Should acpi_lid_dir = NULL be put here?

> + acpi_button_dir = NULL;
>  remove_button_dir:
>   remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
[Lv Zheng] 
Should acpi_button_dir = NULL be put here?

>   goto done;
> @@ -207,8 +209,10 @@ static int acpi_button_remove_fs(struct
> acpi_device *device)
> acpi_device_dir(device));
>   remove_proc_entry(acpi_device_bid(device),
> acpi_lid_dir);
> + acpi_lid_dir = NULL;
>   acpi_device_dir(device) = NULL;
>   remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID,
> acpi_button_dir);
[Lv Zheng] 
Should acpi_lid_dir = NULL be put here?

> + acpi_button_dir = NULL;
>   remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
[Lv Zheng] 
Should acpi_button_dir = NULL be put here?

Thanks and best regards
Lv

> 
>   return 0;
> --
> 2.5.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ACPI / button: remove pointer to old lid_sysfs on unbind

[Zheng, Lv]

Hi, Benjamin

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Benjamin Tissoires
> Subject: [PATCH] ACPI / button: remove pointer to old lid_sysfs on unbind
> 
> When we removed the procfs dir on error or if the driver is
> unbound, the two variables acpi_lid_dir and acpi_button_dir
> were not reset. On the next rebind, those static variables
> were not null and we couldn't re-register the device again.
> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/acpi/button.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 5c3b091..e413599 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -188,9 +188,11 @@ done:
[Lv Zheng] 
I have a concern here for acpi_button_add_fs().
It looks like that this function doesn't support 2 lid devices.
So why do we need /proc/acpi/button/lid/LID0 folder?

>  remove_dev_dir:
>   remove_proc_entry(acpi_device_bid(device),
> acpi_lid_dir);
> + acpi_lid_dir = NULL;
>   acpi_device_dir(device) = NULL;
>  remove_lid_dir:
>   remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID,
> acpi_button_dir);
[Lv Zheng] 
Should acpi_lid_dir = NULL be put here?

> + acpi_button_dir = NULL;
>  remove_button_dir:
>   remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
[Lv Zheng] 
Should acpi_button_dir = NULL be put here?

>   goto done;
> @@ -207,8 +209,10 @@ static int acpi_button_remove_fs(struct
> acpi_device *device)
> acpi_device_dir(device));
>   remove_proc_entry(acpi_device_bid(device),
> acpi_lid_dir);
> + acpi_lid_dir = NULL;
>   acpi_device_dir(device) = NULL;
>   remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID,
> acpi_button_dir);
[Lv Zheng] 
Should acpi_lid_dir = NULL be put here?

> + acpi_button_dir = NULL;
>   remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
[Lv Zheng] 
Should acpi_button_dir = NULL be put here?

Thanks and best regards
Lv

> 
>   return 0;
> --
> 2.5.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

[David Miller]

From: John Stultz 
Date: Thu, 28 Jul 2016 21:18:16 -0700

> After moving my HiKey tree to pre-v4.8-rc, I noticed when using
> Android that I was getting routing errors after toggling networking on
> and off (or entering suspend). Wifi associated, but I got some
> rounting errors in the logcat the connection manager wouldn't detect a
> valid network.
> 
> Not being able to figure out exactly what was going wrong from the
> userspace side, I bisected (manually rebasing a 70 patch stack each
> step :P) it down and it seems that the commit: 153380ec4b9b
> ("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule") is causing
> the problem.
> 
> Reverting that patch seems to make things work again.
> 
> I'm no networking guru, but I'm happy to help debug this further if
> folks can walk me through it a bit.

It simply sounds like Android's userspace is specifying NLM_F_EXCL when
it shouldn't be during FIB rule netlink operations.

[PATCH 5/5] mmc: sdhci-of-arasan: add power domain support

[Shawn Lin]

We should enable power domain once provided. Otherwise
we take risk of bus err as it's maybe in off state before
probing.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/sdhci-of-arasan.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index e0f193f..e507e94 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "sdhci-pltfm.h"
 
 #define SDHCI_ARASAN_CLK_CTRL_OFFSET   0x2c
@@ -515,6 +517,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_dis_ahb;
}
 
+   pm_runtime_enable(host->dev);
+   pm_runtime_get_sync(host->dev);
+
sdhci_get_of_property(pdev);
pltfm_host->clk = clk_xin;
 
@@ -577,6 +582,8 @@ clk_dis_ahb:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
 err_pltfm_free:
sdhci_pltfm_free(pdev);
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
return ret;
 }
 
@@ -599,6 +606,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
 
clk_disable_unprepare(clk_ahb);
 
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
+
return ret;
 }
 
-- 
2.3.7

[PATCH 1/5] Documentation: mmc: synopsys-dw-mshc: add power domain description

[Shawn Lin]

This patch adds power domain as a optional property for dw_mmc.
We should handle the power domain if available as it's in off
state dut to the policy of power-saving after booting up. Otherwise
dw_mmc can not be accessed.

Signed-off-by: Shawn Lin 

---

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 8636f5a..f48febd 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -81,6 +81,8 @@ Optional properties:
 * dma-names: request names for generic DMA client binding. Must be "rx-tx".
   Refer to dma.txt for details.
 
+* power-domains: Must contain a reference to the PM domain, if available.
+
 Aliases:
 
 - All the MSHC controller nodes should be represented in the aliases node using
-- 
2.3.7

Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

[David Miller]

From: John Stultz 
Date: Thu, 28 Jul 2016 21:18:16 -0700

> After moving my HiKey tree to pre-v4.8-rc, I noticed when using
> Android that I was getting routing errors after toggling networking on
> and off (or entering suspend). Wifi associated, but I got some
> rounting errors in the logcat the connection manager wouldn't detect a
> valid network.
> 
> Not being able to figure out exactly what was going wrong from the
> userspace side, I bisected (manually rebasing a 70 patch stack each
> step :P) it down and it seems that the commit: 153380ec4b9b
> ("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule") is causing
> the problem.
> 
> Reverting that patch seems to make things work again.
> 
> I'm no networking guru, but I'm happy to help debug this further if
> folks can walk me through it a bit.

It simply sounds like Android's userspace is specifying NLM_F_EXCL when
it shouldn't be during FIB rule netlink operations.

[PATCH 5/5] mmc: sdhci-of-arasan: add power domain support

[Shawn Lin]

We should enable power domain once provided. Otherwise
we take risk of bus err as it's maybe in off state before
probing.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/sdhci-of-arasan.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index e0f193f..e507e94 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "sdhci-pltfm.h"
 
 #define SDHCI_ARASAN_CLK_CTRL_OFFSET   0x2c
@@ -515,6 +517,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_dis_ahb;
}
 
+   pm_runtime_enable(host->dev);
+   pm_runtime_get_sync(host->dev);
+
sdhci_get_of_property(pdev);
pltfm_host->clk = clk_xin;
 
@@ -577,6 +582,8 @@ clk_dis_ahb:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
 err_pltfm_free:
sdhci_pltfm_free(pdev);
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
return ret;
 }
 
@@ -599,6 +606,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
 
clk_disable_unprepare(clk_ahb);
 
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
+
return ret;
 }
 
-- 
2.3.7

[PATCH 1/5] Documentation: mmc: synopsys-dw-mshc: add power domain description

[Shawn Lin]

This patch adds power domain as a optional property for dw_mmc.
We should handle the power domain if available as it's in off
state dut to the policy of power-saving after booting up. Otherwise
dw_mmc can not be accessed.

Signed-off-by: Shawn Lin 

---

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 8636f5a..f48febd 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -81,6 +81,8 @@ Optional properties:
 * dma-names: request names for generic DMA client binding. Must be "rx-tx".
   Refer to dma.txt for details.
 
+* power-domains: Must contain a reference to the PM domain, if available.
+
 Aliases:
 
 - All the MSHC controller nodes should be represented in the aliases node using
-- 
2.3.7

[PATCH 2/5] Documentation: mmc: sdhci-of-arasan: add power domain description

[Shawn Lin]

This patch adds power domain as a optional property for sdhci-of-arasan.
We should handle the power domain if available as it's in off
state due to the policy of power-saving after booting up. Otherwise
controller can not be accessed.

Signed-off-by: Shawn Lin 
---

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 3404afa..b5fb563 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -36,6 +36,7 @@ Optional Properties:
   - #clock-cells: If specified this should be the value <0>.  With this 
property
 in place we will export a clock representing the Card Clock.  This clock
 is expected to be consumed by our PHY.  You must also specify
+  - power-domains: Must contain a reference to the PM domain, if available.
 
 Example:
sdhci@e010 {
-- 
2.3.7

[PATCH 2/5] Documentation: mmc: sdhci-of-arasan: add power domain description

[Shawn Lin]

This patch adds power domain as a optional property for sdhci-of-arasan.
We should handle the power domain if available as it's in off
state due to the policy of power-saving after booting up. Otherwise
controller can not be accessed.

Signed-off-by: Shawn Lin 
---

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 3404afa..b5fb563 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -36,6 +36,7 @@ Optional Properties:
   - #clock-cells: If specified this should be the value <0>.  With this 
property
 in place we will export a clock representing the Card Clock.  This clock
 is expected to be consumed by our PHY.  You must also specify
+  - power-domains: Must contain a reference to the PM domain, if available.
 
 Example:
sdhci@e010 {
-- 
2.3.7

[PATCH 3/5] arm64: dts: rockchip: Provide power-domains for sd/sdio/emmc controllers

[Shawn Lin]

We add these two properties as we need to enable it manually in case
of been turned off by pd code if not referenced. We can't take risk of
it, so let's do it.

Signed-off-by: Shawn Lin 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4c84229..5744883 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -210,6 +210,7 @@
 < SCLK_SDIO_DRV>, < SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -223,6 +224,7 @@
 < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+   power-domains = < RK3399_PD_SD>;
status = "disabled";
};
 
@@ -239,6 +241,7 @@
#clock-cells = <0>;
phys = <_phy>;
phy-names = "phy_arasan";
+   power-domains = < RK3399_PD_EMMC>;
status = "disabled";
};
 
-- 
2.3.7

[PATCH 4/5] mmc: dw_mmc: add power domain support

[Shawn Lin]

We should enable power domain once provided. Otherwise
we take risk of bus err as it's maybe in off state before
probing.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/dw_mmc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 32380d5..8b39168 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -3024,6 +3026,9 @@ int dw_mci_probe(struct dw_mci *host)
host->bus_hz = clk_get_rate(host->ciu_clk);
}
 
+   pm_runtime_enable(host->dev);
+   pm_runtime_get_sync(host->dev);
+
if (!host->bus_hz) {
dev_err(host->dev,
"Platform data must supply bus speed\n");
@@ -3197,6 +3202,9 @@ err_clk_biu:
if (!IS_ERR(host->biu_clk))
clk_disable_unprepare(host->biu_clk);
 
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
+
return ret;
 }
 EXPORT_SYMBOL(dw_mci_probe);
@@ -3226,6 +3234,9 @@ void dw_mci_remove(struct dw_mci *host)
 
if (!IS_ERR(host->biu_clk))
clk_disable_unprepare(host->biu_clk);
+
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
 }
 EXPORT_SYMBOL(dw_mci_remove);
 
-- 
2.3.7

[PATCH 3/5] arm64: dts: rockchip: Provide power-domains for sd/sdio/emmc controllers

[Shawn Lin]

We add these two properties as we need to enable it manually in case
of been turned off by pd code if not referenced. We can't take risk of
it, so let's do it.

Signed-off-by: Shawn Lin 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4c84229..5744883 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -210,6 +210,7 @@
 < SCLK_SDIO_DRV>, < SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -223,6 +224,7 @@
 < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+   power-domains = < RK3399_PD_SD>;
status = "disabled";
};
 
@@ -239,6 +241,7 @@
#clock-cells = <0>;
phys = <_phy>;
phy-names = "phy_arasan";
+   power-domains = < RK3399_PD_EMMC>;
status = "disabled";
};
 
-- 
2.3.7

[PATCH 4/5] mmc: dw_mmc: add power domain support

[Shawn Lin]

We should enable power domain once provided. Otherwise
we take risk of bus err as it's maybe in off state before
probing.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/dw_mmc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 32380d5..8b39168 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -3024,6 +3026,9 @@ int dw_mci_probe(struct dw_mci *host)
host->bus_hz = clk_get_rate(host->ciu_clk);
}
 
+   pm_runtime_enable(host->dev);
+   pm_runtime_get_sync(host->dev);
+
if (!host->bus_hz) {
dev_err(host->dev,
"Platform data must supply bus speed\n");
@@ -3197,6 +3202,9 @@ err_clk_biu:
if (!IS_ERR(host->biu_clk))
clk_disable_unprepare(host->biu_clk);
 
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
+
return ret;
 }
 EXPORT_SYMBOL(dw_mci_probe);
@@ -3226,6 +3234,9 @@ void dw_mci_remove(struct dw_mci *host)
 
if (!IS_ERR(host->biu_clk))
clk_disable_unprepare(host->biu_clk);
+
+   pm_runtime_put(host->dev);
+   pm_runtime_disable(host->dev);
 }
 EXPORT_SYMBOL(dw_mci_remove);
 
-- 
2.3.7

[PATCH 0/5] Add power domain support for dw_mmc/sdhci-of-arasan

[Shawn Lin]

We need to enable the power domain manually while probing as the
power policy will turn off the pd which is not referenced. Otherwise
we may take risk of breaking kernel once Feng Xiao land the rockchip pd
relate stuff. So, let's do it in advance.

This pachset is based on the latest linux-next[1] which should contain
the next branch of linux-mmc and dt stuff. It's ideal to pack these all
into Ulf' tree with Heiko's ack for dts, Rob's ack for Doc and Jaehoon's
ack for dw_mmc. But it's okay to be merged seperately.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Thanks.



Shawn Lin (5):
  Documentation: mmc: synopsys-dw-mshc: add power domain description
  Documentation: mmc: sdhci-of-arasan: add power domain description
  arm64: dts: rockchip: Provide power-domains for sd/sdio/emmc
controllers
  mmc: dw_mmc: add power domain support
  mmc: sdhci-of-arasan: add power domain support

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt |  1 +
 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt |  2 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  3 +++
 drivers/mmc/host/dw_mmc.c  | 11 +++
 drivers/mmc/host/sdhci-of-arasan.c | 10 ++
 5 files changed, 27 insertions(+)

-- 
2.3.7

[Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

[John Stultz]

After moving my HiKey tree to pre-v4.8-rc, I noticed when using
Android that I was getting routing errors after toggling networking on
and off (or entering suspend). Wifi associated, but I got some
rounting errors in the logcat the connection manager wouldn't detect a
valid network.

Not being able to figure out exactly what was going wrong from the
userspace side, I bisected (manually rebasing a 70 patch stack each
step :P) it down and it seems that the commit: 153380ec4b9b
("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule") is causing
the problem.

Reverting that patch seems to make things work again.

I'm no networking guru, but I'm happy to help debug this further if
folks can walk me through it a bit.

thanks
-john

Re: linux-next: build failure after merge of the vfs tree

[Al Viro]

On Fri, Jul 29, 2016 at 11:19:38AM +1000, Stephen Rothwell wrote:
> ---
>  fs/fuse/dir.c| 2 +-
>  fs/fuse/fuse_i.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index f910578e51ba..c47b7780ce37 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -935,7 +935,7 @@ int fuse_update_attributes(struct inode *inode, struct 
> kstat *stat,
>  }
>  
>  int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
> -  u64 child_nodeid, const struct qstr *name)
> +  u64 child_nodeid, struct qstr *name)
>  {
>   int err = -ENOTDIR;
>   struct inode *parent;

I'm not sure if it's the best way to handle that, TBH...  It might be better
to pass name.name/name.len separately here.  Both callers have a _lot_ of
code duplication; I've a patch getting rid of code duplication there, will
play with it and see if it would make sense to quit messing with struct
qstr while we are at it.

BTW, I'd been toying with the following trick:

static inline const struct qstr *d_name(const struct dentry *dentry)
{
return >d_name;
}
with subsequent switch of dentry->d_name.foo to d_name(dentry)->foo and
>d_name to d_name(dentry).  Note 'const' in the above - the point is,
there are very few places where dentry->d_name can be legitimately modified
(__d_alloc(), swap_names() and copy_name()) and it'd be nice to have cc(1)
enforce that.  Changing d_name to const struct qstr (and explicitly casting
in the aforementioned 3 functions) would do it, but it's deep in nasal daemon
territory; OTOH, conversion to the helper above with subsequent renaming of
the field to something easily greppable for would get the same effect and
stay within standard C.

FWIW, the whole "constify struct qstr * arguments" series is due to hunting
for ppc bug reported a while ago; it manifested as NULL ->d_name.name observed
in __d_lookup_rcu().  AFAICS, it's an effect of earlier memory corruption,
seeing that there was list_del() in prune_dcache_sb() hitting NULL ->prev->next
(in __list_del_entry(), probably via prune_dcache_sb()->shrink_dentry_list()->
d_shrink_del()->list_del_init(>d_lru)), but it would be nice to have
an easier way to prove that nothing would be able to bugger ->d_name.

[PATCH 0/5] Add power domain support for dw_mmc/sdhci-of-arasan

[Shawn Lin]

We need to enable the power domain manually while probing as the
power policy will turn off the pd which is not referenced. Otherwise
we may take risk of breaking kernel once Feng Xiao land the rockchip pd
relate stuff. So, let's do it in advance.

This pachset is based on the latest linux-next[1] which should contain
the next branch of linux-mmc and dt stuff. It's ideal to pack these all
into Ulf' tree with Heiko's ack for dts, Rob's ack for Doc and Jaehoon's
ack for dw_mmc. But it's okay to be merged seperately.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Thanks.



Shawn Lin (5):
  Documentation: mmc: synopsys-dw-mshc: add power domain description
  Documentation: mmc: sdhci-of-arasan: add power domain description
  arm64: dts: rockchip: Provide power-domains for sd/sdio/emmc
controllers
  mmc: dw_mmc: add power domain support
  mmc: sdhci-of-arasan: add power domain support

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt |  1 +
 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt |  2 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  3 +++
 drivers/mmc/host/dw_mmc.c  | 11 +++
 drivers/mmc/host/sdhci-of-arasan.c | 10 ++
 5 files changed, 27 insertions(+)

-- 
2.3.7

[Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

[John Stultz]

After moving my HiKey tree to pre-v4.8-rc, I noticed when using
Android that I was getting routing errors after toggling networking on
and off (or entering suspend). Wifi associated, but I got some
rounting errors in the logcat the connection manager wouldn't detect a
valid network.

Not being able to figure out exactly what was going wrong from the
userspace side, I bisected (manually rebasing a 70 patch stack each
step :P) it down and it seems that the commit: 153380ec4b9b
("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule") is causing
the problem.

Reverting that patch seems to make things work again.

I'm no networking guru, but I'm happy to help debug this further if
folks can walk me through it a bit.

thanks
-john

Re: linux-next: build failure after merge of the vfs tree

[Al Viro]

On Fri, Jul 29, 2016 at 11:19:38AM +1000, Stephen Rothwell wrote:
> ---
>  fs/fuse/dir.c| 2 +-
>  fs/fuse/fuse_i.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index f910578e51ba..c47b7780ce37 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -935,7 +935,7 @@ int fuse_update_attributes(struct inode *inode, struct 
> kstat *stat,
>  }
>  
>  int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
> -  u64 child_nodeid, const struct qstr *name)
> +  u64 child_nodeid, struct qstr *name)
>  {
>   int err = -ENOTDIR;
>   struct inode *parent;

I'm not sure if it's the best way to handle that, TBH...  It might be better
to pass name.name/name.len separately here.  Both callers have a _lot_ of
code duplication; I've a patch getting rid of code duplication there, will
play with it and see if it would make sense to quit messing with struct
qstr while we are at it.

BTW, I'd been toying with the following trick:

static inline const struct qstr *d_name(const struct dentry *dentry)
{
return >d_name;
}
with subsequent switch of dentry->d_name.foo to d_name(dentry)->foo and
>d_name to d_name(dentry).  Note 'const' in the above - the point is,
there are very few places where dentry->d_name can be legitimately modified
(__d_alloc(), swap_names() and copy_name()) and it'd be nice to have cc(1)
enforce that.  Changing d_name to const struct qstr (and explicitly casting
in the aforementioned 3 functions) would do it, but it's deep in nasal daemon
territory; OTOH, conversion to the helper above with subsequent renaming of
the field to something easily greppable for would get the same effect and
stay within standard C.

FWIW, the whole "constify struct qstr * arguments" series is due to hunting
for ppc bug reported a while ago; it manifested as NULL ->d_name.name observed
in __d_lookup_rcu().  AFAICS, it's an effect of earlier memory corruption,
seeing that there was list_del() in prune_dcache_sb() hitting NULL ->prev->next
(in __list_del_entry(), probably via prune_dcache_sb()->shrink_dentry_list()->
d_shrink_del()->list_del_init(>d_lru)), but it would be nice to have
an easier way to prove that nothing would be able to bugger ->d_name.

RE: [PATCH 1/1] EDAC, sb_edac: Fix channel reporting on Knights Landing

[Odzioba, Lukasz]

On Saturday, July 23, 2016 1:45 AM, Lukasz Odzioba wrote:
> On Intel Xeon Phi Knights Landing processor family the channels
> of memory controller have untypical arrangement - MC0 is mapped to
> CH3,4,5 and MC1 is mapped to CH0,1,2. This causes EDAC driver to
> report the channel name incorrectly.
>
> We missed this change earlier, so the code already contains
> similar comment, but the translation function is incorrect.
>
> Without this patch:
>  errors in DIMM_A and DIMM_D were reported in DIMM_D
>  errors in DIMM_B and DIMM_E were reported in DIMM_E
>  errors in DIMM_C and DIMM_F were reported in DIMM_F
>
> Fixes: d0cdf9003140 ("sb_edac: Add Knights Landing (Xeon Phi gen 2) support")

Hi,
I would greatly appreciate it if you kindly give me some feedback on this patch.

Thanks,
Lukas

RE: [PATCH 1/1] EDAC, sb_edac: Fix channel reporting on Knights Landing

[Odzioba, Lukasz]

On Saturday, July 23, 2016 1:45 AM, Lukasz Odzioba wrote:
> On Intel Xeon Phi Knights Landing processor family the channels
> of memory controller have untypical arrangement - MC0 is mapped to
> CH3,4,5 and MC1 is mapped to CH0,1,2. This causes EDAC driver to
> report the channel name incorrectly.
>
> We missed this change earlier, so the code already contains
> similar comment, but the translation function is incorrect.
>
> Without this patch:
>  errors in DIMM_A and DIMM_D were reported in DIMM_D
>  errors in DIMM_B and DIMM_E were reported in DIMM_E
>  errors in DIMM_C and DIMM_F were reported in DIMM_F
>
> Fixes: d0cdf9003140 ("sb_edac: Add Knights Landing (Xeon Phi gen 2) support")

Hi,
I would greatly appreciate it if you kindly give me some feedback on this patch.

Thanks,
Lukas

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/x86/include/asm/thread_info.h

between commit:

  609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")

from the tip tree and commit:

  58f9594bd42f ("signal: consolidate {TS,TLF}_RESTORE_SIGMASK code")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/thread_info.h
index d4b0fd24a63e,b45ffdda3549..
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@@ -263,35 -219,8 +263,11 @@@ static inline int arch_within_stack_fra
   * have to worry about atomic accesses.
   */
  #define TS_COMPAT 0x0002  /* 32bit syscall active (64BIT)*/
 +#ifdef CONFIG_COMPAT
 +#define TS_I386_REGS_POKED0x0004  /* regs poked by 32-bit ptracer */
 +#endif
- #define TS_RESTORE_SIGMASK0x0008  /* restore signal mask in do_signal() */
  
  #ifndef __ASSEMBLY__
- #define HAVE_SET_RESTORE_SIGMASK  1
- static inline void set_restore_sigmask(void)
- {
-   struct thread_info *ti = current_thread_info();
-   ti->status |= TS_RESTORE_SIGMASK;
-   WARN_ON(!test_bit(TIF_SIGPENDING, (unsigned long *)>flags));
- }
- static inline void clear_restore_sigmask(void)
- {
-   current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
- }
- static inline bool test_restore_sigmask(void)
- {
-   return current_thread_info()->status & TS_RESTORE_SIGMASK;
- }
- static inline bool test_and_clear_restore_sigmask(void)
- {
-   struct thread_info *ti = current_thread_info();
-   if (!(ti->status & TS_RESTORE_SIGMASK))
-   return false;
-   ti->status &= ~TS_RESTORE_SIGMASK;
-   return true;
- }
  
  static inline bool in_ia32_syscall(void)
  {

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/x86/include/asm/thread_info.h

between commit:

  609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")

from the tip tree and commit:

  58f9594bd42f ("signal: consolidate {TS,TLF}_RESTORE_SIGMASK code")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/thread_info.h
index d4b0fd24a63e,b45ffdda3549..
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@@ -263,35 -219,8 +263,11 @@@ static inline int arch_within_stack_fra
   * have to worry about atomic accesses.
   */
  #define TS_COMPAT 0x0002  /* 32bit syscall active (64BIT)*/
 +#ifdef CONFIG_COMPAT
 +#define TS_I386_REGS_POKED0x0004  /* regs poked by 32-bit ptracer */
 +#endif
- #define TS_RESTORE_SIGMASK0x0008  /* restore signal mask in do_signal() */
  
  #ifndef __ASSEMBLY__
- #define HAVE_SET_RESTORE_SIGMASK  1
- static inline void set_restore_sigmask(void)
- {
-   struct thread_info *ti = current_thread_info();
-   ti->status |= TS_RESTORE_SIGMASK;
-   WARN_ON(!test_bit(TIF_SIGPENDING, (unsigned long *)>flags));
- }
- static inline void clear_restore_sigmask(void)
- {
-   current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
- }
- static inline bool test_restore_sigmask(void)
- {
-   return current_thread_info()->status & TS_RESTORE_SIGMASK;
- }
- static inline bool test_and_clear_restore_sigmask(void)
- {
-   struct thread_info *ti = current_thread_info();
-   if (!(ti->status & TS_RESTORE_SIGMASK))
-   return false;
-   ti->status &= ~TS_RESTORE_SIGMASK;
-   return true;
- }
  
  static inline bool in_ia32_syscall(void)
  {

Re: [PATCH v2 2/2] sparc64: Fix pagetable freeing for hugepage regions

[David Miller]

From: Nitin Gupta 
Date: Thu, 23 Jun 2016 15:05:36 -0700

> 8M pages now allocate page tables till PMD level only.
> So, when freeing page table for 8M hugepage backed region,
> make sure we don't try to access non-existent PTE level.
> 
> Signed-off-by: Nitin Gupta 

The manner in which you have submitted this change breaks
bisectability.

The "problem" you are fixing here is introduced by you in patch #1.

You need to combine these two changes together, otherwise there is
an intermediate state where the kernel is broken by your changes.

RE: [PATCH v2] perf sched: fix wrong conversion of task state

[Tomoki Sekiyama]

Hi Hiramatsu-san,

On 2016/7/28, 2016 8:43, Masami Hiramatsu wrote:
> Hmm, this includes several fixes and enhancements.
> 1. Use first bit of the state instead of state itself (critical bug to
avoid crash?)
> 2. Check the range of the array and return '?' if out (minor bug, it can
access data area)
> 3. Fix TASK_STATE_TO_CHAR_STR to swap X and Z.
> 4. Add new 'N+' to TASK_STATE_TO_CHAR_STR. (how about 'n'?)
> 5. Treat a preempted task as THREAD_WAIT_CPU.
>
> so IMHO, it is better to split this patch into atleast 2, #1 and #2
(critical bugfix),
> #3, #4, and #5 (minor update).

This time I will fix only the invalid array access and
adapting to the current kernel TASK_STATE, and leave the
preempted task handling for later follow-up.

 [..]
>> @@ -897,9 +898,10 @@ static int thread_atoms_insert(struct perf_sched
*sched, struct thread *thread)
>> +return bit < sizeof(str) - 1 ? str[bit] : '?';
>
> You'd better use ARRAY_SIZE(str) instead of sizeof() for array here.

OK, will change this to use ARRAY_SIZE on the next update.

Thanks,
Tomoki Sekiyama

Re: [PATCH v2 2/2] sparc64: Fix pagetable freeing for hugepage regions

[David Miller]

From: Nitin Gupta 
Date: Thu, 23 Jun 2016 15:05:36 -0700

> 8M pages now allocate page tables till PMD level only.
> So, when freeing page table for 8M hugepage backed region,
> make sure we don't try to access non-existent PTE level.
> 
> Signed-off-by: Nitin Gupta 

The manner in which you have submitted this change breaks
bisectability.

The "problem" you are fixing here is introduced by you in patch #1.

You need to combine these two changes together, otherwise there is
an intermediate state where the kernel is broken by your changes.

RE: [PATCH v2] perf sched: fix wrong conversion of task state

[Tomoki Sekiyama]

Hi Hiramatsu-san,

On 2016/7/28, 2016 8:43, Masami Hiramatsu wrote:
> Hmm, this includes several fixes and enhancements.
> 1. Use first bit of the state instead of state itself (critical bug to
avoid crash?)
> 2. Check the range of the array and return '?' if out (minor bug, it can
access data area)
> 3. Fix TASK_STATE_TO_CHAR_STR to swap X and Z.
> 4. Add new 'N+' to TASK_STATE_TO_CHAR_STR. (how about 'n'?)
> 5. Treat a preempted task as THREAD_WAIT_CPU.
>
> so IMHO, it is better to split this patch into atleast 2, #1 and #2
(critical bugfix),
> #3, #4, and #5 (minor update).

This time I will fix only the invalid array access and
adapting to the current kernel TASK_STATE, and leave the
preempted task handling for later follow-up.

 [..]
>> @@ -897,9 +898,10 @@ static int thread_atoms_insert(struct perf_sched
*sched, struct thread *thread)
>> +return bit < sizeof(str) - 1 ? str[bit] : '?';
>
> You'd better use ARRAY_SIZE(str) instead of sizeof() for array here.

OK, will change this to use ARRAY_SIZE on the next update.

Thanks,
Tomoki Sekiyama

[PATCH v3] perf sched: fix wrong conversion of task state

[Tomoki Sekiyama]

sched_out_state() converts the prev_state u64 bitmask to a char in
a wrong way, which may cause invalid memory access.
TASK_STATE_TO_CHAR_STR should also be fixed to adapt current
kernel's sched.h.

Signed-off-by: Tomoki Sekiyama 
Cc: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Masami Hiramatsu 
---
 tools/perf/builtin-sched.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0dfe8df..5776263 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -70,7 +70,7 @@ struct sched_atom {
struct task_desc*wakee;
 };
 
-#define TASK_STATE_TO_CHAR_STR "RSDTtZXxKWP"
+#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWPNn"
 
 enum thread_state {
THREAD_SLEEPING = 0,
@@ -897,9 +897,10 @@ static int thread_atoms_insert(struct perf_sched *sched, 
struct thread *thread)
 
 static char sched_out_state(u64 prev_state)
 {
-   const char *str = TASK_STATE_TO_CHAR_STR;
+   const char str[] = TASK_STATE_TO_CHAR_STR;
+   unsigned int bit = prev_state ? __ffs(prev_state) + 1 : 0;
 
-   return str[prev_state];
+   return bit < ARRAY_SIZE(str) - 1 ? str[bit] : '?';
 }
 
 static int
-- 
2.7.4

[PATCH v3] perf sched: fix wrong conversion of task state

[Tomoki Sekiyama]

sched_out_state() converts the prev_state u64 bitmask to a char in
a wrong way, which may cause invalid memory access.
TASK_STATE_TO_CHAR_STR should also be fixed to adapt current
kernel's sched.h.

Signed-off-by: Tomoki Sekiyama 
Cc: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Masami Hiramatsu 
---
 tools/perf/builtin-sched.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0dfe8df..5776263 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -70,7 +70,7 @@ struct sched_atom {
struct task_desc*wakee;
 };
 
-#define TASK_STATE_TO_CHAR_STR "RSDTtZXxKWP"
+#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWPNn"
 
 enum thread_state {
THREAD_SLEEPING = 0,
@@ -897,9 +897,10 @@ static int thread_atoms_insert(struct perf_sched *sched, 
struct thread *thread)
 
 static char sched_out_state(u64 prev_state)
 {
-   const char *str = TASK_STATE_TO_CHAR_STR;
+   const char str[] = TASK_STATE_TO_CHAR_STR;
+   unsigned int bit = prev_state ? __ffs(prev_state) + 1 : 0;
 
-   return str[prev_state];
+   return bit < ARRAY_SIZE(str) - 1 ? str[bit] : '?';
 }
 
 static int
-- 
2.7.4

[PATCH] cxl: replace loop with for_each_child_of_node(), remove unneeded of_node_put()

[Andrew Donnellan]

Rewrite the cxl_guest_init_afu() loop in cxl_of_probe() to use
for_each_child_of_node() rather than a hand-coded for loop.

Remove the useless of_node_put(afu_np) call after the loop, where it's
guaranteed that afu_np == NULL.

Reported-by: SF Markus Elfring 
Reported-by: Julia Lawall 
Signed-off-by: Andrew Donnellan 

---

Checked the of_node_put() with Fred, he thinks it was probably just left
over from an earlier private version of the code and we can just get rid of
it.
---
 drivers/misc/cxl/of.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/cxl/of.c b/drivers/misc/cxl/of.c
index edc4583..ec175ea 100644
--- a/drivers/misc/cxl/of.c
+++ b/drivers/misc/cxl/of.c
@@ -460,7 +460,7 @@ int cxl_of_probe(struct platform_device *pdev)
struct device_node *afu_np = NULL;
struct cxl *adapter = NULL;
int ret;
-   int slice, slice_ok;
+   int slice = 0, slice_ok = 0;
 
pr_devel("in %s\n", __func__);
 
@@ -476,13 +476,13 @@ int cxl_of_probe(struct platform_device *pdev)
}
 
/* init afu */
-   slice_ok = 0;
-   for (afu_np = NULL, slice = 0; (afu_np = of_get_next_child(np, 
afu_np)); slice++) {
+   for_each_child_of_node(np, afu_np) {
if ((ret = cxl_guest_init_afu(adapter, slice, afu_np)))
dev_err(>dev, "AFU %i failed to initialise: %i\n",
slice, ret);
else
slice_ok++;
+   slice++;
}
 
if (slice_ok == 0) {
@@ -490,8 +490,6 @@ int cxl_of_probe(struct platform_device *pdev)
adapter->slices = 0;
}
 
-   if (afu_np)
-   of_node_put(afu_np);
return 0;
 }
 
-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

[PATCH] cxl: replace loop with for_each_child_of_node(), remove unneeded of_node_put()

[Andrew Donnellan]

Rewrite the cxl_guest_init_afu() loop in cxl_of_probe() to use
for_each_child_of_node() rather than a hand-coded for loop.

Remove the useless of_node_put(afu_np) call after the loop, where it's
guaranteed that afu_np == NULL.

Reported-by: SF Markus Elfring 
Reported-by: Julia Lawall 
Signed-off-by: Andrew Donnellan 

---

Checked the of_node_put() with Fred, he thinks it was probably just left
over from an earlier private version of the code and we can just get rid of
it.
---
 drivers/misc/cxl/of.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/cxl/of.c b/drivers/misc/cxl/of.c
index edc4583..ec175ea 100644
--- a/drivers/misc/cxl/of.c
+++ b/drivers/misc/cxl/of.c
@@ -460,7 +460,7 @@ int cxl_of_probe(struct platform_device *pdev)
struct device_node *afu_np = NULL;
struct cxl *adapter = NULL;
int ret;
-   int slice, slice_ok;
+   int slice = 0, slice_ok = 0;
 
pr_devel("in %s\n", __func__);
 
@@ -476,13 +476,13 @@ int cxl_of_probe(struct platform_device *pdev)
}
 
/* init afu */
-   slice_ok = 0;
-   for (afu_np = NULL, slice = 0; (afu_np = of_get_next_child(np, 
afu_np)); slice++) {
+   for_each_child_of_node(np, afu_np) {
if ((ret = cxl_guest_init_afu(adapter, slice, afu_np)))
dev_err(>dev, "AFU %i failed to initialise: %i\n",
slice, ret);
else
slice_ok++;
+   slice++;
}
 
if (slice_ok == 0) {
@@ -490,8 +490,6 @@ int cxl_of_probe(struct platform_device *pdev)
adapter->slices = 0;
}
 
-   if (afu_np)
-   of_node_put(afu_np);
return 0;
 }
 
-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH V6 3/9] irqdomain: Don't set type when mapping an IRQ

[Masahiro Yamada]

Hi.


I noticed my board would not work any more
when pulling recent updates.


I did "git-bisect" and I found the following commit is it.



commit 1e2a7d78499ec8859d2b469051b7b80bad3b08aa
Author: Jon Hunter 
Date:   Tue Jun 7 16:12:28 2016 +0100

irqdomain: Don't set type when mapping an IRQ




With reverting it, everything works fine for me.

My board is arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts

Is anything wrong with IRQ settings in my Device Tree?


If 1e2a7d784 is really a buggy commit,
could you do something please?







2016-06-08 0:12 GMT+09:00 Jon Hunter :
> Some IRQ chips, such as GPIO controllers or secondary level interrupt
> controllers, may require require additional runtime power management
> control to ensure they are accessible. For such IRQ chips, it makes sense
> to enable the IRQ chip when interrupts are requested and disabled them
> again once all interrupts have been freed.
>
> When mapping an IRQ, the IRQ type settings are read and then programmed.
> The mapping of the IRQ happens before the IRQ is requested and so the
> programming of the type settings occurs before the IRQ is requested. This
> is a problem for IRQ chips that require additional power management
> control because they may not be accessible yet. Therefore, when mapping
> the IRQ, don't program the type settings, just save them and then program
> these saved settings when the IRQ is requested (so long as if they are not
> overridden via the call to request the IRQ).
>
> Add a stub function for irq_domain_free_irqs() to avoid any compilation
> errors when CONFIG_IRQ_DOMAIN_HIERARCHY is not selected.
>
> Signed-off-by: Jon Hunter 
> Reviewed-by: Marc Zyngier 
> ---
>  include/linux/irqdomain.h |  3 +++
>  kernel/irq/irqdomain.c| 23 ++-
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index f1f36e04d885..317503763314 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -452,6 +452,9 @@ static inline int irq_domain_alloc_irqs(struct irq_domain 
> *domain,
> return -1;
>  }
>
> +static inline void irq_domain_free_irqs(unsigned int virq,
> +   unsigned int nr_irqs) { }
> +
>  static inline bool irq_domain_is_hierarchy(struct irq_domain *domain)
>  {
> return false;
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index f3ff1eb8dd09..caa6a63d26f0 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -567,6 +567,7 @@ static void of_phandle_args_to_fwspec(struct 
> of_phandle_args *irq_data,
>  unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>  {
> struct irq_domain *domain;
> +   struct irq_data *irq_data;
> irq_hw_number_t hwirq;
> unsigned int type = IRQ_TYPE_NONE;
> int virq;
> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
> *fwspec)
>  * it now and return the interrupt number.
>  */
> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> -   irq_set_irq_type(virq, type);
> +   irq_data = irq_get_irq_data(virq);
> +   if (!irq_data)
> +   return 0;
> +
> +   irqd_set_trigger_type(irq_data, type);
> return virq;
> }
>
> @@ -634,10 +639,18 @@ unsigned int irq_create_fwspec_mapping(struct 
> irq_fwspec *fwspec)
> return virq;
> }
>
> -   /* Set type if specified and different than the current one */
> -   if (type != IRQ_TYPE_NONE &&
> -   type != irq_get_trigger_type(virq))
> -   irq_set_irq_type(virq, type);
> +   irq_data = irq_get_irq_data(virq);
> +   if (!irq_data) {
> +   if (irq_domain_is_hierarchy(domain))
> +   irq_domain_free_irqs(virq, 1);
> +   else
> +   irq_dispose_mapping(virq);
> +   return 0;
> +   }
> +
> +   /* Store trigger type */
> +   irqd_set_trigger_type(irq_data, type);
> +
> return virq;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_fwspec_mapping);
> --
> 2.1.4
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH V6 3/9] irqdomain: Don't set type when mapping an IRQ

[Masahiro Yamada]

Hi.


I noticed my board would not work any more
when pulling recent updates.


I did "git-bisect" and I found the following commit is it.



commit 1e2a7d78499ec8859d2b469051b7b80bad3b08aa
Author: Jon Hunter 
Date:   Tue Jun 7 16:12:28 2016 +0100

irqdomain: Don't set type when mapping an IRQ




With reverting it, everything works fine for me.

My board is arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts

Is anything wrong with IRQ settings in my Device Tree?


If 1e2a7d784 is really a buggy commit,
could you do something please?







2016-06-08 0:12 GMT+09:00 Jon Hunter :
> Some IRQ chips, such as GPIO controllers or secondary level interrupt
> controllers, may require require additional runtime power management
> control to ensure they are accessible. For such IRQ chips, it makes sense
> to enable the IRQ chip when interrupts are requested and disabled them
> again once all interrupts have been freed.
>
> When mapping an IRQ, the IRQ type settings are read and then programmed.
> The mapping of the IRQ happens before the IRQ is requested and so the
> programming of the type settings occurs before the IRQ is requested. This
> is a problem for IRQ chips that require additional power management
> control because they may not be accessible yet. Therefore, when mapping
> the IRQ, don't program the type settings, just save them and then program
> these saved settings when the IRQ is requested (so long as if they are not
> overridden via the call to request the IRQ).
>
> Add a stub function for irq_domain_free_irqs() to avoid any compilation
> errors when CONFIG_IRQ_DOMAIN_HIERARCHY is not selected.
>
> Signed-off-by: Jon Hunter 
> Reviewed-by: Marc Zyngier 
> ---
>  include/linux/irqdomain.h |  3 +++
>  kernel/irq/irqdomain.c| 23 ++-
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index f1f36e04d885..317503763314 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -452,6 +452,9 @@ static inline int irq_domain_alloc_irqs(struct irq_domain 
> *domain,
> return -1;
>  }
>
> +static inline void irq_domain_free_irqs(unsigned int virq,
> +   unsigned int nr_irqs) { }
> +
>  static inline bool irq_domain_is_hierarchy(struct irq_domain *domain)
>  {
> return false;
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index f3ff1eb8dd09..caa6a63d26f0 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -567,6 +567,7 @@ static void of_phandle_args_to_fwspec(struct 
> of_phandle_args *irq_data,
>  unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>  {
> struct irq_domain *domain;
> +   struct irq_data *irq_data;
> irq_hw_number_t hwirq;
> unsigned int type = IRQ_TYPE_NONE;
> int virq;
> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
> *fwspec)
>  * it now and return the interrupt number.
>  */
> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> -   irq_set_irq_type(virq, type);
> +   irq_data = irq_get_irq_data(virq);
> +   if (!irq_data)
> +   return 0;
> +
> +   irqd_set_trigger_type(irq_data, type);
> return virq;
> }
>
> @@ -634,10 +639,18 @@ unsigned int irq_create_fwspec_mapping(struct 
> irq_fwspec *fwspec)
> return virq;
> }
>
> -   /* Set type if specified and different than the current one */
> -   if (type != IRQ_TYPE_NONE &&
> -   type != irq_get_trigger_type(virq))
> -   irq_set_irq_type(virq, type);
> +   irq_data = irq_get_irq_data(virq);
> +   if (!irq_data) {
> +   if (irq_domain_is_hierarchy(domain))
> +   irq_domain_free_irqs(virq, 1);
> +   else
> +   irq_dispose_mapping(virq);
> +   return 0;
> +   }
> +
> +   /* Store trigger type */
> +   irqd_set_trigger_type(irq_data, type);
> +
> return virq;
>  }
>  EXPORT_SYMBOL_GPL(irq_create_fwspec_mapping);
> --
> 2.1.4
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/3] new feature: monitoring page cache events

[George Amvrosiadis]

On Thu, Jul 28, 2016 at 02:02:45PM -0700, Dave Hansen wrote:
> On 07/25/2016 08:47 PM, George Amvrosiadis wrote:
> >  21 files changed, 2424 insertions(+), 1 deletion(-)
> 
> I like the idea, but yikes, that's a lot of code.
> 
> Have you considered using or augmenting the kernel's existing tracing
> mechanisms?  Have you considered using something like netlink for
> transporting the data out of the kernel?
>

We contemplated a couple other solutions. One was extending existing debugging
mechanisms. E.g., there are already tracepoints at __add_to_page_cache_locked()
and __delete_from_page_cache(). A consistent reaction I got for doing that,
however, was that of exposing an unruly interface to user applications, which
is certainly not an elegant solution. After that experience, and reading up on
issues of the auditing subsystem (https://lwn.net/Articles/600568/) I decided
to avoid going further down that path.

> The PageDirty() hooks look simple but turn out to be horribly deep.
> Where we used to have a plain old bit set, we now have new locks,
> potentially long periods of irq disabling, and loops over all the tasks
> doing duet, even path lookup!
> 

It's true that the hooks are deep, but they are fully exercised only once per
inode, per task. The reasoning behind the 'struct bmap_rbnode'->seen bitmap is
to remember whether an inode was seen before by a given task. During that first
access is when we do the path lookup to decide whether this inode is relevant
to the task and mark 'struct bmap_rbnode'->relv accordingly. If it is not, we
ignore future events from it. Tasks can also use the 'structu bmap_rbnode'->done
bitmap to indicate that they are done with a specific inode, which also stops
those events from passing that task loop.

> Given a big system, I would imagine these locks slowing down
> SetPageDirty() and things like write() pretty severely.  Have you done
> an assessment of the performance impact of this change?   I can't
> imagine this being used in any kind of performance or
> scalability-sensitive environment.
> 

I have used filebench to saturate an HDD and an SSD, registered a task to be
notified about every file in the filesystem, and measured no difference in I/O
throughput. To measure the CPU utilization of Duet, I tried an extreme case
where I booted using only one core and again saturated an HDD using filebench.
There was a 1-1.5% increase in CPU utilization. There is a description of this
result in the paper. I have also tuned filebench to hit the cache often in my
experiments (more than 60-70% of accesses going to less than 10% of the data),
but the results were similar. For the Hadoop and Spark experiments we used a
24-node cluster and these overhead numbers didn't seem to affect performance.

> The current tracing code has a model where the trace producers put data
> in *one* place, then all the mulitple consumers pull it out of that
> place.  Duet seems to have the model that the producer puts the data in
> multiple places and consumers consume it from their own private copies.
>  That seems a bit backwards and puts cost directly in to hot code paths.
>  Even a single task watching a single file on the system makes everyone
> go in and pay some of this cost for every SetPageDirty().
> 

Duet operates in a similar way. There is one large global hash table to avoid
collisions, so that on average a single lookup is sufficient to place a page in
it. Due to its global nature, if a page is of interest to multiple tasks, only
one entry is used to hold the events for that page across all tasks. And to
avoid walking that hash table for relevant events on a read(), each task
maintains a separate bitmap of the hash table's buckets that tells it which
buckets to look into. (In the past I've also tried a work queue approach on the
hot code path, but the overhead was almost double as a result of allocating the
work queue items.)

Having said all the above, Dave, I've seen your work at the 2013 Linux Plumbers
Conference on scalability issues, so if you think I'm missing something in my
replies, please call me out on that. I'm definitely open to improving this code.

> Let's say we had a big system with virtually everything sitting in the
> page cache.  Does duet have a way to find things currently _in_ the
> cache, or only when things move in/out of it?
> 

At task registration time we grab the superblock for the filesystem of the
registered path, and then scan_page_cache() traverses the list of inodes
currently in memory. We enqueue ADDED and DIRTY events for relevant inodes
as needed.

> Tasks seem to have a fixed 'struct path' ->regpath at duet_task_init()
> time.  The code goes page->mapping->inode->i_dentry and then tries to
> compare that with the originally recorded path.  Does this even work in
> the face of things like bind mounts, mounts that change after
> duet_task_init(), or mounting a fs with a different superblock
> underneath a watched path?  It seems awfully fragile.

This 

Re: [PATCH 0/3] new feature: monitoring page cache events

[George Amvrosiadis]

On Thu, Jul 28, 2016 at 02:02:45PM -0700, Dave Hansen wrote:
> On 07/25/2016 08:47 PM, George Amvrosiadis wrote:
> >  21 files changed, 2424 insertions(+), 1 deletion(-)
> 
> I like the idea, but yikes, that's a lot of code.
> 
> Have you considered using or augmenting the kernel's existing tracing
> mechanisms?  Have you considered using something like netlink for
> transporting the data out of the kernel?
>

We contemplated a couple other solutions. One was extending existing debugging
mechanisms. E.g., there are already tracepoints at __add_to_page_cache_locked()
and __delete_from_page_cache(). A consistent reaction I got for doing that,
however, was that of exposing an unruly interface to user applications, which
is certainly not an elegant solution. After that experience, and reading up on
issues of the auditing subsystem (https://lwn.net/Articles/600568/) I decided
to avoid going further down that path.

> The PageDirty() hooks look simple but turn out to be horribly deep.
> Where we used to have a plain old bit set, we now have new locks,
> potentially long periods of irq disabling, and loops over all the tasks
> doing duet, even path lookup!
> 

It's true that the hooks are deep, but they are fully exercised only once per
inode, per task. The reasoning behind the 'struct bmap_rbnode'->seen bitmap is
to remember whether an inode was seen before by a given task. During that first
access is when we do the path lookup to decide whether this inode is relevant
to the task and mark 'struct bmap_rbnode'->relv accordingly. If it is not, we
ignore future events from it. Tasks can also use the 'structu bmap_rbnode'->done
bitmap to indicate that they are done with a specific inode, which also stops
those events from passing that task loop.

> Given a big system, I would imagine these locks slowing down
> SetPageDirty() and things like write() pretty severely.  Have you done
> an assessment of the performance impact of this change?   I can't
> imagine this being used in any kind of performance or
> scalability-sensitive environment.
> 

I have used filebench to saturate an HDD and an SSD, registered a task to be
notified about every file in the filesystem, and measured no difference in I/O
throughput. To measure the CPU utilization of Duet, I tried an extreme case
where I booted using only one core and again saturated an HDD using filebench.
There was a 1-1.5% increase in CPU utilization. There is a description of this
result in the paper. I have also tuned filebench to hit the cache often in my
experiments (more than 60-70% of accesses going to less than 10% of the data),
but the results were similar. For the Hadoop and Spark experiments we used a
24-node cluster and these overhead numbers didn't seem to affect performance.

> The current tracing code has a model where the trace producers put data
> in *one* place, then all the mulitple consumers pull it out of that
> place.  Duet seems to have the model that the producer puts the data in
> multiple places and consumers consume it from their own private copies.
>  That seems a bit backwards and puts cost directly in to hot code paths.
>  Even a single task watching a single file on the system makes everyone
> go in and pay some of this cost for every SetPageDirty().
> 

Duet operates in a similar way. There is one large global hash table to avoid
collisions, so that on average a single lookup is sufficient to place a page in
it. Due to its global nature, if a page is of interest to multiple tasks, only
one entry is used to hold the events for that page across all tasks. And to
avoid walking that hash table for relevant events on a read(), each task
maintains a separate bitmap of the hash table's buckets that tells it which
buckets to look into. (In the past I've also tried a work queue approach on the
hot code path, but the overhead was almost double as a result of allocating the
work queue items.)

Having said all the above, Dave, I've seen your work at the 2013 Linux Plumbers
Conference on scalability issues, so if you think I'm missing something in my
replies, please call me out on that. I'm definitely open to improving this code.

> Let's say we had a big system with virtually everything sitting in the
> page cache.  Does duet have a way to find things currently _in_ the
> cache, or only when things move in/out of it?
> 

At task registration time we grab the superblock for the filesystem of the
registered path, and then scan_page_cache() traverses the list of inodes
currently in memory. We enqueue ADDED and DIRTY events for relevant inodes
as needed.

> Tasks seem to have a fixed 'struct path' ->regpath at duet_task_init()
> time.  The code goes page->mapping->inode->i_dentry and then tries to
> compare that with the originally recorded path.  Does this even work in
> the face of things like bind mounts, mounts that change after
> duet_task_init(), or mounting a fs with a different superblock
> underneath a watched path?  It seems awfully fragile.

This 

Re: [PATCH 2/2] mmc: dw_mmc: remove the deprecated "supports-highspeed" property

[Jaehoon Chung]

Hi Shawn,

On 07/29/2016 11:44 AM, Shawn Lin wrote:
> 在 2016/7/28 17:55, Jaehoon Chung 写道:
>> Remvoe the deprecated "supports-highspeed" property.
>> DWMMC controller will not use this property anymore.
>>
> 
> We had set up a flag day to remove these deprecated property
> long time agao.
> 
> It doesn't *break* old dtb which may(not ?) still boot up new
> kernel code as we just make it suffer from lower speed, then
> I think it's time for them to migrate to the new property anyway.

Thanks for reviewing!

Best Regards,
Jaehoon Chung

> 
> So,
> 
> Reviewed-by: Shawn Lin 
> 
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 5 -
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1b719a6..e9faedd 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2890,11 +2890,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
>> dw_mci *host)
>>  return ERR_PTR(ret);
>>  }
>>
>> -if (of_find_property(np, "supports-highspeed", NULL)) {
>> -dev_info(dev, "supports-highspeed property is deprecated.\n");
>> -pdata->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>> -}
>> -
>>  return pdata;
>>  }
>>
>>
> 
> 

Re: [PATCH 2/2] mmc: dw_mmc: remove the deprecated "supports-highspeed" property

[Jaehoon Chung]

Hi Shawn,

On 07/29/2016 11:44 AM, Shawn Lin wrote:
> 在 2016/7/28 17:55, Jaehoon Chung 写道:
>> Remvoe the deprecated "supports-highspeed" property.
>> DWMMC controller will not use this property anymore.
>>
> 
> We had set up a flag day to remove these deprecated property
> long time agao.
> 
> It doesn't *break* old dtb which may(not ?) still boot up new
> kernel code as we just make it suffer from lower speed, then
> I think it's time for them to migrate to the new property anyway.

Thanks for reviewing!

Best Regards,
Jaehoon Chung

> 
> So,
> 
> Reviewed-by: Shawn Lin 
> 
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 5 -
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1b719a6..e9faedd 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2890,11 +2890,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
>> dw_mci *host)
>>  return ERR_PTR(ret);
>>  }
>>
>> -if (of_find_property(np, "supports-highspeed", NULL)) {
>> -dev_info(dev, "supports-highspeed property is deprecated.\n");
>> -pdata->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>> -}
>> -
>>  return pdata;
>>  }
>>
>>
> 
> 

Re: [PATCH] mm: move swap-in anonymous page into active list

[Minchan Kim]

On Fri, Jul 29, 2016 at 12:25:40PM +0900, Minchan Kim wrote:
> Every swap-in anonymous page starts from inactive lru list's head.
> It should be activated unconditionally when VM decide to reclaim
> because page table entry for the page always usually has marked
> accessed bit. Thus, their window size for getting a new referece
> is 2 * NR_inactive + NR_active while others is NR_active + NR_active.

 NR_inactive

typo

Re: [PATCH] mm: move swap-in anonymous page into active list

[Minchan Kim]

On Fri, Jul 29, 2016 at 12:25:40PM +0900, Minchan Kim wrote:
> Every swap-in anonymous page starts from inactive lru list's head.
> It should be activated unconditionally when VM decide to reclaim
> because page table entry for the page always usually has marked
> accessed bit. Thus, their window size for getting a new referece
> is 2 * NR_inactive + NR_active while others is NR_active + NR_active.

 NR_inactive

typo

[PATCH] mm: move swap-in anonymous page into active list

[Minchan Kim]

Every swap-in anonymous page starts from inactive lru list's head.
It should be activated unconditionally when VM decide to reclaim
because page table entry for the page always usually has marked
accessed bit. Thus, their window size for getting a new referece
is 2 * NR_inactive + NR_active while others is NR_active + NR_active.

It's not fair that it has more chance to be referenced compared
to other newly allocated page which starts from active lru list's
head.

Signed-off-by: Minchan Kim 
---
 mm/memory.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/memory.c b/mm/memory.c
index 4425b6059339..3a730b920242 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2642,6 +2642,7 @@ int do_swap_page(struct fault_env *fe, pte_t orig_pte)
if (page == swapcache) {
do_page_add_anon_rmap(page, vma, fe->address, exclusive);
mem_cgroup_commit_charge(page, memcg, true, false);
+   activate_page(page);
} else { /* ksm created a completely new copy */
page_add_new_anon_rmap(page, vma, fe->address, false);
mem_cgroup_commit_charge(page, memcg, false, false);
-- 
1.9.1

[PATCH] mm: move swap-in anonymous page into active list

[Minchan Kim]

Every swap-in anonymous page starts from inactive lru list's head.
It should be activated unconditionally when VM decide to reclaim
because page table entry for the page always usually has marked
accessed bit. Thus, their window size for getting a new referece
is 2 * NR_inactive + NR_active while others is NR_active + NR_active.

It's not fair that it has more chance to be referenced compared
to other newly allocated page which starts from active lru list's
head.

Signed-off-by: Minchan Kim 
---
 mm/memory.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/memory.c b/mm/memory.c
index 4425b6059339..3a730b920242 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2642,6 +2642,7 @@ int do_swap_page(struct fault_env *fe, pte_t orig_pte)
if (page == swapcache) {
do_page_add_anon_rmap(page, vma, fe->address, exclusive);
mem_cgroup_commit_charge(page, memcg, true, false);
+   activate_page(page);
} else { /* ksm created a completely new copy */
page_add_new_anon_rmap(page, vma, fe->address, false);
mem_cgroup_commit_charge(page, memcg, false, false);
-- 
1.9.1

Build failure in linux mainline when building arcv2 images

[Guenter Roeck]

Hi Vineet,

Mainline fails to build arcv2 images with the following error.

{standard input}: Assembler messages:
{standard input}:19174: Error: Instruction with long immediate data in delay 
slot
make[2]: *** [block/cfq-iosched.o] Error 1

Bisect points to commit 9a7f38c42c2 ("cfq-iosched: Convert from jiffies to 
nanoseconds"),
but I don't really hold it responsible. It looks more like a compiler / 
binutils problem
to me.

I am using a toolchain built with buildroot (gcc 4.8.3). Is there a more recent 
toolchain
than the one in buildroot available, by any chance ? If yes, where do I find it 
?

Thanks,
Guenter

[PATCH 1/2] Documentation: kdump: update maxcpus to nr_cpus

[Zhou Wenjian]

Parameter nr_cpus is used to bring up a SMP dump-capture kernel,
instead of the old parameter maxcpus. This commit update it in
Documentation/kdump/kdump.txt.

Signed-off-by: Zhou Wenjian 
---
 Documentation/kdump/kdump.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..9a77247 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -392,7 +392,7 @@ Notes on loading the dump-capture kernel:
 
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
-  kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  kernel or specify nr_cpus=1 option while loading dump-capture kernel.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
1.8.3.1

[PATCH 2/2] Documentation: kdump: add description of bringing up SMP dump-capture kernel

[Zhou Wenjian]

SMP dump-capture kernel is useful to improve the performance of kdump in
some cases. So add the description of bringing up SMP dump-capture kernel.

Signed-off-by: Zhou Wenjian 
---
 Documentation/kdump/kdump.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 9a77247..155a63c 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify nr_cpus=1 option while loading dump-capture kernel.
 
+* We should bring up a SMP dump-capture kernel if we intend to use 
multi-threads
+  programs with it, such as parallel dump feature of makedumpfile. Otherwise,
+  the multi-threads program may have a great performance degradation.
+  To bring up a SMP dump-capture kernel, we should specify nr_cpus=[X] and
+  disable_cpu_apic=[Y] options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
1.8.3.1

[PATCH 1/2] Documentation: kdump: update maxcpus to nr_cpus

[Zhou Wenjian]

Parameter nr_cpus is used to bring up a SMP dump-capture kernel,
instead of the old parameter maxcpus. This commit update it in
Documentation/kdump/kdump.txt.

Signed-off-by: Zhou Wenjian 
---
 Documentation/kdump/kdump.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..9a77247 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -392,7 +392,7 @@ Notes on loading the dump-capture kernel:
 
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
-  kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  kernel or specify nr_cpus=1 option while loading dump-capture kernel.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
1.8.3.1

[PATCH 2/2] Documentation: kdump: add description of bringing up SMP dump-capture kernel

[Zhou Wenjian]

SMP dump-capture kernel is useful to improve the performance of kdump in
some cases. So add the description of bringing up SMP dump-capture kernel.

Signed-off-by: Zhou Wenjian 
---
 Documentation/kdump/kdump.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 9a77247..155a63c 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify nr_cpus=1 option while loading dump-capture kernel.
 
+* We should bring up a SMP dump-capture kernel if we intend to use 
multi-threads
+  programs with it, such as parallel dump feature of makedumpfile. Otherwise,
+  the multi-threads program may have a great performance degradation.
+  To bring up a SMP dump-capture kernel, we should specify nr_cpus=[X] and
+  disable_cpu_apic=[Y] options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
1.8.3.1

Build failure in linux mainline when building arcv2 images

[Guenter Roeck]

Hi Vineet,

Mainline fails to build arcv2 images with the following error.

{standard input}: Assembler messages:
{standard input}:19174: Error: Instruction with long immediate data in delay 
slot
make[2]: *** [block/cfq-iosched.o] Error 1

Bisect points to commit 9a7f38c42c2 ("cfq-iosched: Convert from jiffies to 
nanoseconds"),
but I don't really hold it responsible. It looks more like a compiler / 
binutils problem
to me.

I am using a toolchain built with buildroot (gcc 4.8.3). Is there a more recent 
toolchain
than the one in buildroot available, by any chance ? If yes, where do I find it 
?

Thanks,
Guenter

[PATCH v5] virtio: new feature to detect IOMMU device quirk

[Michael S. Tsirkin]

The interaction between virtio and IOMMUs is messy.

On most systems with virtio, physical addresses match bus addresses,
and it doesn't particularly matter which one we use to program
the device.

On some systems, including Xen and any system with a physical device
that speaks virtio behind a physical IOMMU, we must program the IOMMU
for virtio DMA to work at all.

On other systems, including SPARC and PPC64, virtio-pci devices are
enumerated as though they are behind an IOMMU, but the virtio host
ignores the IOMMU, so we must either pretend that the IOMMU isn't
there or somehow map everything as the identity.

Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.

Any device with this feature bit set to 0 needs a quirk and has to be
passed physical addresses (as opposed to bus addresses) even though
the device is behind an IOMMU.

Note: it has to be a per-device quirk because for example, there could
be a mix of passed-through and virtual virtio devices. As another
example, some devices could be implemented by an out of process
hypervisor backend (in case of qemu vhost, or vhost-user) and so support
for an IOMMU needs to be coded up separately.

It would be cleanest to handle this in IOMMU core code, but that needs
per-device DMA ops. While we are waiting for that to be implemented, use
a work-around in virtio core.

Note: a "noiommu" feature is a quirk - add a wrapper to make
that clear.

Signed-off-by: Michael S. Tsirkin 
---

Changes from v4:
Clarify that iommu quirk is the feature, even though we use
register value 0 to detect this (for compatibility).

Changes from v3:
In response to Christoph's comments, add TODO so we remember to
move this into DMA core.  Definitely something we want to do but doesn't
seem practical for this release cycle.


 include/linux/virtio_config.h  | 13 +
 include/uapi/linux/virtio_config.h | 10 +-
 drivers/virtio/virtio_ring.c   | 15 ++-
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 6e6cb0c..26c155b 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -149,6 +149,19 @@ static inline bool virtio_has_feature(const struct 
virtio_device *vdev,
return __virtio_test_bit(vdev, fbit);
 }
 
+/**
+ * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * @vdev: the device
+ */
+static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+{
+   /*
+* Note the reverse polarity of the quirk feature (compared to most
+* other features), this is for compatibility with legacy systems.
+*/
+   return !virtio_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
+}
+
 static inline
 struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev,
vq_callback_t *c, const char *n)
diff --git a/include/uapi/linux/virtio_config.h 
b/include/uapi/linux/virtio_config.h
index 4cb65bb..308e209 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -49,7 +49,7 @@
  * transport being used (eg. virtio_ring), the rest are per-device feature
  * bits. */
 #define VIRTIO_TRANSPORT_F_START   28
-#define VIRTIO_TRANSPORT_F_END 33
+#define VIRTIO_TRANSPORT_F_END 34
 
 #ifndef VIRTIO_CONFIG_NO_LEGACY
 /* Do we get callbacks when the ring is completely used, even if we've
@@ -63,4 +63,12 @@
 /* v1.0 compliant. */
 #define VIRTIO_F_VERSION_1 32
 
+/*
+ * If clear - device has the IOMMU bypass quirk feature.
+ * If set - use platform tools to detect the IOMMU.
+ *
+ * Note the reverse polarity (compared to most other features),
+ * this is for compatibility with legacy systems.
+ */
+#define VIRTIO_F_IOMMU_PLATFORM33
 #endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index ca6bfdd..114a0c8 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -117,7 +117,10 @@ struct vring_virtqueue {
 #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
 
 /*
- * The interaction between virtio and a possible IOMMU is a mess.
+ * Modern virtio devices have feature bits to specify whether they need a
+ * quirk and bypass the IOMMU. If not there, just use the DMA API.
+ *
+ * If there, the interaction between virtio and DMA API is messy.
  *
  * On most systems with virtio, physical addresses match bus addresses,
  * and it doesn't particularly matter whether we use the DMA API.
@@ -133,10 +136,18 @@ struct vring_virtqueue {
  *
  * For the time being, we preserve historic behavior and bypass the DMA
  * API.
+ *
+ * TODO: install a per-device DMA ops structure that does the right thing
+ * taking into account all the above quirks, and use the DMA API
+ * unconditionally on data path.
  */
 
 static bool 

[PATCH v5] virtio: new feature to detect IOMMU device quirk

[Michael S. Tsirkin]

The interaction between virtio and IOMMUs is messy.

On most systems with virtio, physical addresses match bus addresses,
and it doesn't particularly matter which one we use to program
the device.

On some systems, including Xen and any system with a physical device
that speaks virtio behind a physical IOMMU, we must program the IOMMU
for virtio DMA to work at all.

On other systems, including SPARC and PPC64, virtio-pci devices are
enumerated as though they are behind an IOMMU, but the virtio host
ignores the IOMMU, so we must either pretend that the IOMMU isn't
there or somehow map everything as the identity.

Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.

Any device with this feature bit set to 0 needs a quirk and has to be
passed physical addresses (as opposed to bus addresses) even though
the device is behind an IOMMU.

Note: it has to be a per-device quirk because for example, there could
be a mix of passed-through and virtual virtio devices. As another
example, some devices could be implemented by an out of process
hypervisor backend (in case of qemu vhost, or vhost-user) and so support
for an IOMMU needs to be coded up separately.

It would be cleanest to handle this in IOMMU core code, but that needs
per-device DMA ops. While we are waiting for that to be implemented, use
a work-around in virtio core.

Note: a "noiommu" feature is a quirk - add a wrapper to make
that clear.

Signed-off-by: Michael S. Tsirkin 
---

Changes from v4:
Clarify that iommu quirk is the feature, even though we use
register value 0 to detect this (for compatibility).

Changes from v3:
In response to Christoph's comments, add TODO so we remember to
move this into DMA core.  Definitely something we want to do but doesn't
seem practical for this release cycle.


 include/linux/virtio_config.h  | 13 +
 include/uapi/linux/virtio_config.h | 10 +-
 drivers/virtio/virtio_ring.c   | 15 ++-
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 6e6cb0c..26c155b 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -149,6 +149,19 @@ static inline bool virtio_has_feature(const struct 
virtio_device *vdev,
return __virtio_test_bit(vdev, fbit);
 }
 
+/**
+ * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * @vdev: the device
+ */
+static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+{
+   /*
+* Note the reverse polarity of the quirk feature (compared to most
+* other features), this is for compatibility with legacy systems.
+*/
+   return !virtio_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
+}
+
 static inline
 struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev,
vq_callback_t *c, const char *n)
diff --git a/include/uapi/linux/virtio_config.h 
b/include/uapi/linux/virtio_config.h
index 4cb65bb..308e209 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -49,7 +49,7 @@
  * transport being used (eg. virtio_ring), the rest are per-device feature
  * bits. */
 #define VIRTIO_TRANSPORT_F_START   28
-#define VIRTIO_TRANSPORT_F_END 33
+#define VIRTIO_TRANSPORT_F_END 34
 
 #ifndef VIRTIO_CONFIG_NO_LEGACY
 /* Do we get callbacks when the ring is completely used, even if we've
@@ -63,4 +63,12 @@
 /* v1.0 compliant. */
 #define VIRTIO_F_VERSION_1 32
 
+/*
+ * If clear - device has the IOMMU bypass quirk feature.
+ * If set - use platform tools to detect the IOMMU.
+ *
+ * Note the reverse polarity (compared to most other features),
+ * this is for compatibility with legacy systems.
+ */
+#define VIRTIO_F_IOMMU_PLATFORM33
 #endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index ca6bfdd..114a0c8 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -117,7 +117,10 @@ struct vring_virtqueue {
 #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
 
 /*
- * The interaction between virtio and a possible IOMMU is a mess.
+ * Modern virtio devices have feature bits to specify whether they need a
+ * quirk and bypass the IOMMU. If not there, just use the DMA API.
+ *
+ * If there, the interaction between virtio and DMA API is messy.
  *
  * On most systems with virtio, physical addresses match bus addresses,
  * and it doesn't particularly matter whether we use the DMA API.
@@ -133,10 +136,18 @@ struct vring_virtqueue {
  *
  * For the time being, we preserve historic behavior and bypass the DMA
  * API.
+ *
+ * TODO: install a per-device DMA ops structure that does the right thing
+ * taking into account all the above quirks, and use the DMA API
+ * unconditionally on data path.
  */
 
 static bool vring_use_dma_api(struct 

Re: [PATCH v3 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

On Thu, Jul 28, 2016 at 05:17:06PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 28, 2016 at 04:01:41PM -0700, Dmitry Torokhov wrote:
> 
> > > + u8 tx_buf[MAX_SPI_FRAMESIZE];
> > > + u8 rx_buf[MAX_SPI_FRAMESIZE];
> > 
> > Both of these need to be annotated as "cacheline_aligned" since we
> > eye them for use in DMA transfers.
> 
> Huh. That sure looks true to me..
> 
> We make that same mistake in all other tpm SPI drivers.
> 
> Can someone send a patch please?
> 

Just did.

Thanks,
Andrey

Re: [PATCH v3 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

On Thu, Jul 28, 2016 at 05:17:06PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 28, 2016 at 04:01:41PM -0700, Dmitry Torokhov wrote:
> 
> > > + u8 tx_buf[MAX_SPI_FRAMESIZE];
> > > + u8 rx_buf[MAX_SPI_FRAMESIZE];
> > 
> > Both of these need to be annotated as "cacheline_aligned" since we
> > eye them for use in DMA transfers.
> 
> Huh. That sure looks true to me..
> 
> We make that same mistake in all other tpm SPI drivers.
> 
> Can someone send a patch please?
> 

Just did.

Thanks,
Andrey

[PATCH] tpm: fix cacheline alignment for DMA-able buffers

[Andrey Pronin]

Annotate buffers used in spi transactions as cacheline_aligned
to use in DMA transfers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/st33zp24/spi.c | 4 ++--
 drivers/char/tpm/tpm_tis_spi.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/st33zp24/spi.c b/drivers/char/tpm/st33zp24/spi.c
index 9f5a011..0e9aad9 100644
--- a/drivers/char/tpm/st33zp24/spi.c
+++ b/drivers/char/tpm/st33zp24/spi.c
@@ -70,8 +70,8 @@
 struct st33zp24_spi_phy {
struct spi_device *spi_device;
 
-   u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE];
-   u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE];
+   u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE] cacheline_aligned;
+   u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE] cacheline_aligned;
 
int io_lpcpd;
int latency;
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index dbaad9c..58d7758 100644
--- a/drivers/char/tpm/tpm_tis_spi.c
+++ b/drivers/char/tpm/tpm_tis_spi.c
@@ -48,8 +48,8 @@ struct tpm_tis_spi_phy {
struct tpm_tis_data priv;
struct spi_device *spi_device;
 
-   u8 tx_buf[MAX_SPI_FRAMESIZE + 4];
-   u8 rx_buf[MAX_SPI_FRAMESIZE + 4];
+   u8 tx_buf[MAX_SPI_FRAMESIZE + 4] cacheline_aligned;
+   u8 rx_buf[MAX_SPI_FRAMESIZE + 4] cacheline_aligned;
 };
 
 static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data 
*data)
-- 
2.6.6

[PATCH] tpm: fix cacheline alignment for DMA-able buffers

[Andrey Pronin]

Annotate buffers used in spi transactions as cacheline_aligned
to use in DMA transfers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/st33zp24/spi.c | 4 ++--
 drivers/char/tpm/tpm_tis_spi.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/st33zp24/spi.c b/drivers/char/tpm/st33zp24/spi.c
index 9f5a011..0e9aad9 100644
--- a/drivers/char/tpm/st33zp24/spi.c
+++ b/drivers/char/tpm/st33zp24/spi.c
@@ -70,8 +70,8 @@
 struct st33zp24_spi_phy {
struct spi_device *spi_device;
 
-   u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE];
-   u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE];
+   u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE] cacheline_aligned;
+   u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE] cacheline_aligned;
 
int io_lpcpd;
int latency;
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index dbaad9c..58d7758 100644
--- a/drivers/char/tpm/tpm_tis_spi.c
+++ b/drivers/char/tpm/tpm_tis_spi.c
@@ -48,8 +48,8 @@ struct tpm_tis_spi_phy {
struct tpm_tis_data priv;
struct spi_device *spi_device;
 
-   u8 tx_buf[MAX_SPI_FRAMESIZE + 4];
-   u8 rx_buf[MAX_SPI_FRAMESIZE + 4];
+   u8 tx_buf[MAX_SPI_FRAMESIZE + 4] cacheline_aligned;
+   u8 rx_buf[MAX_SPI_FRAMESIZE + 4] cacheline_aligned;
 };
 
 static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data 
*data)
-- 
2.6.6

Re: [RFC] can we use vmalloc to alloc thread stack if compaction failed

[Joonsoo Kim]

On Thu, Jul 28, 2016 at 08:07:51AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 28, 2016 at 3:51 AM, Xishi Qiu  wrote:
> > On 2016/7/28 17:43, Michal Hocko wrote:
> >
> >> On Thu 28-07-16 16:45:06, Xishi Qiu wrote:
> >>> On 2016/7/28 15:58, Michal Hocko wrote:
> >>>
>  On Thu 28-07-16 15:41:53, Xishi Qiu wrote:
> > On 2016/7/28 15:20, Michal Hocko wrote:
> >
> >> On Thu 28-07-16 15:08:26, Xishi Qiu wrote:
> >>> Usually THREAD_SIZE_ORDER is 2, it means we need to alloc 16kb 
> >>> continuous
> >>> physical memory during fork a new process.
> >>>
> >>> If the system's memory is very small, especially the smart phone, 
> >>> maybe there
> >>> is only 1G memory. So the free memory is very small and compaction is 
> >>> not
> >>> always success in slowpath(__alloc_pages_slowpath), then alloc thread 
> >>> stack
> >>> may be failed for memory fragment.
> >>
> >> Well, with the current implementation of the page allocator those
> >> requests will not fail in most cases. The oom killer would be invoked 
> >> in
> >> order to free up some memory.
> >>
> >
> > Hi Michal,
> >
> > Yes, it success in most cases, but I did have seen this problem in some
> > stress-test.
> >
> > DMA free:470628kB, but alloc 2 order block failed during fork a new 
> > process.
> > There are so many memory fragments and the large block may be soon 
> > taken by
> > others after compact because of stress-test.
> >
> > --- dmesg messages ---
> > 07-13 08:41:51.341 
> > <4>[309805.658142s][pid:1361,cpu5,sManagerService]sManagerService: page 
> > allocation failure: order:2, mode:0x2000d1
> 
>  Yes but this is __GFP_DMA allocation. I guess you have already reported
>  this failure and you've been told that this is quite unexpected for the
>  kernel stack allocation. It is your out-of-tree patch which just makes
>  things worse because DMA restricted allocations are considered "lowmem"
>  and so they do not invoke OOM killer and do not retry like regular
>  GFP_KERNEL allocations.
> >>>
> >>> Hi Michal,
> >>>
> >>> Yes, we add GFP_DMA, but I don't think this is the key for the problem.
> >>
> >> You are restricting the allocation request to a single zone which is
> >> definitely not good. Look at how many larger order pages are available
> >> in the Normal zone.
> >>
> >>> If we do oom-killer, maybe we will get a large block later, but there
> >>> is enough free memory before oom(although most of them are fragments).
> >>
> >> Killing a task is of course the last resort action. It would give you
> >> larger order blocks used for the victims thread.
> >>
> >>> I wonder if we can alloc success without kill any process in this 
> >>> situation.
> >>
> >> Sure it would be preferable to compact that memory but that might be
> >> hard with your restriction in place. Consider that DMA zone would tend
> >> to be less movable than normal zones as users would have to pin it for
> >> DMA. Your DMA is really large so this might turn out to just happen to
> >> work but note that the primary problem here is that you put a zone
> >> restriction for your allocations.
> >>
> >>> Maybe use vmalloc is a good way, but I don't know the influence.
> >>
> >> You can have a look at vmalloc patches posted by Andy. They are not that
> >> trivial.
> >>
> >
> > Hi Michal,
> >
> > Thank you for your comment, could you give me the link?
> >
> 
> I've been keeping it mostly up to date in this branch:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/vmap_stack
> 
> It's currently out of sync due to a bunch of the patches being queued
> elsewhere for the merge window.

Hello, Andy.

I have some questions about it.

IIUC, to turn on HAVE_ARCH_VMAP_STACK on different architecture, there
is nothing to be done in architecture side if the architecture doesn't
support lazily faults in top-level paging entries for the vmalloc
area. Is my understanding is correct?

And, I'd like to know how you search problematic places using kernel
stack for DMA.

One note is that, stack overflow happens at the previous page of the
stack end position if stack grows down, but, guard page is placed at
the next page of the stack begin position. So, this stack overflow
detection depends on the fact that previous vmalloc-ed area is allocated
without VM_NO_GUARD. There isn't many users for this flag so there
would be no problem but just note.

Thanks.

Re: [RFC] can we use vmalloc to alloc thread stack if compaction failed

[Joonsoo Kim]

On Thu, Jul 28, 2016 at 08:07:51AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 28, 2016 at 3:51 AM, Xishi Qiu  wrote:
> > On 2016/7/28 17:43, Michal Hocko wrote:
> >
> >> On Thu 28-07-16 16:45:06, Xishi Qiu wrote:
> >>> On 2016/7/28 15:58, Michal Hocko wrote:
> >>>
>  On Thu 28-07-16 15:41:53, Xishi Qiu wrote:
> > On 2016/7/28 15:20, Michal Hocko wrote:
> >
> >> On Thu 28-07-16 15:08:26, Xishi Qiu wrote:
> >>> Usually THREAD_SIZE_ORDER is 2, it means we need to alloc 16kb 
> >>> continuous
> >>> physical memory during fork a new process.
> >>>
> >>> If the system's memory is very small, especially the smart phone, 
> >>> maybe there
> >>> is only 1G memory. So the free memory is very small and compaction is 
> >>> not
> >>> always success in slowpath(__alloc_pages_slowpath), then alloc thread 
> >>> stack
> >>> may be failed for memory fragment.
> >>
> >> Well, with the current implementation of the page allocator those
> >> requests will not fail in most cases. The oom killer would be invoked 
> >> in
> >> order to free up some memory.
> >>
> >
> > Hi Michal,
> >
> > Yes, it success in most cases, but I did have seen this problem in some
> > stress-test.
> >
> > DMA free:470628kB, but alloc 2 order block failed during fork a new 
> > process.
> > There are so many memory fragments and the large block may be soon 
> > taken by
> > others after compact because of stress-test.
> >
> > --- dmesg messages ---
> > 07-13 08:41:51.341 
> > <4>[309805.658142s][pid:1361,cpu5,sManagerService]sManagerService: page 
> > allocation failure: order:2, mode:0x2000d1
> 
>  Yes but this is __GFP_DMA allocation. I guess you have already reported
>  this failure and you've been told that this is quite unexpected for the
>  kernel stack allocation. It is your out-of-tree patch which just makes
>  things worse because DMA restricted allocations are considered "lowmem"
>  and so they do not invoke OOM killer and do not retry like regular
>  GFP_KERNEL allocations.
> >>>
> >>> Hi Michal,
> >>>
> >>> Yes, we add GFP_DMA, but I don't think this is the key for the problem.
> >>
> >> You are restricting the allocation request to a single zone which is
> >> definitely not good. Look at how many larger order pages are available
> >> in the Normal zone.
> >>
> >>> If we do oom-killer, maybe we will get a large block later, but there
> >>> is enough free memory before oom(although most of them are fragments).
> >>
> >> Killing a task is of course the last resort action. It would give you
> >> larger order blocks used for the victims thread.
> >>
> >>> I wonder if we can alloc success without kill any process in this 
> >>> situation.
> >>
> >> Sure it would be preferable to compact that memory but that might be
> >> hard with your restriction in place. Consider that DMA zone would tend
> >> to be less movable than normal zones as users would have to pin it for
> >> DMA. Your DMA is really large so this might turn out to just happen to
> >> work but note that the primary problem here is that you put a zone
> >> restriction for your allocations.
> >>
> >>> Maybe use vmalloc is a good way, but I don't know the influence.
> >>
> >> You can have a look at vmalloc patches posted by Andy. They are not that
> >> trivial.
> >>
> >
> > Hi Michal,
> >
> > Thank you for your comment, could you give me the link?
> >
> 
> I've been keeping it mostly up to date in this branch:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/vmap_stack
> 
> It's currently out of sync due to a bunch of the patches being queued
> elsewhere for the merge window.

Hello, Andy.

I have some questions about it.

IIUC, to turn on HAVE_ARCH_VMAP_STACK on different architecture, there
is nothing to be done in architecture side if the architecture doesn't
support lazily faults in top-level paging entries for the vmalloc
area. Is my understanding is correct?

And, I'd like to know how you search problematic places using kernel
stack for DMA.

One note is that, stack overflow happens at the previous page of the
stack end position if stack grows down, but, guard page is placed at
the next page of the stack begin position. So, this stack overflow
detection depends on the fact that previous vmalloc-ed area is allocated
without VM_NO_GUARD. There isn't many users for this flag so there
would be no problem but just note.

Thanks.

[PATCH v8 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Shawn Lin]

This patch adds a binding that describes the Rockchip PCIe controller
found on Rockchip SoCs PCIe interface.

Signed-off-by: Shawn Lin 

Acked-by: Rob Herring 
Reviewed-by: Brian Norris 
---

Changes in v8:
- add Brian's review-tag

Changes in v7:
- move optional properties ahead of interrupt subnode
- use 0-base index for INTx

Changes in v6:
- add ack tag from Rob

Changes in v5:
- fix wrong example reported by Marc
- add seperate section to describe the interrupt controller child
  node

Changes in v4:
- fix example of adding intermediate interrupt controller for pcie
  legacy interrrupt

Changes in v3:
- fix example dts code suggested by Rob and Marc
- remove driver's behaviour of regulator

Changes in v2:
- fix lots clk/reset stuff suggested by Heiko
- remove msi-parent and add msi-map suggested by Marc
- drop phy related stuff
- some others minor fixes

 .../devicetree/bindings/pci/rockchip-pcie.txt  | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
new file mode 100644
index 000..3f74c87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -0,0 +1,106 @@
+* Rockchip AXI PCIe Root Port Bridge DT description
+
+Required properties:
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- compatible: Should contain "rockchip,rk3399-pcie"
+- reg: Two register ranges as listed in the reg-names property
+- reg-names: Must include the following names
+   - "axi-base"
+   - "apb-base"
+- clocks: Must contain an entry for each entry in clock-names.
+   See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+   - "aclk"
+   - "aclk-perf"
+   - "hclk"
+   - "pm"
+- msi-map: Maps a Requester ID to an MSI controller and associated.
+   See ./pci-msi.txt
+- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
+- phy-names:  MUST be "pcie-phy".
+- interrupts: Three interrupt entries must be specified.
+- interrupt-names: Must include the following names
+   - "sys"
+   - "legacy"
+   - "client"
+- resets: Must contain five entries for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following names
+   - "core"
+   - "mgmt"
+   - "mgmt-sticky"
+   - "pipe"
+- pinctrl-names : The pin control state names
+- pinctrl-0: The "default" pinctrl state
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- interrupt-map-mask and interrupt-map: standard PCI properties
+
+Optional Property:
+- ep-gpios: contain the entry for pre-reset gpio
+- num-lanes: number of lanes to use
+- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie.
+- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie.
+- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie.
+
+*Interrupt controller child node*
+The core controller provides a single interrupt for legacy INTx. The pcie node
+should contain an interrupt controller node as a target for the PCI
+'interrupt-map' property. This node represents the domain at which the four
+INTx interrupts are decoded and routed.
+
+
+Required properties for Interrupt controller child node:
+- interrupt-controller: identifies the node as an interrupt controller
+- #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+
+Example:
+
+pcie0: pcie@f800 {
+   compatible = "rockchip,rk3399-pcie";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   clocks = < ACLK_PCIE>, < ACLK_PERF_PCIE>,
+< PCLK_PCIE>, < SCLK_PCIE_PM>;
+   clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+   bus-range = <0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "sys", "legacy", "client";
+   assigned-clocks = < SCLK_PCIEPHY_REF>;
+   assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
+   assigned-clock-rates = <1>;
+   ep-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   ranges = <0x8300 0x0 0xfa00 0x0 0xfa00 0x0 0x60
+ 0x8100 0x0 0xfa60 0x0 0xfa60 0x0 0x10>;
+   num-lanes = <4>;
+   msi-map = <0x0  0x0 0x1000>;
+   reg = <0x0 0xf800 0x0 0x200>, <0x0 0xfd00 0x0 

[PATCH v8 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

[Shawn Lin]

This patch adds Rockchip PCIe controller support found
on RK3399 Soc platform.

Signed-off-by: Shawn Lin 

Reviewed-by: Brian Norris 
---

Changes in v8:
- fix all the comments suggested by Bjorn Helgaas in v7[1]
  [1] https://patchwork.kernel.org/patch/9233887/
- enable bandwith interrupt for debug

Changes in v7:
- make it as a build-in driver
- improve gen1/2 training timeout checking
- only clear known interrupt
- fix INTx for 0-base index

Changes in v6:
- use "depends on PCI_MSI_IRQ_DOMAIN" suggested by Arnd

Changes in v5:
- handle multiple pending INTx at the same time
  suggested by Marc

Changes in v4:
- address the comments from Brain

Changes in v3:
- remove header file
- remove struct msi_controller and move most of variables
  of rockchip_pcie_port to become the local ones.
- allow legacy int even if enabling MSI
- drop regulator set voltage operation suggested by Doug

Changes in v2:
- remove phy related stuff and call phy API
- add new head file and define lots of macro to make
  the code more readable
- remove lots msi related code suggested by Marc
- add IO window address translation
- init_port and parse_dt reconstruction suggested by Bharat
- improve wr_own_conf suggested by Arnd
- make pcie as an interrupt controller and fix wrong int handler
  suggested by Marc
- remove PCI_PROBE_ONLY suggested by Lorenzo

 drivers/pci/host/Kconfig |   11 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-rockchip.c | 1257 ++
 3 files changed, 1269 insertions(+)
 create mode 100644 drivers/pci/host/pcie-rockchip.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c917e2f..4d714d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -264,4 +264,15 @@ config PCIE_ARTPEC6
  Say Y here to enable PCIe controller support on Axis ARTPEC-6
  SoCs.  This PCIe controller uses the DesignWare core.
 
+config PCIE_ROCKCHIP
+   bool "Rockchip PCIe controller"
+   depends on ARM64 && ARCH_ROCKCHIP
+   depends on OF
+   depends on PCI_MSI_IRQ_DOMAIN
+   select MFD_SYSCON
+   help
+ Say Y here if you want internal PCI support on Rockchip SoC.
+ There is 1 internal PCIe port available to support GEN2 with
+ 4 slots.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 5bc0af2..695f716 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
 obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
 obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
+obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
new file mode 100644
index 000..13ac199
--- /dev/null
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -0,0 +1,1257 @@
+/*
+ * Rockchip AXI PCIe host controller driver
+ *
+ * Copyright (c) 2016 Rockchip, Inc.
+ *
+ * Author: Shawn Lin 
+ * Wenrui Li 
+ *
+ * Bits taken from Synopsys Designware Host controller driver and
+ * ARM PCI Host generic driver.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PCIE_CLIENT_BASE   0x0
+#define PCIE_RC_CONFIG_NORMAL_BASE 0x80
+#define PCIE_RC_CONFIG_BASE0xa0
+#define PCIE_RC_CONFIG_LCSR_OFFSET 0xd0
+#define PCIE_RC_CONFIG_LCSR_BW_ENA 0x1
+#define PCIE_RC_CONFIG_LCSR_LBMIE  BIT(10)
+#define PCIE_RC_CONFIG_LCSR_LABIE  BIT(11)
+#define PCIE_RC_CONFIG_LCSR_LBMS   BIT(30)
+#define PCIE_RC_CONFIG_LCSR_LAMS   BIT(31)
+#define PCIE_CORE_LINK_CTRL_STATUS 0x8000d0
+#define PCIE_CORE_CTRL_MGMT_BASE   0x90
+#define PCIE_CORE_AXI_CONF_BASE0xc0
+#define PCIE_CORE_AXI_INBOUND_BASE 0xc00800
+#define PCIE_CLIENT_BASIC_STATUS0  0x44
+#define PCIE_CLIENT_BASIC_STATUS1  0x48
+#define PCIE_CLIENT_INT_MASK   0x4c
+#define PCIE_CLIENT_INT_STATUS 0x50
+#define PCIE_CLIENT_INT_LEGACY_DONEBIT(15)
+#define PCIE_CLIENT_INT_MSGBIT(14)
+#define PCIE_CLIENT_INT_HOT_RSTBIT(13)
+#define PCIE_CLIENT_INT_DPABIT(12)
+#define PCIE_CLIENT_INT_FATAL_ERR  BIT(11)
+#define PCIE_CLIENT_INT_NFATAL_ERR BIT(10)
+#define 

[PATCH v8 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Shawn Lin]

This patch adds a binding that describes the Rockchip PCIe controller
found on Rockchip SoCs PCIe interface.

Signed-off-by: Shawn Lin 

Acked-by: Rob Herring 
Reviewed-by: Brian Norris 
---

Changes in v8:
- add Brian's review-tag

Changes in v7:
- move optional properties ahead of interrupt subnode
- use 0-base index for INTx

Changes in v6:
- add ack tag from Rob

Changes in v5:
- fix wrong example reported by Marc
- add seperate section to describe the interrupt controller child
  node

Changes in v4:
- fix example of adding intermediate interrupt controller for pcie
  legacy interrrupt

Changes in v3:
- fix example dts code suggested by Rob and Marc
- remove driver's behaviour of regulator

Changes in v2:
- fix lots clk/reset stuff suggested by Heiko
- remove msi-parent and add msi-map suggested by Marc
- drop phy related stuff
- some others minor fixes

 .../devicetree/bindings/pci/rockchip-pcie.txt  | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
new file mode 100644
index 000..3f74c87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -0,0 +1,106 @@
+* Rockchip AXI PCIe Root Port Bridge DT description
+
+Required properties:
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- compatible: Should contain "rockchip,rk3399-pcie"
+- reg: Two register ranges as listed in the reg-names property
+- reg-names: Must include the following names
+   - "axi-base"
+   - "apb-base"
+- clocks: Must contain an entry for each entry in clock-names.
+   See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+   - "aclk"
+   - "aclk-perf"
+   - "hclk"
+   - "pm"
+- msi-map: Maps a Requester ID to an MSI controller and associated.
+   See ./pci-msi.txt
+- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
+- phy-names:  MUST be "pcie-phy".
+- interrupts: Three interrupt entries must be specified.
+- interrupt-names: Must include the following names
+   - "sys"
+   - "legacy"
+   - "client"
+- resets: Must contain five entries for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following names
+   - "core"
+   - "mgmt"
+   - "mgmt-sticky"
+   - "pipe"
+- pinctrl-names : The pin control state names
+- pinctrl-0: The "default" pinctrl state
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- interrupt-map-mask and interrupt-map: standard PCI properties
+
+Optional Property:
+- ep-gpios: contain the entry for pre-reset gpio
+- num-lanes: number of lanes to use
+- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie.
+- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie.
+- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie.
+
+*Interrupt controller child node*
+The core controller provides a single interrupt for legacy INTx. The pcie node
+should contain an interrupt controller node as a target for the PCI
+'interrupt-map' property. This node represents the domain at which the four
+INTx interrupts are decoded and routed.
+
+
+Required properties for Interrupt controller child node:
+- interrupt-controller: identifies the node as an interrupt controller
+- #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+
+Example:
+
+pcie0: pcie@f800 {
+   compatible = "rockchip,rk3399-pcie";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   clocks = < ACLK_PCIE>, < ACLK_PERF_PCIE>,
+< PCLK_PCIE>, < SCLK_PCIE_PM>;
+   clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+   bus-range = <0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "sys", "legacy", "client";
+   assigned-clocks = < SCLK_PCIEPHY_REF>;
+   assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
+   assigned-clock-rates = <1>;
+   ep-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   ranges = <0x8300 0x0 0xfa00 0x0 0xfa00 0x0 0x60
+ 0x8100 0x0 0xfa60 0x0 0xfa60 0x0 0x10>;
+   num-lanes = <4>;
+   msi-map = <0x0  0x0 0x1000>;
+   reg = <0x0 0xf800 0x0 0x200>, <0x0 0xfd00 0x0 0x100>;
+   reg-names = "axi-base", "apb-base";
+   resets = < 

[PATCH v8 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

[Shawn Lin]

This patch adds Rockchip PCIe controller support found
on RK3399 Soc platform.

Signed-off-by: Shawn Lin 

Reviewed-by: Brian Norris 
---

Changes in v8:
- fix all the comments suggested by Bjorn Helgaas in v7[1]
  [1] https://patchwork.kernel.org/patch/9233887/
- enable bandwith interrupt for debug

Changes in v7:
- make it as a build-in driver
- improve gen1/2 training timeout checking
- only clear known interrupt
- fix INTx for 0-base index

Changes in v6:
- use "depends on PCI_MSI_IRQ_DOMAIN" suggested by Arnd

Changes in v5:
- handle multiple pending INTx at the same time
  suggested by Marc

Changes in v4:
- address the comments from Brain

Changes in v3:
- remove header file
- remove struct msi_controller and move most of variables
  of rockchip_pcie_port to become the local ones.
- allow legacy int even if enabling MSI
- drop regulator set voltage operation suggested by Doug

Changes in v2:
- remove phy related stuff and call phy API
- add new head file and define lots of macro to make
  the code more readable
- remove lots msi related code suggested by Marc
- add IO window address translation
- init_port and parse_dt reconstruction suggested by Bharat
- improve wr_own_conf suggested by Arnd
- make pcie as an interrupt controller and fix wrong int handler
  suggested by Marc
- remove PCI_PROBE_ONLY suggested by Lorenzo

 drivers/pci/host/Kconfig |   11 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-rockchip.c | 1257 ++
 3 files changed, 1269 insertions(+)
 create mode 100644 drivers/pci/host/pcie-rockchip.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c917e2f..4d714d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -264,4 +264,15 @@ config PCIE_ARTPEC6
  Say Y here to enable PCIe controller support on Axis ARTPEC-6
  SoCs.  This PCIe controller uses the DesignWare core.
 
+config PCIE_ROCKCHIP
+   bool "Rockchip PCIe controller"
+   depends on ARM64 && ARCH_ROCKCHIP
+   depends on OF
+   depends on PCI_MSI_IRQ_DOMAIN
+   select MFD_SYSCON
+   help
+ Say Y here if you want internal PCI support on Rockchip SoC.
+ There is 1 internal PCIe port available to support GEN2 with
+ 4 slots.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 5bc0af2..695f716 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
 obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
 obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
+obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
new file mode 100644
index 000..13ac199
--- /dev/null
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -0,0 +1,1257 @@
+/*
+ * Rockchip AXI PCIe host controller driver
+ *
+ * Copyright (c) 2016 Rockchip, Inc.
+ *
+ * Author: Shawn Lin 
+ * Wenrui Li 
+ *
+ * Bits taken from Synopsys Designware Host controller driver and
+ * ARM PCI Host generic driver.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PCIE_CLIENT_BASE   0x0
+#define PCIE_RC_CONFIG_NORMAL_BASE 0x80
+#define PCIE_RC_CONFIG_BASE0xa0
+#define PCIE_RC_CONFIG_LCSR_OFFSET 0xd0
+#define PCIE_RC_CONFIG_LCSR_BW_ENA 0x1
+#define PCIE_RC_CONFIG_LCSR_LBMIE  BIT(10)
+#define PCIE_RC_CONFIG_LCSR_LABIE  BIT(11)
+#define PCIE_RC_CONFIG_LCSR_LBMS   BIT(30)
+#define PCIE_RC_CONFIG_LCSR_LAMS   BIT(31)
+#define PCIE_CORE_LINK_CTRL_STATUS 0x8000d0
+#define PCIE_CORE_CTRL_MGMT_BASE   0x90
+#define PCIE_CORE_AXI_CONF_BASE0xc0
+#define PCIE_CORE_AXI_INBOUND_BASE 0xc00800
+#define PCIE_CLIENT_BASIC_STATUS0  0x44
+#define PCIE_CLIENT_BASIC_STATUS1  0x48
+#define PCIE_CLIENT_INT_MASK   0x4c
+#define PCIE_CLIENT_INT_STATUS 0x50
+#define PCIE_CLIENT_INT_LEGACY_DONEBIT(15)
+#define PCIE_CLIENT_INT_MSGBIT(14)
+#define PCIE_CLIENT_INT_HOT_RSTBIT(13)
+#define PCIE_CLIENT_INT_DPABIT(12)
+#define PCIE_CLIENT_INT_FATAL_ERR  BIT(11)
+#define PCIE_CLIENT_INT_NFATAL_ERR BIT(10)
+#define PCIE_CLIENT_INT_CORR_ERR   BIT(9)
+#define PCIE_CLIENT_INT_INTD   BIT(8)
+#define 

Re: [PATCH 2/2] mmc: dw_mmc: remove the deprecated "supports-highspeed" property

[Shawn Lin]

在 2016/7/28 17:55, Jaehoon Chung 写道:

Remvoe the deprecated "supports-highspeed" property.
DWMMC controller will not use this property anymore.



We had set up a flag day to remove these deprecated property
long time agao.

It doesn't *break* old dtb which may(not ?) still boot up new
kernel code as we just make it suffer from lower speed, then
I think it's time for them to migrate to the new property anyway.

So,

Reviewed-by: Shawn Lin 


Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/host/dw_mmc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1b719a6..e9faedd 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2890,11 +2890,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
dw_mci *host)
return ERR_PTR(ret);
}

-   if (of_find_property(np, "supports-highspeed", NULL)) {
-   dev_info(dev, "supports-highspeed property is deprecated.\n");
-   pdata->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
-   }
-
return pdata;
 }





--
Best Regards
Shawn Lin

Re: [PATCH 2/2] mmc: dw_mmc: remove the deprecated "supports-highspeed" property

[Shawn Lin]

在 2016/7/28 17:55, Jaehoon Chung 写道:

Remvoe the deprecated "supports-highspeed" property.
DWMMC controller will not use this property anymore.



We had set up a flag day to remove these deprecated property
long time agao.

It doesn't *break* old dtb which may(not ?) still boot up new
kernel code as we just make it suffer from lower speed, then
I think it's time for them to migrate to the new property anyway.

So,

Reviewed-by: Shawn Lin 


Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/host/dw_mmc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1b719a6..e9faedd 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2890,11 +2890,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
dw_mci *host)
return ERR_PTR(ret);
}

-   if (of_find_property(np, "supports-highspeed", NULL)) {
-   dev_info(dev, "supports-highspeed property is deprecated.\n");
-   pdata->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
-   }
-
return pdata;
 }





--
Best Regards
Shawn Lin

[PATCH] lkdtm: Fix targets for objcopy usage

[Kees Cook]

The targets for lkdtm's objcopy were missing which caused them to always
be rebuilt. This corrects the problem.

Additionally, commit f8fa70f392fa ("arm64: localise Image objcopy flags")
has landed now, so this removes the work-around for the global OBJCOPY
flag setting.

Reported-by: Linus Torvalds 
Signed-off-by: Kees Cook 
---
 drivers/misc/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4387ccb79e64..132f4e3462ba 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -65,9 +65,9 @@ lkdtm-$(CONFIG_LKDTM) += lkdtm_perms.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_rodata_objcopy.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_usercopy.o
 
-OBJCOPYFLAGS :=
 OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
--set-section-flags .text=alloc,readonly \
--rename-section .text=.rodata
-$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o
+targets += lkdtm_rodata.o lkdtm_rodata_objcopy.o
+$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o FORCE
$(call if_changed,objcopy)
-- 
2.7.4


-- 
Kees Cook
Brillo & Chrome OS Security

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Steven Rostedt]

On Thu, 28 Jul 2016 18:25:33 -0700
Linus Torvalds  wrote:

> I tried something like that, but the CFLAGS games the tracing code
> does made my thing result in
> 
>   kernel/trace/Makefile:20: *** Recursive variable 'KBUILD_CFLAGS'
> references itself (eventually).  Stop.
> 
> but yes, if you have the magic fingers to make it work, limiting the
> -Wno-frame-address to just the tracing code sounds like the
> RightThing(tm).

Take 2:

It compiles for me, but I don't have a compiler that has that warning
to test with. See if this works. BTW, it looks like that last comma
before the ending parenthesis is not needed.

Signed-off-by: Steven Rostedt 
---
diff --git a/Makefile b/Makefile
index 393b615..d384848 100644
--- a/Makefile
+++ b/Makefile
@@ -620,7 +620,6 @@ include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 979e7bf..d0a1617 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -1,4 +1,8 @@
 
+# We are fully aware of the dangers of __builtin_return_address()
+FRAME_CFLAGS := $(call cc-disable-warning,frame-address)
+KBUILD_CFLAGS += $(FRAME_CFLAGS)
+
 # Do not instrument the tracer itself:
 
 ifdef CONFIG_FUNCTION_TRACER

[PATCH] lkdtm: Fix targets for objcopy usage

[Kees Cook]

The targets for lkdtm's objcopy were missing which caused them to always
be rebuilt. This corrects the problem.

Additionally, commit f8fa70f392fa ("arm64: localise Image objcopy flags")
has landed now, so this removes the work-around for the global OBJCOPY
flag setting.

Reported-by: Linus Torvalds 
Signed-off-by: Kees Cook 
---
 drivers/misc/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4387ccb79e64..132f4e3462ba 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -65,9 +65,9 @@ lkdtm-$(CONFIG_LKDTM) += lkdtm_perms.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_rodata_objcopy.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_usercopy.o
 
-OBJCOPYFLAGS :=
 OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
--set-section-flags .text=alloc,readonly \
--rename-section .text=.rodata
-$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o
+targets += lkdtm_rodata.o lkdtm_rodata_objcopy.o
+$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o FORCE
$(call if_changed,objcopy)
-- 
2.7.4


-- 
Kees Cook
Brillo & Chrome OS Security

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

[Steven Rostedt]

On Thu, 28 Jul 2016 18:25:33 -0700
Linus Torvalds  wrote:

> I tried something like that, but the CFLAGS games the tracing code
> does made my thing result in
> 
>   kernel/trace/Makefile:20: *** Recursive variable 'KBUILD_CFLAGS'
> references itself (eventually).  Stop.
> 
> but yes, if you have the magic fingers to make it work, limiting the
> -Wno-frame-address to just the tracing code sounds like the
> RightThing(tm).

Take 2:

It compiles for me, but I don't have a compiler that has that warning
to test with. See if this works. BTW, it looks like that last comma
before the ending parenthesis is not needed.

Signed-off-by: Steven Rostedt 
---
diff --git a/Makefile b/Makefile
index 393b615..d384848 100644
--- a/Makefile
+++ b/Makefile
@@ -620,7 +620,6 @@ include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 979e7bf..d0a1617 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -1,4 +1,8 @@
 
+# We are fully aware of the dangers of __builtin_return_address()
+FRAME_CFLAGS := $(call cc-disable-warning,frame-address)
+KBUILD_CFLAGS += $(FRAME_CFLAGS)
+
 # Do not instrument the tracer itself:
 
 ifdef CONFIG_FUNCTION_TRACER

Re: [PATCH] perf sched: fix wrong conversion of task state

[関山友輝 / SEKIYAMA，TOMOKI]

On 2016/07/28 23:26、David Ahern wrote:
>> But that means we cannot handle preemption correctly as far as
>> sched:sched_switch
>> event uses TASK_STATE_MAX to mark preempted tasks.
>> 
>> Should we stop using TASK_STATE_MAX for preempted tasks in ftrace and
>> use (1 << 63) or something that doesn't change on kernel version instead?
> 
> ftrace printing is within the kernel so it has consistency.
Agreed.

> It is the save data and analyze later use case that can not assume 
> TASK_STATE_MAX means preemption since the value of TASK_STATE_MAX is kernel 
> version dependent.

That means we cannot measure delay by preemption using perf sched latency. :(
It might be helpful if the preemption mark becomes kernel-version-independent 
at least for future kernel version..

Anyway, this time I will post the patch to fix only invalid conversion issue of 
task state with this patch.

Thanks,
Tomoki Sekiyama

Re: [PATCH] perf sched: fix wrong conversion of task state

[関山友輝 / SEKIYAMA，TOMOKI]

On 2016/07/28 23:26、David Ahern wrote:
>> But that means we cannot handle preemption correctly as far as
>> sched:sched_switch
>> event uses TASK_STATE_MAX to mark preempted tasks.
>> 
>> Should we stop using TASK_STATE_MAX for preempted tasks in ftrace and
>> use (1 << 63) or something that doesn't change on kernel version instead?
> 
> ftrace printing is within the kernel so it has consistency.
Agreed.

> It is the save data and analyze later use case that can not assume 
> TASK_STATE_MAX means preemption since the value of TASK_STATE_MAX is kernel 
> version dependent.

That means we cannot measure delay by preemption using perf sched latency. :(
It might be helpful if the preemption mark becomes kernel-version-independent 
at least for future kernel version..

Anyway, this time I will post the patch to fix only invalid conversion issue of 
task state with this patch.

Thanks,
Tomoki Sekiyama

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

[Fu Wei]

Hi Suzuki,

On 28 July 2016 at 17:39, Suzuki K Poulose  wrote:
> On 27/07/16 18:29, fu@linaro.org wrote:
>>
>> From: Tomasz Nowicki 
>>
>> This commit provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)add a new subfunction "hest_ia32_init" for
>> "acpi_disable_cmcff" which is used by IA-32 Architecture
>> Corrected Machine Check (CMC).
>> (2)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (3)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>>
>> [Fu Wei: improve && upstream]
>>
>
>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5420cb0..d3d02dc 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* Macros for consistency checks of the GICC subtable of MADT */
>>  #define ACPI_MADT_GICC_LENGTH  \
>> @@ -110,8 +111,21 @@ static inline const char *acpi_get_enable_method(int
>> cpu)
>>  }
>>
>>  #ifdef CONFIG_ACPI_APEI
>> +#define acpi_disable_cmcff 1
>>  pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> -#endif
>> +
>> +/*
>> + * Despite its name, this function must still broadcast the TLB
>> + * invalidation in order to ensure other CPUs don't up with with junk
>
>
> Please fix the comment above ^^^.

Thanks for pointing it out, the fixed patch will out in minutes.

>
>
> Suzuki



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

[Fu Wei]

Hi Suzuki,

On 28 July 2016 at 17:39, Suzuki K Poulose  wrote:
> On 27/07/16 18:29, fu@linaro.org wrote:
>>
>> From: Tomasz Nowicki 
>>
>> This commit provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)add a new subfunction "hest_ia32_init" for
>> "acpi_disable_cmcff" which is used by IA-32 Architecture
>> Corrected Machine Check (CMC).
>> (2)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (3)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>>
>> [Fu Wei: improve && upstream]
>>
>
>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5420cb0..d3d02dc 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* Macros for consistency checks of the GICC subtable of MADT */
>>  #define ACPI_MADT_GICC_LENGTH  \
>> @@ -110,8 +111,21 @@ static inline const char *acpi_get_enable_method(int
>> cpu)
>>  }
>>
>>  #ifdef CONFIG_ACPI_APEI
>> +#define acpi_disable_cmcff 1
>>  pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> -#endif
>> +
>> +/*
>> + * Despite its name, this function must still broadcast the TLB
>> + * invalidation in order to ensure other CPUs don't up with with junk
>
>
> Please fix the comment above ^^^.

Thanks for pointing it out, the fixed patch will out in minutes.

>
>
> Suzuki



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v3 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

On Wed, Jul 20, 2016 at 05:40:24PM +0800, Peter Chen wrote:
> Add binding doc for generic power sequence library.
> 
> Signed-off-by: Peter Chen 
> Acked-by: Philipp Zabel 
> ---
>  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 000..48bb3e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clock for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> + {
> + vbus-supply = <_usb_otg1_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usb_otg1_id>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + genesys: hub@1 {
> + compatible = "usb5e3,608";
> + reg = <1>;
> +
> + clocks = < IMX6SX_CLK_CKO>;
> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> + reset-duration-us = <10>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + asix: ethernet@1 {
> + compatible = "usbb95,1708";
> + reg = <1>;
> +
> + clocks = < IMX6SX_CLK_IPG>;
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
> ethernet_rst */
> + reset-duration-us = <15>;
> + };
> + };
> +};
> -- 
> 1.9.1

Rob, would you please help to ack dts changes in this series if you are
ok with them?

-- 

Best Regards,
Peter Chen

Re: [PATCH v3 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

On Wed, Jul 20, 2016 at 05:40:24PM +0800, Peter Chen wrote:
> Add binding doc for generic power sequence library.
> 
> Signed-off-by: Peter Chen 
> Acked-by: Philipp Zabel 
> ---
>  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 000..48bb3e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clock for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> + {
> + vbus-supply = <_usb_otg1_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usb_otg1_id>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + genesys: hub@1 {
> + compatible = "usb5e3,608";
> + reg = <1>;
> +
> + clocks = < IMX6SX_CLK_CKO>;
> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> + reset-duration-us = <10>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + asix: ethernet@1 {
> + compatible = "usbb95,1708";
> + reg = <1>;
> +
> + clocks = < IMX6SX_CLK_IPG>;
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
> ethernet_rst */
> + reset-duration-us = <15>;
> + };
> + };
> +};
> -- 
> 1.9.1

Rob, would you please help to ack dts changes in this series if you are
ok with them?

-- 

Best Regards,
Peter Chen

Re: [tip:smp/hotplug 5/6] arch/x86/xen/enlighten.c:1522:2: error: implicit declaration of function 'xen_pvh_early_cpu_init'

[Boris Ostrovsky]

On 07/28/2016 12:14 PM, kbuild test robot wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/hotplug
head:   c713c8cb2055f5f3b32ee4315be589177a2658cc
commit: 854e9fa5a56a9771fad4701a427e4844d2cbade1 [5/6] xen/x86: Define stubs 
for xen_smp_intr_init/xen_smp_intr_free
config: x86_64-randconfig-x011-201630 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout 854e9fa5a56a9771fad4701a427e4844d2cbade1
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

   arch/x86/xen/enlighten.c: In function 'xen_pvh_early_guest_init':

arch/x86/xen/enlighten.c:1522:2: error: implicit declaration of function 
'xen_pvh_early_cpu_init' [-Werror=implicit-function-declaration]

 xen_pvh_early_cpu_init(0, false);
 ^~




Thomas,

So I clearly missed the PVH case and I see that the patches were 
reverted from the branch. Do you want me to take them through Xen tree 
so you won't have to deal with breakage?


If yes I will assume your ACK for the second patch
http://marc.info/?i=1458221613-21563-3-git-send-email-boris.ostrovsky%40oracle.com

Sorry about that.

-boris





   cc1: some warnings being treated as errors

vim +/xen_pvh_early_cpu_init +1522 arch/x86/xen/enlighten.c

d285d683 Mukesh Rathor   2013-12-13  1516
c9f6e997 Roger Pau Monne 2014-01-20  1517   if 
(!xen_feature(XENFEAT_hvm_callback_vector))
c9f6e997 Roger Pau Monne 2014-01-20  1518   return;
c9f6e997 Roger Pau Monne 2014-01-20  1519
d285d683 Mukesh Rathor   2013-12-13  1520   xen_have_vector_callback = 1;
a2ef5dc2 Mukesh Rathor   2014-09-10  1521
a2ef5dc2 Mukesh Rathor   2014-09-10 @1522   xen_pvh_early_cpu_init(0, 
false);
c9f6e997 Roger Pau Monne 2014-01-20  1523   xen_pvh_set_cr_flags(0);
d285d683 Mukesh Rathor   2013-12-13  1524
d285d683 Mukesh Rathor   2013-12-13  1525  #ifdef CONFIG_X86_32

:: The code at line 1522 was first introduced by commit
:: a2ef5dc2c7cbedbeb4c847039845afaea5e63745 x86/xen: Set EFER.NX and 
EFER.SCE in PVH guests

:: TO: Mukesh Rathor 
:: CC: David Vrabel 

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

Re: [tip:smp/hotplug 5/6] arch/x86/xen/enlighten.c:1522:2: error: implicit declaration of function 'xen_pvh_early_cpu_init'

[Boris Ostrovsky]

On 07/28/2016 12:14 PM, kbuild test robot wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/hotplug
head:   c713c8cb2055f5f3b32ee4315be589177a2658cc
commit: 854e9fa5a56a9771fad4701a427e4844d2cbade1 [5/6] xen/x86: Define stubs 
for xen_smp_intr_init/xen_smp_intr_free
config: x86_64-randconfig-x011-201630 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout 854e9fa5a56a9771fad4701a427e4844d2cbade1
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

   arch/x86/xen/enlighten.c: In function 'xen_pvh_early_guest_init':

arch/x86/xen/enlighten.c:1522:2: error: implicit declaration of function 
'xen_pvh_early_cpu_init' [-Werror=implicit-function-declaration]

 xen_pvh_early_cpu_init(0, false);
 ^~




Thomas,

So I clearly missed the PVH case and I see that the patches were 
reverted from the branch. Do you want me to take them through Xen tree 
so you won't have to deal with breakage?


If yes I will assume your ACK for the second patch
http://marc.info/?i=1458221613-21563-3-git-send-email-boris.ostrovsky%40oracle.com

Sorry about that.

-boris





   cc1: some warnings being treated as errors

vim +/xen_pvh_early_cpu_init +1522 arch/x86/xen/enlighten.c

d285d683 Mukesh Rathor   2013-12-13  1516
c9f6e997 Roger Pau Monne 2014-01-20  1517   if 
(!xen_feature(XENFEAT_hvm_callback_vector))
c9f6e997 Roger Pau Monne 2014-01-20  1518   return;
c9f6e997 Roger Pau Monne 2014-01-20  1519
d285d683 Mukesh Rathor   2013-12-13  1520   xen_have_vector_callback = 1;
a2ef5dc2 Mukesh Rathor   2014-09-10  1521
a2ef5dc2 Mukesh Rathor   2014-09-10 @1522   xen_pvh_early_cpu_init(0, 
false);
c9f6e997 Roger Pau Monne 2014-01-20  1523   xen_pvh_set_cr_flags(0);
d285d683 Mukesh Rathor   2013-12-13  1524
d285d683 Mukesh Rathor   2013-12-13  1525  #ifdef CONFIG_X86_32

:: The code at line 1522 was first introduced by commit
:: a2ef5dc2c7cbedbeb4c847039845afaea5e63745 x86/xen: Set EFER.NX and 
EFER.SCE in PVH guests

:: TO: Mukesh Rathor 
:: CC: David Vrabel 

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

[PATCH v4 0/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

This patchset adds support for H1 Secure Microcontroller running
Cr50 firmware. It implements several functions, including TPM-like
functionality, and communicates over SPI using the FIFO protocol
described in the PTP Spec, section 6.
H1 is a proprietary chip that the Chrome OS team is investigating
for inclusion in future Chromebooks.

Depends on the following patchset:
 - tpm_tis_core: add optional max xfer size check

v2: Removed driver-specific sysfs attributes.
Compatible id changed to cr50 from cr50_spi.
Updated descriptions of the supported device/interface.

v3: Fixed potential race-condition with last_access_jiffies.
Started using tx_buf/rx_buf in cr50_spi_phy to avoid
potential problems with DMA.
Removed DT properties for fw timing parameters.
Fixed style.

v4: Fixed cacheline alignment for xfer buffers.

Andrey Pronin (2):
  tpm: devicetree: document properties for cr50
  tpm: add driver for cr50 on SPI

 .../devicetree/bindings/security/tpm/cr50_spi.txt  |  21 ++
 drivers/char/tpm/Kconfig   |   9 +
 drivers/char/tpm/Makefile  |   1 +
 drivers/char/tpm/cr50_spi.c| 350 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
 create mode 100644 drivers/char/tpm/cr50_spi.c

-- 
2.6.6

[PATCH v4 0/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

This patchset adds support for H1 Secure Microcontroller running
Cr50 firmware. It implements several functions, including TPM-like
functionality, and communicates over SPI using the FIFO protocol
described in the PTP Spec, section 6.
H1 is a proprietary chip that the Chrome OS team is investigating
for inclusion in future Chromebooks.

Depends on the following patchset:
 - tpm_tis_core: add optional max xfer size check

v2: Removed driver-specific sysfs attributes.
Compatible id changed to cr50 from cr50_spi.
Updated descriptions of the supported device/interface.

v3: Fixed potential race-condition with last_access_jiffies.
Started using tx_buf/rx_buf in cr50_spi_phy to avoid
potential problems with DMA.
Removed DT properties for fw timing parameters.
Fixed style.

v4: Fixed cacheline alignment for xfer buffers.

Andrey Pronin (2):
  tpm: devicetree: document properties for cr50
  tpm: add driver for cr50 on SPI

 .../devicetree/bindings/security/tpm/cr50_spi.txt  |  21 ++
 drivers/char/tpm/Kconfig   |   9 +
 drivers/char/tpm/Makefile  |   1 +
 drivers/char/tpm/cr50_spi.c| 350 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
 create mode 100644 drivers/char/tpm/cr50_spi.c

-- 
2.6.6

[PATCH v4 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware. The firmware running on the currently supported H1
Secure Microcontroller requires a special driver to handle its
specifics:
 - need to ensure a certain delay between spi transactions, or else
   the chip may miss some part of the next transaction;
 - if there is no spi activity for some time, it may go to sleep,
   and needs to be waken up before sending further commands;
 - access to vendor-specific registers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/Kconfig|   9 ++
 drivers/char/tpm/Makefile   |   1 +
 drivers/char/tpm/cr50_spi.c | 350 
 3 files changed, 360 insertions(+)
 create mode 100644 drivers/char/tpm/cr50_spi.c

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1..3320acc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -100,6 +100,15 @@ config TCG_ATMEL
  will be accessible from within Linux.  To compile this driver 
  as a module, choose M here; the module will be called tpm_atmel.
 
+config TCG_CR50_SPI
+   tristate "TCG PTP FIFO Interface over SPI - Chips with Cr50 Firmware"
+   depends on SPI
+   select TCG_TIS_CORE
+   ---help---
+ If you have a chip running Cr50 firmware on SPI bus, say Yes and it
+ will be accessible from within Linux. To compile this driver as a
+ module, choose M here; the module will be called cr50_spi.
+
 config TCG_INFINEON
tristate "Infineon Technologies TPM Interface"
depends on PNP
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a385fb8..b346306 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_TCG_TIS_I2C_INFINEON) += tpm_i2c_infineon.o
 obj-$(CONFIG_TCG_TIS_I2C_NUVOTON) += tpm_i2c_nuvoton.o
 obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
 obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
+obj-$(CONFIG_TCG_CR50_SPI) += cr50_spi.o
 obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
 obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
 obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
diff --git a/drivers/char/tpm/cr50_spi.c b/drivers/char/tpm/cr50_spi.c
new file mode 100644
index 000..9cc1620
--- /dev/null
+++ b/drivers/char/tpm/cr50_spi.c
@@ -0,0 +1,350 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ *
+ * This device driver implements a TCG PTP FIFO interface over SPI for chips
+ * with Cr50 firmware.
+ * It is based on tpm_tis_spi driver by Peter Huewe and Christophe Ricard.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include "tpm.h"
+#include "tpm_tis_core.h"
+
+/*
+ * Cr50 timing constants:
+ * - can go to sleep not earlier than after CR50_SLEEP_DELAY_MSEC
+ * - needs up to CR50_WAKE_START_DELAY_MSEC to wake after sleep
+ * - requires at least CR50_ACCESS_DELAY_MSEC between transactions
+ */
+#define CR50_SLEEP_DELAY_MSEC  1000
+#define CR50_WAKE_START_DELAY_MSEC 60
+#define CR50_ACCESS_DELAY_MSEC 2
+
+#define MAX_SPI_FRAMESIZE  64
+
+#define TPM_CR50_FW_VER(l) (0x0F90 | ((l) << 12))
+#define TPM_CR50_MAX_FW_VER_LEN64
+
+struct cr50_spi_phy {
+   struct tpm_tis_data priv;
+   struct spi_device *spi_device;
+
+   struct mutex time_track_mutex;
+   unsigned long last_access_jiffies;
+   unsigned long wake_after_jiffies;
+
+   unsigned long access_delay_jiffies;
+   unsigned long sleep_delay_jiffies;
+   unsigned int wake_start_delay_msec;
+
+   u8 tx_buf[MAX_SPI_FRAMESIZE] cacheline_aligned;
+   u8 rx_buf[MAX_SPI_FRAMESIZE] cacheline_aligned;
+};
+
+static struct cr50_spi_phy *to_cr50_spi_phy(struct tpm_tis_data *data)
+{
+   return container_of(data, struct cr50_spi_phy, priv);
+}
+
+/*
+ * Cr50 needs to have at least some delay between consecutive
+ * transactions. Make sure we wait.
+ */
+static void cr50_ensure_access_delay(struct cr50_spi_phy *phy)
+{
+   /*
+* Note: There is a small chance, if Cr50 is not accessed in a few days,
+* that time_in_range will not provide the correct result after the wrap
+* around for jiffies. In this case, we'll have an unneeded short delay,
+* which is fine.
+*/
+   unsigned long allowed_access =
+   phy->last_access_jiffies + phy->access_delay_jiffies;
+   unsigned long time_now = jiffies;
+
+   if (time_in_range_open(time_now,
+  phy->last_access_jiffies, allowed_access))
+   mdelay(jiffies_to_msecs(allowed_access - time_now));
+}
+
+/*
+ * Cr50 might go to sleep if there is no SPI activity for some time and
+ * miss 

[PATCH v4 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50
firmware. The firmware running on the currently supported H1
Secure Microcontroller requires a special driver to handle its
specifics:
 - need to ensure a certain delay between spi transactions, or else
   the chip may miss some part of the next transaction;
 - if there is no spi activity for some time, it may go to sleep,
   and needs to be waken up before sending further commands;
 - access to vendor-specific registers.

Signed-off-by: Andrey Pronin 
---
 drivers/char/tpm/Kconfig|   9 ++
 drivers/char/tpm/Makefile   |   1 +
 drivers/char/tpm/cr50_spi.c | 350 
 3 files changed, 360 insertions(+)
 create mode 100644 drivers/char/tpm/cr50_spi.c

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1..3320acc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -100,6 +100,15 @@ config TCG_ATMEL
  will be accessible from within Linux.  To compile this driver 
  as a module, choose M here; the module will be called tpm_atmel.
 
+config TCG_CR50_SPI
+   tristate "TCG PTP FIFO Interface over SPI - Chips with Cr50 Firmware"
+   depends on SPI
+   select TCG_TIS_CORE
+   ---help---
+ If you have a chip running Cr50 firmware on SPI bus, say Yes and it
+ will be accessible from within Linux. To compile this driver as a
+ module, choose M here; the module will be called cr50_spi.
+
 config TCG_INFINEON
tristate "Infineon Technologies TPM Interface"
depends on PNP
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a385fb8..b346306 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_TCG_TIS_I2C_INFINEON) += tpm_i2c_infineon.o
 obj-$(CONFIG_TCG_TIS_I2C_NUVOTON) += tpm_i2c_nuvoton.o
 obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
 obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
+obj-$(CONFIG_TCG_CR50_SPI) += cr50_spi.o
 obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
 obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
 obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
diff --git a/drivers/char/tpm/cr50_spi.c b/drivers/char/tpm/cr50_spi.c
new file mode 100644
index 000..9cc1620
--- /dev/null
+++ b/drivers/char/tpm/cr50_spi.c
@@ -0,0 +1,350 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ *
+ * This device driver implements a TCG PTP FIFO interface over SPI for chips
+ * with Cr50 firmware.
+ * It is based on tpm_tis_spi driver by Peter Huewe and Christophe Ricard.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include "tpm.h"
+#include "tpm_tis_core.h"
+
+/*
+ * Cr50 timing constants:
+ * - can go to sleep not earlier than after CR50_SLEEP_DELAY_MSEC
+ * - needs up to CR50_WAKE_START_DELAY_MSEC to wake after sleep
+ * - requires at least CR50_ACCESS_DELAY_MSEC between transactions
+ */
+#define CR50_SLEEP_DELAY_MSEC  1000
+#define CR50_WAKE_START_DELAY_MSEC 60
+#define CR50_ACCESS_DELAY_MSEC 2
+
+#define MAX_SPI_FRAMESIZE  64
+
+#define TPM_CR50_FW_VER(l) (0x0F90 | ((l) << 12))
+#define TPM_CR50_MAX_FW_VER_LEN64
+
+struct cr50_spi_phy {
+   struct tpm_tis_data priv;
+   struct spi_device *spi_device;
+
+   struct mutex time_track_mutex;
+   unsigned long last_access_jiffies;
+   unsigned long wake_after_jiffies;
+
+   unsigned long access_delay_jiffies;
+   unsigned long sleep_delay_jiffies;
+   unsigned int wake_start_delay_msec;
+
+   u8 tx_buf[MAX_SPI_FRAMESIZE] cacheline_aligned;
+   u8 rx_buf[MAX_SPI_FRAMESIZE] cacheline_aligned;
+};
+
+static struct cr50_spi_phy *to_cr50_spi_phy(struct tpm_tis_data *data)
+{
+   return container_of(data, struct cr50_spi_phy, priv);
+}
+
+/*
+ * Cr50 needs to have at least some delay between consecutive
+ * transactions. Make sure we wait.
+ */
+static void cr50_ensure_access_delay(struct cr50_spi_phy *phy)
+{
+   /*
+* Note: There is a small chance, if Cr50 is not accessed in a few days,
+* that time_in_range will not provide the correct result after the wrap
+* around for jiffies. In this case, we'll have an unneeded short delay,
+* which is fine.
+*/
+   unsigned long allowed_access =
+   phy->last_access_jiffies + phy->access_delay_jiffies;
+   unsigned long time_now = jiffies;
+
+   if (time_in_range_open(time_now,
+  phy->last_access_jiffies, allowed_access))
+   mdelay(jiffies_to_msecs(allowed_access - time_now));
+}
+
+/*
+ * Cr50 might go to sleep if there is no SPI activity for some time and
+ * miss the first few