[PATCH] staging: lustre: lnet: prefer kcalloc over kzalloc with multiply

[Sumit Pundir]

Use kcalloc for allocating an array instead of kzalloc with
multiply. kcalloc is the preferred API. Issue reported by
checkpatch.pl

Signed-off-by: Sumit Pundir 
---
 drivers/staging/lustre/lnet/lnet/config.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/config.c 
b/drivers/staging/lustre/lnet/lnet/config.c
index 1516ac6..0aea268 100644
--- a/drivers/staging/lustre/lnet/lnet/config.c
+++ b/drivers/staging/lustre/lnet/lnet/config.c
@@ -1146,7 +1146,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
if (nif <= 0)
return nif;
 
-   ipaddrs = kzalloc(nif * sizeof(*ipaddrs), GFP_KERNEL);
+   ipaddrs = kcalloc(nif, sizeof(*ipaddrs), GFP_KERNEL);
if (!ipaddrs) {
CERROR("Can't allocate ipaddrs[%d]\n", nif);
lnet_ipif_free_enumeration(ifnames, nif);
@@ -1179,7 +1179,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
*ipaddrsp = ipaddrs;
} else {
if (nip > 0) {
-   ipaddrs2 = kzalloc(nip * sizeof(*ipaddrs2),
+   ipaddrs2 = kcalloc(nip, sizeof(*ipaddrs2),
   GFP_KERNEL);
if (!ipaddrs2) {
CERROR("Can't allocate ipaddrs[%d]\n", nip);
-- 
2.7.4

[PATCH] staging: lustre: lnet: prefer kcalloc over kzalloc with multiply

[Sumit Pundir]

Use kcalloc for allocating an array instead of kzalloc with
multiply. kcalloc is the preferred API. Issue reported by
checkpatch.pl

Signed-off-by: Sumit Pundir 
---
 drivers/staging/lustre/lnet/lnet/config.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/config.c 
b/drivers/staging/lustre/lnet/lnet/config.c
index 1516ac6..0aea268 100644
--- a/drivers/staging/lustre/lnet/lnet/config.c
+++ b/drivers/staging/lustre/lnet/lnet/config.c
@@ -1146,7 +1146,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
if (nif <= 0)
return nif;
 
-   ipaddrs = kzalloc(nif * sizeof(*ipaddrs), GFP_KERNEL);
+   ipaddrs = kcalloc(nif, sizeof(*ipaddrs), GFP_KERNEL);
if (!ipaddrs) {
CERROR("Can't allocate ipaddrs[%d]\n", nif);
lnet_ipif_free_enumeration(ifnames, nif);
@@ -1179,7 +1179,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
*ipaddrsp = ipaddrs;
} else {
if (nip > 0) {
-   ipaddrs2 = kzalloc(nip * sizeof(*ipaddrs2),
+   ipaddrs2 = kcalloc(nip, sizeof(*ipaddrs2),
   GFP_KERNEL);
if (!ipaddrs2) {
CERROR("Can't allocate ipaddrs[%d]\n", nip);
-- 
2.7.4

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

[Thomas Gleixner]

On Fri, 19 Jan 2018, Vitaly Kuznetsov wrote:
> kbuild test robot <l...@intel.com> writes:
> 
> > Hi Vitaly,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on tip/auto-latest]
> > [also build test WARNING on v4.15-rc8 next-20180118]
> > [cannot apply to tip/x86/core kvm/linux-next]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/x86-kvm-hyperv-stable-clocksorce-for-L2-guests-when-running-nested-KVM-on-Hyper-V/20180119-160814
> > config: x86_64-allmodconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64 
> >
> > All warnings (new ones prefixed by >>):
> >
> >In file included from include/linux/kasan.h:17:0,
> > from include/linux/slab.h:129,
> > from include/linux/irq.h:26,
> > from arch/x86/include/asm/hardirq.h:6,
> > from include/linux/hardirq.h:9,
> > from include/linux/interrupt.h:13,
> > from arch/x86/include/asm/mshyperv.h:8,
> > from arch/x86//entry/vdso/vdso32/../vclock_gettime.c:20,
> > from arch/x86//entry/vdso/vdso32/vclock_gettime.c:33:
> >arch/x86/include/asm/pgtable.h: In function 'clone_pgd_range':
> >arch/x86/include/asm/pgtable.h:1129:9: error: implicit declaration of 
> > function 'kernel_to_user_pgdp'; did you mean 'u64_to_user_ptr'? 
> > [-Werror=implicit-function-declaration]
> >  memcpy(kernel_to_user_pgdp(dst), kernel_to_user_pgdp(src),
> > ^~~
> 
> Sorry but I'm failing to see how this (and all the rest) is related to
> my patch ...

You added '#include ' to mshyperv.h which is included in
vclock_gettime.c and pulls in other stuff which fails to expand

Thanks,

tglx

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

[Thomas Gleixner]

On Fri, 19 Jan 2018, Vitaly Kuznetsov wrote:
> kbuild test robot  writes:
> 
> > Hi Vitaly,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on tip/auto-latest]
> > [also build test WARNING on v4.15-rc8 next-20180118]
> > [cannot apply to tip/x86/core kvm/linux-next]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/x86-kvm-hyperv-stable-clocksorce-for-L2-guests-when-running-nested-KVM-on-Hyper-V/20180119-160814
> > config: x86_64-allmodconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64 
> >
> > All warnings (new ones prefixed by >>):
> >
> >In file included from include/linux/kasan.h:17:0,
> > from include/linux/slab.h:129,
> > from include/linux/irq.h:26,
> > from arch/x86/include/asm/hardirq.h:6,
> > from include/linux/hardirq.h:9,
> > from include/linux/interrupt.h:13,
> > from arch/x86/include/asm/mshyperv.h:8,
> > from arch/x86//entry/vdso/vdso32/../vclock_gettime.c:20,
> > from arch/x86//entry/vdso/vdso32/vclock_gettime.c:33:
> >arch/x86/include/asm/pgtable.h: In function 'clone_pgd_range':
> >arch/x86/include/asm/pgtable.h:1129:9: error: implicit declaration of 
> > function 'kernel_to_user_pgdp'; did you mean 'u64_to_user_ptr'? 
> > [-Werror=implicit-function-declaration]
> >  memcpy(kernel_to_user_pgdp(dst), kernel_to_user_pgdp(src),
> > ^~~
> 
> Sorry but I'm failing to see how this (and all the rest) is related to
> my patch ...

You added '#include ' to mshyperv.h which is included in
vclock_gettime.c and pulls in other stuff which fails to expand

Thanks,

tglx

[PATCH] f2fs: correct removexattr behavior for null valued extended attribute

[Chao Yu]

From: Daeho Jeong 

__vfs_removexattr() transfers "NULL" value to the setxattr handler of
the f2fs filesystem in order to remove the extended attribute. But,
__f2fs_setxattr() just ignores the removal request when the value of
the extended attribute is already NULL. We have to remove the extended
attribute itself even if the value of that is already NULL.

We can reporduce this bug with the below:

1. touch file
2. setfattr -n "user.foo" file
3. setfattr -x "user.foo" file
4. getfattr -d file
> user.foo

Signed-off-by: Daeho Jeong 
Signed-off-by: Youngjin Gil 
Tested-by: Hobin Woo 
Tested-by: Chao Yu 
Reviewed-by: Chao Yu 
Signed-off-by: Chao Yu 
---
 fs/f2fs/xattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 600162f4ddbf..ae2dfa709f5d 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -600,7 +600,7 @@ static int __f2fs_setxattr(struct inode *inode, int index,
goto exit;
}
 
-   if (f2fs_xattr_value_same(here, value, size))
+   if (value && f2fs_xattr_value_same(here, value, size))
goto exit;
} else if ((flags & XATTR_REPLACE)) {
error = -ENODATA;
-- 
2.14.1.145.gb3622a4ee

[PATCH] f2fs: correct removexattr behavior for null valued extended attribute

[Chao Yu]

From: Daeho Jeong 

__vfs_removexattr() transfers "NULL" value to the setxattr handler of
the f2fs filesystem in order to remove the extended attribute. But,
__f2fs_setxattr() just ignores the removal request when the value of
the extended attribute is already NULL. We have to remove the extended
attribute itself even if the value of that is already NULL.

We can reporduce this bug with the below:

1. touch file
2. setfattr -n "user.foo" file
3. setfattr -x "user.foo" file
4. getfattr -d file
> user.foo

Signed-off-by: Daeho Jeong 
Signed-off-by: Youngjin Gil 
Tested-by: Hobin Woo 
Tested-by: Chao Yu 
Reviewed-by: Chao Yu 
Signed-off-by: Chao Yu 
---
 fs/f2fs/xattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 600162f4ddbf..ae2dfa709f5d 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -600,7 +600,7 @@ static int __f2fs_setxattr(struct inode *inode, int index,
goto exit;
}
 
-   if (f2fs_xattr_value_same(here, value, size))
+   if (value && f2fs_xattr_value_same(here, value, size))
goto exit;
} else if ((flags & XATTR_REPLACE)) {
error = -ENODATA;
-- 
2.14.1.145.gb3622a4ee

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

[PrasannaKumar Muralidharan]

Hi Paul,

On 30 December 2017 at 19:21, Paul Cercueil  wrote:
> When the watchdog was configured for nowayout, and after the
> userspace watchdog daemon closed the dev node without sending the
> magic character, unloading this module stopped the watchdog
> hardware, which was clearly a problem.
>
> Besides, unloading the module is not possible when the userspace
> watchdog daemon is running, so it's safe to assume that we don't
> need to stop the watchdog hardware in the jz4740_wdt_remove()
> function.
>
> For this reason, the jz4740_wdt_remove() function can then be
> dropped alltogether.
>
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/watchdog/jz4740_wdt.c | 8 
>  1 file changed, 8 deletions(-)
>
>  v2: New patch in this series
>
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
> index fa7f49a3212c..02b9b8e946a2 100644
> --- a/drivers/watchdog/jz4740_wdt.c
> +++ b/drivers/watchdog/jz4740_wdt.c
> @@ -205,16 +205,8 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
> return 0;
>  }
>
> -static int jz4740_wdt_remove(struct platform_device *pdev)
> -{
> -   struct jz4740_wdt_drvdata *drvdata = platform_get_drvdata(pdev);
> -
> -   return jz4740_wdt_stop(>wdt);
> -}
> -
>  static struct platform_driver jz4740_wdt_driver = {
> .probe = jz4740_wdt_probe,
> -   .remove = jz4740_wdt_remove,
> .driver = {
> .name = "jz4740-wdt",
> .of_match_table = of_match_ptr(jz4740_wdt_of_matches),
> --
> 2.11.0
>
>

As ".remove" is removed and wdt is required for restarting the system
I am thinking that stop callback is also not required. If so does it
makes sense to remove the stop callback? I can submit a patch for the
same once this patch series goes in.

Regards,
PrasannaKumar

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

[PrasannaKumar Muralidharan]

Hi Paul,

On 30 December 2017 at 19:21, Paul Cercueil  wrote:
> When the watchdog was configured for nowayout, and after the
> userspace watchdog daemon closed the dev node without sending the
> magic character, unloading this module stopped the watchdog
> hardware, which was clearly a problem.
>
> Besides, unloading the module is not possible when the userspace
> watchdog daemon is running, so it's safe to assume that we don't
> need to stop the watchdog hardware in the jz4740_wdt_remove()
> function.
>
> For this reason, the jz4740_wdt_remove() function can then be
> dropped alltogether.
>
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/watchdog/jz4740_wdt.c | 8 
>  1 file changed, 8 deletions(-)
>
>  v2: New patch in this series
>
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
> index fa7f49a3212c..02b9b8e946a2 100644
> --- a/drivers/watchdog/jz4740_wdt.c
> +++ b/drivers/watchdog/jz4740_wdt.c
> @@ -205,16 +205,8 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
> return 0;
>  }
>
> -static int jz4740_wdt_remove(struct platform_device *pdev)
> -{
> -   struct jz4740_wdt_drvdata *drvdata = platform_get_drvdata(pdev);
> -
> -   return jz4740_wdt_stop(>wdt);
> -}
> -
>  static struct platform_driver jz4740_wdt_driver = {
> .probe = jz4740_wdt_probe,
> -   .remove = jz4740_wdt_remove,
> .driver = {
> .name = "jz4740-wdt",
> .of_match_table = of_match_ptr(jz4740_wdt_of_matches),
> --
> 2.11.0
>
>

As ".remove" is removed and wdt is required for restarting the system
I am thinking that stop callback is also not required. If so does it
makes sense to remove the stop callback? I can submit a patch for the
same once this patch series goes in.

Regards,
PrasannaKumar

Re: ACPI: sbshc: remove raw pointer from printk message

[Greg Kroah-Hartman]

On Sat, Jan 20, 2018 at 12:53:39AM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 19, 2018 at 10:06 AM, Greg Kroah-Hartman
>  wrote:
> > There's no need to be printing a raw kernel pointer to the kernel log at
> > every boot.  So just remove it, and change the whole message to use the
> > correct dev_info() call at the same time.
> >
> > Reported-by: Wang Qize 
> > Cc: stable 
> 
> I will remember this one. ;-)
> 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Acked-by: Rafael J. Wysocki 

Does that mean you want me to take this through my tree?  Or is there an
acpi tree it will go through?

thanks,

greg k-h

Re: ACPI: sbshc: remove raw pointer from printk message

[Greg Kroah-Hartman]

On Sat, Jan 20, 2018 at 12:53:39AM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 19, 2018 at 10:06 AM, Greg Kroah-Hartman
>  wrote:
> > There's no need to be printing a raw kernel pointer to the kernel log at
> > every boot.  So just remove it, and change the whole message to use the
> > correct dev_info() call at the same time.
> >
> > Reported-by: Wang Qize 
> > Cc: stable 
> 
> I will remember this one. ;-)
> 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Acked-by: Rafael J. Wysocki 

Does that mean you want me to take this through my tree?  Or is there an
acpi tree it will go through?

thanks,

greg k-h

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

[PrasannaKumar Muralidharan]

Hi Paul,

On 30 December 2017 at 19:21, Paul Cercueil  wrote:
> The watchdog driver can restart the system by simply configuring the
> hardware for a timeout of 0 seconds.
>
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Guenter Roeck 
> ---
>  drivers/watchdog/jz4740_wdt.c | 9 +
>  1 file changed, 9 insertions(+)
>
>  v2: No change
>
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
> index 92d6ca8ceb49..fa7f49a3212c 100644
> --- a/drivers/watchdog/jz4740_wdt.c
> +++ b/drivers/watchdog/jz4740_wdt.c
> @@ -130,6 +130,14 @@ static int jz4740_wdt_stop(struct watchdog_device 
> *wdt_dev)
> return 0;
>  }
>
> +static int jz4740_wdt_restart(struct watchdog_device *wdt_dev,
> + unsigned long action, void *data)
> +{
> +   wdt_dev->timeout = 0;
> +   jz4740_wdt_start(wdt_dev);
> +   return 0;
> +}
> +
>  static const struct watchdog_info jz4740_wdt_info = {
> .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
> .identity = "jz4740 Watchdog",
> @@ -141,6 +149,7 @@ static const struct watchdog_ops jz4740_wdt_ops = {
> .stop = jz4740_wdt_stop,
> .ping = jz4740_wdt_ping,
> .set_timeout = jz4740_wdt_set_timeout,
> +   .restart = jz4740_wdt_restart,
>  };
>
>  #ifdef CONFIG_OF
> --
> 2.11.0
>
>

Noticed that min_timeout of the watchdog device is set to 1 but this
function calls start with timeout set to 0. Even though this works I
feel it is better to set min_timeout to 0.

Regards,
PrasannaKumar

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

[PrasannaKumar Muralidharan]

Hi Paul,

On 30 December 2017 at 19:21, Paul Cercueil  wrote:
> The watchdog driver can restart the system by simply configuring the
> hardware for a timeout of 0 seconds.
>
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Guenter Roeck 
> ---
>  drivers/watchdog/jz4740_wdt.c | 9 +
>  1 file changed, 9 insertions(+)
>
>  v2: No change
>
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
> index 92d6ca8ceb49..fa7f49a3212c 100644
> --- a/drivers/watchdog/jz4740_wdt.c
> +++ b/drivers/watchdog/jz4740_wdt.c
> @@ -130,6 +130,14 @@ static int jz4740_wdt_stop(struct watchdog_device 
> *wdt_dev)
> return 0;
>  }
>
> +static int jz4740_wdt_restart(struct watchdog_device *wdt_dev,
> + unsigned long action, void *data)
> +{
> +   wdt_dev->timeout = 0;
> +   jz4740_wdt_start(wdt_dev);
> +   return 0;
> +}
> +
>  static const struct watchdog_info jz4740_wdt_info = {
> .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
> .identity = "jz4740 Watchdog",
> @@ -141,6 +149,7 @@ static const struct watchdog_ops jz4740_wdt_ops = {
> .stop = jz4740_wdt_stop,
> .ping = jz4740_wdt_ping,
> .set_timeout = jz4740_wdt_set_timeout,
> +   .restart = jz4740_wdt_restart,
>  };
>
>  #ifdef CONFIG_OF
> --
> 2.11.0
>
>

Noticed that min_timeout of the watchdog device is set to 1 but this
function calls start with timeout set to 0. Even though this works I
feel it is better to set min_timeout to 0.

Regards,
PrasannaKumar

[tip:x86/platform] x86/jailhouse: Respect pci=lastbus command line settings

[tip-bot for Jan Kiszka]

Commit-ID:  3b42349d56c96e144401d2317d8eeb9937511423
Gitweb: https://git.kernel.org/tip/3b42349d56c96e144401d2317d8eeb9937511423
Author: Jan Kiszka 
AuthorDate: Fri, 19 Jan 2018 11:06:30 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 20 Jan 2018 08:15:44 +0100

x86/jailhouse: Respect pci=lastbus command line settings

Limiting the scan width to the known last bus via the command line can
accelerate the boot noteworthy.

Signed-off-by: Jan Kiszka 
Signed-off-by: Thomas Gleixner 
Cc: Jailhouse 
Link: https://lkml.kernel.org/r/51f5fe62-ca8f-9286-5cdb-39df3fad7...@siemens.com

---
 arch/x86/kernel/jailhouse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 2b7ebbe..b68fd89 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -119,8 +119,10 @@ static int __init jailhouse_pci_arch_init(void)
/*
 * There are no bridges on the virtual PCI root bus under Jailhouse,
 * thus no other way to discover all devices than a full scan.
+* Respect any overrides via the command line, though.
 */
-   pcibios_last_bus = 0xff;
+   if (pcibios_last_bus < 0)
+   pcibios_last_bus = 0xff;
 
return 0;
 }

[tip:x86/platform] x86/jailhouse: Respect pci=lastbus command line settings

[tip-bot for Jan Kiszka]

Commit-ID:  3b42349d56c96e144401d2317d8eeb9937511423
Gitweb: https://git.kernel.org/tip/3b42349d56c96e144401d2317d8eeb9937511423
Author: Jan Kiszka 
AuthorDate: Fri, 19 Jan 2018 11:06:30 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 20 Jan 2018 08:15:44 +0100

x86/jailhouse: Respect pci=lastbus command line settings

Limiting the scan width to the known last bus via the command line can
accelerate the boot noteworthy.

Signed-off-by: Jan Kiszka 
Signed-off-by: Thomas Gleixner 
Cc: Jailhouse 
Link: https://lkml.kernel.org/r/51f5fe62-ca8f-9286-5cdb-39df3fad7...@siemens.com

---
 arch/x86/kernel/jailhouse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 2b7ebbe..b68fd89 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -119,8 +119,10 @@ static int __init jailhouse_pci_arch_init(void)
/*
 * There are no bridges on the virtual PCI root bus under Jailhouse,
 * thus no other way to discover all devices than a full scan.
+* Respect any overrides via the command line, though.
 */
-   pcibios_last_bus = 0xff;
+   if (pcibios_last_bus < 0)
+   pcibios_last_bus = 0xff;
 
return 0;
 }

[tip:x86/platform] x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

[tip-bot for Jan Kiszka]

Commit-ID:  11f19ec025dd421c54978c69e42d86758fa310de
Gitweb: https://git.kernel.org/tip/11f19ec025dd421c54978c69e42d86758fa310de
Author: Jan Kiszka 
AuthorDate: Fri, 19 Jan 2018 11:06:17 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 20 Jan 2018 08:15:43 +0100

x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

Otherwise, Linux will not recognize precalibrated_tsc_khz and disable
the tsc as clocksource.

Signed-off-by: Jan Kiszka 
Signed-off-by: Thomas Gleixner 
Cc: Jailhouse 
Link: https://lkml.kernel.org/r/975fbfc9-2a64-cc56-40d5-164992ec3...@siemens.com

---
 arch/x86/kernel/jailhouse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 7ade152..2b7ebbe 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -176,6 +176,7 @@ static void __init jailhouse_init_platform(void)
pr_debug("Jailhouse: PM-Timer IO Port: %#x\n", pmtmr_ioport);
 
precalibrated_tsc_khz = setup_data.tsc_khz;
+   setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
pci_probe = 0;
 

[tip:x86/platform] x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

[tip-bot for Jan Kiszka]

Commit-ID:  11f19ec025dd421c54978c69e42d86758fa310de
Gitweb: https://git.kernel.org/tip/11f19ec025dd421c54978c69e42d86758fa310de
Author: Jan Kiszka 
AuthorDate: Fri, 19 Jan 2018 11:06:17 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 20 Jan 2018 08:15:43 +0100

x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

Otherwise, Linux will not recognize precalibrated_tsc_khz and disable
the tsc as clocksource.

Signed-off-by: Jan Kiszka 
Signed-off-by: Thomas Gleixner 
Cc: Jailhouse 
Link: https://lkml.kernel.org/r/975fbfc9-2a64-cc56-40d5-164992ec3...@siemens.com

---
 arch/x86/kernel/jailhouse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 7ade152..2b7ebbe 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -176,6 +176,7 @@ static void __init jailhouse_init_platform(void)
pr_debug("Jailhouse: PM-Timer IO Port: %#x\n", pmtmr_ioport);
 
precalibrated_tsc_khz = setup_data.tsc_khz;
+   setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
pci_probe = 0;
 

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/19/18 13:20), Steven Rostedt wrote:
[..]
> I was thinking about this a bit more, and instead of offloading a
> recursive printk, perhaps its best to simply throttle it. Because the
> problem may not go away if a printk thread takes over, because the bug
> is really the printk infrastructure filling the printk buffer keeping
> printk from ever stopping.

right. I didn't quite got it how that would help. if we would
kick_offload every time we add new printks after call_console_drivers(),
then we can just end up in a kick_offload loop traveling across all CPUs.

[..]
>  asmlinkage int vprintk_emit(int facility, int level,
>   const char *dict, size_t dictlen,
> @@ -1849,6 +1918,17 @@ asmlinkage int vprintk_emit(int facility, int level,
>  
>   /* This stops the holder of console_sem just where we want him */
>   logbuf_lock_irqsave(flags);
> +
> + if (recursion_check_test()) {
> + /* A printk happened within a printk at the same context */
> + if (this_cpu_inc_return(recursion_count) > recursion_max) {
> + atomic_inc(_overflow);
> + logbuf_unlock_irqrestore(flags);
> + printed_len = 0;
> + goto out;
> + }
> + }

didn't have time to look at this carefully, but is this possible?

printks from console_unlock()->call_console_drivers() are redirected
to printk_safe buffer. we need irq_work on that CPU to flush its
printk_safe buffer.

>  EXPORT_SYMBOL(vprintk_emit);
> @@ -2343,9 +2428,14 @@ void console_unlock(void)
>   seen_seq = log_next_seq;
>   }
>  
> - if (console_seq < log_first_seq) {
> + if (console_seq < log_first_seq || 
> atomic_read(_overflow)) {
> + size_t missed;
> +
> + missed = atomic_xchg(_overflow, 0);
> + missed += log_first_seq - console_seq;
> +
>   len = sprintf(text, "** %u printk messages dropped 
> **\n",
> -   (unsigned)(log_first_seq - console_seq));
> +   (unsigned)missed);
>  
>   /* messages are gone, move to first one */
>   console_seq = log_first_seq;

how are we going to distinguish between lockdep splats, for instance,
or WARNs from call_console_drivers() -> foo_write(), which are valuable,
and kmalloc() print outs, which might be less valuable? are we going to
lose all of them now? then we can do a much simpler thing - steal one
bit from `printk_context' and use if for a new PRINTK_NOOP_CONTEXT, which
will be set around call_console_drivers(). vprintk_func() would redirect
printks to vprintk_noop(fmt, args), which will do nothing.

-ss

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/19/18 13:20), Steven Rostedt wrote:
[..]
> I was thinking about this a bit more, and instead of offloading a
> recursive printk, perhaps its best to simply throttle it. Because the
> problem may not go away if a printk thread takes over, because the bug
> is really the printk infrastructure filling the printk buffer keeping
> printk from ever stopping.

right. I didn't quite got it how that would help. if we would
kick_offload every time we add new printks after call_console_drivers(),
then we can just end up in a kick_offload loop traveling across all CPUs.

[..]
>  asmlinkage int vprintk_emit(int facility, int level,
>   const char *dict, size_t dictlen,
> @@ -1849,6 +1918,17 @@ asmlinkage int vprintk_emit(int facility, int level,
>  
>   /* This stops the holder of console_sem just where we want him */
>   logbuf_lock_irqsave(flags);
> +
> + if (recursion_check_test()) {
> + /* A printk happened within a printk at the same context */
> + if (this_cpu_inc_return(recursion_count) > recursion_max) {
> + atomic_inc(_overflow);
> + logbuf_unlock_irqrestore(flags);
> + printed_len = 0;
> + goto out;
> + }
> + }

didn't have time to look at this carefully, but is this possible?

printks from console_unlock()->call_console_drivers() are redirected
to printk_safe buffer. we need irq_work on that CPU to flush its
printk_safe buffer.

>  EXPORT_SYMBOL(vprintk_emit);
> @@ -2343,9 +2428,14 @@ void console_unlock(void)
>   seen_seq = log_next_seq;
>   }
>  
> - if (console_seq < log_first_seq) {
> + if (console_seq < log_first_seq || 
> atomic_read(_overflow)) {
> + size_t missed;
> +
> + missed = atomic_xchg(_overflow, 0);
> + missed += log_first_seq - console_seq;
> +
>   len = sprintf(text, "** %u printk messages dropped 
> **\n",
> -   (unsigned)(log_first_seq - console_seq));
> +   (unsigned)missed);
>  
>   /* messages are gone, move to first one */
>   console_seq = log_first_seq;

how are we going to distinguish between lockdep splats, for instance,
or WARNs from call_console_drivers() -> foo_write(), which are valuable,
and kmalloc() print outs, which might be less valuable? are we going to
lose all of them now? then we can do a much simpler thing - steal one
bit from `printk_context' and use if for a new PRINTK_NOOP_CONTEXT, which
will be set around call_console_drivers(). vprintk_func() would redirect
printks to vprintk_noop(fmt, args), which will do nothing.

-ss

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 10:57 PM, Laura Abbott wrote:

On 01/19/2018 10:15 PM, Tom Lendacky wrote:

On 1/19/2018 11:25 PM, Gabriel C wrote:

2018-01-20 5:02 GMT+01:00 Laura Abbott :

On 01/19/2018 06:23 PM, Gabriel C wrote:


2018-01-20 2:23 GMT+01:00 Laura Abbott :


Hi,



Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN 
box ,

on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports
about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a 
struct to

reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] 
x86/mm:

Use a
struct to reduce parameters for SME PGD mapping


Configuration is at

https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide 


Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.



But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.


Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )


I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.


  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.


If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?



Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..




The machines I have are a Lenovo X1 Carbon and a Lenovo T470s.
A Lenovo X220 ThinkPad also reported the problem.

If I comment out sme_encrypt_kernel it boots:

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 7ba5d819ebe3..443ef5d3f1fa 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -158,7 +158,7 @@ 

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 10:57 PM, Laura Abbott wrote:

On 01/19/2018 10:15 PM, Tom Lendacky wrote:

On 1/19/2018 11:25 PM, Gabriel C wrote:

2018-01-20 5:02 GMT+01:00 Laura Abbott :

On 01/19/2018 06:23 PM, Gabriel C wrote:


2018-01-20 2:23 GMT+01:00 Laura Abbott :


Hi,



Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN 
box ,

on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports
about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a 
struct to

reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] 
x86/mm:

Use a
struct to reduce parameters for SME PGD mapping


Configuration is at

https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide 


Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.



But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.


Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )


I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.


  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.


If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?



Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..




The machines I have are a Lenovo X1 Carbon and a Lenovo T470s.
A Lenovo X220 ThinkPad also reported the problem.

If I comment out sme_encrypt_kernel it boots:

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 7ba5d819ebe3..443ef5d3f1fa 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -158,7 +158,7 @@ unsigned long __head __startup_64(unsigned 

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams  wrote:
> Changes since v3 [1]
> * Drop 'ifence_array_ptr' and associated compile-time + run-time
>   switching and just use the masking approach all the time.
>
> * Convert 'get_user' to use pointer sanitization via masking rather than
>   lfence. '__get_user' and associated paths still rely on
>   lfence. (Linus)
>
>   "Basically, the rule is trivial: find all 'stac' users, and use
>address masking if those users already integrate the limit
>check, and lfence they don't."
>
> * At syscall entry sanitize the syscall number under speculation
>   to remove a user controlled pointer de-reference in kernel
>   space.  (Linus)
>
> * Fix a raw lfence in the kvm code (added for v4.15-rc8) to use
>   'array_ptr'.
>
> * Propose 'array_idx' as a way to sanitize user input that is
>   later used as an array index, but where the validation is
>   happening in a different code block than the array reference.
>   (Christian).
>
> * Fix grammar in speculation.txt (Kees)
>
> ---
>
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [2]
> and the Documentation patch in this series."
>
> A precondition of using this attack on the kernel is to get a user
> controlled pointer de-referenced (under speculation) in privileged code.
> The primary source of user controlled pointers in the kernel is the
> arguments passed to 'get_user' and '__get_user'. An example of other
> user controlled pointers are user-controlled array / pointer offsets.
>
> Better tooling is needed to find more arrays / pointers with user
> controlled indices / offsets that can be converted to use 'array_ptr' or
> 'array_idx'. A few are included in this set, and these are not expected
> to be complete. That said, the 'get_user' protections raise the bar on
> finding a vulnerable gadget in the kernel.
>
> These patches are also available via the 'nospec-v4' git branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4

I've pushed out a nospec-v4.1 with the below minor cleanup, a fixup of
the changelog for "kvm, x86: fix spectre-v1 mitigation", and added
Paolo's ack.

 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4.1

diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index 8af35be1869e..b8a9222e34d1 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -37,7 +37,7 @@ static inline unsigned long array_ptr_mask(unsigned
long idx, unsigned long sz)
unsigned long _i = (idx);   \
unsigned long _mask = array_ptr_mask(_i, (sz)); \
\
-   __u._ptr = _arr + (_i & _mask); \
+   __u._ptr = _arr + _i;   \
__u._bit &= _mask;  \
__u._ptr;   \
 })

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams  wrote:
> Changes since v3 [1]
> * Drop 'ifence_array_ptr' and associated compile-time + run-time
>   switching and just use the masking approach all the time.
>
> * Convert 'get_user' to use pointer sanitization via masking rather than
>   lfence. '__get_user' and associated paths still rely on
>   lfence. (Linus)
>
>   "Basically, the rule is trivial: find all 'stac' users, and use
>address masking if those users already integrate the limit
>check, and lfence they don't."
>
> * At syscall entry sanitize the syscall number under speculation
>   to remove a user controlled pointer de-reference in kernel
>   space.  (Linus)
>
> * Fix a raw lfence in the kvm code (added for v4.15-rc8) to use
>   'array_ptr'.
>
> * Propose 'array_idx' as a way to sanitize user input that is
>   later used as an array index, but where the validation is
>   happening in a different code block than the array reference.
>   (Christian).
>
> * Fix grammar in speculation.txt (Kees)
>
> ---
>
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [2]
> and the Documentation patch in this series."
>
> A precondition of using this attack on the kernel is to get a user
> controlled pointer de-referenced (under speculation) in privileged code.
> The primary source of user controlled pointers in the kernel is the
> arguments passed to 'get_user' and '__get_user'. An example of other
> user controlled pointers are user-controlled array / pointer offsets.
>
> Better tooling is needed to find more arrays / pointers with user
> controlled indices / offsets that can be converted to use 'array_ptr' or
> 'array_idx'. A few are included in this set, and these are not expected
> to be complete. That said, the 'get_user' protections raise the bar on
> finding a vulnerable gadget in the kernel.
>
> These patches are also available via the 'nospec-v4' git branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4

I've pushed out a nospec-v4.1 with the below minor cleanup, a fixup of
the changelog for "kvm, x86: fix spectre-v1 mitigation", and added
Paolo's ack.

 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4.1

diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index 8af35be1869e..b8a9222e34d1 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -37,7 +37,7 @@ static inline unsigned long array_ptr_mask(unsigned
long idx, unsigned long sz)
unsigned long _i = (idx);   \
unsigned long _mask = array_ptr_mask(_i, (sz)); \
\
-   __u._ptr = _arr + (_i & _mask); \
+   __u._ptr = _arr + _i;   \
__u._bit &= _mask;  \
__u._ptr;   \
 })

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 10:15 PM, Tom Lendacky wrote:

On 1/19/2018 11:25 PM, Gabriel C wrote:

2018-01-20 5:02 GMT+01:00 Laura Abbott :

On 01/19/2018 06:23 PM, Gabriel C wrote:


2018-01-20 2:23 GMT+01:00 Laura Abbott :


Hi,



Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports
about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
Use a
struct to reduce parameters for SME PGD mapping


Configuration is at

https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.



But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.


Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )


I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.


  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.


If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?



Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..




The machines I have are a Lenovo X1 Carbon and a Lenovo T470s.
A Lenovo X220 ThinkPad also reported the problem.

If I comment out sme_encrypt_kernel it boots:

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 7ba5d819ebe3..443ef5d3f1fa 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -158,7 +158,7 @@ unsigned long __head __startup_64(unsigned long 
physaddr,

 

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 10:15 PM, Tom Lendacky wrote:

On 1/19/2018 11:25 PM, Gabriel C wrote:

2018-01-20 5:02 GMT+01:00 Laura Abbott :

On 01/19/2018 06:23 PM, Gabriel C wrote:


2018-01-20 2:23 GMT+01:00 Laura Abbott :


Hi,



Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports
about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
Use a
struct to reduce parameters for SME PGD mapping


Configuration is at

https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.



But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.


Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )


I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.


  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.


If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?



Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..




The machines I have are a Lenovo X1 Carbon and a Lenovo T470s.
A Lenovo X220 ThinkPad also reported the problem.

If I comment out sme_encrypt_kernel it boots:

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 7ba5d819ebe3..443ef5d3f1fa 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -158,7 +158,7 @@ unsigned long __head __startup_64(unsigned long 
physaddr,

*p += load_delta - 

Re: [PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Add reg_drivevbus regualtor for boards which are using
> external regulator to drive the OTG VBus through N_VBUSEN
> PMIC pin.
>
> Signed-off-by: Jagan Teki 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Add reg_drivevbus regualtor for boards which are using
> external regulator to drive the OTG VBus through N_VBUSEN
> PMIC pin.
>
> Signed-off-by: Jagan Teki 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Like axp221, axp223, axp813 the axp803 is also supporting external
> regulator to drive the  OTG VBus through N_VBUSEN PMIC pin.
>
> Add support for it.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Rob Herring 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Like axp221, axp223, axp813 the axp803 is also supporting external
> regulator to drive the  OTG VBus through N_VBUSEN PMIC pin.
>
> Add support for it.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Rob Herring 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Add usb otg support for bananapi-m64 board,
> - USB-ID connected with PH9
> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v4:
> - rebase on master
> - tested otg host mode.
> Changes for v3:
> - Move the position of reg_drivevbus as per binding documentation.
> Changes for v2:
> - add drvvbus regulator
> - add N_VBUSEN pin
>
>  .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts  | 21 
> +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> index a697567..26e8534 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> @@ -86,6 +86,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -156,6 +160,10 @@
> status = "okay";
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -168,6 +176,7 @@
> reg = <0x3a3>;
> interrupt-parent = <_intc>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +   x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
> };
>  };
>
> @@ -283,6 +292,11 @@
> regulator-name = "vcc-rtc";
>  };
>
> +_drivevbus {

Please keep the nodes in alphabetical order. Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +   regulator-name = "usb0-vbus";
> +   status = "okay";
> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins_a>;
> @@ -295,6 +309,13 @@
> status = "okay";
>  };
>
> +_otg {
> +   dr_mode = "otg";
> +   status = "okay";
> +};
> +
>   {
> +   usb0_id_det-gpios = < 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
> +   usb0_vbus-supply = <_drivevbus>;
> status = "okay";
>  };
> --
> 2.7.4
>

Re: [PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

[Chen-Yu Tsai]

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki  wrote:
> Add usb otg support for bananapi-m64 board,
> - USB-ID connected with PH9
> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v4:
> - rebase on master
> - tested otg host mode.
> Changes for v3:
> - Move the position of reg_drivevbus as per binding documentation.
> Changes for v2:
> - add drvvbus regulator
> - add N_VBUSEN pin
>
>  .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts  | 21 
> +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> index a697567..26e8534 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> @@ -86,6 +86,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -156,6 +160,10 @@
> status = "okay";
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -168,6 +176,7 @@
> reg = <0x3a3>;
> interrupt-parent = <_intc>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +   x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
> };
>  };
>
> @@ -283,6 +292,11 @@
> regulator-name = "vcc-rtc";
>  };
>
> +_drivevbus {

Please keep the nodes in alphabetical order. Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +   regulator-name = "usb0-vbus";
> +   status = "okay";
> +};
> +
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins_a>;
> @@ -295,6 +309,13 @@
> status = "okay";
>  };
>
> +_otg {
> +   dr_mode = "otg";
> +   status = "okay";
> +};
> +
>   {
> +   usb0_id_det-gpios = < 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
> +   usb0_vbus-supply = <_drivevbus>;
> status = "okay";
>  };
> --
> 2.7.4
>

[PATCH v7 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

[Oza Pawandeep]

Implement error_resume callback in DPC so, after DPC trigger event
enumerates the devices beneath.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 7838b02..352f7f0 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -146,16 +146,30 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 
 static void dpc_wait_link_inactive(struct dpc_dev *dpc)
 {
-   unsigned long timeout = jiffies + HZ;
struct pci_dev *pdev = dpc->dev->port;
-   struct device *dev = >dev->device;
-   u16 lnk_status;
bool active = false;
 
pci_wait_for_link(pdev, active);
 }
 
 /**
+ * dpc_error_resume - enumerate the devices beneath
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver during nonfatal recovery.
+ */
+static void dpc_error_resume(struct pci_dev *pdev)
+{
+   bool active = true;
+
+   if (pci_wait_for_link(pdev, active)) {
+   pci_lock_rescan_remove();
+   pci_rescan_bus(pdev->bus);
+   pci_unlock_rescan_remove();
+   }
+}
+
+/**
  * dpc_reset_link - reset link DPC  routine
  * @dev: pointer to Root Port's pci_dev data structure
  *
@@ -413,6 +427,7 @@ static void dpc_remove(struct pcie_device *dev)
.service= PCIE_PORT_SERVICE_DPC,
.probe  = dpc_probe,
.remove = dpc_remove,
+   .error_resume   = dpc_error_resume,
.reset_link = dpc_reset_link,
 };
 
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index 05385c0..c4876ab 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -236,6 +236,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
  * @state: error state
  * @error_mesg: message to print
  * @cb: callback to be broadcasted
+ * @severity: error severity
  *
  * Invoked during error recovery process. Once being invoked, the content
  * of error severity will be broadcasted to all downstream drivers in a
@@ -244,7 +245,8 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
 static pci_ers_result_t broadcast_error_message(struct pci_dev *dev,
enum pci_channel_state state,
char *error_mesg,
-   int (*cb)(struct pci_dev *, void *))
+   int (*cb)(struct pci_dev *, void *),
+   int severity)
 {
struct aer_broadcast_data result_data;
 
@@ -256,6 +258,15 @@ static pci_ers_result_t broadcast_error_message(struct 
pci_dev *dev,
result_data.result = PCI_ERS_RESULT_RECOVERED;
 
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+   /* If DPC is triggered, call resume error hanlder
+* because, at this point we can safely assume that
+* link recovery has happened.
+*/
+   if ((severity == DPC_FATAL) &&
+   (cb == report_resume)) {
+   cb(dev, NULL);
+   return PCI_ERS_RESULT_RECOVERED;
+   }
/*
 * If the error is reported by a bridge, we think this error
 * is related to the downstream link of the bridge, so we
@@ -305,7 +316,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"error_detected",
-   report_error_detected);
+   report_error_detected,
+   severity);
 
if ((severity == AER_FATAL) ||
(severity == DPC_FATAL)) {
@@ -318,7 +330,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"mmio_enabled",
-   report_mmio_enabled);
+   report_mmio_enabled,
+   severity);
 
if (status == PCI_ERS_RESULT_NEED_RESET) {
/*
@@ -329,7 +342,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"slot_reset",
-   report_slot_reset);
+   report_slot_reset,
+   severity);
}
 
if (status != PCI_ERS_RESULT_RECOVERED)
@@ -338,7 +352,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
broadcast_error_message(dev,
state,
"resume",
-   report_resume);
+   report_resume,
+   severity);
 
dev_info(>dev, "Device recovery successful\n");
mutex_unlock(_err_recovery_lock);
-- 
Qualcomm Datacenter Technologies, 

[PATCH v7 5/7] PCI/AER: Unify aer error defines at single space

[Oza Pawandeep]

This patch moves AER error defines to drivers/pci/pci.h.
So that it unifies the error repoting codes at single place along with dpc

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6402f7f..216ee47 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -56,6 +56,7 @@
 #include 
 
 #include "apei-internal.h"
+#include "../../pci/pci.h"
 
 #define GHES_PFX   "GHES: "
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 3b79593..2e19953 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,7 +343,11 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
-#define DPC_FATAL  4
+#define AER_NONFATAL   0
+#define AER_FATAL  1
+#define AER_CORRECTABLE2
+
+#define DPC_FATAL  4
 
 void pci_do_recovery(struct pci_dev *dev, int severity);
 
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 54c4b69..cd3ad55 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "aerdrv.h"
+#include "../../pci.h"
 #include 
 
 #define AER_AGENT_RECEIVER 0
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 8f87bbe..3eac8ed 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -11,10 +11,6 @@
 #include 
 #include 
 
-#define AER_NONFATAL   0
-#define AER_FATAL  1
-#define AER_CORRECTABLE2
-
 struct pci_dev;
 
 struct aer_header_log_regs {
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 4/7] PCI/DPC: Unify and plumb error handling into DPC

[Oza Pawandeep]

Current DPC driver does not do recovery, e.g. calling end-point's driver's
callbacks, which sanitize the sw.

DPC driver implements link_reset callback, and calls pci_do_recovery.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 665ff6c..3b79593 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,8 +343,12 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
+#define DPC_FATAL  4
+
 void pci_do_recovery(struct pci_dev *dev, int severity);
 
+
+
 #ifdef CONFIG_PCIE_PTM
 void pci_ptm_init(struct pci_dev *dev);
 #else
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 2d976a6..b5c9fbd 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include "../pci.h"
+#include "portdrv.h"
+
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
 
 struct rp_pio_header_log_regs {
u32 dw0;
@@ -67,6 +70,60 @@ struct dpc_dev {
"Memory Request Completion Timeout", /* Bit Position 18 */
 };
 
