[PATCH 4.4 00/16] Backported fixes taken from Sony's Vendor tree

[PATCH 4.4 00/16] Backported fixes taken from Sony's Vendor tree

[Lee Jones]

A recent review of the Sony Xperia Development kernel tree [0] resulted
in the discovery of various patches which have been backported from
Mainline in order to fix an array of issues.  These patches should be
applied to Stable such that everyone can benefit from them.

Note: The review is still on-going (~50%) - more to follow.

[0] https://github.com/sonyxperiadev/kernel

Alexey Brodkin (1):
  devres: Align data[] to ARCH_KMALLOC_MINALIGN

Austin Kim (1):
  mm/vmalloc.c: move 'area->pages' after if statement

Chris Lew (1):
  soc: qcom: smem: Use le32_to_cpu for comparison

Dedy Lansky (2):
  wil6210: fix temperature debugfs
  wil6210: rate limit wil_rx_refill error

Geert Uytterhoeven (2):
  gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants
  clk: Fix debugfs_create_*() usage

Hamad Kadmany (1):
  wil6210: increase firmware ready timeout

Joe Moriarty (1):
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

Markus Elfring (1):
  crypto: talitos - Delete an error message for a failed memory
    allocation in talitos_edesc_alloc()

Mohit Aggarwal (1):
  rtc: pm8xxx: Fix issue in RTC write path

Rob Clark (1):
  drm/msm: stop abusing dma_map/unmap for cache

Rob Herring (1):
  of: fix missing kobject init for !SYSFS && OF_DYNAMIC config

Subhash Jadavani (1):
  scsi: ufs: ufs-qcom: remove broken hci version quirk

Will Deacon (1):
  arm64: traps: Don't print stack or raw PC/LR values in backtraces

Yangtao Li (1):
  serial/sunsu: add missing of_node_put()

 arch/arm64/kernel/process.c                |  9 ++-
 arch/arm64/kernel/traps.c                  | 72 +---------------------
 drivers/base/devres.c                      | 10 ++-
 drivers/clk/clk.c                          | 30 +++++----
 drivers/crypto/talitos.c                   |  1 -
 drivers/gpio/gpiolib.c                     |  8 +--
 drivers/gpu/drm/drm_dp_mst_topology.c      |  8 ++-
 drivers/gpu/drm/msm/msm_gem.c              |  4 +-
 drivers/net/wireless/ath/wil6210/debugfs.c |  7 ++-
 drivers/net/wireless/ath/wil6210/main.c    |  2 +-
 drivers/net/wireless/ath/wil6210/txrx.c    |  4 +-
 drivers/of/base.c                          |  3 -
 drivers/rtc/rtc-pm8xxx.c                   | 49 +++++++++++----
 drivers/scsi/ufs/ufs-qcom.c                |  2 +-
 drivers/soc/qcom/smem.c                    |  2 +-
 drivers/tty/serial/sunsu.c                 | 20 ++++--
 mm/vmalloc.c                               |  8 ++-
 17 files changed, 107 insertions(+), 132 deletions(-)

-- 
2.25.1

[PATCH 4.4 01/16] drm/msm: stop abusing dma_map/unmap for cache

[Lee Jones]

From: Rob Clark <robdclark@chromium.org>

[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]

Recently splats like this started showing up:

   WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
   Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide
   CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
   Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
   Workqueue: msm msm_gem_free_work [msm]
   pstate: 80c00005 (Nzcv daif +PAN +UAO)
   pc : __iommu_dma_unmap+0xb8/0xc0
   lr : __iommu_dma_unmap+0x54/0xc0
   sp : ffff0000119abce0
   x29: ffff0000119abce0 x28: 0000000000000000
   x27: ffff8001f9946648 x26: ffff8001ec271068
   x25: 0000000000000000 x24: ffff8001ea3580a8
   x23: ffff8001f95ba010 x22: ffff80018e83ba88
   x21: ffff8001e548f000 x20: fffffffffffff000
   x19: 0000000000001000 x18: 00000000c00001fe
   x17: 0000000000000000 x16: 0000000000000000
   x15: ffff000015b70068 x14: 0000000000000005
   x13: 0003142cc1be1768 x12: 0000000000000001
   x11: ffff8001f6de9100 x10: 0000000000000009
   x9 : ffff000015b78000 x8 : 0000000000000000
   x7 : 0000000000000001 x6 : fffffffffffff000
   x5 : 0000000000000fff x4 : ffff00001065dbc8
   x3 : 000000000000000d x2 : 0000000000001000
   x1 : fffffffffffff000 x0 : 0000000000000000
   Call trace:
    __iommu_dma_unmap+0xb8/0xc0
    iommu_dma_unmap_sg+0x98/0xb8
    put_pages+0x5c/0xf0 [msm]
    msm_gem_free_work+0x10c/0x150 [msm]
    process_one_work+0x1e0/0x330
    worker_thread+0x40/0x438
    kthread+0x12c/0x130
    ret_from_fork+0x10/0x18
   ---[ end trace afc0dc5ab81a06bf ]---

Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.

Cc: Stephen Boyd <sboyd@kernel.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/msm/msm_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 644faf3ae93a3..055859095cf01 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -104,7 +104,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
 		 * because display controller, GPU, etc. are not coherent:
 		 */
 		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-			dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+			dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
 					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
 	}
 
@@ -120,7 +120,7 @@ static void put_pages(struct drm_gem_object *obj)
 		 * because display controller, GPU, etc. are not coherent:
 		 */
 		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-			dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+			dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl,
 					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
 
 		if (msm_obj->sgt)
-- 
2.25.1

[PATCH 4.4 02/16] gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants

[Lee Jones]

From: Geert Uytterhoeven <geert+renesas@glider.be>

Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed
the functions to use a "gpiod" prefix, and commit 79a9becda8940deb
("gpiolib: export descriptor-based GPIO interface") introduced the "raw"
variants, but both changes forgot to update the comments.

Readd a similar reference to gpiod_set_value(), which was accidentally
removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source
handling to gpiod_set_value_cansleep()").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpio/gpiolib.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 503405d32d240..3369dcc230e58 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1304,7 +1304,7 @@ int gpiod_get_raw_value(const struct gpio_desc *desc)
 {
 	if (!desc)
 		return 0;
-	/* Should be using gpio_get_value_cansleep() */
+	/* Should be using gpiod_get_raw_value_cansleep() */
 	WARN_ON(desc->chip->can_sleep);
 	return _gpiod_get_raw_value(desc);
 }
@@ -1325,7 +1325,7 @@ int gpiod_get_value(const struct gpio_desc *desc)
 	int value;
 	if (!desc)
 		return 0;
-	/* Should be using gpio_get_value_cansleep() */
+	/* Should be using gpiod_get_value_cansleep() */
 	WARN_ON(desc->chip->can_sleep);
 
 	value = _gpiod_get_raw_value(desc);