+static int find_dpc_dev_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver;
+   struct device **dev;
+
+   dev = (struct device **) data;
+
+   if (device->bus == _port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *dev = device;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+static struct device *pci_find_dpc_dev(struct pci_dev *pdev)
+{
+   struct device *dev = NULL;
+
+   device_for_each_child(>dev, , find_dpc_dev_iter);
+
+   return dev;
+}
+
+static int find_dpc_service_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver, **drv;
+
+   drv = (struct pcie_port_service_driver **) data;
+
+   if (device->bus == _port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *drv = service_driver;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+struct pcie_port_service_driver *pci_find_dpc_service(struct pci_dev *dev)
+{
+   struct pcie_port_service_driver *drv = NULL;
+
+   device_for_each_child(>dev, , find_dpc_service_iter);
+
+   return drv;
+}
+EXPORT_SYMBOL(pci_find_dpc_service);
+
 static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 {
unsigned long timeout = jiffies + HZ;
@@ -104,11 +161,23 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
dev_warn(dev, "Link state not disabled for DPC event\n");
 }
 
-static void interrupt_event_handler(struct work_struct *work)
+/**
+ * dpc_reset_link - reset link DPC  routine
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver when performing link reset at Root Port.
+ */
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
 {
-   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
-   struct pci_dev *dev, *temp, *pdev = dpc->dev->port;
struct pci_bus *parent = pdev->subordinate;
+   struct pci_dev *dev, *temp;
+   struct dpc_dev *dpc;
+   struct pcie_device *pciedev;
+   struct device *devdpc;
+
+   devdpc = pci_find_dpc_dev(pdev);
+   pciedev = to_pcie_device(devdpc);
+   dpc = get_service_data(pciedev);
 
pci_lock_rescan_remove();
list_for_each_entry_safe_reverse(dev, temp, >devices,
@@ -125,7 +194,7 @@ static void interrupt_event_handler(struct work_struct 
*work)
 
dpc_wait_link_inactive(dpc);
if (dpc->rp && dpc_wait_rp_inactive(dpc))
-   return;
+   return PCI_ERS_RESULT_DISCONNECT;
if (dpc->rp && dpc->rp_pio_status) {
pci_write_config_dword(pdev,
  dpc->cap_pos + PCI_EXP_DPC_RP_PIO_STATUS,
@@ -135,6 +204,17 @@ static void interrupt_event_handler(struct work_struct 
*work)
 
pci_write_config_word(pdev, dpc->cap_pos + PCI_EXP_DPC_STATUS,
PCI_EXP_DPC_STATUS_TRIGGER | PCI_EXP_DPC_STATUS_INTERRUPT);
+
+   return PCI_ERS_RESULT_RECOVERED;
+}
+
+static void interrupt_event_handler(struct work_struct *work)
+{
+   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
+   struct pci_dev *pdev = dpc->dev->port;
+
+   /* From DPC point of view error is always FATAL. */
+   pci_do_recovery(pdev, DPC_FATAL);
 }
 
 static void dpc_rp_pio_print_tlp_header(struct device *dev,
@@ -339,6 +419,7 @@ static void dpc_remove(struct pcie_device *dev)
.service= PCIE_PORT_SERVICE_DPC,

[PATCH v7 6/7] PCI: Unify wait for link active into generic pci

[Oza Pawandeep]

Clients such as pciehp, dpc are using pcie_wait_link_active, which waits
till the link becomes active or inactive.

Made generic function and moved it to drivers/pci/pci.c

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 7bab060..26afeff 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -245,25 +245,12 @@ bool pciehp_check_link_active(struct controller *ctrl)
return ret;
 }
 
-static void __pcie_wait_link_active(struct controller *ctrl, bool active)
+static bool pcie_wait_link_active(struct controller *ctrl)
 {
-   int timeout = 1000;
-
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   while (timeout > 0) {
-   msleep(10);
-   timeout -= 10;
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   }
-   ctrl_dbg(ctrl, "Data Link Layer Link Active not %s in 1000 msec\n",
-   active ? "set" : "cleared");
-}
+   struct pci_dev *pdev = ctrl_dev(ctrl);
+   bool active = true;
 
-static void pcie_wait_link_active(struct controller *ctrl)
-{
-   __pcie_wait_link_active(ctrl, true);
+   return pci_wait_for_link(pdev, active);
 }
 
 static bool pci_bus_check_dev(struct pci_bus *bus, int devfn)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4a7c686..5e7e588 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4079,6 +4079,41 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
return 0;
 }
 
+/**
+ * pci__wait_for_link - Wait for link till its active/inactive
+ * @dev: Bridge device
+ * @active: waiting for active or inactive ?
+ *
+ * Use this to wait till link becomes active or inactive.
+ */
+
+bool pci_wait_for_link(struct pci_dev *pdev, bool active)
+{
+   int timeout = 1000;
+   bool ret;
+   u16 lnk_status;
+
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+
+   while ((ret != active) && (timeout > 0)) {
+   msleep(10);
+   timeout -= 10;
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+   }
+
+   if (ret == active)
+   return true;
+   
+   dev_printk(KERN_DEBUG, >dev,
+  "Data Link Layer Link Active not %s in 1000 msec\n",
+  active ? "set" : "cleared");
+
+   return false;
+}
+EXPORT_SYMBOL(pci_wait_for_link);
+
 void pci_reset_secondary_bus(struct pci_dev *dev)
 {
u16 ctrl;
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index b5c9fbd..7838b02 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -150,15 +150,9 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
struct pci_dev *pdev = dpc->dev->port;
struct device *dev = >dev->device;
u16 lnk_status;
+   bool active = false;
 
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
-   while (lnk_status & PCI_EXP_LNKSTA_DLLLA &&
-   !time_after(jiffies, timeout)) {
-   msleep(10);
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
-   }
-   if (lnk_status & PCI_EXP_LNKSTA_DLLLA)
-   dev_warn(dev, "Link state not disabled for DPC event\n");
+   pci_wait_for_link(pdev, active);
 }
 
 /**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c170c92..f9f6a3d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1201,6 +1201,7 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
 int pci_request_selected_regions(struct pci_dev *, int, const char *);
 int pci_request_selected_regions_exclusive(struct pci_dev *, int, const char 
*);
 void pci_release_selected_regions(struct pci_dev *, int);
+bool pci_wait_for_link(struct pci_dev *pdev, bool active);
 
 /* drivers/pci/bus.c */
 struct pci_bus *pci_bus_get(struct pci_bus *bus);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 5/7] PCI/AER: Unify aer error defines at single space

[Oza Pawandeep]

This patch moves AER error defines to drivers/pci/pci.h.
So that it unifies the error repoting codes at single place along with dpc

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6402f7f..216ee47 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -56,6 +56,7 @@
 #include 
 
 #include "apei-internal.h"
+#include "../../pci/pci.h"
 
 #define GHES_PFX   "GHES: "
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 3b79593..2e19953 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,7 +343,11 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
-#define DPC_FATAL  4
+#define AER_NONFATAL   0
+#define AER_FATAL  1
+#define AER_CORRECTABLE2
+
+#define DPC_FATAL  4
 
 void pci_do_recovery(struct pci_dev *dev, int severity);
 
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 54c4b69..cd3ad55 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "aerdrv.h"
+#include "../../pci.h"
 #include 
 
 #define AER_AGENT_RECEIVER 0
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 8f87bbe..3eac8ed 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -11,10 +11,6 @@
 #include 
 #include 
 
-#define AER_NONFATAL   0
-#define AER_FATAL  1
-#define AER_CORRECTABLE2
-
 struct pci_dev;
 
 struct aer_header_log_regs {
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 4/7] PCI/DPC: Unify and plumb error handling into DPC

[Oza Pawandeep]

Current DPC driver does not do recovery, e.g. calling end-point's driver's
callbacks, which sanitize the sw.

DPC driver implements link_reset callback, and calls pci_do_recovery.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 665ff6c..3b79593 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,8 +343,12 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
+#define DPC_FATAL  4
+
 void pci_do_recovery(struct pci_dev *dev, int severity);
 
+
+
 #ifdef CONFIG_PCIE_PTM
 void pci_ptm_init(struct pci_dev *dev);
 #else
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 2d976a6..b5c9fbd 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include "../pci.h"
+#include "portdrv.h"
+
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
 
 struct rp_pio_header_log_regs {
u32 dw0;
@@ -67,6 +70,60 @@ struct dpc_dev {
"Memory Request Completion Timeout", /* Bit Position 18 */
 };
 
+static int find_dpc_dev_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver;
+   struct device **dev;
+
+   dev = (struct device **) data;
+
+   if (device->bus == _port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *dev = device;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+static struct device *pci_find_dpc_dev(struct pci_dev *pdev)
+{
+   struct device *dev = NULL;
+
+   device_for_each_child(>dev, , find_dpc_dev_iter);
+
+   return dev;
+}
+
+static int find_dpc_service_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver, **drv;
+
+   drv = (struct pcie_port_service_driver **) data;
+
+   if (device->bus == _port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *drv = service_driver;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+struct pcie_port_service_driver *pci_find_dpc_service(struct pci_dev *dev)
+{
+   struct pcie_port_service_driver *drv = NULL;
+
+   device_for_each_child(>dev, , find_dpc_service_iter);
+
+   return drv;
+}
+EXPORT_SYMBOL(pci_find_dpc_service);
+
 static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 {
unsigned long timeout = jiffies + HZ;
@@ -104,11 +161,23 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
dev_warn(dev, "Link state not disabled for DPC event\n");
 }
 
-static void interrupt_event_handler(struct work_struct *work)
+/**
+ * dpc_reset_link - reset link DPC  routine
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver when performing link reset at Root Port.
+ */
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
 {
-   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
-   struct pci_dev *dev, *temp, *pdev = dpc->dev->port;
struct pci_bus *parent = pdev->subordinate;
+   struct pci_dev *dev, *temp;
+   struct dpc_dev *dpc;
+   struct pcie_device *pciedev;
+   struct device *devdpc;
+
+   devdpc = pci_find_dpc_dev(pdev);
+   pciedev = to_pcie_device(devdpc);
+   dpc = get_service_data(pciedev);
 
pci_lock_rescan_remove();
list_for_each_entry_safe_reverse(dev, temp, >devices,
@@ -125,7 +194,7 @@ static void interrupt_event_handler(struct work_struct 
*work)
 
dpc_wait_link_inactive(dpc);
if (dpc->rp && dpc_wait_rp_inactive(dpc))
-   return;
+   return PCI_ERS_RESULT_DISCONNECT;
if (dpc->rp && dpc->rp_pio_status) {
pci_write_config_dword(pdev,
  dpc->cap_pos + PCI_EXP_DPC_RP_PIO_STATUS,
@@ -135,6 +204,17 @@ static void interrupt_event_handler(struct work_struct 
*work)
 
pci_write_config_word(pdev, dpc->cap_pos + PCI_EXP_DPC_STATUS,
PCI_EXP_DPC_STATUS_TRIGGER | PCI_EXP_DPC_STATUS_INTERRUPT);
+
+   return PCI_ERS_RESULT_RECOVERED;
+}
+
+static void interrupt_event_handler(struct work_struct *work)
+{
+   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
+   struct pci_dev *pdev = dpc->dev->port;
+
+   /* From DPC point of view error is always FATAL. */
+   pci_do_recovery(pdev, DPC_FATAL);
 }
 
 static void dpc_rp_pio_print_tlp_header(struct device *dev,
@@ -339,6 +419,7 @@ static void dpc_remove(struct pcie_device *dev)
.service= PCIE_PORT_SERVICE_DPC,
.probe  = 

[PATCH v7 6/7] PCI: Unify wait for link active into generic pci

[Oza Pawandeep]

Clients such as pciehp, dpc are using pcie_wait_link_active, which waits
till the link becomes active or inactive.

Made generic function and moved it to drivers/pci/pci.c

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 7bab060..26afeff 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -245,25 +245,12 @@ bool pciehp_check_link_active(struct controller *ctrl)
return ret;
 }
 
-static void __pcie_wait_link_active(struct controller *ctrl, bool active)
+static bool pcie_wait_link_active(struct controller *ctrl)
 {
-   int timeout = 1000;
-
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   while (timeout > 0) {
-   msleep(10);
-   timeout -= 10;
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   }
-   ctrl_dbg(ctrl, "Data Link Layer Link Active not %s in 1000 msec\n",
-   active ? "set" : "cleared");
-}
+   struct pci_dev *pdev = ctrl_dev(ctrl);
+   bool active = true;
 
-static void pcie_wait_link_active(struct controller *ctrl)
-{
-   __pcie_wait_link_active(ctrl, true);
+   return pci_wait_for_link(pdev, active);
 }
 
 static bool pci_bus_check_dev(struct pci_bus *bus, int devfn)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4a7c686..5e7e588 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4079,6 +4079,41 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
return 0;
 }
 
+/**
+ * pci__wait_for_link - Wait for link till its active/inactive
+ * @dev: Bridge device
+ * @active: waiting for active or inactive ?
+ *
+ * Use this to wait till link becomes active or inactive.
+ */
+
+bool pci_wait_for_link(struct pci_dev *pdev, bool active)
+{
+   int timeout = 1000;
+   bool ret;
+   u16 lnk_status;
+
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+
+   while ((ret != active) && (timeout > 0)) {
+   msleep(10);
+   timeout -= 10;
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+   }
+
+   if (ret == active)
+   return true;
+   
+   dev_printk(KERN_DEBUG, >dev,
+  "Data Link Layer Link Active not %s in 1000 msec\n",
+  active ? "set" : "cleared");
+
+   return false;
+}
+EXPORT_SYMBOL(pci_wait_for_link);
+
 void pci_reset_secondary_bus(struct pci_dev *dev)
 {
u16 ctrl;
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index b5c9fbd..7838b02 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -150,15 +150,9 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
struct pci_dev *pdev = dpc->dev->port;
struct device *dev = >dev->device;
u16 lnk_status;
+   bool active = false;
 
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
-   while (lnk_status & PCI_EXP_LNKSTA_DLLLA &&
-   !time_after(jiffies, timeout)) {
-   msleep(10);
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, _status);
-   }
-   if (lnk_status & PCI_EXP_LNKSTA_DLLLA)
-   dev_warn(dev, "Link state not disabled for DPC event\n");
+   pci_wait_for_link(pdev, active);
 }
 
 /**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c170c92..f9f6a3d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1201,6 +1201,7 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
 int pci_request_selected_regions(struct pci_dev *, int, const char *);
 int pci_request_selected_regions_exclusive(struct pci_dev *, int, const char 
*);
 void pci_release_selected_regions(struct pci_dev *, int);
+bool pci_wait_for_link(struct pci_dev *pdev, bool active);
 
 /* drivers/pci/bus.c */
 struct pci_bus *pci_bus_get(struct pci_bus *bus);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

[Oza Pawandeep]

Implement error_resume callback in DPC so, after DPC trigger event
enumerates the devices beneath.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 7838b02..352f7f0 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -146,16 +146,30 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 
 static void dpc_wait_link_inactive(struct dpc_dev *dpc)
 {
-   unsigned long timeout = jiffies + HZ;
struct pci_dev *pdev = dpc->dev->port;
-   struct device *dev = >dev->device;
-   u16 lnk_status;
bool active = false;
 
pci_wait_for_link(pdev, active);
 }
 
 /**
+ * dpc_error_resume - enumerate the devices beneath
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver during nonfatal recovery.
+ */
+static void dpc_error_resume(struct pci_dev *pdev)
+{
+   bool active = true;
+
+   if (pci_wait_for_link(pdev, active)) {
+   pci_lock_rescan_remove();
+   pci_rescan_bus(pdev->bus);
+   pci_unlock_rescan_remove();
+   }
+}
+
+/**
  * dpc_reset_link - reset link DPC  routine
  * @dev: pointer to Root Port's pci_dev data structure
  *
@@ -413,6 +427,7 @@ static void dpc_remove(struct pcie_device *dev)
.service= PCIE_PORT_SERVICE_DPC,
.probe  = dpc_probe,
.remove = dpc_remove,
+   .error_resume   = dpc_error_resume,
.reset_link = dpc_reset_link,
 };
 
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index 05385c0..c4876ab 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -236,6 +236,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
  * @state: error state
  * @error_mesg: message to print
  * @cb: callback to be broadcasted
+ * @severity: error severity
  *
  * Invoked during error recovery process. Once being invoked, the content
  * of error severity will be broadcasted to all downstream drivers in a
@@ -244,7 +245,8 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
 static pci_ers_result_t broadcast_error_message(struct pci_dev *dev,
enum pci_channel_state state,
char *error_mesg,
-   int (*cb)(struct pci_dev *, void *))
+   int (*cb)(struct pci_dev *, void *),
+   int severity)
 {
struct aer_broadcast_data result_data;
 
@@ -256,6 +258,15 @@ static pci_ers_result_t broadcast_error_message(struct 
pci_dev *dev,
result_data.result = PCI_ERS_RESULT_RECOVERED;
 
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+   /* If DPC is triggered, call resume error hanlder
+* because, at this point we can safely assume that
+* link recovery has happened.
+*/
+   if ((severity == DPC_FATAL) &&
+   (cb == report_resume)) {
+   cb(dev, NULL);
+   return PCI_ERS_RESULT_RECOVERED;
+   }
/*
 * If the error is reported by a bridge, we think this error
 * is related to the downstream link of the bridge, so we
@@ -305,7 +316,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"error_detected",
-   report_error_detected);
+   report_error_detected,
+   severity);
 
if ((severity == AER_FATAL) ||
(severity == DPC_FATAL)) {
@@ -318,7 +330,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"mmio_enabled",
-   report_mmio_enabled);
+   report_mmio_enabled,
+   severity);
 
if (status == PCI_ERS_RESULT_NEED_RESET) {
/*
@@ -329,7 +342,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"slot_reset",
-   report_slot_reset);
+   report_slot_reset,
+   severity);
}
 
if (status != PCI_ERS_RESULT_RECOVERED)
@@ -338,7 +352,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
broadcast_error_message(dev,
state,
"resume",
-   report_resume);
+   report_resume,
+   severity);
 
dev_info(>dev, "Device recovery successful\n");
mutex_unlock(_err_recovery_lock);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate 

[PATCH v7 1/7] PCI/AER: Rename error recovery to generic pci naming

[Oza Pawandeep]

This patch renames error recovery to generic name with pci prefix

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 7448052..6cb1b36 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -482,7 +482,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
 }
 
 /**
- * do_recovery - handle nonfatal/fatal error recovery process
+ * pci_do_recovery - handle nonfatal/fatal error recovery process
  * @dev: pointer to a pci_dev data structure of agent detecting an error
  * @severity: error severity type
  *
@@ -490,7 +490,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
  * error detected message to all downstream drivers within a hierarchy in
  * question and return the returned code.
  */
-static void do_recovery(struct pci_dev *dev, int severity)
+static void pci_do_recovery(struct pci_dev *dev, int severity)
 {
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
@@ -569,7 +569,7 @@ static void handle_error_source(struct pcie_device *aerdev,
pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS,
info->status);
} else
-   do_recovery(dev, info->severity);
+   pci_do_recovery(dev, info->severity);
 }
 
 #ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -633,7 +633,7 @@ static void aer_recover_work_func(struct work_struct *work)
continue;
}
cper_print_aer(pdev, entry.severity, entry.regs);
-   do_recovery(pdev, entry.severity);
+   pci_do_recovery(pdev, entry.severity);
pci_dev_put(pdev);
}
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 1/7] PCI/AER: Rename error recovery to generic pci naming

[Oza Pawandeep]

This patch renames error recovery to generic name with pci prefix

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 7448052..6cb1b36 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -482,7 +482,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
 }
 
 /**
- * do_recovery - handle nonfatal/fatal error recovery process
+ * pci_do_recovery - handle nonfatal/fatal error recovery process
  * @dev: pointer to a pci_dev data structure of agent detecting an error
  * @severity: error severity type
  *
@@ -490,7 +490,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
  * error detected message to all downstream drivers within a hierarchy in
  * question and return the returned code.
  */
-static void do_recovery(struct pci_dev *dev, int severity)
+static void pci_do_recovery(struct pci_dev *dev, int severity)
 {
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
@@ -569,7 +569,7 @@ static void handle_error_source(struct pcie_device *aerdev,
pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS,
info->status);
} else
-   do_recovery(dev, info->severity);
+   pci_do_recovery(dev, info->severity);
 }
 
 #ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -633,7 +633,7 @@ static void aer_recover_work_func(struct work_struct *work)
continue;
}
cper_print_aer(pdev, entry.severity, entry.regs);
-   do_recovery(pdev, entry.severity);
+   pci_do_recovery(pdev, entry.severity);
pci_dev_put(pdev);
}
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 2/7] PCI/AER: factor out error reporting from AER

[Oza Pawandeep]

This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
DPC should be able to register callbacks and attmept recovery when DPC
trigger event occurs.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f6b58b3..665ff6c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -342,6 +342,9 @@ static inline resource_size_t pci_resource_alignment(struct 
pci_dev *dev,
 
 void pci_enable_acs(struct pci_dev *dev);
 
+/* PCI error reporting and recovery */
+void pci_do_recovery(struct pci_dev *dev, int severity);
+
 #ifdef CONFIG_PCIE_PTM
 void pci_ptm_init(struct pci_dev *dev);
 #else
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 223e4c3..d669497 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -6,7 +6,7 @@
 # Build PCI Express ASPM if needed
 obj-$(CONFIG_PCIEASPM) += aspm.o
 
-pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o
+pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o 
pcie-err.o
 pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o
 
 obj-$(CONFIG_PCIEPORTBUS)  += pcieportdrv.o
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 5449e5c..bc9db53 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -76,36 +76,6 @@ struct aer_rpc {
 */
 };
 
-struct aer_broadcast_data {
-   enum pci_channel_state state;
-   enum pci_ers_result result;
-};
-
-static inline pci_ers_result_t merge_result(enum pci_ers_result orig,
-   enum pci_ers_result new)
-{
-   if (new == PCI_ERS_RESULT_NO_AER_DRIVER)
-   return PCI_ERS_RESULT_NO_AER_DRIVER;
-
-   if (new == PCI_ERS_RESULT_NONE)
-   return orig;
-
-   switch (orig) {
-   case PCI_ERS_RESULT_CAN_RECOVER:
-   case PCI_ERS_RESULT_RECOVERED:
-   orig = new;
-   break;
-   case PCI_ERS_RESULT_DISCONNECT:
-   if (new == PCI_ERS_RESULT_NEED_RESET)
-   orig = PCI_ERS_RESULT_NEED_RESET;
-   break;
-   default:
-   break;
-   }
-
-   return orig;
-}
-
 extern struct bus_type pcie_port_bus_type;
 void aer_isr(struct work_struct *work);
 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 6cb1b36..7934de0 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include "aerdrv.h"
+#include "../../pci.h"
 
 #definePCI_EXP_AER_FLAGS   (PCI_EXP_DEVCTL_CERE | 
PCI_EXP_DEVCTL_NFERE | \
 PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -234,189 +235,6 @@ static bool find_source_device(struct pci_dev *parent,
return true;
 }
 
-static int report_error_detected(struct pci_dev *dev, void *data)
-{
-   pci_ers_result_t vote;
-   const struct pci_error_handlers *err_handler;
-   struct aer_broadcast_data *result_data;
-   result_data = (struct aer_broadcast_data *) data;
-
-   device_lock(>dev);
-   dev->error_state = result_data->state;
-
-   if (!dev->driver ||
-   !dev->driver->err_handler ||
-   !dev->driver->err_handler->error_detected) {
-   if (result_data->state == pci_channel_io_frozen &&
-   dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
-   /*
-* In case of fatal recovery, if one of down-
-* stream device has no driver. We might be
-* unable to recover because a later insmod
-* of a driver for this device is unaware of
-* its hw state.
-*/
-   dev_printk(KERN_DEBUG, >dev, "device has %s\n",
-  dev->driver ?
-  "no AER-aware driver" : "no driver");
-   }
-
-   /*
-* If there's any device in the subtree that does not
-* have an error_detected callback, returning
-* PCI_ERS_RESULT_NO_AER_DRIVER prevents calling of
-* the subsequent mmio_enabled/slot_reset/resume
-* callbacks of "any" device in the subtree. All the
-* devices in the subtree are left in the error state
-* without recovery.
-*/
-
-   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
-   vote = PCI_ERS_RESULT_NO_AER_DRIVER;
-   else
-   vote = PCI_ERS_RESULT_NONE;
-   } else {
-   err_handler = dev->driver->err_handler;
-   vote = err_handler->error_detected(dev, 

[PATCH v7 3/7] PCI/ERR: add mutex to synchronize recovery

[Oza Pawandeep]

This patch protects pci_do_recovery with mutex.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index a532fe0..8318c84 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -20,6 +20,8 @@
 #include 
 #include "portdrv.h"
 
+static DEFINE_MUTEX(pci_err_recovery_lock);
+
 struct aer_broadcast_data {
enum pci_channel_state state;
enum pci_ers_result result;
@@ -283,6 +285,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
 
+   mutex_lock(_err_recovery_lock);
+
if (severity == AER_FATAL)
state = pci_channel_io_frozen;
else
@@ -326,9 +330,11 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
report_resume);
 
dev_info(>dev, "Device recovery successful\n");
+   mutex_unlock(_err_recovery_lock);
return;
 
 failed:
/* TODO: Should kernel panic here? */
dev_info(>dev, "Device recovery failed\n");
+   mutex_unlock(_err_recovery_lock);
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 2/7] PCI/AER: factor out error reporting from AER

[Oza Pawandeep]

This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
DPC should be able to register callbacks and attmept recovery when DPC
trigger event occurs.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f6b58b3..665ff6c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -342,6 +342,9 @@ static inline resource_size_t pci_resource_alignment(struct 
pci_dev *dev,
 
 void pci_enable_acs(struct pci_dev *dev);
 
+/* PCI error reporting and recovery */
+void pci_do_recovery(struct pci_dev *dev, int severity);
+
 #ifdef CONFIG_PCIE_PTM
 void pci_ptm_init(struct pci_dev *dev);
 #else
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 223e4c3..d669497 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -6,7 +6,7 @@
 # Build PCI Express ASPM if needed
 obj-$(CONFIG_PCIEASPM) += aspm.o
 
-pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o
+pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o 
pcie-err.o
 pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o
 
 obj-$(CONFIG_PCIEPORTBUS)  += pcieportdrv.o
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 5449e5c..bc9db53 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -76,36 +76,6 @@ struct aer_rpc {
 */
 };
 
-struct aer_broadcast_data {
-   enum pci_channel_state state;
-   enum pci_ers_result result;
-};
-
-static inline pci_ers_result_t merge_result(enum pci_ers_result orig,
-   enum pci_ers_result new)
-{
-   if (new == PCI_ERS_RESULT_NO_AER_DRIVER)
-   return PCI_ERS_RESULT_NO_AER_DRIVER;
-
-   if (new == PCI_ERS_RESULT_NONE)
-   return orig;
-
-   switch (orig) {
-   case PCI_ERS_RESULT_CAN_RECOVER:
-   case PCI_ERS_RESULT_RECOVERED:
-   orig = new;
-   break;
-   case PCI_ERS_RESULT_DISCONNECT:
-   if (new == PCI_ERS_RESULT_NEED_RESET)
-   orig = PCI_ERS_RESULT_NEED_RESET;
-   break;
-   default:
-   break;
-   }
-
-   return orig;
-}
-
 extern struct bus_type pcie_port_bus_type;
 void aer_isr(struct work_struct *work);
 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 6cb1b36..7934de0 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include "aerdrv.h"
+#include "../../pci.h"
 
 #definePCI_EXP_AER_FLAGS   (PCI_EXP_DEVCTL_CERE | 
PCI_EXP_DEVCTL_NFERE | \
 PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -234,189 +235,6 @@ static bool find_source_device(struct pci_dev *parent,
return true;
 }
 
-static int report_error_detected(struct pci_dev *dev, void *data)
-{
-   pci_ers_result_t vote;
-   const struct pci_error_handlers *err_handler;
-   struct aer_broadcast_data *result_data;
-   result_data = (struct aer_broadcast_data *) data;
-
-   device_lock(>dev);
-   dev->error_state = result_data->state;
-
-   if (!dev->driver ||
-   !dev->driver->err_handler ||
-   !dev->driver->err_handler->error_detected) {
-   if (result_data->state == pci_channel_io_frozen &&
-   dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
-   /*
-* In case of fatal recovery, if one of down-
-* stream device has no driver. We might be
-* unable to recover because a later insmod
-* of a driver for this device is unaware of
-* its hw state.
-*/
-   dev_printk(KERN_DEBUG, >dev, "device has %s\n",
-  dev->driver ?
-  "no AER-aware driver" : "no driver");
-   }
-
-   /*
-* If there's any device in the subtree that does not
-* have an error_detected callback, returning
-* PCI_ERS_RESULT_NO_AER_DRIVER prevents calling of
-* the subsequent mmio_enabled/slot_reset/resume
-* callbacks of "any" device in the subtree. All the
-* devices in the subtree are left in the error state
-* without recovery.
-*/
-
-   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
-   vote = PCI_ERS_RESULT_NO_AER_DRIVER;
-   else
-   vote = PCI_ERS_RESULT_NONE;
-   } else {
-   err_handler = dev->driver->err_handler;
-   vote = err_handler->error_detected(dev, result_data->state);
-   }

[PATCH v7 3/7] PCI/ERR: add mutex to synchronize recovery

[Oza Pawandeep]

This patch protects pci_do_recovery with mutex.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index a532fe0..8318c84 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -20,6 +20,8 @@
 #include 
 #include "portdrv.h"
 
+static DEFINE_MUTEX(pci_err_recovery_lock);
+
 struct aer_broadcast_data {
enum pci_channel_state state;
enum pci_ers_result result;
@@ -283,6 +285,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
 
+   mutex_lock(_err_recovery_lock);
+
if (severity == AER_FATAL)
state = pci_channel_io_frozen;
else
@@ -326,9 +330,11 @@ void pci_do_recovery(struct pci_dev *dev, int severity)
report_resume);
 
dev_info(>dev, "Device recovery successful\n");
+   mutex_unlock(_err_recovery_lock);
return;
 
 failed:
/* TODO: Should kernel panic here? */
dev_info(>dev, "Device recovery failed\n");
+   mutex_unlock(_err_recovery_lock);
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 0/7] Address error and recovery for AER and DPC

[Oza Pawandeep]

This patch set brings in error handling support for DPC

The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER gets triggered, but also when DPC get
triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.

DPC should enumerate the devices after recovering the link, which is
achieved by implementing error_resume callback.

Changes since v6:
Sinan's and Stefan's comments implemented.
> reordered patch 6 and 7
> cleaned up
Changes since v5:
Sinan's and Keith's comments incorporated.
> made separate patch for mutex
> unified error repotting codes into driver/pci/pci.h
> got rid of wait link active/inactive and
  made generic function in driver/pci/pci.c
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and recovery
> removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error Message,
the Requester ID from the Message is recorded in the DPC Error
Source ID register and that Message is discarded and not forwarded Upstream.
"
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check

Oza Pawandeep (7):
  PCI/AER: Rename error recovery to generic pci naming
  PCI/AER: factor out error reporting from AER
  PCI/ERR: add mutex to synchronize recovery
  PCI/DPC: Unify and plumb error handling into DPC
  PCI/AER: Unify aer error defines at single space
  PCI/DPC: Enumerate the devices after DPC trigger event
  PCI: Unify wait for link active into generic pci

 drivers/acpi/apei/ghes.c   |   1 +
 drivers/pci/hotplug/pciehp_hpc.c   |  21 +-
 drivers/pci/pci.c  |  39 +++-
 drivers/pci/pci.h  |  11 +
 drivers/pci/pcie/Makefile  |   2 +-
 drivers/pci/pcie/aer/aerdrv.h  |  30 ---
 drivers/pci/pcie/aer/aerdrv_core.c | 293 +-
 drivers/pci/pcie/aer/aerdrv_errprint.c |   1 +
 drivers/pci/pcie/pcie-dpc.c| 115 ++-
 drivers/pci/pcie/pcie-err.c| 366 +
 drivers/pci/pcie/portdrv.h |   2 +
 include/linux/aer.h|   4 -
 include/linux/pci.h|   1 +
 13 files changed, 534 insertions(+), 352 deletions(-)
 create mode 100644 drivers/pci/pcie/pcie-err.c

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 0/7] Address error and recovery for AER and DPC

[Oza Pawandeep]

This patch set brings in error handling support for DPC

The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER gets triggered, but also when DPC get
triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.

DPC should enumerate the devices after recovering the link, which is
achieved by implementing error_resume callback.

Changes since v6:
Sinan's and Stefan's comments implemented.
> reordered patch 6 and 7
> cleaned up
Changes since v5:
Sinan's and Keith's comments incorporated.
> made separate patch for mutex
> unified error repotting codes into driver/pci/pci.h
> got rid of wait link active/inactive and
  made generic function in driver/pci/pci.c
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and recovery
> removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error Message,
the Requester ID from the Message is recorded in the DPC Error
Source ID register and that Message is discarded and not forwarded Upstream.
"
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check

Oza Pawandeep (7):
  PCI/AER: Rename error recovery to generic pci naming
  PCI/AER: factor out error reporting from AER
  PCI/ERR: add mutex to synchronize recovery
  PCI/DPC: Unify and plumb error handling into DPC
  PCI/AER: Unify aer error defines at single space
  PCI/DPC: Enumerate the devices after DPC trigger event
  PCI: Unify wait for link active into generic pci

 drivers/acpi/apei/ghes.c   |   1 +
 drivers/pci/hotplug/pciehp_hpc.c   |  21 +-
 drivers/pci/pci.c  |  39 +++-
 drivers/pci/pci.h  |  11 +
 drivers/pci/pcie/Makefile  |   2 +-
 drivers/pci/pcie/aer/aerdrv.h  |  30 ---
 drivers/pci/pcie/aer/aerdrv_core.c | 293 +-
 drivers/pci/pcie/aer/aerdrv_errprint.c |   1 +
 drivers/pci/pcie/pcie-dpc.c| 115 ++-
 drivers/pci/pcie/pcie-err.c| 366 +
 drivers/pci/pcie/portdrv.h |   2 +
 include/linux/aer.h|   4 -
 include/linux/pci.h|   1 +
 13 files changed, 534 insertions(+), 352 deletions(-)
 create mode 100644 drivers/pci/pcie/pcie-err.c

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Tom Lendacky]

On 1/19/2018 11:25 PM, Gabriel C wrote:
> 2018-01-20 5:02 GMT+01:00 Laura Abbott :
>> On 01/19/2018 06:23 PM, Gabriel C wrote:
>>>
>>> 2018-01-20 2:23 GMT+01:00 Laura Abbott :

 Hi,
>>>
>>>
>>> Hi ,
>>>

 Fedora got multiple reports of an early bootup crash post -rc8.
 Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
 parameters for SME PGD mapping") . It doesn't revert cleanly
 but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
 as well it boots up fine.

 Annoyingly, I can't seem to get any actual kernel logs even with
 earlyprintk. It just reboots immediately (triple fault?). This
 happens on both of my Lenovo machines and I can ask other reporters
 for details as well.

>>>
>>> I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
>>> on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
>>> on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
>>> disabled.
>>>
>>> Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
>>> current master/rc8++ without to see something like this.
>>>
>>> Also we pushed these patches on 4.14.13/14 and didn't got any reports
>>> about
>>> something like this.
>>>
>>> What Lenovo boxes are these ? maybe I find one to reproduce.
>>>
>>>
 $ git bisect log
 # bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
 'trace-v4.15-rc4-3' of
 git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
 # good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
 git bisect start 'origin/master' 'v4.15-rc8'
 # bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
 'mmc-v4.15-rc2-3' of
 git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
 git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
 # good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
 'mac80211-for-davem-2018-01-15' of
 git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
 git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
 # good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
 'x86-pti-for-linus' of
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
 git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
 # bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
 Prevent
 use after free
 git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
 # good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
 Remove
 init_bsp_APIC()"
 git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
 # bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
 reduce parameters for SME PGD mapping
 git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
 # good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
 register
 saving in the __enc_copy() assembly code
 git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
 # first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
 Use a
 struct to reduce parameters for SME PGD mapping


 Configuration is at

 https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
 Note that I do think this is something in the Fedora configuration
 because a generic "make defconfig" booted just fine.
>>>
>>>
>>> But maybe some of the Fedora patches ?
>>>
>>> Can you try an kernel with the config but without any patches ?
>>> Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?
>>>
>>
>> The bisect was a vanilla kernel without Fedora patches.
> 
> Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
> Workstation  ( EPYC CPU )

I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.

>  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
> I disabled Selinux since I don't use it here and module  signing.
> 
> Also with your config my serial setup won't work and the kernel hangs
> but mem_encrypt=on/off works just fine.

If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?

> 
> Also I notice on the Workstation it takes forever to boot untill
> 'DMA-API' reports out-of-memory
> ( dunno how much memory it need but the box has 128GB of RAM )..

I haven't seen this before.

Thanks,
Tom

> 
> 
> Can you 

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Tom Lendacky]

On 1/19/2018 11:25 PM, Gabriel C wrote:
> 2018-01-20 5:02 GMT+01:00 Laura Abbott :
>> On 01/19/2018 06:23 PM, Gabriel C wrote:
>>>
>>> 2018-01-20 2:23 GMT+01:00 Laura Abbott :

 Hi,
>>>
>>>
>>> Hi ,
>>>

 Fedora got multiple reports of an early bootup crash post -rc8.
 Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
 parameters for SME PGD mapping") . It doesn't revert cleanly
 but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
 as well it boots up fine.

 Annoyingly, I can't seem to get any actual kernel logs even with
 earlyprintk. It just reboots immediately (triple fault?). This
 happens on both of my Lenovo machines and I can ask other reporters
 for details as well.

>>>
>>> I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
>>> on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
>>> on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
>>> disabled.
>>>
>>> Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
>>> current master/rc8++ without to see something like this.
>>>
>>> Also we pushed these patches on 4.14.13/14 and didn't got any reports
>>> about
>>> something like this.
>>>
>>> What Lenovo boxes are these ? maybe I find one to reproduce.
>>>
>>>
 $ git bisect log
 # bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
 'trace-v4.15-rc4-3' of
 git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
 # good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
 git bisect start 'origin/master' 'v4.15-rc8'
 # bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
 'mmc-v4.15-rc2-3' of
 git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
 git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
 # good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
 'mac80211-for-davem-2018-01-15' of
 git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
 git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
 # good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
 'x86-pti-for-linus' of
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
 git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
 # bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
 Prevent
 use after free
 git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
 # good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
 Remove
 init_bsp_APIC()"
 git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
 # bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
 reduce parameters for SME PGD mapping
 git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
 # good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
 register
 saving in the __enc_copy() assembly code
 git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
 # first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
 Use a
 struct to reduce parameters for SME PGD mapping


 Configuration is at

 https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
 Note that I do think this is something in the Fedora configuration
 because a generic "make defconfig" booted just fine.
>>>
>>>
>>> But maybe some of the Fedora patches ?
>>>
>>> Can you try an kernel with the config but without any patches ?
>>> Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?
>>>
>>
>> The bisect was a vanilla kernel without Fedora patches.
> 
> Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
> Workstation  ( EPYC CPU )

I've tried multiple config combinations on my EPYC system and have not
been able to reproduce this issue and have not had any boot issues with
mem_encrypt=on or mem_encrypt=off.  I don't have access to a non-AMD box
at the moment, but I'm really scratching my head on this one.

>  with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
> I disabled Selinux since I don't use it here and module  signing.
> 
> Also with your config my serial setup won't work and the kernel hangs
> but mem_encrypt=on/off works just fine.

If your using the EPYC serial device and you haven't enabled legacy
serial device support (if your BIOS supports that), then you're using
it as a platform device.  The fedora config has not set the
CONFIG_X86_AMD_PLATFORM_DEVICE setting so you won't get the module
to load and give you serial output.

I'm confused when you say the kernel hangs but mem_encrypt=on/off works
just fine, can you explain that a bit more?

> 
> Also I notice on the Workstation it takes forever to boot untill
> 'DMA-API' reports out-of-memory
> ( dunno how much memory it need but the box has 128GB of RAM )..

I haven't seen this before.

Thanks,
Tom

> 
> 
> Can you tell us your Lenovo models  please  ?
> 

[PATCH] scsi: 3ware: use pci_iounmap instead of iounmap

[Christophe JAILLET]

'base_addr' has been mapped using 'pci_iomap()'. It should be freed with
the corresponding 'pci_iounmap()' instead of 'iomap()'.

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/3w-sas.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index cf9f2a09b47d..231b04dd9076 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -1692,7 +1692,7 @@ static int twl_probe(struct pci_dev *pdev, const struct 
pci_device_id *dev_id)
pci_disable_msi(pdev);
scsi_remove_host(host);
 out_iounmap:
-   iounmap(tw_dev->base_addr);
+   pci_iounmap(pdev, tw_dev->base_addr);
 out_release_mem_region:
pci_release_regions(pdev);
 out_free_device_extension:
@@ -1738,7 +1738,7 @@ static void twl_remove(struct pci_dev *pdev)
pci_disable_msi(pdev);
 
/* Free IO remapping */
-   iounmap(tw_dev->base_addr);
+   pci_iounmap(pdev, tw_dev->base_addr);
 
/* Free up the mem region */
pci_release_regions(pdev);
-- 
2.14.1

[PATCH] scsi: 3ware: use pci_iounmap instead of iounmap

[Christophe JAILLET]

'base_addr' has been mapped using 'pci_iomap()'. It should be freed with
the corresponding 'pci_iounmap()' instead of 'iomap()'.

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/3w-sas.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index cf9f2a09b47d..231b04dd9076 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -1692,7 +1692,7 @@ static int twl_probe(struct pci_dev *pdev, const struct 
pci_device_id *dev_id)
pci_disable_msi(pdev);
scsi_remove_host(host);
 out_iounmap:
-   iounmap(tw_dev->base_addr);
+   pci_iounmap(pdev, tw_dev->base_addr);
 out_release_mem_region:
pci_release_regions(pdev);
 out_free_device_extension:
@@ -1738,7 +1738,7 @@ static void twl_remove(struct pci_dev *pdev)
pci_disable_msi(pdev);
 
/* Free IO remapping */
-   iounmap(tw_dev->base_addr);
+   pci_iounmap(pdev, tw_dev->base_addr);
 
/* Free up the mem region */
pci_release_regions(pdev);
-- 
2.14.1

Re: [PATCH 1/1] ARM: dts: sunxi: Add Olimex A20-SOM204-EVB board

[Chen-Yu Tsai]

On Fri, Jan 19, 2018 at 9:27 PM, Stefan Mavrodiev  wrote:
> On 01/18/2018 04:28 PM, Chen-Yu Tsai wrote:
>>
>> On Thu, Jan 18, 2018 at 6:07 PM, Maxime Ripard
>>  wrote:
>>>
>>> Hi!
>>>
>>> On Mon, Jan 15, 2018 at 12:07:34PM +0200, Stefan Mavrodiev wrote:
>>
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Olimex A20-SOM204-EVB";
>> + compatible = "olimex,a20-olimex-som204-evb", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = 
>> + serial1 = 
>> + serial2 = 
>> + spi0 = 
>> + spi1 = 
>> + ethernet1 = 
>
> ethernet1? if there's a single network interface, it should be
> ethernet0.

 I think this will conflict the gmac alias defined in sun7i-a20.dtsi:

 aliases {
  ethernet0 = 
 };
>>>
>>> We have that? That's bad, but you're right :)
>>>
>> + stat {
>> + label = "a20-som204:green:stat";
>> + gpios = < 8 0 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + led1 {
>> + label = "a20-som204-evb:green:led1";
>> + gpios = < 8 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + led2 {
>> + label = "a20-som204-evb:yellow:led2";
>> + gpios = < 8 11 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>
> You don't have the same prefix between stat and led1/led2. I'm fine
> with both, but you should be consistent :)

 STAT led is on the SOM204 module, while led1/2 on the EVB. Thats why
 they have different prefix.
>>>
>>> Still, the user and the system will see it as a single board, and the
>>> documentation states that it should be the board name. I'm not quite
>>> sure what a good rule would be here. Have you looked at how other
>>> boards dealt with it? Chen-Yu, any opinion on this?
>>
>> Follow the bindings, I guess? I don't think we (sunxi) have dealt
>> with modules that have LEDs or anything that needs to be named after
>> the board.
>>
>> On a related topic, I don't know if you (Stefan / Olimex) want to split
>> this into a .dtsi file for the SoM, and a .dts file for the EVB. It might
>> help your customers?
>
> I'm not sure this will be good ideal. We will have one EVB with all
> possible peripheries. On the other hand, we are planning 3-4 different
> SOM204 modules (A20, A64, RK). I think this will make the dtsi
> incompatible.

Yes. That was what I mentioned in the second half of my reply.

>
> Maybe if there is one dtsi for the base SOM204 module (one for each arch)
> and
> multiple dts for boards with additional features. But this will generate
> 10-20
> dts files. I think this will be better handled using overlays in the uboot.

OK. I'm guessing there's the possibility that some pins or GPIOs get muxed
to different functions depending on what base board is used? How would
you list them, if you only had one .dts file, say for the EVB? Clearly
the SoM cannot work by itself, so it probably doesn't get its own .dts
file.

>
> About the leds, I'm ok to be named after full board name (a20-som204-evb).

Cool.

ChenYu

>>
>> I've tried it previously, and it helps in some ways
>> when you're matching the files to the schematics. But it is confusing
>> when you want the big picture. On the other hand, this is not going to
>> help with supporting different modules on the same baseboard, as the
>> routing, peripherals and labels likely won't match up. Just my two cents.
>>
>> ChenYu
>
> Regards,
> Stefan Mavrodiev

Re: [PATCH 1/1] ARM: dts: sunxi: Add Olimex A20-SOM204-EVB board

[Chen-Yu Tsai]

On Fri, Jan 19, 2018 at 9:27 PM, Stefan Mavrodiev  wrote:
> On 01/18/2018 04:28 PM, Chen-Yu Tsai wrote:
>>
>> On Thu, Jan 18, 2018 at 6:07 PM, Maxime Ripard
>>  wrote:
>>>
>>> Hi!
>>>
>>> On Mon, Jan 15, 2018 at 12:07:34PM +0200, Stefan Mavrodiev wrote:
>>
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Olimex A20-SOM204-EVB";
>> + compatible = "olimex,a20-olimex-som204-evb", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = 
>> + serial1 = 
>> + serial2 = 
>> + spi0 = 
>> + spi1 = 
>> + ethernet1 = 
>
> ethernet1? if there's a single network interface, it should be
> ethernet0.

 I think this will conflict the gmac alias defined in sun7i-a20.dtsi:

 aliases {
  ethernet0 = 
 };
>>>
>>> We have that? That's bad, but you're right :)
>>>
>> + stat {
>> + label = "a20-som204:green:stat";
>> + gpios = < 8 0 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + led1 {
>> + label = "a20-som204-evb:green:led1";
>> + gpios = < 8 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + led2 {
>> + label = "a20-som204-evb:yellow:led2";
>> + gpios = < 8 11 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>
> You don't have the same prefix between stat and led1/led2. I'm fine
> with both, but you should be consistent :)

 STAT led is on the SOM204 module, while led1/2 on the EVB. Thats why
 they have different prefix.
>>>
>>> Still, the user and the system will see it as a single board, and the
>>> documentation states that it should be the board name. I'm not quite
>>> sure what a good rule would be here. Have you looked at how other
>>> boards dealt with it? Chen-Yu, any opinion on this?
>>
>> Follow the bindings, I guess? I don't think we (sunxi) have dealt
>> with modules that have LEDs or anything that needs to be named after
>> the board.
>>
>> On a related topic, I don't know if you (Stefan / Olimex) want to split
>> this into a .dtsi file for the SoM, and a .dts file for the EVB. It might
>> help your customers?
>
> I'm not sure this will be good ideal. We will have one EVB with all
> possible peripheries. On the other hand, we are planning 3-4 different
> SOM204 modules (A20, A64, RK). I think this will make the dtsi
> incompatible.

Yes. That was what I mentioned in the second half of my reply.

>
> Maybe if there is one dtsi for the base SOM204 module (one for each arch)
> and
> multiple dts for boards with additional features. But this will generate
> 10-20
> dts files. I think this will be better handled using overlays in the uboot.

OK. I'm guessing there's the possibility that some pins or GPIOs get muxed
to different functions depending on what base board is used? How would
you list them, if you only had one .dts file, say for the EVB? Clearly
the SoM cannot work by itself, so it probably doesn't get its own .dts
file.

>
> About the leds, I'm ok to be named after full board name (a20-som204-evb).

Cool.

ChenYu

>>
>> I've tried it previously, and it helps in some ways
>> when you're matching the files to the schematics. But it is confusing
>> when you want the big picture. On the other hand, this is not going to
>> help with supporting different modules on the same baseboard, as the
>> routing, peripherals and labels likely won't match up. Just my two cents.
>>
>> ChenYu
>
> Regards,
> Stefan Mavrodiev

Re: [PATCH] printk: drop redundant devkmsg_log_str memsets

[Sergey Senozhatsky]

On (01/19/18 09:17), Steven Rostedt wrote:
> Yep, and even the sysctl checks for the terminating nul string, so
> there's no leaks of any kind.
> 
> Tested by adding: printk.devkmsg=on and running:
> 
>  $ hexdump -C /proc/sys/kernel/printk_devkmsg
>   6f 6e 0a  |on.|
> 0003
> 
> 
> Reviewed-by: Steven Rostedt (VMware) 

thanks.

-ss

Re: [PATCH] printk: drop redundant devkmsg_log_str memsets

[Sergey Senozhatsky]

On (01/19/18 09:17), Steven Rostedt wrote:
> Yep, and even the sysctl checks for the terminating nul string, so
> there's no leaks of any kind.
> 
> Tested by adding: printk.devkmsg=on and running:
> 
>  $ hexdump -C /proc/sys/kernel/printk_devkmsg
>   6f 6e 0a  |on.|
> 0003
> 
> 
> Reviewed-by: Steven Rostedt (VMware) 

thanks.

-ss

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Gabriel C]

2018-01-20 5:02 GMT+01:00 Laura Abbott :
> On 01/19/2018 06:23 PM, Gabriel C wrote:
>>
>> 2018-01-20 2:23 GMT+01:00 Laura Abbott :
>>>
>>> Hi,
>>
>>
>> Hi ,
>>
>>>
>>> Fedora got multiple reports of an early bootup crash post -rc8.
>>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
>>> parameters for SME PGD mapping") . It doesn't revert cleanly
>>> but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
>>> as well it boots up fine.
>>>
>>> Annoyingly, I can't seem to get any actual kernel logs even with
>>> earlyprintk. It just reboots immediately (triple fault?). This
>>> happens on both of my Lenovo machines and I can ask other reporters
>>> for details as well.
>>>
>>
>> I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
>> on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
>> on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
>> disabled.
>>
>> Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
>> current master/rc8++ without to see something like this.
>>
>> Also we pushed these patches on 4.14.13/14 and didn't got any reports
>> about
>> something like this.
>>
>> What Lenovo boxes are these ? maybe I find one to reproduce.
>>
>>
>>> $ git bisect log
>>> # bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
>>> 'trace-v4.15-rc4-3' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
>>> # good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
>>> git bisect start 'origin/master' 'v4.15-rc8'
>>> # bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
>>> 'mmc-v4.15-rc2-3' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
>>> git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
>>> # good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
>>> 'mac80211-for-davem-2018-01-15' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
>>> git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
>>> # good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
>>> 'x86-pti-for-linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>> git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
>>> # bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
>>> Prevent
>>> use after free
>>> git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
>>> # good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
>>> Remove
>>> init_bsp_APIC()"
>>> git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
>>> # bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
>>> reduce parameters for SME PGD mapping
>>> git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
>>> # good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
>>> register
>>> saving in the __enc_copy() assembly code
>>> git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
>>> # first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
>>> Use a
>>> struct to reduce parameters for SME PGD mapping
>>>
>>>
>>> Configuration is at
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
>>> Note that I do think this is something in the Fedora configuration
>>> because a generic "make defconfig" booted just fine.
>>
>>
>> But maybe some of the Fedora patches ?
>>
>> Can you try an kernel with the config but without any patches ?
>> Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?
>>
>
> The bisect was a vanilla kernel without Fedora patches.

Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )
 with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.

Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..


Can you tell us your Lenovo models  please  ?

Reagrds,

Gabriel C

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Gabriel C]