@@ -1501,7 +1501,7 @@ void gpiod_set_raw_value(struct gpio_desc *desc, int value)
 {
 	if (!desc)
 		return;
-	/* Should be using gpio_set_value_cansleep() */
+	/* Should be using gpiod_set_raw_value_cansleep() */
 	WARN_ON(desc->chip->can_sleep);
 	_gpiod_set_raw_value(desc, value);
 }
@@ -1522,7 +1522,7 @@ void gpiod_set_value(struct gpio_desc *desc, int value)
 {
 	if (!desc)
 		return;
-	/* Should be using gpio_set_value_cansleep() */
+	/* Should be using gpiod_set_value_cansleep() */
 	WARN_ON(desc->chip->can_sleep);
 	if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
 		value = !value;
-- 
2.25.1

Re: [PATCH 4.4 02/16] gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants

[Greg KH]

On Thu, Apr 23, 2020 at 09:40:00PM +0100, Lee Jones wrote:
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed
> the functions to use a "gpiod" prefix, and commit 79a9becda8940deb
> ("gpiolib: export descriptor-based GPIO interface") introduced the "raw"
> variants, but both changes forgot to update the comments.
> 
> Readd a similar reference to gpiod_set_value(), which was accidentally
> removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source
> handling to gpiod_set_value_cansleep()").
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.be
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/gpio/gpiolib.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

What is the upstream git commit id for this patch?  Please add it and
resend.

thanks,

greg k-h

[PATCH 4.4 02/16 (v2)] gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants

[Lee Jones]

[ Upstream commit 3285170f28a850638794cdfe712eb6d93e51e706 ]

Recently splats like this started showing up:

   WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
   Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide
   CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
   Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
   Workqueue: msm msm_gem_free_work [msm]
   pstate: 80c00005 (Nzcv daif +PAN +UAO)
   pc : __iommu_dma_unmap+0xb8/0xc0
   lr : __iommu_dma_unmap+0x54/0xc0
   sp : ffff0000119abce0
   x29: ffff0000119abce0 x28: 0000000000000000
   x27: ffff8001f9946648 x26: ffff8001ec271068
   x25: 0000000000000000 x24: ffff8001ea3580a8
   x23: ffff8001f95ba010 x22: ffff80018e83ba88
   x21: ffff8001e548f000 x20: fffffffffffff000
   x19: 0000000000001000 x18: 00000000c00001fe
   x17: 0000000000000000 x16: 0000000000000000
   x15: ffff000015b70068 x14: 0000000000000005
   x13: 0003142cc1be1768 x12: 0000000000000001
   x11: ffff8001f6de9100 x10: 0000000000000009
   x9 : ffff000015b78000 x8 : 0000000000000000
   x7 : 0000000000000001 x6 : fffffffffffff000
   x5 : 0000000000000fff x4 : ffff00001065dbc8
   x3 : 000000000000000d x2 : 0000000000001000
   x1 : fffffffffffff000 x0 : 0000000000000000
   Call trace:
    __iommu_dma_unmap+0xb8/0xc0
    iommu_dma_unmap_sg+0x98/0xb8
    put_pages+0x5c/0xf0 [msm]
    msm_gem_free_work+0x10c/0x150 [msm]
    process_one_work+0x1e0/0x330
    worker_thread+0x40/0x438
    kthread+0x12c/0x130
    ret_from_fork+0x10/0x18
   ---[ end trace afc0dc5ab81a06bf ]---

Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.

Cc: Stephen Boyd <sboyd@kernel.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/msm/msm_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 644faf3ae93a3..055859095cf01 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -104,7 +104,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
 		 * because display controller, GPU, etc. are not coherent:
 		 */
 		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-			dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+			dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
 					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
 	}
 
@@ -120,7 +120,7 @@ static void put_pages(struct drm_gem_object *obj)
 		 * because display controller, GPU, etc. are not coherent:
 		 */
 		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-			dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+			dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl,
 					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
 
 		if (msm_obj->sgt)
-- 
2.25.1

[PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Lee Jones]

From: Alexey Brodkin <alexey.brodkin@synopsys.com>

[ Upstream commit a66d972465d15b1d89281258805eb8b47d66bd36 ]

Initially we bumped into problem with 32-bit aligned atomic64_t
on ARC, see [1]. And then during quite lengthly discussion Peter Z.
mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense.
If allocation is done by plain kmalloc() obtained buffer will be
ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via
devm_kmalloc() should have any other alignment?

This way we at least get the same behavior for both types of
allocation.

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004009.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004036.html

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg KH <greg@kroah.com>
Cc: <stable@vger.kernel.org> # 4.8+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/base/devres.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 8fc654f0807bf..9763325a9c944 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -24,8 +24,14 @@ struct devres_node {
 
 struct devres {
 	struct devres_node		node;
-	/* -- 3 pointers */
-	unsigned long long		data[];	/* guarantee ull alignment */
+	/*
+	 * Some archs want to perform DMA into kmalloc caches
+	 * and need a guaranteed alignment larger than
+	 * the alignment of a 64-bit integer.
+	 * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
+	 * buffer alignment as if it was allocated by plain kmalloc().
+	 */
+	u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
 };
 
 struct devres_group {
-- 
2.25.1

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Greg Kroah-Hartman]