2018-01-20 5:02 GMT+01:00 Laura Abbott :
> On 01/19/2018 06:23 PM, Gabriel C wrote:
>>
>> 2018-01-20 2:23 GMT+01:00 Laura Abbott :
>>>
>>> Hi,
>>
>>
>> Hi ,
>>
>>>
>>> Fedora got multiple reports of an early bootup crash post -rc8.
>>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
>>> parameters for SME PGD mapping") . It doesn't revert cleanly
>>> but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
>>> as well it boots up fine.
>>>
>>> Annoyingly, I can't seem to get any actual kernel logs even with
>>> earlyprintk. It just reboots immediately (triple fault?). This
>>> happens on both of my Lenovo machines and I can ask other reporters
>>> for details as well.
>>>
>>
>> I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
>> on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
>> on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs
>> disabled.
>>
>> Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
>> current master/rc8++ without to see something like this.
>>
>> Also we pushed these patches on 4.14.13/14 and didn't got any reports
>> about
>> something like this.
>>
>> What Lenovo boxes are these ? maybe I find one to reproduce.
>>
>>
>>> $ git bisect log
>>> # bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
>>> 'trace-v4.15-rc4-3' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
>>> # good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
>>> git bisect start 'origin/master' 'v4.15-rc8'
>>> # bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
>>> 'mmc-v4.15-rc2-3' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
>>> git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
>>> # good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
>>> 'mac80211-for-davem-2018-01-15' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
>>> git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
>>> # good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
>>> 'x86-pti-for-linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>> git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
>>> # bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm:
>>> Prevent
>>> use after free
>>> git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
>>> # good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic:
>>> Remove
>>> init_bsp_APIC()"
>>> git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
>>> # bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
>>> reduce parameters for SME PGD mapping
>>> git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
>>> # good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up
>>> register
>>> saving in the __enc_copy() assembly code
>>> git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
>>> # first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm:
>>> Use a
>>> struct to reduce parameters for SME PGD mapping
>>>
>>>
>>> Configuration is at
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
>>> Note that I do think this is something in the Fedora configuration
>>> because a generic "make defconfig" booted just fine.
>>
>>
>> But maybe some of the Fedora patches ?
>>
>> Can you try an kernel with the config but without any patches ?
>> Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?
>>
>
> The bisect was a vanilla kernel without Fedora patches.

Ok . I did an build ( v4.15-rc8-225-g8dd903d2cf7b ) on my AMD
Workstation  ( EPYC CPU )
 with your 64bit config and one on the Ideapad ( Intel i7-6498DU ) ..
I disabled Selinux since I don't use it here and module  signing.

Also with your config my serial setup won't work and the kernel hangs
but mem_encrypt=on/off works just fine.

Also I notice on the Workstation it takes forever to boot untill
'DMA-API' reports out-of-memory
( dunno how much memory it need but the box has 128GB of RAM )..


Can you tell us your Lenovo models  please  ?

Reagrds,

Gabriel C

Re: [mm 4.15-rc8] Random oopses under memory pressure.

[Al Viro]

On Sat, Jan 20, 2018 at 02:02:37AM +, Al Viro wrote:

> Note that those sizes are rather sensitive to lockdep, spinlock debugging, 
> etc.

That they certainly are: on one of the testing .config I'm using it gave this:
   1104 sizeof struct page = 56
 81 sizeof struct cpufreq_frequency_table = 12
 32 sizeof struct Indirect = 24
  7 sizeof struct zone = 1400
  7 sizeof struct hstate = 152
  6 sizeof struct lock_class = 336
  6 sizeof struct hpet_dev = 152
  6 sizeof struct ext4_extent = 12
  4 sizeof struct ext4_extent_idx = 12
  3 sizeof struct mbox_chan = 456
  2 sizeof struct strip_zone = 24
  2 sizeof struct kobj_attribute = 48
  2 sizeof struct kernel_param = 40
  2 sizeof struct exception_table_entry = 12
  1 sizeof struct vif_device = 104
  1 sizeof struct unixware_slice = 12
  1 sizeof struct svc_pool = 152
  1 sizeof struct srcu_node = 152
  1 sizeof struct r5worker_group = 56
  1 sizeof struct pebs_record_core = 144
  1 sizeof struct netdev_queue = 384
  1 sizeof struct mirror = 40
  1 sizeof struct mif_device = 56
  1 sizeof struct e1000_tx_ring = 48
  1 sizeof struct dx_frame = 24
  1 sizeof struct bts_record = 24
  1 sizeof struct ata_device = 2560
  1 sizeof struct acpi_processor_cx = 52

Re: [mm 4.15-rc8] Random oopses under memory pressure.

[Al Viro]

On Sat, Jan 20, 2018 at 02:02:37AM +, Al Viro wrote:

> Note that those sizes are rather sensitive to lockdep, spinlock debugging, 
> etc.

That they certainly are: on one of the testing .config I'm using it gave this:
   1104 sizeof struct page = 56
 81 sizeof struct cpufreq_frequency_table = 12
 32 sizeof struct Indirect = 24
  7 sizeof struct zone = 1400
  7 sizeof struct hstate = 152
  6 sizeof struct lock_class = 336
  6 sizeof struct hpet_dev = 152
  6 sizeof struct ext4_extent = 12
  4 sizeof struct ext4_extent_idx = 12
  3 sizeof struct mbox_chan = 456
  2 sizeof struct strip_zone = 24
  2 sizeof struct kobj_attribute = 48
  2 sizeof struct kernel_param = 40
  2 sizeof struct exception_table_entry = 12
  1 sizeof struct vif_device = 104
  1 sizeof struct unixware_slice = 12
  1 sizeof struct svc_pool = 152
  1 sizeof struct srcu_node = 152
  1 sizeof struct r5worker_group = 56
  1 sizeof struct pebs_record_core = 144
  1 sizeof struct netdev_queue = 384
  1 sizeof struct mirror = 40
  1 sizeof struct mif_device = 56
  1 sizeof struct e1000_tx_ring = 48
  1 sizeof struct dx_frame = 24
  1 sizeof struct bts_record = 24
  1 sizeof struct ata_device = 2560
  1 sizeof struct acpi_processor_cx = 52

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

[Pavan Kondeti]

Hi Steve,

On Fri, Jan 19, 2018 at 02:51:15PM -0500, Steven Rostedt wrote:
> On Sat, 20 Jan 2018 00:27:56 +0530
> Pavan Kondeti  wrote:
> 
> > Hi Steve,
> > 
> > Thanks for the patch.
> > 
> > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote:
> > > On Fri, 19 Jan 2018 13:11:21 -0500
> > > Steven Rostedt  wrote:
> > >   
> > > >  void rto_push_irq_work_func(struct irq_work *work)
> > > >  {
> > > > +   struct root_domain *rd =
> > > > +   container_of(work, struct root_domain, rto_push_work);
> > > > struct rq *rq;  
> > > 
> > > Notice that I also remove the dependency on rq from getting the rd.
> > >   
> > 
> > Nice. This snippet it self solves the original problem, I reported.
> > I will test your patch and let you know the results.
> > 
> >
> 
> I'll break the patch up into two then. One with this snippet, and the
> other with the rd ref counting.
> 

Yeah, this snippet fixed the original problem.

I have not seen "use after free" of rd in my testing. But I can see
we are operating on a rd for which refcount is 0. After applying your
refcount patch, it never happened. I also verified that we are freeing
the rd via IRQ work by dropping the last reference.

Thanks for your help with the patches. Please copy linux-stable for
the 1st patch.

Feel free to use
Tested-by: Pavankumar Kondeti 

Thanks,
Pavan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

[Pavan Kondeti]

Hi Steve,

On Fri, Jan 19, 2018 at 02:51:15PM -0500, Steven Rostedt wrote:
> On Sat, 20 Jan 2018 00:27:56 +0530
> Pavan Kondeti  wrote:
> 
> > Hi Steve,
> > 
> > Thanks for the patch.
> > 
> > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote:
> > > On Fri, 19 Jan 2018 13:11:21 -0500
> > > Steven Rostedt  wrote:
> > >   
> > > >  void rto_push_irq_work_func(struct irq_work *work)
> > > >  {
> > > > +   struct root_domain *rd =
> > > > +   container_of(work, struct root_domain, rto_push_work);
> > > > struct rq *rq;  
> > > 
> > > Notice that I also remove the dependency on rq from getting the rd.
> > >   
> > 
> > Nice. This snippet it self solves the original problem, I reported.
> > I will test your patch and let you know the results.
> > 
> >
> 
> I'll break the patch up into two then. One with this snippet, and the
> other with the rd ref counting.
> 

Yeah, this snippet fixed the original problem.

I have not seen "use after free" of rd in my testing. But I can see
we are operating on a rd for which refcount is 0. After applying your
refcount patch, it never happened. I also verified that we are freeing
the rd via IRQ work by dropping the last reference.

Thanks for your help with the patches. Please copy linux-stable for
the 1st patch.

Feel free to use
Tested-by: Pavankumar Kondeti 

Thanks,
Pavan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

[Jens Axboe]

On 1/19/18 4:52 PM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 10:38:41AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:37 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
 On 1/19/18 9:26 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:05 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 08:48:55AM -0700, Jens Axboe wrote:
 On 1/19/18 8:40 AM, Ming Lei wrote:
 Where does the dm STS_RESOURCE error usually come from - what's 
 exact
 resource are we running out of?
>>>
>>> It is from blk_get_request(underlying queue), see
>>> multipath_clone_and_map().
>>
>> That's what I thought. So for a low queue depth underlying queue, 
>> it's
>> quite possible that this situation can happen. Two potential 
>> solutions
>> I see:
>>
>> 1) As described earlier in this thread, having a mechanism for being
>>notified when the scarce resource becomes available. It would not
>>be hard to tap into the existing sbitmap wait queue for that.
>>
>> 2) Have dm set BLK_MQ_F_BLOCKING and just sleep on the resource
>>allocation. I haven't read the dm code to know if this is a
>>possibility or not.
>>
>> I'd probably prefer #1. It's a classic case of trying to get the
>> request, and if it fails, add ourselves to the sbitmap tag wait
>> queue head, retry, and bail if that also fails. Connecting the
>> scarce resource and the consumer is the only way to really fix
>> this, without bogus arbitrary delays.
>
> Right, as I have replied to Bart, using mod_delayed_work_on() with
> returning BLK_STS_NO_DEV_RESOURCE(or sort of name) for the scarce
> resource should fix this issue.

 It'll fix the forever stall, but it won't really fix it, as we'll slow
 down the dm device by some random amount.

 A simple test case would be to have a null_blk device with a queue 
 depth
 of one, and dm on top of that. Start a fio job that runs two jobs: one
 that does IO to the underlying device, and one that does IO to the dm
 device. If the job on the dm device runs substantially slower than the
 one to the underlying device, then the problem isn't really fixed.
>>>
>>> I remembered that I tried this test on scsi-debug & dm-mpath over 
>>> scsi-debug,
>>> seems not observed this issue, could you explain a bit why IO over 
>>> dm-mpath
>>> may be slower? Because both two IO contexts call same get_request(), and
>>> in theory dm-mpath should be a bit quicker since it uses direct issue 
>>> for
>>> underlying queue, without io scheduler involved.
>>
>> Because if you lose the race for getting the request, you'll have some
>> arbitrary delay before trying again, potentially. Compared to the direct
>
> But the restart still works, one request is completed, then the queue
> is return immediately because we use mod_delayed_work_on(0), so looks
> no such issue.

 There are no pending requests for this case, nothing to restart the
 queue. When you fail that blk_get_request(), you are idle, nothing
 is pending.
>>>
>>> I think we needn't worry about that, once a device is attached to
>>> dm-rq, it can't be mounted any more, and usually user don't use the device
>>> directly and by dm-mpath at the same time.
>>
>> Here's an example of that, using my current block tree (merged into
>> master).  The setup is dm-mpath on top of null_blk, the latter having
>> just a single request. Both are mq devices.
>>
>> Fio direct 4k random reads on dm_mq: ~250K iops
>>
>> Start dd on underlying device (or partition on same device), just doing
>> sequential reads.
>>
>> Fio direct 4k random reads on dm_mq with dd running: 9 iops
>>
>> No schedulers involved.
>>
>> https://i.imgur.com/WTDnnwE.gif
> 
> If null_blk's timer mode is used with a bit delay introduced, I guess
> the effect from direct access to underlying queue shouldn't be so
> serious. But it still won't be good as direct access.

Doesn't matter if it's used at the default of 10usec completion
latency, or inline complete. Same result, I ran both.

> Another way may be to introduce a variants blk_get_request(), such as
> blk_get_request_with_notify(), then pass the current dm-rq's hctx to
> it, and use the tag's waitqueue to handle that. But the change can be
> a bit big.

Yes, that's exactly the solution I suggested both yesterday and today.

-- 
Jens Axboe

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

[Jens Axboe]

On 1/19/18 4:52 PM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 10:38:41AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:37 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
 On 1/19/18 9:26 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:05 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 08:48:55AM -0700, Jens Axboe wrote:
 On 1/19/18 8:40 AM, Ming Lei wrote:
 Where does the dm STS_RESOURCE error usually come from - what's 
 exact
 resource are we running out of?
>>>
>>> It is from blk_get_request(underlying queue), see
>>> multipath_clone_and_map().
>>
>> That's what I thought. So for a low queue depth underlying queue, 
>> it's
>> quite possible that this situation can happen. Two potential 
>> solutions
>> I see:
>>
>> 1) As described earlier in this thread, having a mechanism for being
>>notified when the scarce resource becomes available. It would not
>>be hard to tap into the existing sbitmap wait queue for that.
>>
>> 2) Have dm set BLK_MQ_F_BLOCKING and just sleep on the resource
>>allocation. I haven't read the dm code to know if this is a
>>possibility or not.
>>
>> I'd probably prefer #1. It's a classic case of trying to get the
>> request, and if it fails, add ourselves to the sbitmap tag wait
>> queue head, retry, and bail if that also fails. Connecting the
>> scarce resource and the consumer is the only way to really fix
>> this, without bogus arbitrary delays.
>
> Right, as I have replied to Bart, using mod_delayed_work_on() with
> returning BLK_STS_NO_DEV_RESOURCE(or sort of name) for the scarce
> resource should fix this issue.

 It'll fix the forever stall, but it won't really fix it, as we'll slow
 down the dm device by some random amount.

 A simple test case would be to have a null_blk device with a queue 
 depth
 of one, and dm on top of that. Start a fio job that runs two jobs: one
 that does IO to the underlying device, and one that does IO to the dm
 device. If the job on the dm device runs substantially slower than the
 one to the underlying device, then the problem isn't really fixed.
>>>
>>> I remembered that I tried this test on scsi-debug & dm-mpath over 
>>> scsi-debug,
>>> seems not observed this issue, could you explain a bit why IO over 
>>> dm-mpath
>>> may be slower? Because both two IO contexts call same get_request(), and
>>> in theory dm-mpath should be a bit quicker since it uses direct issue 
>>> for
>>> underlying queue, without io scheduler involved.
>>
>> Because if you lose the race for getting the request, you'll have some
>> arbitrary delay before trying again, potentially. Compared to the direct
>
> But the restart still works, one request is completed, then the queue
> is return immediately because we use mod_delayed_work_on(0), so looks
> no such issue.

 There are no pending requests for this case, nothing to restart the
 queue. When you fail that blk_get_request(), you are idle, nothing
 is pending.
>>>
>>> I think we needn't worry about that, once a device is attached to
>>> dm-rq, it can't be mounted any more, and usually user don't use the device
>>> directly and by dm-mpath at the same time.
>>
>> Here's an example of that, using my current block tree (merged into
>> master).  The setup is dm-mpath on top of null_blk, the latter having
>> just a single request. Both are mq devices.
>>
>> Fio direct 4k random reads on dm_mq: ~250K iops
>>
>> Start dd on underlying device (or partition on same device), just doing
>> sequential reads.
>>
>> Fio direct 4k random reads on dm_mq with dd running: 9 iops
>>
>> No schedulers involved.
>>
>> https://i.imgur.com/WTDnnwE.gif
> 
> If null_blk's timer mode is used with a bit delay introduced, I guess
> the effect from direct access to underlying queue shouldn't be so
> serious. But it still won't be good as direct access.

Doesn't matter if it's used at the default of 10usec completion
latency, or inline complete. Same result, I ran both.

> Another way may be to introduce a variants blk_get_request(), such as
> blk_get_request_with_notify(), then pass the current dm-rq's hctx to
> it, and use the tag's waitqueue to handle that. But the change can be
> a bit big.

Yes, that's exactly the solution I suggested both yesterday and today.

-- 
Jens Axboe

[PATCH 2/2] f2fs: recover some i_inline flags

[Jaegeuk Kim]

This fixes lost i_inline flags during roll-forward.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/recovery.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index cbeef73bc4dd..2354f1e05e19 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -211,6 +211,15 @@ static void recover_inode(struct inode *inode, struct page 
*page)
 
F2FS_I(inode)->i_advise = raw->i_advise;
 
+   if (raw->i_inline & F2FS_PIN_FILE)
+   set_inode_flag(inode, FI_PIN_FILE);
+   if (raw->i_inline & F2FS_DATA_EXIST)
+   set_inode_flag(inode, FI_DATA_EXIST);
+   else
+   clear_inode_flag(inode, FI_DATA_EXIST);
+   if (!(raw->i_inline & F2FS_INLINE_DOTS))
+   clear_inode_flag(inode, FI_INLINE_DOTS);
+
if (file_enc_name(inode))
name = "";
else
-- 
2.15.0.531.g2ccb3012c9-goog

[PATCH 2/2] f2fs: recover some i_inline flags

[Jaegeuk Kim]

This fixes lost i_inline flags during roll-forward.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/recovery.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index cbeef73bc4dd..2354f1e05e19 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -211,6 +211,15 @@ static void recover_inode(struct inode *inode, struct page 
*page)
 
F2FS_I(inode)->i_advise = raw->i_advise;
 
+   if (raw->i_inline & F2FS_PIN_FILE)
+   set_inode_flag(inode, FI_PIN_FILE);
+   if (raw->i_inline & F2FS_DATA_EXIST)
+   set_inode_flag(inode, FI_DATA_EXIST);
+   else
+   clear_inode_flag(inode, FI_DATA_EXIST);
+   if (!(raw->i_inline & F2FS_INLINE_DOTS))
+   clear_inode_flag(inode, FI_INLINE_DOTS);
+
if (file_enc_name(inode))
name = "";
else
-- 
2.15.0.531.g2ccb3012c9-goog

[PATCH 1/2] f2fs: allow to recover node blocks given updated checkpoint

[Jaegeuk Kim]

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll-
forward recovery. Let's relax the condition to recover them.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 0ee3e5ff49a3..15280eeb24ea 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -305,10 +305,11 @@ static inline bool is_recoverable_dnode(struct page *page)
struct f2fs_checkpoint *ckpt = F2FS_CKPT(F2FS_P_SB(page));
__u64 cp_ver = cur_cp_version(ckpt);
 
-   if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG))
+   if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG)) {
cp_ver |= (cur_cp_crc(ckpt) << 32);
-
-   return cp_ver == cpver_of_node(page);
+   return cp_ver == cpver_of_node(page);
+   }
+   return (cp_ver << 32) == (cpver_of_node(page) << 32);
 }
 
 /*
-- 
2.15.0.531.g2ccb3012c9-goog

[PATCH 1/2] f2fs: allow to recover node blocks given updated checkpoint

[Jaegeuk Kim]

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll-
forward recovery. Let's relax the condition to recover them.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 0ee3e5ff49a3..15280eeb24ea 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -305,10 +305,11 @@ static inline bool is_recoverable_dnode(struct page *page)
struct f2fs_checkpoint *ckpt = F2FS_CKPT(F2FS_P_SB(page));
__u64 cp_ver = cur_cp_version(ckpt);
 
-   if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG))
+   if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG)) {
cp_ver |= (cur_cp_crc(ckpt) << 32);
-
-   return cp_ver == cpver_of_node(page);
+   return cp_ver == cpver_of_node(page);
+   }
+   return (cp_ver << 32) == (cpver_of_node(page) << 32);
 }
 
 /*
-- 
2.15.0.531.g2ccb3012c9-goog

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Tom Lendacky]

On 1/19/2018 8:38 PM, Linus Torvalds wrote:
> On Fri, Jan 19, 2018 at 5:23 PM, Laura Abbott  wrote:
>>
>> Fedora got multiple reports of an early bootup crash post -rc8.
>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
>> parameters for SME PGD mapping") . It doesn't revert cleanly
>> but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
>> as well it boots up fine.
> 
> Odd. I've tried to read through that patch three times to find
> anything it actually changes, and I can't find anything.
> 
> It looks like that patch should have absolutely no actual behavioral impact.
> 
> But clearly I'm missing something. Can anybody see what the mistake in
> the conversion is?

I'll take a closer look at this, but it really shouldn't have any effect,
especially on a non-AMD box (which I'm assuming this is?) and with memory
encryption off by default.

Thanks,
Tom

> 
>  Linus
> 

[PATCH] power: supply: da9030_battery: fix boolean value assignment in da9030_set_charge

[Gustavo A. R. Silva]

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Fixes: 342d765e011f ("power_supply: Add Dialog DA9030 battery charger driver")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/power/supply/da9030_battery.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/da9030_battery.c 
b/drivers/power/supply/da9030_battery.c
index 5ca0f4d..2cc05bc 100644
--- a/drivers/power/supply/da9030_battery.c
+++ b/drivers/power/supply/da9030_battery.c
@@ -238,10 +238,10 @@ static void da9030_set_charge(struct da9030_charger 
*charger, int on)
val = DA9030_CHRG_CHARGER_ENABLE;
val |= (charger->charge_milliamp / 100) << 3;
val |= (charger->charge_millivolt - 4000) / 50;
-   charger->is_on = 1;
+   charger->is_on = true;
} else {
val = 0;
-   charger->is_on = 0;
+   charger->is_on = false;
}
 
da903x_write(charger->master, DA9030_CHARGE_CONTROL, val);
-- 
2.7.4

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Tom Lendacky]

On 1/19/2018 8:38 PM, Linus Torvalds wrote:
> On Fri, Jan 19, 2018 at 5:23 PM, Laura Abbott  wrote:
>>
>> Fedora got multiple reports of an early bootup crash post -rc8.
>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
>> parameters for SME PGD mapping") . It doesn't revert cleanly
>> but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
>> as well it boots up fine.
> 
> Odd. I've tried to read through that patch three times to find
> anything it actually changes, and I can't find anything.
> 
> It looks like that patch should have absolutely no actual behavioral impact.
> 
> But clearly I'm missing something. Can anybody see what the mistake in
> the conversion is?

I'll take a closer look at this, but it really shouldn't have any effect,
especially on a non-AMD box (which I'm assuming this is?) and with memory
encryption off by default.

Thanks,
Tom

> 
>  Linus
> 

[PATCH] power: supply: da9030_battery: fix boolean value assignment in da9030_set_charge

[Gustavo A. R. Silva]

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Fixes: 342d765e011f ("power_supply: Add Dialog DA9030 battery charger driver")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/power/supply/da9030_battery.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/da9030_battery.c 
b/drivers/power/supply/da9030_battery.c
index 5ca0f4d..2cc05bc 100644
--- a/drivers/power/supply/da9030_battery.c
+++ b/drivers/power/supply/da9030_battery.c
@@ -238,10 +238,10 @@ static void da9030_set_charge(struct da9030_charger 
*charger, int on)
val = DA9030_CHRG_CHARGER_ENABLE;
val |= (charger->charge_milliamp / 100) << 3;
val |= (charger->charge_millivolt - 4000) / 50;
-   charger->is_on = 1;
+   charger->is_on = true;
} else {
val = 0;
-   charger->is_on = 0;
+   charger->is_on = false;
}
 
da903x_write(charger->master, DA9030_CHARGE_CONTROL, val);
-- 
2.7.4

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 06:23 PM, Gabriel C wrote:

2018-01-20 2:23 GMT+01:00 Laura Abbott :

Hi,


Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm: Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic: Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a
struct to reduce parameters for SME PGD mapping


Configuration is at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.


But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.



Thanks,
Laura


Regards,

Gabriel C

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

[Laura Abbott]

On 01/19/2018 06:23 PM, Gabriel C wrote:

2018-01-20 2:23 GMT+01:00 Laura Abbott :

Hi,


Hi ,



Fedora got multiple reports of an early bootup crash post -rc8.
Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce
parameters for SME PGD mapping") . It doesn't revert cleanly
but if I revert the few other changes in arch/x86/mm/mem_encrypt.c
as well it boots up fine.

Annoyingly, I can't seem to get any actual kernel logs even with
earlyprintk. It just reboots immediately (triple fault?). This
happens on both of my Lenovo machines and I can ask other reporters
for details as well.



I tested these patches on 2 Lenovo Ideapad both with Skylake CPUs
on a older dual Xeon box , on 2 Toshibas with AMD APUs , on a RYZEN box ,
on dual EPYC box .. ofc on EPYC with mem_encrypt=on on the Intel CPUs disabled.

Also tested on top 4.14.13 , 4.14.14 as well on top 4.15.0-rc7 and on
current master/rc8++ without to see something like this.

Also we pushed these patches on 4.14.13/14 and didn't got any reports about
something like this.

What Lenovo boxes are these ? maybe I find one to reproduce.



$ git bisect log
# bad: [ec835f8104a21f4d4eeb9d316ee71d2b4a7f00de] Merge tag
'trace-v4.15-rc4-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
# good: [a8750ddca918032d6349adbf9a4b6555e7db20da] Linux 4.15-rc8
git bisect start 'origin/master' 'v4.15-rc8'
# bad: [79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68] Merge tag
'mmc-v4.15-rc2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 79683f80e4f07dba13cc08d0ebcf5c7b0aa1bf68
# good: [161f72ed6dbe7fb176585091d3b797125d310399] Merge tag
'mac80211-for-davem-2018-01-15' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
git bisect good 161f72ed6dbe7fb176585091d3b797125d310399
# good: [88dc7fca18001fd883e5ace775afa316b68c8f2c] Merge branch
'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 88dc7fca18001fd883e5ace775afa316b68c8f2c
# bad: [d47924417319e3b6a728c0b690f183e75bc2a702] x86/intel_rdt/cqm: Prevent
use after free
git bisect bad d47924417319e3b6a728c0b690f183e75bc2a702
# good: [fc90ccfd286eabb05ec54521367df8663cf0bbbf] Revert "x86/apic: Remove
init_bsp_APIC()"
git bisect good fc90ccfd286eabb05ec54521367df8663cf0bbbf
# bad: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a struct to
reduce parameters for SME PGD mapping
git bisect bad bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
# good: [1303880179e67c59e801429b7e5d0f6b21137d99] x86/mm: Clean up register
saving in the __enc_copy() assembly code
git bisect good 1303880179e67c59e801429b7e5d0f6b21137d99
# first bad commit: [bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4] x86/mm: Use a
struct to reduce parameters for SME PGD mapping


Configuration is at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide
Note that I do think this is something in the Fedora configuration
because a generic "make defconfig" booted just fine.


But maybe some of the Fedora patches ?

Can you try an kernel with the config but without any patches ?
Or a defconfig and just enable  CONFIG_AMD_MEM_ENCRYPT ?



The bisect was a vanilla kernel without Fedora patches.



Thanks,
Laura


Regards,

Gabriel C

[PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

[Gustavo A. R. Silva]

Bool initializations should use true and false.

This issue was detected with the help of Coccinelle.

Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller driver")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/pci/host/pcie-altera.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index 5cc4f59..f9ee090 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -156,7 +156,7 @@ static bool altera_pcie_valid_device(struct altera_pcie 
*pcie,
 static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
 {
int i;
-   bool sop = 0;
+   bool sop = false;
u32 ctrl;
u32 reg0, reg1;
u32 comp_status = 1;
-- 
2.7.4

[PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

[Gustavo A. R. Silva]

Bool initializations should use true and false.

This issue was detected with the help of Coccinelle.

Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller driver")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/pci/host/pcie-altera.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index 5cc4f59..f9ee090 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -156,7 +156,7 @@ static bool altera_pcie_valid_device(struct altera_pcie 
*pcie,
 static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
 {
int i;
-   bool sop = 0;
+   bool sop = false;
u32 ctrl;
u32 reg0, reg1;
u32 comp_status = 1;
-- 
2.7.4

[PATCH] iommu/mediatek: Move attach_device after iommu-group is ready for M4Uv1

[Yong Wu]

In the commit 05f80300dc8b, the iommu framework has supposed all the
iommu drivers have their owner iommu-group, it get rid of the FIXME
workarounds while the group is NULL. But the flow of Mediatek M4U gen1
looks a bit trick that it will hang at this case:

==
Unable to handle kernel NULL pointer dereference at virtual address 0030
pgd = c0004000
[0030] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc1-gfadad58-dirty #7
Hardware name: Mediatek Cortex-A7 (Device Tree)
task: df0f8000 task.stack: df0ec000
PC is at mutex_lock+0x28/0x54
LR is at iommu_attach_device+0xa4/0xd4
pc : []lr : []psr: 6013
sp : df0edbb8  ip : df0edbc8  fp : df0edbc4
r10: c114da14  r9 : df2a3e40  r8 : 0003
r7 : df27a210  r6 : df2a90c4  r5 : 0030  r4 : 
r3 : df0f8000  r2 : f000  r1 : df29c610  r0 : 0030
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
xxx
(mutex_lock) from [] (iommu_attach_device+0xa4/0xd4)
(iommu_attach_device) from [] (__arm_iommu_attach_device+0x28/0x90)
(__arm_iommu_attach_device) from [] 
(arm_iommu_attach_device+0x1c/0x30)
(arm_iommu_attach_device) from [] (mtk_iommu_add_device+0xfc/0x214)
(mtk_iommu_add_device) from [] (add_iommu_group+0x3c/0x68)
(add_iommu_group) from [] (bus_for_each_dev+0x78/0xac)
(bus_for_each_dev) from [] (bus_set_iommu+0xb0/0xec)
(bus_set_iommu) from [] (mtk_iommu_probe+0x328/0x368)
(mtk_iommu_probe) from [] (platform_drv_probe+0x5c/0xc0)
(platform_drv_probe) from [] (driver_probe_device+0x2f4/0x4d8)
(driver_probe_device) from [] (__driver_attach+0x10c/0x128)
(__driver_attach) from [] (bus_for_each_dev+0x78/0xac)
(bus_for_each_dev) from [] (driver_attach+0x2c/0x30)
(driver_attach) from [] (bus_add_driver+0x1e0/0x278)
(bus_add_driver) from [] (driver_register+0x88/0x108)
(driver_register) from [] (__platform_driver_register+0x50/0x58)
(__platform_driver_register) from [] (m4u_init+0x24/0x28)
(m4u_init) from [] (do_one_initcall+0xf0/0x17c)
(do_one_initcall) from [] (kernel_init_freeable+0x154/0x1f4)
(kernel_init_freeable) from [] (kernel_init+0x18/0x124)
(kernel_init) from [] (ret_from_fork+0x14/0x2c)
=

The root cause is that "arm_iommu_attach_device" is called before
"iommu_group_get_for_dev" in the interface "mtk_iommu_add_device".
Thus, We adjust the sequence of this two functions.

Unfortunately, there is another issue after the solution above, From
the function "iommu_attach_device", Only one device in each a iommu
group is allowed. In Mediatek case, there is only one m4u group, all
the devices are in one group. thus it get fail at this step.

In order to satisfy this requirement, a new iommu group is allocated
for each a iommu consumer device. But meanwhile, we still have to use
the same domain for all the iommu group. Use a global variable
"mtk_domain_v1" to save the global domain.

CC: Robin Murphy 
CC: Honghui Zhang 
Fixes: 05f80300dc8b ('iommu: Finish making iommu_group support mandatory')
Reported-by: Ryder Lee 
Tested-by: Bibby Hsieh 
Signed-off-by: Yong Wu 
---
base on v4.15-rc1
---
 drivers/iommu/mtk_iommu_v1.c | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 542930c..da2d941 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -103,6 +103,9 @@ struct mtk_iommu_domain {
struct mtk_iommu_data   *data;
 };
 
+/* There is only a iommu domain in M4U gen1. */
+static struct mtk_iommu_domain *mtk_domain_v1;
+
 static struct mtk_iommu_domain *to_mtk_domain(struct iommu_domain *dom)
 {
return container_of(dom, struct mtk_iommu_domain, domain);
@@ -251,10 +254,15 @@ static struct iommu_domain 
*mtk_iommu_domain_alloc(unsigned type)
if (type != IOMMU_DOMAIN_UNMANAGED)
return NULL;
 
+   /* Always return the same domain. */
+   if (mtk_domain_v1)
+   return _domain_v1->domain;
+
dom = kzalloc(sizeof(*dom), GFP_KERNEL);
if (!dom)
return NULL;
 
+   mtk_domain_v1 = dom;
return >domain;
 }
 
@@ -418,20 +426,12 @@ static int mtk_iommu_create_mapping(struct device *dev,
m4udev->archdata.iommu = mtk_mapping;
}
 
-   ret = arm_iommu_attach_device(dev, mtk_mapping);
-   if (ret)
-   goto err_release_mapping;
-
return 0;
-
-err_release_mapping:
-   arm_iommu_release_mapping(mtk_mapping);
-   m4udev->archdata.iommu = NULL;
-   return ret;
 }
 
 static int mtk_iommu_add_device(struct device *dev)
 {
+   struct dma_iommu_mapping *mtk_mapping;
struct of_phandle_args iommu_spec;
struct of_phandle_iterator it;
struct mtk_iommu_data 

[PATCH] iommu/mediatek: Move attach_device after iommu-group is ready for M4Uv1

[Yong Wu]

In the commit 05f80300dc8b, the iommu framework has supposed all the
iommu drivers have their owner iommu-group, it get rid of the FIXME
workarounds while the group is NULL. But the flow of Mediatek M4U gen1
looks a bit trick that it will hang at this case:

==
Unable to handle kernel NULL pointer dereference at virtual address 0030
pgd = c0004000
[0030] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc1-gfadad58-dirty #7
Hardware name: Mediatek Cortex-A7 (Device Tree)
task: df0f8000 task.stack: df0ec000
PC is at mutex_lock+0x28/0x54
LR is at iommu_attach_device+0xa4/0xd4
pc : []lr : []psr: 6013
sp : df0edbb8  ip : df0edbc8  fp : df0edbc4
r10: c114da14  r9 : df2a3e40  r8 : 0003
r7 : df27a210  r6 : df2a90c4  r5 : 0030  r4 : 
r3 : df0f8000  r2 : f000  r1 : df29c610  r0 : 0030
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
xxx
(mutex_lock) from [] (iommu_attach_device+0xa4/0xd4)
(iommu_attach_device) from [] (__arm_iommu_attach_device+0x28/0x90)
(__arm_iommu_attach_device) from [] 
(arm_iommu_attach_device+0x1c/0x30)
(arm_iommu_attach_device) from [] (mtk_iommu_add_device+0xfc/0x214)
(mtk_iommu_add_device) from [] (add_iommu_group+0x3c/0x68)
(add_iommu_group) from [] (bus_for_each_dev+0x78/0xac)
(bus_for_each_dev) from [] (bus_set_iommu+0xb0/0xec)
(bus_set_iommu) from [] (mtk_iommu_probe+0x328/0x368)
(mtk_iommu_probe) from [] (platform_drv_probe+0x5c/0xc0)
(platform_drv_probe) from [] (driver_probe_device+0x2f4/0x4d8)
(driver_probe_device) from [] (__driver_attach+0x10c/0x128)
(__driver_attach) from [] (bus_for_each_dev+0x78/0xac)
(bus_for_each_dev) from [] (driver_attach+0x2c/0x30)
(driver_attach) from [] (bus_add_driver+0x1e0/0x278)
(bus_add_driver) from [] (driver_register+0x88/0x108)
(driver_register) from [] (__platform_driver_register+0x50/0x58)
(__platform_driver_register) from [] (m4u_init+0x24/0x28)
(m4u_init) from [] (do_one_initcall+0xf0/0x17c)
(do_one_initcall) from [] (kernel_init_freeable+0x154/0x1f4)
(kernel_init_freeable) from [] (kernel_init+0x18/0x124)
(kernel_init) from [] (ret_from_fork+0x14/0x2c)
=

The root cause is that "arm_iommu_attach_device" is called before
"iommu_group_get_for_dev" in the interface "mtk_iommu_add_device".
Thus, We adjust the sequence of this two functions.

Unfortunately, there is another issue after the solution above, From
the function "iommu_attach_device", Only one device in each a iommu
group is allowed. In Mediatek case, there is only one m4u group, all
the devices are in one group. thus it get fail at this step.

In order to satisfy this requirement, a new iommu group is allocated
for each a iommu consumer device. But meanwhile, we still have to use
the same domain for all the iommu group. Use a global variable
"mtk_domain_v1" to save the global domain.

CC: Robin Murphy 
CC: Honghui Zhang 
Fixes: 05f80300dc8b ('iommu: Finish making iommu_group support mandatory')
Reported-by: Ryder Lee 
Tested-by: Bibby Hsieh 
Signed-off-by: Yong Wu 
---
base on v4.15-rc1
---
 drivers/iommu/mtk_iommu_v1.c | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 542930c..da2d941 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -103,6 +103,9 @@ struct mtk_iommu_domain {
struct mtk_iommu_data   *data;
 };
 
+/* There is only a iommu domain in M4U gen1. */
+static struct mtk_iommu_domain *mtk_domain_v1;
+
 static struct mtk_iommu_domain *to_mtk_domain(struct iommu_domain *dom)
 {
return container_of(dom, struct mtk_iommu_domain, domain);
@@ -251,10 +254,15 @@ static struct iommu_domain 
*mtk_iommu_domain_alloc(unsigned type)
if (type != IOMMU_DOMAIN_UNMANAGED)
return NULL;
 
+   /* Always return the same domain. */
+   if (mtk_domain_v1)
+   return _domain_v1->domain;
+
dom = kzalloc(sizeof(*dom), GFP_KERNEL);
if (!dom)
return NULL;
 
+   mtk_domain_v1 = dom;
return >domain;
 }
 
@@ -418,20 +426,12 @@ static int mtk_iommu_create_mapping(struct device *dev,
m4udev->archdata.iommu = mtk_mapping;
}
 
-   ret = arm_iommu_attach_device(dev, mtk_mapping);
-   if (ret)
-   goto err_release_mapping;
-
return 0;
-
-err_release_mapping:
-   arm_iommu_release_mapping(mtk_mapping);
-   m4udev->archdata.iommu = NULL;
-   return ret;
 }
 
 static int mtk_iommu_add_device(struct device *dev)
 {
+   struct dma_iommu_mapping *mtk_mapping;
struct of_phandle_args iommu_spec;
struct of_phandle_iterator it;
struct mtk_iommu_data *data;
@@ -460,7 +460,9 @@ static int mtk_iommu_add_device(struct device *dev)
return PTR_ERR(group);
 
  

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng  wrote:
>
>
> 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby  写到:
>>Hi Icenowy,
>>
>>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng 
>>wrote:
>>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die
>>used
>>> for many new F-series products, including F1C100A, F1C100s, F1C200s,
>>> F1C500, F1C600).
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  arch/arm/mach-sunxi/Kconfig| 13 +
>>>  arch/arm/mach-sunxi/Makefile   |  1 +
>>>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>>>  3 files changed, 36 insertions(+)
>>>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>>>
>>> diff --git a/arch/arm/mach-sunxi/Kconfig
>>b/arch/arm/mach-sunxi/Kconfig
>>> index 65509a35935f..78ac9ce70641 100644
>>> --- a/arch/arm/mach-sunxi/Kconfig
>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>> @@ -59,3 +59,16 @@ config MACH_SUN9I
>>> select ARM_GIC
>>>
>>>  endif
>>> +
>>> +menuconfig ARCH_SUNXI_V5
>>> +   bool "Allwinner SoCs"
>>
>>That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?
>
> This is already required by armv5.
>
> Allwinner currently has only ARMv5,7,8 SoCs. ARMv8 is under
> arm64 architecture, and ARMv5 and v7 cannot be selected at the same time.

I'm going to try to back my way out of this hole by saying that they
should be more descriptive anyway (and it'll give clueless kconfiggers
a hint as to why they're not seeing their SoC listed)

However you're right, if both cannot be visible at the same time, then
it really doesn't matter if they both have the same name.

Sorry for the noise,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng  wrote:
>
>
> 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby  写到:
>>Hi Icenowy,
>>
>>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng 
>>wrote:
>>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die
>>used
>>> for many new F-series products, including F1C100A, F1C100s, F1C200s,
>>> F1C500, F1C600).
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  arch/arm/mach-sunxi/Kconfig| 13 +
>>>  arch/arm/mach-sunxi/Makefile   |  1 +
>>>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>>>  3 files changed, 36 insertions(+)
>>>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>>>
>>> diff --git a/arch/arm/mach-sunxi/Kconfig
>>b/arch/arm/mach-sunxi/Kconfig
>>> index 65509a35935f..78ac9ce70641 100644
>>> --- a/arch/arm/mach-sunxi/Kconfig
>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>> @@ -59,3 +59,16 @@ config MACH_SUN9I
>>> select ARM_GIC
>>>
>>>  endif
>>> +
>>> +menuconfig ARCH_SUNXI_V5
>>> +   bool "Allwinner SoCs"
>>
>>That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?
>
> This is already required by armv5.
>
> Allwinner currently has only ARMv5,7,8 SoCs. ARMv8 is under
> arm64 architecture, and ARMv5 and v7 cannot be selected at the same time.