On Thu, Apr 23, 2020 at 09:40:01PM +0100, Lee Jones wrote:
> From: Alexey Brodkin <alexey.brodkin@synopsys.com>
> 
> [ Upstream commit a66d972465d15b1d89281258805eb8b47d66bd36 ]
> 
> Initially we bumped into problem with 32-bit aligned atomic64_t
> on ARC, see [1]. And then during quite lengthly discussion Peter Z.
> mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense.
> If allocation is done by plain kmalloc() obtained buffer will be
> ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via
> devm_kmalloc() should have any other alignment?
> 
> This way we at least get the same behavior for both types of
> allocation.
> 
> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004009.html
> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004036.html
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: David Laight <David.Laight@ACULAB.COM>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Greg KH <greg@kroah.com>
> Cc: <stable@vger.kernel.org> # 4.8+
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/base/devres.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index 8fc654f0807bf..9763325a9c944 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -24,8 +24,14 @@ struct devres_node {
>  
>  struct devres {
>  	struct devres_node		node;
> -	/* -- 3 pointers */
> -	unsigned long long		data[];	/* guarantee ull alignment */
> +	/*
> +	 * Some archs want to perform DMA into kmalloc caches
> +	 * and need a guaranteed alignment larger than
> +	 * the alignment of a 64-bit integer.
> +	 * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> +	 * buffer alignment as if it was allocated by plain kmalloc().
> +	 */
> +	u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
>  };
>  
>  struct devres_group {
> -- 
> 2.25.1
> 

I don't want to apply this to older kernels as it could cause extra
memory usage for no good reason.  I have no idea why a non ARC system
would want it :(

greg k-h

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Geert Uytterhoeven]

Hi Greg,

On Wed, May 13, 2020 at 11:35 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 23, 2020 at 09:40:01PM +0100, Lee Jones wrote:
> > From: Alexey Brodkin <alexey.brodkin@synopsys.com>
> >
> > [ Upstream commit a66d972465d15b1d89281258805eb8b47d66bd36 ]
> >
> > Initially we bumped into problem with 32-bit aligned atomic64_t
> > on ARC, see [1]. And then during quite lengthly discussion Peter Z.
> > mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense.
> > If allocation is done by plain kmalloc() obtained buffer will be
> > ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via
> > devm_kmalloc() should have any other alignment?
> >
> > This way we at least get the same behavior for both types of
> > allocation.
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004009.html
> > [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004036.html
> >
> > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: David Laight <David.Laight@ACULAB.COM>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Vineet Gupta <vgupta@synopsys.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Greg KH <greg@kroah.com>
> > Cc: <stable@vger.kernel.org> # 4.8+
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  drivers/base/devres.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> > index 8fc654f0807bf..9763325a9c944 100644
> > --- a/drivers/base/devres.c
> > +++ b/drivers/base/devres.c
> > @@ -24,8 +24,14 @@ struct devres_node {
> >
> >  struct devres {
> >       struct devres_node              node;
> > -     /* -- 3 pointers */
> > -     unsigned long long              data[]; /* guarantee ull alignment */
> > +     /*
> > +      * Some archs want to perform DMA into kmalloc caches
> > +      * and need a guaranteed alignment larger than
> > +      * the alignment of a 64-bit integer.
> > +      * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> > +      * buffer alignment as if it was allocated by plain kmalloc().
> > +      */
> > +     u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> >  };
> >
> >  struct devres_group {
> > --
> > 2.25.1
> >
>
> I don't want to apply this to older kernels as it could cause extra
> memory usage for no good reason.  I have no idea why a non ARC system
> would want it :(

I think the reference to ARC is a red herring.
The real issue is that buffers used for DMA may not have the required
alignment, which is not limited to ARC systems.

Note that I'm also not super happy with the extra memory usage.
But devm_*() conveniences come with their penalties...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[David Laight]

From: Geert Uytterhoeven
> Sent: 13 May 2020 10:49
...
> > I don't want to apply this to older kernels as it could cause extra
> > memory usage for no good reason.  I have no idea why a non ARC system
> > would want it :(
> 
> I think the reference to ARC is a red herring.
> The real issue is that buffers used for DMA may not have the required
> alignment, which is not limited to ARC systems.
> 
> Note that I'm also not super happy with the extra memory usage.
> But devm_*() conveniences come with their penalties...

Interesting thought.
Could the devm 'header' be put right at the end of the kmalloc()
buffer?

Then the driver would be given aligned address.

	David
 

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Geert Uytterhoeven]

Hi David,

On Wed, May 13, 2020 at 12:10 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 13 May 2020 10:49
> ...
> > > I don't want to apply this to older kernels as it could cause extra
> > > memory usage for no good reason.  I have no idea why a non ARC system
> > > would want it :(
> >
> > I think the reference to ARC is a red herring.
> > The real issue is that buffers used for DMA may not have the required
> > alignment, which is not limited to ARC systems.
> >
> > Note that I'm also not super happy with the extra memory usage.
> > But devm_*() conveniences come with their penalties...
>
> Interesting thought.
> Could the devm 'header' be put right at the end of the kmalloc()
> buffer?
>
> Then the driver would be given aligned address.

Yes, if the header is extended to contain the real start address of the
allocated block.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Geert Uytterhoeven]

Hi David,

On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, May 13, 2020 at 12:10 PM David Laight <David.Laight@aculab.com> wrote:
> > From: Geert Uytterhoeven
> > > Sent: 13 May 2020 10:49
> > ...
> > > > I don't want to apply this to older kernels as it could cause extra
> > > > memory usage for no good reason.  I have no idea why a non ARC system
> > > > would want it :(
> > >
> > > I think the reference to ARC is a red herring.
> > > The real issue is that buffers used for DMA may not have the required
> > > alignment, which is not limited to ARC systems.
> > >
> > > Note that I'm also not super happy with the extra memory usage.
> > > But devm_*() conveniences come with their penalties...
> >
> > Interesting thought.
> > Could the devm 'header' be put right at the end of the kmalloc()
> > buffer?
> >
> > Then the driver would be given aligned address.
>
> Yes, if the header is extended to contain the real start address of the
> allocated block.

But that would break explicit freeing through devm_kfree(), as that is
passed a pointer to the payload, not the header.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[David Laight]

From: Geert Uytterhoeven
> Sent: 13 May 2020 12:07
> Hi David,
> 
> On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, May 13, 2020 at 12:10 PM David Laight <David.Laight@aculab.com> wrote:
> > > From: Geert Uytterhoeven
> > > > Sent: 13 May 2020 10:49
> > > ...
> > > > > I don't want to apply this to older kernels as it could cause extra
> > > > > memory usage for no good reason.  I have no idea why a non ARC system
> > > > > would want it :(
> > > >
> > > > I think the reference to ARC is a red herring.
> > > > The real issue is that buffers used for DMA may not have the required
> > > > alignment, which is not limited to ARC systems.
> > > >
> > > > Note that I'm also not super happy with the extra memory usage.
> > > > But devm_*() conveniences come with their penalties...
> > >
> > > Interesting thought.
> > > Could the devm 'header' be put right at the end of the kmalloc()
> > > buffer?
> > >
> > > Then the driver would be given aligned address.
> >
> > Yes, if the header is extended to contain the real start address of the
> > allocated block.
> 
> But that would break explicit freeing through devm_kfree(), as that is
> passed a pointer to the payload, not the header.

There is a function that gives the full size of memory that kmalloc()
returns.
That can be used to find the end and hence the header.

I don't think you can find the base/size from an address within the
buffer - so a length and/or pointer is needed to find the start.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Geert Uytterhoeven]

Hi David,

On Wed, May 13, 2020 at 2:37 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Wed, May 13, 2020 at 12:10 PM David Laight <David.Laight@aculab.com> wrote:
> > > > From: Geert Uytterhoeven
> > > > > Sent: 13 May 2020 10:49
> > > > ...
> > > > > > I don't want to apply this to older kernels as it could cause extra
> > > > > > memory usage for no good reason.  I have no idea why a non ARC system
> > > > > > would want it :(
> > > > >
> > > > > I think the reference to ARC is a red herring.
> > > > > The real issue is that buffers used for DMA may not have the required
> > > > > alignment, which is not limited to ARC systems.
> > > > >
> > > > > Note that I'm also not super happy with the extra memory usage.
> > > > > But devm_*() conveniences come with their penalties...
> > > >
> > > > Interesting thought.
> > > > Could the devm 'header' be put right at the end of the kmalloc()
> > > > buffer?
> > > >
> > > > Then the driver would be given aligned address.
> > >
> > > Yes, if the header is extended to contain the real start address of the
> > > allocated block.
> >
> > But that would break explicit freeing through devm_kfree(), as that is
> > passed a pointer to the payload, not the header.
>
> There is a function that gives the full size of memory that kmalloc()
> returns.
> That can be used to find the end and hence the header.

Do you know the name of the function?

> I don't think you can find the base/size from an address within the
> buffer - so a length and/or pointer is needed to find the start.

If that's really possible, then we can finally fix this in a more
ememory-efficient
way.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[David Laight]

From: Geert Uytterhoeven
> Sent: 13 May 2020 14:26
> Hi David,
> 
> On Wed, May 13, 2020 at 2:37 PM David Laight <David.Laight@aculab.com> wrote:
> > From: Geert Uytterhoeven
> > > On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Wed, May 13, 2020 at 12:10 PM David Laight <David.Laight@aculab.com> wrote:
> > > > > From: Geert Uytterhoeven
> > > > > > Sent: 13 May 2020 10:49
> > > > > ...
> > > > > > > I don't want to apply this to older kernels as it could cause extra
> > > > > > > memory usage for no good reason.  I have no idea why a non ARC system
> > > > > > > would want it :(
> > > > > >
> > > > > > I think the reference to ARC is a red herring.
> > > > > > The real issue is that buffers used for DMA may not have the required
> > > > > > alignment, which is not limited to ARC systems.
> > > > > >
> > > > > > Note that I'm also not super happy with the extra memory usage.
> > > > > > But devm_*() conveniences come with their penalties...
> > > > >
> > > > > Interesting thought.
> > > > > Could the devm 'header' be put right at the end of the kmalloc()
> > > > > buffer?
> > > > >
> > > > > Then the driver would be given aligned address.
> > > >
> > > > Yes, if the header is extended to contain the real start address of the
> > > > allocated block.
> > >
> > > But that would break explicit freeing through devm_kfree(), as that is
> > > passed a pointer to the payload, not the header.
> >
> > There is a function that gives the full size of memory that kmalloc()
> > returns.
> > That can be used to find the end and hence the header.
> 
> Do you know the name of the function?

ksize() - used by the skb allocating code.

I don't know how the all the allocators behave.
Some might be adding a header anyway - which might actually have
space it in that devm_alloc could use.

OTOH I've seen kernel memory allocators that (effectively) put
the index of the pool into the page table.
They need no red tape at all.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[Peter Zijlstra]

On Wed, May 13, 2020 at 10:10:03AM +0000, David Laight wrote:
> From: Geert Uytterhoeven
> > Sent: 13 May 2020 10:49
> ...
> > > I don't want to apply this to older kernels as it could cause extra
> > > memory usage for no good reason.  I have no idea why a non ARC system
> > > would want it :(
> > 
> > I think the reference to ARC is a red herring.
> > The real issue is that buffers used for DMA may not have the required
> > alignment, which is not limited to ARC systems.
> > 
> > Note that I'm also not super happy with the extra memory usage.
> > But devm_*() conveniences come with their penalties...
> 
> Interesting thought.
> Could the devm 'header' be put right at the end of the kmalloc()
> buffer?

https://lkml.kernel.org/r/20191220140655.GN2827@hirez.programming.kicks-ass.net

RE: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN

[David Laight]

From: Peter Zijlstra
> Sent: 13 May 2020 14:36
> 
> On Wed, May 13, 2020 at 10:10:03AM +0000, David Laight wrote:
> > From: Geert Uytterhoeven
> > > Sent: 13 May 2020 10:49
> > ...
> > > > I don't want to apply this to older kernels as it could cause extra
> > > > memory usage for no good reason.  I have no idea why a non ARC system
> > > > would want it :(
> > >
> > > I think the reference to ARC is a red herring.
> > > The real issue is that buffers used for DMA may not have the required
> > > alignment, which is not limited to ARC systems.
> > >
> > > Note that I'm also not super happy with the extra memory usage.
> > > But devm_*() conveniences come with their penalties...
> >
> > Interesting thought.
> > Could the devm 'header' be put right at the end of the kmalloc()
> > buffer?
> 
> https://lkml.kernel.org/r/20191220140655.GN2827@hirez.programming.kicks-ass.net

All the way around the loop.....

ISTR there have also been issues with one of the kmalloc() implementations
adding a header to the memory block.
Didn't it generate 4n+2 aligned buffers on m68k - breaking code that
tried to use the two lower bits of an address.

If one of the kmalloc()s behaves like that it ought to be possible
for devm_alloc() to use the spare space in the same cache line??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

[PATCH 4.4 04/16] crypto: talitos - Delete an error message for a failed memory allocation in talitos_edesc_alloc()

[Lee Jones]

From: Markus Elfring <elfring@users.sourceforge.net>

[ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/crypto/talitos.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 1c8857e7db894..f3d0a33f4ddb4 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
 		if (iv_dma)
 			dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
 
-		dev_err(dev, "could not allocate edescriptor\n");
 		return ERR_PTR(-ENOMEM);
 	}
 
-- 
2.25.1

Re: [PATCH 4.4 04/16] crypto: talitos - Delete an error message for a failed memory allocation in talitos_edesc_alloc()

[Greg KH]

On Thu, Apr 23, 2020 at 09:40:02PM +0100, Lee Jones wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 
> [ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/crypto/talitos.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 1c8857e7db894..f3d0a33f4ddb4 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
>  		if (iv_dma)
>  			dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
>  
> -		dev_err(dev, "could not allocate edescriptor\n");

Not really stable material, also missing from 4.9 and 4.14 trees.

Re: [PATCH 4.4 04/16] crypto: talitos - Delete an error message for a failed memory allocation in talitos_edesc_alloc()

[Lee Jones]

On Wed, 13 May 2020, Greg KH wrote:

> On Thu, Apr 23, 2020 at 09:40:02PM +0100, Lee Jones wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > 
> > [ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]
> > 
> > Omit an extra message for a memory allocation failure in this function.
> > 
> > This issue was detected by using the Coccinelle software.
> > 
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  drivers/crypto/talitos.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> > index 1c8857e7db894..f3d0a33f4ddb4 100644
> > --- a/drivers/crypto/talitos.c
> > +++ b/drivers/crypto/talitos.c
> > @@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
> >  		if (iv_dma)
> >  			dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
> >  
> > -		dev_err(dev, "could not allocate edescriptor\n");
> 
> Not really stable material, also missing from 4.9 and 4.14 trees.

This doesn't apply to 4.9 or 4.14.

Looks like it was already removed in:

 4.9: 	   47fbc54bbe52709fbdc50f5578acf964962942b2
 4.14:	   c3f5e4efce3e2ece7f31826a14849e60d342bde1

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 4.4 05/16] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Lee Jones]

From: Joe Moriarty <joe.moriarty@oracle.com>

[ Upstream commit 22a07038c0eaf4d1315a493ce66dcd255accba19 ]

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.

Signed-off-by: Joe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index f5229b083f8ea..abf5bd09de33b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1036,10 +1036,12 @@ static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
 		lct = drm_dp_calculate_rad(port, rad);
 
 		port->mstb = drm_dp_add_mst_branch_device(lct, rad);
-		port->mstb->mgr = port->mgr;
-		port->mstb->port_parent = port;
+		if (port->mstb) {
+			port->mstb->mgr = port->mgr;
+			port->mstb->port_parent = port;
 
-		send_link = true;
+			send_link = true;
+		}
 		break;
 	}
 	return send_link;
-- 
2.25.1

Re: [PATCH 4.4 05/16] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Greg KH]

On Thu, Apr 23, 2020 at 09:40:03PM +0100, Lee Jones wrote:
> From: Joe Moriarty <joe.moriarty@oracle.com>
> 
> [ Upstream commit 22a07038c0eaf4d1315a493ce66dcd255accba19 ]
> 
> The Parfait (version 2.1.0) static code analysis tool found the
> following NULL pointer derefernce problem.
> 
> - drivers/gpu/drm/drm_dp_mst_topology.c
> The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
> could result in a NULL pointer being returned to port->mstb due to a
> failure to allocate memory for port->mstb.
> 
> Signed-off-by: Joe Moriarty <joe.moriarty@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.com
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Already in the 4.4.220 release.

[PATCH 4.4 06/16] clk: Fix debugfs_create_*() usage

[Lee Jones]

From: Geert Uytterhoeven <geert+renesas@glider.be>

[ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]

When exposing data access through debugfs, the correct
debugfs_create_*() functions must be used, matching the data
types.

Remove all casts from data pointers passed to debugfs_create_*()
functions, as such casts prevent the compiler from flagging bugs.

clk_core.rate and .accuracy are "unsigned long", hence casting
their addresses to "u32 *" exposed the wrong halves on big-endian
64-bit systems. Fix this by using debugfs_create_ulong() instead.

Octal permissions are preferred, as they are easier to read than
symbolic permissions. Hence replace "S_IRUGO" by "0444"
throughout.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[sboyd@codeaurora.org: Squash the octal change in too]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/clk/clk.c | 30 ++++++++++++++----------------
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 53c068f90b376..0654dbf86364f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2121,18 +2121,16 @@ static int clk_debug_create_one(struct clk_core *core, struct dentry *pdentry)
 
 	core->dentry = d;
 
-	d = debugfs_create_u32("clk_rate", S_IRUGO, core->dentry,
-			(u32 *)&core->rate);
+	d = debugfs_create_ulong("clk_rate", 0444, core->dentry, &core->rate);
 	if (!d)
 		goto err_out;
 
-	d = debugfs_create_u32("clk_accuracy", S_IRUGO, core->dentry,
-			(u32 *)&core->accuracy);
+	d = debugfs_create_ulong("clk_accuracy", 0444, core->dentry,
+				 &core->accuracy);
 	if (!d)
 		goto err_out;
 
-	d = debugfs_create_u32("clk_phase", S_IRUGO, core->dentry,
-			(u32 *)&core->phase);
+	d = debugfs_create_u32("clk_phase", 0444, core->dentry, &core->phase);
 	if (!d)
 		goto err_out;
 
@@ -2141,18 +2139,18 @@ static int clk_debug_create_one(struct clk_core *core, struct dentry *pdentry)
 	if (!d)
 		goto err_out;
 
-	d = debugfs_create_u32("clk_prepare_count", S_IRUGO, core->dentry,
-			(u32 *)&core->prepare_count);
+	d = debugfs_create_u32("clk_prepare_count", 0444, core->dentry,
+			       &core->prepare_count);
 	if (!d)
 		goto err_out;
 
-	d = debugfs_create_u32("clk_enable_count", S_IRUGO, core->dentry,
-			(u32 *)&core->enable_count);
+	d = debugfs_create_u32("clk_enable_count", 0444, core->dentry,
+			       &core->enable_count);
 	if (!d)
 		goto err_out;
 
-	d = debugfs_create_u32("clk_notifier_count", S_IRUGO, core->dentry,
-			(u32 *)&core->notifier_count);
+	d = debugfs_create_u32("clk_notifier_count", 0444, core->dentry,
+			       &core->notifier_count);
 	if (!d)
 		goto err_out;
 
@@ -2246,22 +2244,22 @@ static int __init clk_debug_init(void)
 	if (!rootdir)
 		return -ENOMEM;
 
-	d = debugfs_create_file("clk_summary", S_IRUGO, rootdir, &all_lists,
+	d = debugfs_create_file("clk_summary", 0444, rootdir, &all_lists,
 				&clk_summary_fops);
 	if (!d)
 		return -ENOMEM;
 
-	d = debugfs_create_file("clk_dump", S_IRUGO, rootdir, &all_lists,
+	d = debugfs_create_file("clk_dump", 0444, rootdir, &all_lists,
 				&clk_dump_fops);
 	if (!d)
 		return -ENOMEM;
 
-	d = debugfs_create_file("clk_orphan_summary", S_IRUGO, rootdir,
+	d = debugfs_create_file("clk_orphan_summary", 0444, rootdir,
 				&orphan_list, &clk_summary_fops);
 	if (!d)
 		return -ENOMEM;
 
-	d = debugfs_create_file("clk_orphan_dump", S_IRUGO, rootdir,
+	d = debugfs_create_file("clk_orphan_dump", 0444, rootdir,
 				&orphan_list, &clk_dump_fops);
 	if (!d)
 		return -ENOMEM;
-- 
2.25.1

Re: [PATCH 4.4 06/16] clk: Fix debugfs_create_*() usage

[Greg KH]

On Thu, Apr 23, 2020 at 09:40:04PM +0100, Lee Jones wrote:
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> [ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]
> 
> When exposing data access through debugfs, the correct
> debugfs_create_*() functions must be used, matching the data
> types.
> 
> Remove all casts from data pointers passed to debugfs_create_*()
> functions, as such casts prevent the compiler from flagging bugs.
> 
> clk_core.rate and .accuracy are "unsigned long", hence casting
> their addresses to "u32 *" exposed the wrong halves on big-endian
> 64-bit systems. Fix this by using debugfs_create_ulong() instead.
> 
> Octal permissions are preferred, as they are easier to read than
> symbolic permissions. Hence replace "S_IRUGO" by "0444"
> throughout.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> [sboyd@codeaurora.org: Squash the octal change in too]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/clk/clk.c | 30 ++++++++++++++----------------
>  1 file changed, 14 insertions(+), 16 deletions(-)

What about 4.9?

I'm going to stop here and wait for a fixed up series of this, and any
newer kernels that need the patches as well.

thanks,

greg k-h

Re: [PATCH 4.4 06/16] clk: Fix debugfs_create_*() usage

[Lee Jones]

On Wed, 13 May 2020, Greg KH wrote:

> On Thu, Apr 23, 2020 at 09:40:04PM +0100, Lee Jones wrote:
> > From: Geert Uytterhoeven <geert+renesas@glider.be>
> > 
> > [ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]
> > 
> > When exposing data access through debugfs, the correct
> > debugfs_create_*() functions must be used, matching the data
> > types.
> > 
> > Remove all casts from data pointers passed to debugfs_create_*()
> > functions, as such casts prevent the compiler from flagging bugs.
> > 
> > clk_core.rate and .accuracy are "unsigned long", hence casting
> > their addresses to "u32 *" exposed the wrong halves on big-endian
> > 64-bit systems. Fix this by using debugfs_create_ulong() instead.
> > 
> > Octal permissions are preferred, as they are easier to read than
> > symbolic permissions. Hence replace "S_IRUGO" by "0444"
> > throughout.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > [sboyd@codeaurora.org: Squash the octal change in too]
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  drivers/clk/clk.c | 30 ++++++++++++++----------------
> >  1 file changed, 14 insertions(+), 16 deletions(-)
> 
> What about 4.9?

I sent this for v4.9 on the 22nd April.

https://www.spinics.net/lists/stable/msg382001.html

> I'm going to stop here and wait for a fixed up series of this, and any
> newer kernels that need the patches as well.
> 
> thanks,
> 
> greg k-h

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 4.4 07/16] arm64: traps: Don't print stack or raw PC/LR values in backtraces

[Lee Jones]

From: Will Deacon <will.deacon@arm.com>

[ Upstream commit a25ffd3a6302a67814280274d8f1aa4ae2ea4b59 ]

Printing raw pointer values in backtraces has potential security
implications and are of questionable value anyway.

This patch follows x86's lead and removes the "Exception stack:" dump
from kernel backtraces, as well as converting PC/LR values to symbols
such as "sysrq_handle_crash+0x20/0x30".

Tested-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm64/kernel/process.c |  9 +++--
 arch/arm64/kernel/traps.c   | 72 ++-----------------------------------
 2 files changed, 7 insertions(+), 74 deletions(-)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 10d6627673cbf..2733b04900d1c 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -180,11 +180,10 @@ void __show_regs(struct pt_regs *regs)
 	}
 
 	show_regs_print_info(KERN_DEFAULT);
-	print_symbol("PC is at %s\n", instruction_pointer(regs));
-	print_symbol("LR is at %s\n", lr);
-	printk("pc : [<%016llx>] lr : [<%016llx>] pstate: %08llx\n",
-	       regs->pc, lr, regs->pstate);
-	printk("sp : %016llx\n", sp);
+	print_symbol("pc : %s\n", regs->pc);
+	print_symbol("lr : %s\n", lr);
+	printk("sp : %016llx pstate : %08llx\n", sp, regs->pstate);
+
 	for (i = top_reg; i >= 0; i--) {
 		printk("x%-2d: %016llx ", i, regs->regs[i]);
 		if (i % 2 == 0)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 02710f99c1374..0cc78d60dac33 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -51,63 +51,9 @@ static const char *handler[]= {
 
 int show_unhandled_signals = 0;
 
-/*
- * Dump out the contents of some memory nicely...
- */
-static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-		     unsigned long top, bool compat)
-{
-	unsigned long first;
-	mm_segment_t fs;
-	int i;
-	unsigned int width = compat ? 4 : 8;
-
-	/*
-	 * We need to switch to kernel mode so that we can use __get_user
-	 * to safely read from kernel space.
-	 */
-	fs = get_fs();
-	set_fs(KERNEL_DS);
-
-	printk("%s%s(0x%016lx to 0x%016lx)\n", lvl, str, bottom, top);
-
-	for (first = bottom & ~31; first < top; first += 32) {
-		unsigned long p;
-		char str[sizeof(" 12345678") * 8 + 1];
-
-		memset(str, ' ', sizeof(str));
-		str[sizeof(str) - 1] = '\0';
-
-		for (p = first, i = 0; i < (32 / width)
-					&& p < top; i++, p += width) {
-			if (p >= bottom && p < top) {
-				unsigned long val;
-
-				if (width == 8) {
-					if (__get_user(val, (unsigned long *)p) == 0)
-						sprintf(str + i * 17, " %016lx", val);
-					else
-						sprintf(str + i * 17, " ????????????????");
-				} else {
-					if (__get_user(val, (unsigned int *)p) == 0)
-						sprintf(str + i * 9, " %08lx", val);
-					else
-						sprintf(str + i * 9, " ????????");
-				}
-			}
-		}
-		printk("%s%04lx:%s\n", lvl, first & 0xffff, str);
-	}
-
-	set_fs(fs);
-}
-
 static void dump_backtrace_entry(unsigned long where)
 {
-	/*
-	 * Note that 'where' can have a physical address, but it's not handled.
-	 */
-	print_ip_sym(where);
+	printk(" %pS\n", (void *)where);
 }
 
 static void __dump_instr(const char *lvl, struct pt_regs *regs)
@@ -170,20 +116,11 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	}
 
 	pr_emerg("Call trace:\n");
-	while (1) {
+	do {
 		unsigned long where = frame.pc;
-		unsigned long stack;
-		int ret;
 
 		dump_backtrace_entry(where);
-		ret = unwind_frame(&frame);
-		if (ret < 0)
-			break;
-		stack = frame.sp;
-		if (in_exception_text(where))
-			dump_mem("", "Exception stack", stack,
-				 stack + sizeof(struct pt_regs), false);
-	}
+	} while (!unwind_frame(&frame));
 }
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
@@ -220,9 +157,6 @@ static int __die(const char *str, int err, struct thread_info *thread,
 		 TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), thread + 1);
 
 	if (!user_mode(regs) || in_interrupt()) {
-		dump_mem(KERN_EMERG, "Stack: ", regs->sp,
-			 THREAD_SIZE + (unsigned long)task_stack_page(tsk),
-			 compat_user_mode(regs));
 		dump_backtrace(regs, tsk);
 		dump_instr(KERN_EMERG, regs);
 	}
-- 
2.25.1

[PATCH 4.4 08/16] serial/sunsu: add missing of_node_put()

[Lee Jones]

From: Yangtao Li <tiny.windzz@gmail.com>

[ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]

of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
This place is not doing this, so fix it.

Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/tty/serial/sunsu.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index e124d2e88996f..8db64282260fb 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1393,22 +1393,32 @@ static inline struct console *SUNSU_CONSOLE(void)
 static enum su_type su_get_type(struct device_node *dp)
 {
 	struct device_node *ap = of_find_node_by_path("/aliases");
+	enum su_type rc = SU_PORT_PORT;
 
 	if (ap) {
+		struct device_node *tmp;
 		const char *keyb = of_get_property(ap, "keyboard", NULL);
 		const char *ms = of_get_property(ap, "mouse", NULL);
 
 		if (keyb) {
-			if (dp == of_find_node_by_path(keyb))
-				return SU_PORT_KBD;
+			tmp = of_find_node_by_path(keyb);
+			if (tmp && dp == tmp){
+				rc = SU_PORT_KBD;
+				goto out;
+			}
 		}
 		if (ms) {
-			if (dp == of_find_node_by_path(ms))
-				return SU_PORT_MS;
+			tmp = of_find_node_by_path(ms);
+			if (tmp && dp == tmp){
+				rc = SU_PORT_MS;
+				goto out;
+			}
 		}
 	}
 
-	return SU_PORT_PORT;
+out:
+	of_node_put(ap);
+	return rc;
 }
 
 static int su_probe(struct platform_device *op)
-- 
2.25.1

Re: [PATCH 4.4 08/16] serial/sunsu: add missing of_node_put()

[Greg Kroah-Hartman]

On Thu, Apr 23, 2020 at 09:40:06PM +0100, Lee Jones wrote:
> From: Yangtao Li <tiny.windzz@gmail.com>
> 
> [ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]
> 
> of_find_node_by_path() acquires a reference to the node
> returned by it and that reference needs to be dropped by its caller.
> This place is not doing this, so fix it.
> 
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/tty/serial/sunsu.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)

What about 4.9.y, 4.14.y, and 4.19.y for this?

greg k-h

Re: [PATCH 4.4 08/16] serial/sunsu: add missing of_node_put()

[Lee Jones]

On Wed, 06 May 2020, Greg Kroah-Hartman wrote:

> On Thu, Apr 23, 2020 at 09:40:06PM +0100, Lee Jones wrote:
> > From: Yangtao Li <tiny.windzz@gmail.com>
> > 
> > [ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]
> > 
> > of_find_node_by_path() acquires a reference to the node
> > returned by it and that reference needs to be dropped by its caller.
> > This place is not doing this, so fix it.
> > 
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  drivers/tty/serial/sunsu.c | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> What about 4.9.y, 4.14.y, and 4.19.y for this?

Yes, according to my results file, it should have been applied:

  stable/results/vendor-sony-xperia-aosp-LA.UM.7.1.r1-phase-2.txt
    20d8e8611eb0 stable-linux-4.4.y stable-linux-4.9.y \
                 stable-linux-4.14.y stable-linux-4.19.y

I can't think why it was dropped.  Perhaps it didn't apply, although I
usually fight to get them applied if at all possible.

Are you able to apply it?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 4.4 09/16] wil6210: increase firmware ready timeout

[Lee Jones]

From: Hamad Kadmany <hkadmany@codeaurora.org>

[ Upstream commit 6ccae584014ef7074359eb4151086beef66ecfa9 ]

Firmware ready event may take longer than
current timeout in some scenarios, for example
with multiple RFs connected where each
requires an initial calibration.

Increase the timeout to support these scenarios.

Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/net/wireless/ath/wil6210/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/main.c b/drivers/net/wireless/ath/wil6210/main.c
index f09fafaaaf1a3..c377937aae1c4 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -741,7 +741,7 @@ static void wil_bl_crash_info(struct wil6210_priv *wil, bool is_err)
 
 static int wil_wait_for_fw_ready(struct wil6210_priv *wil)
 {
-	ulong to = msecs_to_jiffies(1000);
+	ulong to = msecs_to_jiffies(2000);
 	ulong left = wait_for_completion_timeout(&wil->wmi_ready, to);
 
 	if (0 == left) {
-- 
2.25.1

[PATCH 4.4 10/16] wil6210: fix temperature debugfs

[Lee Jones]

From: Dedy Lansky <dlansky@codeaurora.org>

[ Upstream commit 6d9eb7ebae3d7e951bc0999235ae7028eb4cae4f ]

For negative temperatures, "temp" debugfs is showing wrong values.
Use signed types so proper calculations is done for sub zero
temperatures.

Signed-off-by: Dedy Lansky <dlansky@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
index 97bc186f97282..2da03d69ed42e 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1088,7 +1088,7 @@ static const struct file_operations fops_ssid = {
 };
 
 /*---------temp------------*/
-static void print_temp(struct seq_file *s, const char *prefix, u32 t)
+static void print_temp(struct seq_file *s, const char *prefix, s32 t)
 {
 	switch (t) {
 	case 0:
@@ -1096,7 +1096,8 @@ static void print_temp(struct seq_file *s, const char *prefix, u32 t)
 		seq_printf(s, "%s N/A\n", prefix);
 	break;
 	default:
-		seq_printf(s, "%s %d.%03d\n", prefix, t / 1000, t % 1000);
+		seq_printf(s, "%s %s%d.%03d\n", prefix, (t < 0 ? "-" : ""),
+			   abs(t / 1000), abs(t % 1000));
 		break;
 	}
 }
@@ -1104,7 +1105,7 @@ static void print_temp(struct seq_file *s, const char *prefix, u32 t)
 static int wil_temp_debugfs_show(struct seq_file *s, void *data)
 {
 	struct wil6210_priv *wil = s->private;
-	u32 t_m, t_r;
+	s32 t_m, t_r;
 	int rc = wmi_get_temperature(wil, &t_m, &t_r);
 
 	if (rc) {
-- 
2.25.1

[PATCH 4.4 11/16] scsi: ufs: ufs-qcom: remove broken hci version quirk

[Lee Jones]

From: Subhash Jadavani <subhashj@codeaurora.org>

[ Upstream commit 69a6fff068567469c0ef1156ae5ac8d3d71701f0 ]

UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.

[mkp: applied by hand]

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/scsi/ufs/ufs-qcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 4b82c3765e013..2b779a55f6999 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1032,7 +1032,7 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
 		hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
 	}
 
-	if (host->hw_ver.major >= 0x2) {
+	if (host->hw_ver.major == 0x2) {
 		hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
 
 		if (!ufs_qcom_cap_qunipro(host))
-- 
2.25.1

[PATCH 4.4 12/16] wil6210: rate limit wil_rx_refill error

[Lee Jones]

From: Dedy Lansky <dlansky@codeaurora.org>

[ Upstream commit 3d6b72729cc2933906de8d2c602ae05e920b2122 ]

wil_err inside wil_rx_refill can flood the log buffer.
Replace it with wil_err_ratelimited.

Signed-off-by: Dedy Lansky <dlansky@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/net/wireless/ath/wil6210/txrx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 3bc9bc0efbacc..af436292190b1 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -538,8 +538,8 @@ static int wil_rx_refill(struct wil6210_priv *wil, int count)
 			v->swtail = next_tail) {
 		rc = wil_vring_alloc_skb(wil, v, v->swtail, headroom);
 		if (unlikely(rc)) {
-			wil_err(wil, "Error %d in wil_rx_refill[%d]\n",
-				rc, v->swtail);
+			wil_err_ratelimited(wil, "Error %d in rx refill[%d]\n",
+					    rc, v->swtail);
 			break;
 		}
 	}
-- 
2.25.1

[PATCH 4.4 13/16] rtc: pm8xxx: Fix issue in RTC write path

[Lee Jones]

From: Mohit Aggarwal <maggarwa@codeaurora.org>

[ Upstream commit 83220bf38b77a830f8e62ab1a0d0408304f9b966 ]

In order to set time in rtc, need to disable
rtc hw before writing into rtc registers.

Also fixes disabling of alarm while setting
rtc time.

Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/rtc/rtc-pm8xxx.c | 49 +++++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c
index a0dae6271ff64..cd4434cca877c 100644
--- a/drivers/rtc/rtc-pm8xxx.c
+++ b/drivers/rtc/rtc-pm8xxx.c
@@ -74,16 +74,18 @@ struct pm8xxx_rtc {
 /*
  * Steps to write the RTC registers.
  * 1. Disable alarm if enabled.
- * 2. Write 0x00 to LSB.
- * 3. Write Byte[1], Byte[2], Byte[3] then Byte[0].
- * 4. Enable alarm if disabled in step 1.
+ * 2. Disable rtc if enabled.
+ * 3. Write 0x00 to LSB.
+ * 4. Write Byte[1], Byte[2], Byte[3] then Byte[0].
+ * 5. Enable rtc if disabled in step 2.
+ * 6. Enable alarm if disabled in step 1.
  */
 static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
 	int rc, i;
 	unsigned long secs, irq_flags;
-	u8 value[NUM_8_BIT_RTC_REGS], alarm_enabled = 0;
-	unsigned int ctrl_reg;
+	u8 value[NUM_8_BIT_RTC_REGS], alarm_enabled = 0, rtc_disabled = 0;
+	unsigned int ctrl_reg, rtc_ctrl_reg;
 	struct pm8xxx_rtc *rtc_dd = dev_get_drvdata(dev);
 	const struct pm8xxx_rtc_regs *regs = rtc_dd->regs;
 
@@ -92,23 +94,38 @@ static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm)
 
 	rtc_tm_to_time(tm, &secs);
 
+	dev_dbg(dev, "Seconds value to be written to RTC = %lu\n", secs);
+
 	for (i = 0; i < NUM_8_BIT_RTC_REGS; i++) {
 		value[i] = secs & 0xFF;
 		secs >>= 8;
 	}
 
-	dev_dbg(dev, "Seconds value to be written to RTC = %lu\n", secs);
-
 	spin_lock_irqsave(&rtc_dd->ctrl_reg_lock, irq_flags);
 
-	rc = regmap_read(rtc_dd->regmap, regs->ctrl, &ctrl_reg);
+	rc = regmap_read(rtc_dd->regmap, regs->alarm_ctrl, &ctrl_reg);
 	if (rc)
 		goto rtc_rw_fail;
 
 	if (ctrl_reg & regs->alarm_en) {
 		alarm_enabled = 1;
 		ctrl_reg &= ~regs->alarm_en;
-		rc = regmap_write(rtc_dd->regmap, regs->ctrl, ctrl_reg);
+		rc = regmap_write(rtc_dd->regmap, regs->alarm_ctrl, ctrl_reg);
+		if (rc) {
+			dev_err(dev, "Write to RTC Alarm control register failed\n");
+			goto rtc_rw_fail;
+		}
+	}
+
+	/* Disable RTC H/w before writing on RTC register */
+	rc = regmap_read(rtc_dd->regmap, regs->ctrl, &rtc_ctrl_reg);
+	if (rc)
+		goto rtc_rw_fail;
+
+	if (rtc_ctrl_reg & PM8xxx_RTC_ENABLE) {
+		rtc_disabled = 1;
+		rtc_ctrl_reg &= ~PM8xxx_RTC_ENABLE;
+		rc = regmap_write(rtc_dd->regmap, regs->ctrl, rtc_ctrl_reg);
 		if (rc) {
 			dev_err(dev, "Write to RTC control register failed\n");
 			goto rtc_rw_fail;
@@ -137,11 +154,21 @@ static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm)
 		goto rtc_rw_fail;
 	}
 
+	/* Enable RTC H/w after writing on RTC register */
+	if (rtc_disabled) {
+		rtc_ctrl_reg |= PM8xxx_RTC_ENABLE;
+		rc = regmap_write(rtc_dd->regmap, regs->ctrl, rtc_ctrl_reg);
+		if (rc) {
+			dev_err(dev, "Write to RTC control register failed\n");
+			goto rtc_rw_fail;
+		}
+	}
+
 	if (alarm_enabled) {
 		ctrl_reg |= regs->alarm_en;
-		rc = regmap_write(rtc_dd->regmap, regs->ctrl, ctrl_reg);
+		rc = regmap_write(rtc_dd->regmap, regs->alarm_ctrl, ctrl_reg);
 		if (rc) {
-			dev_err(dev, "Write to RTC control register failed\n");
+			dev_err(dev, "Write to RTC Alarm control register failed\n");
 			goto rtc_rw_fail;
 		}
 	}
-- 
2.25.1

[PATCH 4.4 14/16] soc: qcom: smem: Use le32_to_cpu for comparison

[Lee Jones]

From: Chris Lew <clew@codeaurora.org>

[ Upstream commit a216000f0140f415cec96129f777b5234c9d142f ]

Endianness can vary in the system, add le32_to_cpu when comparing
partition sizes from smem.

Signed-off-by: Chris Lew <clew@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/soc/qcom/smem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 19019aa092e86..a1572075b8acc 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -646,7 +646,7 @@ static int qcom_smem_enumerate_partitions(struct qcom_smem *smem,
 			return -EINVAL;
 		}
 
-		if (header->size != entry->size) {
+		if (le32_to_cpu(header->size) != le32_to_cpu(entry->size)) {
 			dev_err(smem->dev,
 				"Partition %d has invalid size\n", i);
 			return -EINVAL;
-- 
2.25.1

[PATCH 4.4 15/16] of: fix missing kobject init for !SYSFS && OF_DYNAMIC config

[Lee Jones]

From: Rob Herring <robh@kernel.org>

[ Upstream commit bd82bbf38cbe27f2c65660da801900d71bcc5cc8 ]

The ref counting is broken for OF_DYNAMIC when sysfs is disabled because
the kobject initialization is skipped. Only the properties
add/remove/update should be skipped for !SYSFS config.

Tested-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Frank Rowand <frowand.list@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/of/base.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 27783223ca5cd..8adffecd710b8 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -167,9 +167,6 @@ int __of_attach_node_sysfs(struct device_node *np)
 	struct property *pp;
 	int rc;
 
-	if (!IS_ENABLED(CONFIG_SYSFS))
-		return 0;
-
 	if (!of_kset)
 		return 0;
 
-- 
2.25.1

[PATCH 4.4 16/16] mm/vmalloc.c: move 'area->pages' after if statement

[Lee Jones]

From: Austin Kim <austindh.kim@gmail.com>

[ Upstream commit 7ea362427c170061b8822dd41bafaa72b3bcb9ad ]

If !area->pages statement is true where memory allocation fails, area is
freed.

In this case 'area->pages = pages' should not executed.  So move
'area->pages = pages' after if statement.

[akpm@linux-foundation.org: give area->pages the same treatment]
Link: http://lkml.kernel.org/r/20190830035716.GA190684@LGEARND20B15
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: Roman Penyaev <rpenyaev@suse.de>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 mm/vmalloc.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c9e6fc6a5fefe..49f15a460a7b3 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1593,7 +1593,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 	nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
 	array_size = (nr_pages * sizeof(struct page *));
 
-	area->nr_pages = nr_pages;
 	/* Please note that the recursion is strictly bounded. */
 	if (array_size > PAGE_SIZE) {
 		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
@@ -1602,13 +1601,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 	} else {
 		pages = kmalloc_node(array_size, nested_gfp, node);
 	}
-	area->pages = pages;
-	if (!area->pages) {
+
+	if (!pages) {
 		remove_vm_area(area->addr);
 		kfree(area);
 		return NULL;
 	}
 
+	area->pages = pages;
+	area->nr_pages = nr_pages;
+
 	for (i = 0; i < area->nr_pages; i++) {
 		struct page *page;
 
-- 
2.25.1