I'm going to try to back my way out of this hole by saying that they
should be more descriptive anyway (and it'll give clueless kconfiggers
a hint as to why they're not seeing their SoC listed)

However you're right, if both cannot be visible at the same time, then
it really doesn't matter if they both have the same name.

Sorry for the noise,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[PATCH 5/6] ARM: da8xx: Move CFGCHIP registration to init_time

[David Lechner]

This moves the registration of the CFGCHIP syscon device to the
init_time callback. This is in preparation of moving to the common
clock framework. There are a number of clocks in this syscon device
so it will be needed at this point in boot to register the clocks.

In da850.c also move the PLL unlock code to make use of the CFGCHIP
regmap. It makes more sense to have it in init_time anyway since it
is related to clocks.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/board-da830-evm.c |  4 
 arch/arm/mach-davinci/board-da850-evm.c |  4 
 arch/arm/mach-davinci/board-mityomapl138.c  |  4 
 arch/arm/mach-davinci/board-omapl138-hawk.c |  4 
 arch/arm/mach-davinci/da830.c   |  1 +
 arch/arm/mach-davinci/da850.c   | 28 
 arch/arm/mach-davinci/devices-da8xx.c   | 29 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  3 ++-
 8 files changed, 19 insertions(+), 58 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index 7adf009..3a1a86c 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -551,10 +551,6 @@ static __init void da830_evm_init(void)
struct davinci_soc_info *soc_info = _soc_info;
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da830_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d9d423d..3063478 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1334,10 +1334,6 @@ static __init void da850_evm_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
b/arch/arm/mach-davinci/board-mityomapl138.c
index f9a725a..d1c8548 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -502,10 +502,6 @@ static void __init mityomapl138_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
/* for now, no special EDMA channels are reserved */
ret = da850_register_edma(NULL);
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index bc8a747..e2ba9da 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -281,10 +281,6 @@ static __init void omapl138_hawk_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 350d767..39de5a6 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1223,6 +1223,7 @@ void __init da830_init(void)
 
 void __init da830_init_time(void)
 {
+   da8xx_register_cfgchip();
davinci_clk_init(da830_clks);
davinci_timer_init();
 }
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 34117e61..5c86d77 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -40,10 +42,6 @@
 
 #define DA850_REF_FREQ 2400
 
-#define CFGCHIP3_ASYNC3_CLKSRC BIT(4)
-#define CFGCHIP3_PLL1_MASTER_LOCK  BIT(5)
-#define CFGCHIP0_PLL_MASTER_LOCK   BIT(4)
-
 static int da850_set_armrate(struct clk *clk, unsigned long rate);
 static int da850_round_armrate(struct clk *clk, unsigned long rate);
 static int da850_set_pll0rate(struct clk *clk, unsigned long armrate);
@@ -1370,8 +1368,6 @@ static const struct davinci_soc_info 
davinci_soc_info_da850 = {
 
 void __init da850_init(void)
 {
-   unsigned int v;
-
davinci_common_init(_soc_info_da850);
 
da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
@@ -1381,20 +1377,20 @@ void __init da850_init(void)
da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
return;
-
-   /* Unlock writing to PLL0 registers */
-   v = 

[PATCH 4/6] ARM: davinci: move davinci_clk_init() to init_time

[David Lechner]

This moves the call of davinci_clk_init() from map_io to init_time for all
boards.

This is the proper place to init clocks. This is also done in preparation
for moving to the common clock framework.

dm646x is a special case because we need to handle different ref_clk rates
depending on which board is being used. The clock init in this case is
modified to set the rate before registering the clocks instead of using
davinci_set_refclk_rate() to recalculate the entire clock tree after all
of the clocks are registered.

Also, the cpu_clks field is removed from struct davinci_soc_info since it
is no longer needed.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/board-da830-evm.c |  2 +-
 arch/arm/mach-davinci/board-da850-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |  2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|  2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 19 +--
 arch/arm/mach-davinci/board-mityomapl138.c  |  2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c |  2 +-
 arch/arm/mach-davinci/board-sffsdr.c|  2 +-
 arch/arm/mach-davinci/da830.c   |  7 +--
 arch/arm/mach-davinci/da850.c   |  7 +--
 arch/arm/mach-davinci/da8xx-dt.c|  2 +-
 arch/arm/mach-davinci/davinci.h |  4 
 arch/arm/mach-davinci/dm355.c   |  8 ++--
 arch/arm/mach-davinci/dm365.c   |  8 ++--
 arch/arm/mach-davinci/dm644x.c  |  8 ++--
 arch/arm/mach-davinci/dm646x.c  | 22 +++---
 arch/arm/mach-davinci/include/mach/common.h |  1 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  3 +++
 21 files changed, 70 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index a58bfca..7adf009 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -638,7 +638,7 @@ MACHINE_START(DAVINCI_DA830_EVM, "DaVinci 
DA830/OMAP-L137/AM17x EVM")
.atag_offset= 0x100,
.map_io = da830_evm_map_io,
.init_irq   = cp_intc_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = da830_init_time,
.init_machine   = da830_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 9daeab3..d9d423d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1481,7 +1481,7 @@ MACHINE_START(DAVINCI_DA850_EVM, "DaVinci 
DA850/OMAP-L138/AM18x EVM")
.atag_offset= 0x100,
.map_io = da850_evm_map_io,
.init_irq   = cp_intc_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = da850_init_time,
.init_machine   = da850_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index d60d998..3c15cb7 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -416,7 +416,7 @@ MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM")
.atag_offset  = 0x100,
.map_io   = dm355_evm_map_io,
.init_irq = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm355_init_time,
.init_machine = dm355_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 1e7e9b8..3ebc89d 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -271,7 +271,7 @@ MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard")
.atag_offset  = 0x100,
.map_io   = dm355_leopard_map_io,
.init_irq = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm355_init_time,
.init_machine = dm355_leopard_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 17b2c29..3daeac7 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -774,7 +774,7 @@ MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
.atag_offset= 0x100,
.map_io = dm365_evm_map_io,
.init_irq   = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm365_init_time,
.init_machine   = dm365_evm_init,

[PATCH 3/6] phy: da8xx-usb: rename clock con_ids

[David Lechner]

This renames the clock con_ids in the DA8XX USB PHY driver as well as
the matching names in the mach clock registration code.

This is in preparation for using device tree clocks where these names
will become part of the device tree bindings. The new names more closely
match the names used in the USB clock diagram in the SoC TRM.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/usb-da8xx.c | 12 ++--
 drivers/phy/ti/phy-da8xx-usb.c|  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/usb-da8xx.c 
b/arch/arm/mach-davinci/usb-da8xx.c
index d480a02..fb31f6e 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -256,14 +256,14 @@ static int usb20_phy_clk_set_parent(struct clk *clk, 
struct clk *parent)
 }
 
 static struct clk usb20_phy_clk = {
-   .name   = "usb20_phy",
+   .name   = "usb0_clk48",
.clk_enable = usb20_phy_clk_enable,
.clk_disable= usb20_phy_clk_disable,
.set_parent = usb20_phy_clk_set_parent,
 };
 
 static struct clk_lookup usb20_phy_clk_lookup =
-   CLK("da8xx-usb-phy", "usb20_phy", _phy_clk);
+   CLK("da8xx-usb-phy", "usb0_clk48", _phy_clk);
 
 /**
  * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
@@ -320,18 +320,18 @@ static int usb11_phy_clk_set_parent(struct clk *clk, 
struct clk *parent)
 }
 
 static struct clk usb11_phy_clk = {
-   .name   = "usb11_phy",
+   .name   = "usb1_clk48",
.set_parent = usb11_phy_clk_set_parent,
 };
 
 static struct clk_lookup usb11_phy_clk_lookup =
-   CLK("da8xx-usb-phy", "usb11_phy", _phy_clk);
+   CLK("da8xx-usb-phy", "usb1_clk48", _phy_clk);
 
 /**
  * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
  *
  * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
- * or "usb20_phy" if false.
+ * or "usb0_clk48" if false.
  */
 int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
 {
@@ -341,7 +341,7 @@ int __init da8xx_register_usb11_phy_clk(bool 
use_usb_refclkin)
if (use_usb_refclkin)
parent = clk_get(NULL, "usb_refclkin");
else
-   parent = clk_get(_usb_phy.dev, "usb20_phy");
+   parent = clk_get(_usb_phy.dev, "usb0_clk48");
if (IS_ERR(parent))
return PTR_ERR(parent);
 
diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index d463587..4daa905 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -160,15 +160,15 @@ static int da8xx_usb_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(d_phy->regmap);
}
 
-   d_phy->usb11_clk = devm_clk_get(dev, "usb11_phy");
+   d_phy->usb11_clk = devm_clk_get(dev, "usb1_clk48");
if (IS_ERR(d_phy->usb11_clk)) {
-   dev_err(dev, "Failed to get usb11_phy clock\n");
+   dev_err(dev, "Failed to get usb1_clk48\n");
return PTR_ERR(d_phy->usb11_clk);
}
 
-   d_phy->usb20_clk = devm_clk_get(dev, "usb20_phy");
+   d_phy->usb20_clk = devm_clk_get(dev, "usb0_clk48");
if (IS_ERR(d_phy->usb20_clk)) {
-   dev_err(dev, "Failed to get usb20_phy clock\n");
+   dev_err(dev, "Failed to get usb0_clk48\n");
return PTR_ERR(d_phy->usb20_clk);
}
 
-- 
2.7.4

[PATCH 6/6] phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

[David Lechner]

This drops the use of syscon_regmap_lookup_by_pdevname() from the
DA8XX USB PHY driver. There are no longer any boards that register
a syscon platform device, so it is no longer needed.

Signed-off-by: David Lechner 
---
 drivers/phy/ti/phy-da8xx-usb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index 4daa905..76f4fe9 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -153,8 +153,6 @@ static int da8xx_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
 
d_phy->regmap = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
-   if (IS_ERR(d_phy->regmap))
-   d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
if (IS_ERR(d_phy->regmap)) {
dev_err(dev, "Failed to get syscon\n");
return PTR_ERR(d_phy->regmap);
-- 
2.7.4

[PATCH 5/6] ARM: da8xx: Move CFGCHIP registration to init_time

[David Lechner]

This moves the registration of the CFGCHIP syscon device to the
init_time callback. This is in preparation of moving to the common
clock framework. There are a number of clocks in this syscon device
so it will be needed at this point in boot to register the clocks.

In da850.c also move the PLL unlock code to make use of the CFGCHIP
regmap. It makes more sense to have it in init_time anyway since it
is related to clocks.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/board-da830-evm.c |  4 
 arch/arm/mach-davinci/board-da850-evm.c |  4 
 arch/arm/mach-davinci/board-mityomapl138.c  |  4 
 arch/arm/mach-davinci/board-omapl138-hawk.c |  4 
 arch/arm/mach-davinci/da830.c   |  1 +
 arch/arm/mach-davinci/da850.c   | 28 
 arch/arm/mach-davinci/devices-da8xx.c   | 29 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  3 ++-
 8 files changed, 19 insertions(+), 58 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index 7adf009..3a1a86c 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -551,10 +551,6 @@ static __init void da830_evm_init(void)
struct davinci_soc_info *soc_info = _soc_info;
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da830_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d9d423d..3063478 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1334,10 +1334,6 @@ static __init void da850_evm_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
b/arch/arm/mach-davinci/board-mityomapl138.c
index f9a725a..d1c8548 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -502,10 +502,6 @@ static void __init mityomapl138_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
/* for now, no special EDMA channels are reserved */
ret = da850_register_edma(NULL);
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index bc8a747..e2ba9da 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -281,10 +281,6 @@ static __init void omapl138_hawk_init(void)
 {
int ret;
 
-   ret = da8xx_register_cfgchip();
-   if (ret)
-   pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 350d767..39de5a6 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1223,6 +1223,7 @@ void __init da830_init(void)
 
 void __init da830_init_time(void)
 {
+   da8xx_register_cfgchip();
davinci_clk_init(da830_clks);
davinci_timer_init();
 }
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 34117e61..5c86d77 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -40,10 +42,6 @@
 
 #define DA850_REF_FREQ 2400
 
-#define CFGCHIP3_ASYNC3_CLKSRC BIT(4)
-#define CFGCHIP3_PLL1_MASTER_LOCK  BIT(5)
-#define CFGCHIP0_PLL_MASTER_LOCK   BIT(4)
-
 static int da850_set_armrate(struct clk *clk, unsigned long rate);
 static int da850_round_armrate(struct clk *clk, unsigned long rate);
 static int da850_set_pll0rate(struct clk *clk, unsigned long armrate);
@@ -1370,8 +1368,6 @@ static const struct davinci_soc_info 
davinci_soc_info_da850 = {
 
 void __init da850_init(void)
 {
-   unsigned int v;
-
davinci_common_init(_soc_info_da850);
 
da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
@@ -1381,20 +1377,20 @@ void __init da850_init(void)
da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
return;
-
-   /* Unlock writing to PLL0 registers */
-   v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG));
-   v 

[PATCH 4/6] ARM: davinci: move davinci_clk_init() to init_time

[David Lechner]

This moves the call of davinci_clk_init() from map_io to init_time for all
boards.

This is the proper place to init clocks. This is also done in preparation
for moving to the common clock framework.

dm646x is a special case because we need to handle different ref_clk rates
depending on which board is being used. The clock init in this case is
modified to set the rate before registering the clocks instead of using
davinci_set_refclk_rate() to recalculate the entire clock tree after all
of the clocks are registered.

Also, the cpu_clks field is removed from struct davinci_soc_info since it
is no longer needed.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/board-da830-evm.c |  2 +-
 arch/arm/mach-davinci/board-da850-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |  2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|  2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 19 +--
 arch/arm/mach-davinci/board-mityomapl138.c  |  2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c |  2 +-
 arch/arm/mach-davinci/board-sffsdr.c|  2 +-
 arch/arm/mach-davinci/da830.c   |  7 +--
 arch/arm/mach-davinci/da850.c   |  7 +--
 arch/arm/mach-davinci/da8xx-dt.c|  2 +-
 arch/arm/mach-davinci/davinci.h |  4 
 arch/arm/mach-davinci/dm355.c   |  8 ++--
 arch/arm/mach-davinci/dm365.c   |  8 ++--
 arch/arm/mach-davinci/dm644x.c  |  8 ++--
 arch/arm/mach-davinci/dm646x.c  | 22 +++---
 arch/arm/mach-davinci/include/mach/common.h |  1 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  3 +++
 21 files changed, 70 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index a58bfca..7adf009 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -638,7 +638,7 @@ MACHINE_START(DAVINCI_DA830_EVM, "DaVinci 
DA830/OMAP-L137/AM17x EVM")
.atag_offset= 0x100,
.map_io = da830_evm_map_io,
.init_irq   = cp_intc_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = da830_init_time,
.init_machine   = da830_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 9daeab3..d9d423d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1481,7 +1481,7 @@ MACHINE_START(DAVINCI_DA850_EVM, "DaVinci 
DA850/OMAP-L138/AM18x EVM")
.atag_offset= 0x100,
.map_io = da850_evm_map_io,
.init_irq   = cp_intc_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = da850_init_time,
.init_machine   = da850_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index d60d998..3c15cb7 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -416,7 +416,7 @@ MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM")
.atag_offset  = 0x100,
.map_io   = dm355_evm_map_io,
.init_irq = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm355_init_time,
.init_machine = dm355_evm_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 1e7e9b8..3ebc89d 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -271,7 +271,7 @@ MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard")
.atag_offset  = 0x100,
.map_io   = dm355_leopard_map_io,
.init_irq = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm355_init_time,
.init_machine = dm355_leopard_init,
.init_late  = davinci_init_late,
.dma_zone_size  = SZ_128M,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 17b2c29..3daeac7 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -774,7 +774,7 @@ MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
.atag_offset= 0x100,
.map_io = dm365_evm_map_io,
.init_irq   = davinci_irq_init,
-   .init_time  = davinci_timer_init,
+   .init_time  = dm365_init_time,
.init_machine   = dm365_evm_init,
.init_late  = 

[PATCH 3/6] phy: da8xx-usb: rename clock con_ids

[David Lechner]

This renames the clock con_ids in the DA8XX USB PHY driver as well as
the matching names in the mach clock registration code.

This is in preparation for using device tree clocks where these names
will become part of the device tree bindings. The new names more closely
match the names used in the USB clock diagram in the SoC TRM.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/usb-da8xx.c | 12 ++--
 drivers/phy/ti/phy-da8xx-usb.c|  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/usb-da8xx.c 
b/arch/arm/mach-davinci/usb-da8xx.c
index d480a02..fb31f6e 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -256,14 +256,14 @@ static int usb20_phy_clk_set_parent(struct clk *clk, 
struct clk *parent)
 }
 
 static struct clk usb20_phy_clk = {
-   .name   = "usb20_phy",
+   .name   = "usb0_clk48",
.clk_enable = usb20_phy_clk_enable,
.clk_disable= usb20_phy_clk_disable,
.set_parent = usb20_phy_clk_set_parent,
 };
 
 static struct clk_lookup usb20_phy_clk_lookup =
-   CLK("da8xx-usb-phy", "usb20_phy", _phy_clk);
+   CLK("da8xx-usb-phy", "usb0_clk48", _phy_clk);
 
 /**
  * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
@@ -320,18 +320,18 @@ static int usb11_phy_clk_set_parent(struct clk *clk, 
struct clk *parent)
 }
 
 static struct clk usb11_phy_clk = {
-   .name   = "usb11_phy",
+   .name   = "usb1_clk48",
.set_parent = usb11_phy_clk_set_parent,
 };
 
 static struct clk_lookup usb11_phy_clk_lookup =
-   CLK("da8xx-usb-phy", "usb11_phy", _phy_clk);
+   CLK("da8xx-usb-phy", "usb1_clk48", _phy_clk);
 
 /**
  * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
  *
  * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
- * or "usb20_phy" if false.
+ * or "usb0_clk48" if false.
  */
 int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
 {
@@ -341,7 +341,7 @@ int __init da8xx_register_usb11_phy_clk(bool 
use_usb_refclkin)
if (use_usb_refclkin)
parent = clk_get(NULL, "usb_refclkin");
else
-   parent = clk_get(_usb_phy.dev, "usb20_phy");
+   parent = clk_get(_usb_phy.dev, "usb0_clk48");
if (IS_ERR(parent))
return PTR_ERR(parent);
 
diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index d463587..4daa905 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -160,15 +160,15 @@ static int da8xx_usb_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(d_phy->regmap);
}
 
-   d_phy->usb11_clk = devm_clk_get(dev, "usb11_phy");
+   d_phy->usb11_clk = devm_clk_get(dev, "usb1_clk48");
if (IS_ERR(d_phy->usb11_clk)) {
-   dev_err(dev, "Failed to get usb11_phy clock\n");
+   dev_err(dev, "Failed to get usb1_clk48\n");
return PTR_ERR(d_phy->usb11_clk);
}
 
-   d_phy->usb20_clk = devm_clk_get(dev, "usb20_phy");
+   d_phy->usb20_clk = devm_clk_get(dev, "usb0_clk48");
if (IS_ERR(d_phy->usb20_clk)) {
-   dev_err(dev, "Failed to get usb20_phy clock\n");
+   dev_err(dev, "Failed to get usb0_clk48\n");
return PTR_ERR(d_phy->usb20_clk);
}
 
-- 
2.7.4

[PATCH 6/6] phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

[David Lechner]

This drops the use of syscon_regmap_lookup_by_pdevname() from the
DA8XX USB PHY driver. There are no longer any boards that register
a syscon platform device, so it is no longer needed.

Signed-off-by: David Lechner 
---
 drivers/phy/ti/phy-da8xx-usb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index 4daa905..76f4fe9 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -153,8 +153,6 @@ static int da8xx_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
 
d_phy->regmap = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
-   if (IS_ERR(d_phy->regmap))
-   d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
if (IS_ERR(d_phy->regmap)) {
dev_err(dev, "Failed to get syscon\n");
return PTR_ERR(d_phy->regmap);
-- 
2.7.4

[PATCH 2/6] phy: da8xx-usb: Always check for syscon compatible

[David Lechner]

This slightly changes the logic for getting the CFGCHIP syscon register.
We now always call syscon_regmap_lookup_by_compatible() even when not
using device tree. This is in preparation for some changes in how the
CFGCHIP syscon regmap is registered on da8xx platforms.

Signed-off-by: David Lechner 
---
 drivers/phy/ti/phy-da8xx-usb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index 1b82bff..d463587 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -152,10 +152,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
*pdev)
if (!d_phy)
return -ENOMEM;
 
-   if (node)
-   d_phy->regmap = syscon_regmap_lookup_by_compatible(
-   "ti,da830-cfgchip");
-   else
+   d_phy->regmap = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
+   if (IS_ERR(d_phy->regmap))
d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
if (IS_ERR(d_phy->regmap)) {
dev_err(dev, "Failed to get syscon\n");
-- 
2.7.4

[PATCH 0/6] ARM: davinci: common clock prep work

[David Lechner]

This series contains some changes needed for the conversion of arch/arm/mach-
davinci to the common clock framework.

Most of the boards in mach-davinci do not have device tree support. However,
CFGCHIP, which is a syscon regmap, is needed during clock init in early boot.
Using a platform device for the syscon at this point is not an option. So,
this series introduces a new way to register a syscon regmap on non-DT systems.

The DA8XX USB PHY driver is a consumer of the CFGCHIP syscon regmap, so some
changes are needed in that driver as well since we are removing the syscon
platform devices. The patch "phy: da8xx-usb: rename clock con_ids" doesn't
have anything to do with syscon, but I included in this series because we are
touching PHY code here anyway and it is also a dependency for the upcoming
common clock framework conversion changes.

Maintainers, please coordinate with Sekhar before committing. We will probably
want everything to go through the linux-davinci tree if possible.

David Lechner (6):
  mfd: syscon: Add syscon_register() function
  phy: da8xx-usb: Always check for syscon compatible
  phy: da8xx-usb: rename clock con_ids
  ARM: davinci: move davinci_clk_init() to init_time
  ARM: da8xx: Move CFGCHIP registration to init_time
  phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

 arch/arm/mach-davinci/board-da830-evm.c |  6 +--
 arch/arm/mach-davinci/board-da850-evm.c |  6 +--
 arch/arm/mach-davinci/board-dm355-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |  2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|  2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 19 +---
 arch/arm/mach-davinci/board-mityomapl138.c  |  6 +--
 arch/arm/mach-davinci/board-neuros-osd2.c   |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c |  6 +--
 arch/arm/mach-davinci/board-sffsdr.c|  2 +-
 arch/arm/mach-davinci/da830.c   |  8 +++-
 arch/arm/mach-davinci/da850.c   | 31 ++---
 arch/arm/mach-davinci/da8xx-dt.c|  2 +-
 arch/arm/mach-davinci/davinci.h |  4 ++
 arch/arm/mach-davinci/devices-da8xx.c   | 29 ++--
 arch/arm/mach-davinci/dm355.c   |  8 +++-
 arch/arm/mach-davinci/dm365.c   |  8 +++-
 arch/arm/mach-davinci/dm644x.c  |  8 +++-
 arch/arm/mach-davinci/dm646x.c  | 22 -
 arch/arm/mach-davinci/include/mach/common.h |  1 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  6 ++-
 arch/arm/mach-davinci/usb-da8xx.c   | 12 ++---
 drivers/mfd/syscon.c| 71 +
 drivers/phy/ti/phy-da8xx-usb.c  | 14 ++
 include/linux/mfd/syscon.h  |  9 
 26 files changed, 178 insertions(+), 110 deletions(-)

-- 
2.7.4

[PATCH 2/6] phy: da8xx-usb: Always check for syscon compatible

[David Lechner]

This slightly changes the logic for getting the CFGCHIP syscon register.
We now always call syscon_regmap_lookup_by_compatible() even when not
using device tree. This is in preparation for some changes in how the
CFGCHIP syscon regmap is registered on da8xx platforms.

Signed-off-by: David Lechner 
---
 drivers/phy/ti/phy-da8xx-usb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/ti/phy-da8xx-usb.c b/drivers/phy/ti/phy-da8xx-usb.c
index 1b82bff..d463587 100644
--- a/drivers/phy/ti/phy-da8xx-usb.c
+++ b/drivers/phy/ti/phy-da8xx-usb.c
@@ -152,10 +152,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
*pdev)
if (!d_phy)
return -ENOMEM;
 
-   if (node)
-   d_phy->regmap = syscon_regmap_lookup_by_compatible(
-   "ti,da830-cfgchip");
-   else
+   d_phy->regmap = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
+   if (IS_ERR(d_phy->regmap))
d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
if (IS_ERR(d_phy->regmap)) {
dev_err(dev, "Failed to get syscon\n");
-- 
2.7.4

[PATCH 0/6] ARM: davinci: common clock prep work

[David Lechner]

This series contains some changes needed for the conversion of arch/arm/mach-
davinci to the common clock framework.

Most of the boards in mach-davinci do not have device tree support. However,
CFGCHIP, which is a syscon regmap, is needed during clock init in early boot.
Using a platform device for the syscon at this point is not an option. So,
this series introduces a new way to register a syscon regmap on non-DT systems.

The DA8XX USB PHY driver is a consumer of the CFGCHIP syscon regmap, so some
changes are needed in that driver as well since we are removing the syscon
platform devices. The patch "phy: da8xx-usb: rename clock con_ids" doesn't
have anything to do with syscon, but I included in this series because we are
touching PHY code here anyway and it is also a dependency for the upcoming
common clock framework conversion changes.

Maintainers, please coordinate with Sekhar before committing. We will probably
want everything to go through the linux-davinci tree if possible.

David Lechner (6):
  mfd: syscon: Add syscon_register() function
  phy: da8xx-usb: Always check for syscon compatible
  phy: da8xx-usb: rename clock con_ids
  ARM: davinci: move davinci_clk_init() to init_time
  ARM: da8xx: Move CFGCHIP registration to init_time
  phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

 arch/arm/mach-davinci/board-da830-evm.c |  6 +--
 arch/arm/mach-davinci/board-da850-evm.c |  6 +--
 arch/arm/mach-davinci/board-dm355-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |  2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |  2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|  2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 19 +---
 arch/arm/mach-davinci/board-mityomapl138.c  |  6 +--
 arch/arm/mach-davinci/board-neuros-osd2.c   |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c |  6 +--
 arch/arm/mach-davinci/board-sffsdr.c|  2 +-
 arch/arm/mach-davinci/da830.c   |  8 +++-
 arch/arm/mach-davinci/da850.c   | 31 ++---
 arch/arm/mach-davinci/da8xx-dt.c|  2 +-
 arch/arm/mach-davinci/davinci.h |  4 ++
 arch/arm/mach-davinci/devices-da8xx.c   | 29 ++--
 arch/arm/mach-davinci/dm355.c   |  8 +++-
 arch/arm/mach-davinci/dm365.c   |  8 +++-
 arch/arm/mach-davinci/dm644x.c  |  8 +++-
 arch/arm/mach-davinci/dm646x.c  | 22 -
 arch/arm/mach-davinci/include/mach/common.h |  1 -
 arch/arm/mach-davinci/include/mach/da8xx.h  |  6 ++-
 arch/arm/mach-davinci/usb-da8xx.c   | 12 ++---
 drivers/mfd/syscon.c| 71 +
 drivers/phy/ti/phy-da8xx-usb.c  | 14 ++
 include/linux/mfd/syscon.h  |  9 
 26 files changed, 178 insertions(+), 110 deletions(-)

-- 
2.7.4

[PATCH 1/6] mfd: syscon: Add syscon_register() function

[David Lechner]

This adds a new syscon_register() function that creates a new syscon
regmap and adds it to the lookup list.

This function serves two purposes:

1. This is needed for platforms without device tree support where the
   syscon regmap is needed in early boot (e.g. clocks), because using a
   platform driver at this point in boot is not an option.

2. It allows other drivers to use syscon_regmap_lookup_by_compatible()
   for both device tree and non-DT platforms instead of having to have
   a separate case that calls syscon_regmap_lookup_by_pdevname().

Signed-off-by: David Lechner 
---
 drivers/mfd/syscon.c   | 71 ++
 include/linux/mfd/syscon.h |  9 ++
 2 files changed, 80 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index b93fe4c..ab086b1 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+#define SYSCON_COMPATIBLE_SIZE 50
+
 static struct platform_driver syscon_driver;
 
 static DEFINE_SPINLOCK(syscon_list_slock);
@@ -34,6 +36,7 @@ struct syscon {
struct device_node *np;
struct regmap *regmap;
struct list_head list;
+   char compatible[SYSCON_COMPATIBLE_SIZE];
 };
 
 static const struct regmap_config syscon_regmap_config = {
@@ -140,9 +143,27 @@ EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
 
 struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
 {
+   struct syscon *entry, *syscon = NULL;
struct device_node *syscon_np;
struct regmap *regmap;
 
+   spin_lock(_list_slock);
+
+   /* Check for entries registered with syscon_register() */
+   list_for_each_entry(entry, _list, list) {
+   if (!entry->compatible)
+   continue;
+   if (!strncmp(entry->compatible, s, SYSCON_COMPATIBLE_SIZE)) {
+   syscon = entry;
+   break;
+   }
+   }
+
+   spin_unlock(_list_slock);
+
+   if (syscon)
+   return syscon->regmap;
+
syscon_np = of_find_compatible_node(NULL, NULL, s);
if (!syscon_np)
return ERR_PTR(-ENODEV);
@@ -196,6 +217,56 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct 
device_node *np,
 }
 EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
 
+/**
+ * syscon_register - Register a new syscon regmap
+ * @start: The starting memory address of the regmap
+ * @size: The size of the regmap in bytes
+ * @compatible: Compatible string used for lookup
+ *
+ * Returns: Pointer to a regmap or a negative error code.
+ */
+struct regmap *syscon_register(resource_size_t start, size_t size,
+  const char *compatible)
+{
+   struct regmap_config syscon_config = syscon_regmap_config;
+   struct syscon *syscon;
+   void __iomem *base;
+   int err;
+
+   syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
+   if (!syscon)
+   return ERR_PTR(-ENOMEM);
+
+   base = ioremap(start, size);
+   if (!base) {
+   err = -ENOMEM;
+   goto err_free_syscon;
+   }
+
+   strncpy(syscon->compatible, compatible, SYSCON_COMPATIBLE_SIZE);
+
+   syscon_config.max_register = size - 1;
+   syscon->regmap = regmap_init_mmio(NULL, base, _config);
+   if (IS_ERR(syscon->regmap)) {
+   err = PTR_ERR(syscon->regmap);
+   goto err_iounmap;
+   }
+
+   spin_lock(_list_slock);
+   list_add_tail(>list, _list);
+   spin_unlock(_list_slock);
+
+   return syscon->regmap;
+
+err_iounmap:
+   iounmap(base);
+err_free_syscon:
+   kfree(syscon);
+
+   return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(syscon_register);
+
 static int syscon_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 40a76b9..ce531b4 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -27,6 +27,8 @@ extern struct regmap *syscon_regmap_lookup_by_pdevname(const 
char *s);
 extern struct regmap *syscon_regmap_lookup_by_phandle(
struct device_node *np,
const char *property);
+extern struct regmap *syscon_register(resource_size_t start, size_t size,
+ const char *compatible);
 #else
 static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
 {
@@ -49,6 +51,13 @@ static inline struct regmap *syscon_regmap_lookup_by_phandle(
 {
return ERR_PTR(-ENOTSUPP);
 }
+
+static inline struct regmap *syscon_register(resource_size_t start,
+size_t size,
+const char *id)
+{
+   return ERR_PTR(-ENOTSUPP);
+}
 #endif
 
 #endif /* __LINUX_MFD_SYSCON_H__ */
-- 
2.7.4

[PATCH 1/6] mfd: syscon: Add syscon_register() function

[David Lechner]

This adds a new syscon_register() function that creates a new syscon
regmap and adds it to the lookup list.

This function serves two purposes:

1. This is needed for platforms without device tree support where the
   syscon regmap is needed in early boot (e.g. clocks), because using a
   platform driver at this point in boot is not an option.

2. It allows other drivers to use syscon_regmap_lookup_by_compatible()
   for both device tree and non-DT platforms instead of having to have
   a separate case that calls syscon_regmap_lookup_by_pdevname().

Signed-off-by: David Lechner 
---
 drivers/mfd/syscon.c   | 71 ++
 include/linux/mfd/syscon.h |  9 ++
 2 files changed, 80 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index b93fe4c..ab086b1 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+#define SYSCON_COMPATIBLE_SIZE 50
+
 static struct platform_driver syscon_driver;
 
 static DEFINE_SPINLOCK(syscon_list_slock);
@@ -34,6 +36,7 @@ struct syscon {
struct device_node *np;
struct regmap *regmap;
struct list_head list;
+   char compatible[SYSCON_COMPATIBLE_SIZE];
 };
 
 static const struct regmap_config syscon_regmap_config = {
@@ -140,9 +143,27 @@ EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
 
 struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
 {
+   struct syscon *entry, *syscon = NULL;
struct device_node *syscon_np;
struct regmap *regmap;
 
+   spin_lock(_list_slock);
+
+   /* Check for entries registered with syscon_register() */
+   list_for_each_entry(entry, _list, list) {
+   if (!entry->compatible)
+   continue;
+   if (!strncmp(entry->compatible, s, SYSCON_COMPATIBLE_SIZE)) {
+   syscon = entry;
+   break;
+   }
+   }
+
+   spin_unlock(_list_slock);
+
+   if (syscon)
+   return syscon->regmap;
+
syscon_np = of_find_compatible_node(NULL, NULL, s);
if (!syscon_np)
return ERR_PTR(-ENODEV);
@@ -196,6 +217,56 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct 
device_node *np,
 }
 EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
 
+/**
+ * syscon_register - Register a new syscon regmap
+ * @start: The starting memory address of the regmap
+ * @size: The size of the regmap in bytes
+ * @compatible: Compatible string used for lookup
+ *
+ * Returns: Pointer to a regmap or a negative error code.
+ */
+struct regmap *syscon_register(resource_size_t start, size_t size,
+  const char *compatible)
+{
+   struct regmap_config syscon_config = syscon_regmap_config;
+   struct syscon *syscon;
+   void __iomem *base;
+   int err;
+
+   syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
+   if (!syscon)
+   return ERR_PTR(-ENOMEM);
+
+   base = ioremap(start, size);
+   if (!base) {
+   err = -ENOMEM;
+   goto err_free_syscon;
+   }
+
+   strncpy(syscon->compatible, compatible, SYSCON_COMPATIBLE_SIZE);
+
+   syscon_config.max_register = size - 1;
+   syscon->regmap = regmap_init_mmio(NULL, base, _config);
+   if (IS_ERR(syscon->regmap)) {
+   err = PTR_ERR(syscon->regmap);
+   goto err_iounmap;
+   }
+
+   spin_lock(_list_slock);
+   list_add_tail(>list, _list);
+   spin_unlock(_list_slock);
+
+   return syscon->regmap;
+
+err_iounmap:
+   iounmap(base);
+err_free_syscon:
+   kfree(syscon);
+
+   return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(syscon_register);
+
 static int syscon_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 40a76b9..ce531b4 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -27,6 +27,8 @@ extern struct regmap *syscon_regmap_lookup_by_pdevname(const 
char *s);
 extern struct regmap *syscon_regmap_lookup_by_phandle(
struct device_node *np,
const char *property);
+extern struct regmap *syscon_register(resource_size_t start, size_t size,
+ const char *compatible);
 #else
 static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
 {
@@ -49,6 +51,13 @@ static inline struct regmap *syscon_regmap_lookup_by_phandle(
 {
return ERR_PTR(-ENOTSUPP);
 }
+
+static inline struct regmap *syscon_register(resource_size_t start,
+size_t size,
+const char *id)
+{
+   return ERR_PTR(-ENOTSUPP);
+}
 #endif
 
 #endif /* __LINUX_MFD_SYSCON_H__ */
-- 
2.7.4

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Icenowy Zheng]

于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby  写到:
>Hi Icenowy,
>
>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng 
>wrote:
>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die
>used
>> for many new F-series products, including F1C100A, F1C100s, F1C200s,
>> F1C500, F1C600).
>>
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm/mach-sunxi/Kconfig| 13 +
>>  arch/arm/mach-sunxi/Makefile   |  1 +
>>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>>  3 files changed, 36 insertions(+)
>>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig
>b/arch/arm/mach-sunxi/Kconfig
>> index 65509a35935f..78ac9ce70641 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -59,3 +59,16 @@ config MACH_SUN9I
>> select ARM_GIC
>>
>>  endif
>> +
>> +menuconfig ARCH_SUNXI_V5
>> +   bool "Allwinner SoCs"
>
>That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?

This is already required by armv5.

Allwinner currently has only ARMv5,7,8 SoCs. ARMv8 is under
arm64 architecture, and ARMv5 and v7 cannot be selected at the same time.

>
>Thanks,

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Icenowy Zheng]

于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby  写到:
>Hi Icenowy,
>
>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng 
>wrote:
>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die
>used
>> for many new F-series products, including F1C100A, F1C100s, F1C200s,
>> F1C500, F1C600).
>>
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm/mach-sunxi/Kconfig| 13 +
>>  arch/arm/mach-sunxi/Makefile   |  1 +
>>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>>  3 files changed, 36 insertions(+)
>>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig
>b/arch/arm/mach-sunxi/Kconfig
>> index 65509a35935f..78ac9ce70641 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -59,3 +59,16 @@ config MACH_SUN9I
>> select ARM_GIC
>>
>>  endif
>> +
>> +menuconfig ARCH_SUNXI_V5
>> +   bool "Allwinner SoCs"
>
>That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?

This is already required by armv5.

Allwinner currently has only ARMv5,7,8 SoCs. ARMv8 is under
arm64 architecture, and ARMv5 and v7 cannot be selected at the same time.

>
>Thanks,

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng  wrote:
> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die used
> for many new F-series products, including F1C100A, F1C100s, F1C200s,
> F1C500, F1C600).
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/mach-sunxi/Kconfig| 13 +
>  arch/arm/mach-sunxi/Makefile   |  1 +
>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>  3 files changed, 36 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 65509a35935f..78ac9ce70641 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -59,3 +59,16 @@ config MACH_SUN9I
> select ARM_GIC
>
>  endif
> +
> +menuconfig ARCH_SUNXI_V5
> +   bool "Allwinner SoCs"

That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng  wrote:
> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die used
> for many new F-series products, including F1C100A, F1C100s, F1C200s,
> F1C500, F1C600).
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/mach-sunxi/Kconfig| 13 +
>  arch/arm/mach-sunxi/Makefile   |  1 +
>  arch/arm/mach-sunxi/sunxi_v5.c | 22 ++
>  3 files changed, 36 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 65509a35935f..78ac9ce70641 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -59,3 +59,16 @@ config MACH_SUN9I
> select ARM_GIC
>
>  endif
> +
> +menuconfig ARCH_SUNXI_V5
> +   bool "Allwinner SoCs"

That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng  wrote:
> Allwinner also has some ARMv5 SoCs.
>
> In order to add support for them, add a CONFIG_ARCH_SUNXI_V7 option that
> is selectable when ARMv7 is selceted, and make CONFIG_ARCH_SUNXI a
> common bool config which is selected by both V7 and V5 sunxi option.
>
> The ARMv7 defconfigs are modified to have the new CONFIG_ARCH_SUNXI_V7
> option.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/configs/multi_v7_defconfig |  2 +-
>  arch/arm/configs/sunxi_defconfig|  2 +-
>  arch/arm/mach-sunxi/Kconfig | 14 --
>  arch/arm/mach-sunxi/Makefile|  2 +-
>  4 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 58153cdf025b..65509a35935f 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1,6 +1,16 @@
> -menuconfig ARCH_SUNXI
> +config ARCH_SUNXI
> +   bool
> +   select ARCH_HAS_RESET_CONTROLLER
> +   select CLKSRC_MMIO
> +   select GENERIC_IRQ_CHIP
> +   select GPIOLIB
> +   select PINCTRL
> +   select RESET_CONTROLLER
> +
> +menuconfig ARCH_SUNXI_V7
> bool "Allwinner SoCs"
> depends on ARCH_MULTI_V7
> +   select ARCH_SUNXI
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_MMIO
> select GENERIC_IRQ_CHIP

Shouldn't you remove all the common ARCH_SUNXI selects from ARCH_SUNXI_v7?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs

[Julian Calaby]

Hi Icenowy,

On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng  wrote:
> Allwinner also has some ARMv5 SoCs.
>
> In order to add support for them, add a CONFIG_ARCH_SUNXI_V7 option that
> is selectable when ARMv7 is selceted, and make CONFIG_ARCH_SUNXI a
> common bool config which is selected by both V7 and V5 sunxi option.
>
> The ARMv7 defconfigs are modified to have the new CONFIG_ARCH_SUNXI_V7
> option.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/configs/multi_v7_defconfig |  2 +-
>  arch/arm/configs/sunxi_defconfig|  2 +-
>  arch/arm/mach-sunxi/Kconfig | 14 --
>  arch/arm/mach-sunxi/Makefile|  2 +-
>  4 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 58153cdf025b..65509a35935f 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1,6 +1,16 @@
> -menuconfig ARCH_SUNXI
> +config ARCH_SUNXI
> +   bool
> +   select ARCH_HAS_RESET_CONTROLLER
> +   select CLKSRC_MMIO
> +   select GENERIC_IRQ_CHIP
> +   select GPIOLIB
> +   select PINCTRL
> +   select RESET_CONTROLLER
> +
> +menuconfig ARCH_SUNXI_V7
> bool "Allwinner SoCs"
> depends on ARCH_MULTI_V7
> +   select ARCH_SUNXI
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_MMIO
> select GENERIC_IRQ_CHIP

Shouldn't you remove all the common ARCH_SUNXI selects from ARCH_SUNXI_v7?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] watchdog: core: make sure the watchdog_worker is not deferred

[Guenter Roeck]

On 01/18/2018 03:11 AM, Christophe Leroy wrote:

commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the
effect of deferring timer handling in case of high CPU load, hence
delaying the delayed work allthought the worker is running which
high realtime priority.

As hrtimers are not managed by softirqs, this patch replaces the
delayed work by a plain work and uses an hrtimer to schedule that work.

Signed-off-by: Christophe Leroy 


Reviewed-by: Guenter Roeck 


---
  drivers/watchdog/watchdog_dev.c | 86 +
  1 file changed, 52 insertions(+), 34 deletions(-)

diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 68bc29e6e79e..ffbdc4642ea5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -36,10 +36,10 @@
  #include /* For the -ENODEV/... values */
  #include/* For file operations */
  #include  /* For __init/__exit/... */
-#include/* For timeout functions */
+#include/* For hrtimers */
  #include/* For printk/panic/... */
  #include  /* For data references */
-#include/* For kthread_delayed_work */
+#include/* For kthread_work */
  #include/* For handling misc devices */
  #include/* For module stuff/... */
  #include /* For mutexes */
@@ -67,9 +67,10 @@ struct watchdog_core_data {
struct cdev cdev;
struct watchdog_device *wdd;
struct mutex lock;
-   unsigned long last_keepalive;
-   unsigned long last_hw_keepalive;
-   struct kthread_delayed_work work;
+   ktime_t last_keepalive;
+   ktime_t last_hw_keepalive;
+   struct hrtimer timer;
+   struct kthread_work work;
unsigned long status;   /* Internal status bits */
  #define _WDOG_DEV_OPEN0   /* Opened ? */
  #define _WDOG_ALLOW_RELEASE   1   /* Did we receive the magic char ? */
@@ -109,18 +110,19 @@ static inline bool watchdog_need_worker(struct 
watchdog_device *wdd)
(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
  }
  
-static long watchdog_next_keepalive(struct watchdog_device *wdd)

+static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
  {
struct watchdog_core_data *wd_data = wdd->wd_data;
unsigned int timeout_ms = wdd->timeout * 1000;
-   unsigned long keepalive_interval;
-   unsigned long last_heartbeat;
-   unsigned long virt_timeout;
+   ktime_t keepalive_interval;
+   ktime_t last_heartbeat, latest_heartbeat;
+   ktime_t virt_timeout;
unsigned int hw_heartbeat_ms;
  
-	virt_timeout = wd_data->last_keepalive + msecs_to_jiffies(timeout_ms);

+   virt_timeout = ktime_add(wd_data->last_keepalive,
+ms_to_ktime(timeout_ms));
hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
-   keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
+   keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
  
  	if (!watchdog_active(wdd))

return keepalive_interval;
@@ -130,8 +132,11 @@ static long watchdog_next_keepalive(struct watchdog_device 
*wdd)
 * after the most recent ping from userspace, the last
 * worker ping has to come in hw_heartbeat_ms before this timeout.
 */
-   last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
-   return min_t(long, last_heartbeat - jiffies, keepalive_interval);
+   last_heartbeat = ktime_sub(virt_timeout, ms_to_ktime(hw_heartbeat_ms));
+   latest_heartbeat = ktime_sub(last_heartbeat, ktime_get());
+   if (ktime_before(latest_heartbeat, keepalive_interval))
+   return latest_heartbeat;
+   return keepalive_interval;
  }
  
  static inline void watchdog_update_worker(struct watchdog_device *wdd)

@@ -139,30 +144,33 @@ static inline void watchdog_update_worker(struct 
watchdog_device *wdd)
struct watchdog_core_data *wd_data = wdd->wd_data;
  
  	if (watchdog_need_worker(wdd)) {

-   long t = watchdog_next_keepalive(wdd);
+   ktime_t t = watchdog_next_keepalive(wdd);
  
  		if (t > 0)

-   kthread_mod_delayed_work(watchdog_kworker,
-_data->work, t);
+   hrtimer_start(_data->timer, t, HRTIMER_MODE_REL);
} else {
-   kthread_cancel_delayed_work_sync(_data->work);
+   hrtimer_cancel(_data->timer);
}
  }
  
  static int __watchdog_ping(struct watchdog_device *wdd)

  {
struct watchdog_core_data *wd_data = wdd->wd_data;
-   unsigned long earliest_keepalive = wd_data->last_hw_keepalive +
-   msecs_to_jiffies(wdd->min_hw_heartbeat_ms);
+   ktime_t earliest_keepalive, now;
int err;
  
-	if (time_is_after_jiffies(earliest_keepalive)) {

- 

Re: [PATCH] watchdog: core: make sure the watchdog_worker is not deferred

[Guenter Roeck]

On 01/18/2018 03:11 AM, Christophe Leroy wrote:

commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the
effect of deferring timer handling in case of high CPU load, hence
delaying the delayed work allthought the worker is running which
high realtime priority.

As hrtimers are not managed by softirqs, this patch replaces the
delayed work by a plain work and uses an hrtimer to schedule that work.

Signed-off-by: Christophe Leroy 


Reviewed-by: Guenter Roeck 


---
  drivers/watchdog/watchdog_dev.c | 86 +
  1 file changed, 52 insertions(+), 34 deletions(-)

diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 68bc29e6e79e..ffbdc4642ea5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -36,10 +36,10 @@
  #include /* For the -ENODEV/... values */
  #include/* For file operations */
  #include  /* For __init/__exit/... */
-#include/* For timeout functions */
+#include/* For hrtimers */
  #include/* For printk/panic/... */
  #include  /* For data references */
-#include/* For kthread_delayed_work */
+#include/* For kthread_work */
  #include/* For handling misc devices */
  #include/* For module stuff/... */
  #include /* For mutexes */
@@ -67,9 +67,10 @@ struct watchdog_core_data {
struct cdev cdev;
struct watchdog_device *wdd;
struct mutex lock;
-   unsigned long last_keepalive;
-   unsigned long last_hw_keepalive;
-   struct kthread_delayed_work work;
+   ktime_t last_keepalive;
+   ktime_t last_hw_keepalive;
+   struct hrtimer timer;
+   struct kthread_work work;
unsigned long status;   /* Internal status bits */
  #define _WDOG_DEV_OPEN0   /* Opened ? */
  #define _WDOG_ALLOW_RELEASE   1   /* Did we receive the magic char ? */
@@ -109,18 +110,19 @@ static inline bool watchdog_need_worker(struct 
watchdog_device *wdd)
(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
  }
  
-static long watchdog_next_keepalive(struct watchdog_device *wdd)

+static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
  {
struct watchdog_core_data *wd_data = wdd->wd_data;
unsigned int timeout_ms = wdd->timeout * 1000;
-   unsigned long keepalive_interval;
-   unsigned long last_heartbeat;
-   unsigned long virt_timeout;
+   ktime_t keepalive_interval;
+   ktime_t last_heartbeat, latest_heartbeat;
+   ktime_t virt_timeout;
unsigned int hw_heartbeat_ms;
  
-	virt_timeout = wd_data->last_keepalive + msecs_to_jiffies(timeout_ms);

+   virt_timeout = ktime_add(wd_data->last_keepalive,
+ms_to_ktime(timeout_ms));
hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
-   keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
+   keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
  
  	if (!watchdog_active(wdd))

return keepalive_interval;
@@ -130,8 +132,11 @@ static long watchdog_next_keepalive(struct watchdog_device 
*wdd)
 * after the most recent ping from userspace, the last
 * worker ping has to come in hw_heartbeat_ms before this timeout.
 */
-   last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
-   return min_t(long, last_heartbeat - jiffies, keepalive_interval);
+   last_heartbeat = ktime_sub(virt_timeout, ms_to_ktime(hw_heartbeat_ms));
+   latest_heartbeat = ktime_sub(last_heartbeat, ktime_get());
+   if (ktime_before(latest_heartbeat, keepalive_interval))
+   return latest_heartbeat;
+   return keepalive_interval;
  }
  
  static inline void watchdog_update_worker(struct watchdog_device *wdd)

@@ -139,30 +144,33 @@ static inline void watchdog_update_worker(struct 
watchdog_device *wdd)
struct watchdog_core_data *wd_data = wdd->wd_data;
  
  	if (watchdog_need_worker(wdd)) {

-   long t = watchdog_next_keepalive(wdd);
+   ktime_t t = watchdog_next_keepalive(wdd);
  
  		if (t > 0)

-   kthread_mod_delayed_work(watchdog_kworker,
-_data->work, t);
+   hrtimer_start(_data->timer, t, HRTIMER_MODE_REL);
} else {
-   kthread_cancel_delayed_work_sync(_data->work);
+   hrtimer_cancel(_data->timer);
}
  }
  
  static int __watchdog_ping(struct watchdog_device *wdd)

  {
struct watchdog_core_data *wd_data = wdd->wd_data;
-   unsigned long earliest_keepalive = wd_data->last_hw_keepalive +
-   msecs_to_jiffies(wdd->min_hw_heartbeat_ms);
+   ktime_t earliest_keepalive, now;
int err;
  
-	if (time_is_after_jiffies(earliest_keepalive)) {

-