November 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] pmdomain: imx: Make imx pgc power domain also set the fwnode" failed to apply to 6.5-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.5-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.5.y git checkout FETCH_HEAD git cherry-pick -x 374de39d38f97b0e58cfee88da590b2d056ccf7f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112257-armless-stump-64b8@gregkh' --subject-prefix 'PATCH 6.5.y' HEAD^.. Possible dependencies: 374de39d38f9 ("pmdomain: imx: Make imx pgc power domain also set the fwnode") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 374de39d38f97b0e58cfee88da590b2d056ccf7f Mon Sep 17 00:00:00 2001 From: Pengfei Li <pengfei.li_1(a)nxp.com> Date: Sat, 21 Oct 2023 02:59:49 +0800 Subject: [PATCH] pmdomain: imx: Make imx pgc power domain also set the fwnode Currently, The imx pgc power domain doesn't set the fwnode pointer, which results in supply regulator device can't get consumer imx pgc power domain device from fwnode when creating a link. This causes the driver core to instead try to create a link between the parent gpc device of imx pgc power domain device and supply regulator device. However, at this point, the gpc device has already been bound, and the link creation will fail. So adding the fwnode pointer to the imx pgc power domain device will fix this issue. Signed-off-by: Pengfei Li <pengfei.li_1(a)nxp.com> Tested-by: Emil Kronborg <emil.kronborg(a)protonmail.com> Fixes: 3fb16866b51d ("driver core: fw_devlink: Make cycle detection more robust") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20231020185949.537083-1-pengfei.li_1@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c index 90a8b2c0676f..419ed15cc10c 100644 --- a/drivers/pmdomain/imx/gpc.c +++ b/drivers/pmdomain/imx/gpc.c @@ -498,6 +498,7 @@ static int imx_gpc_probe(struct platform_device *pdev) pd_pdev->dev.parent = &pdev->dev; pd_pdev->dev.of_node = np; + pd_pdev->dev.fwnode = of_fwnode_handle(np); ret = platform_device_add(pd_pdev); if (ret) {

2 years

1
0
0 0

FAILED: patch "[PATCH] regmap: Ensure range selector registers are updated after" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 0ec7731655de196bc1e4af99e495b38778109d22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112217-steersman-frosted-7a48@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ec7731655de196bc1e4af99e495b38778109d22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Thu, 26 Oct 2023 16:49:19 +0100 Subject: [PATCH] regmap: Ensure range selector registers are updated after cache sync When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin <marcan(a)marcan.st> Cc: stable(a)vger.kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded8277… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index c5d151e9c481..92592f944a3d 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -334,6 +334,11 @@ static int regcache_default_sync(struct regmap *map, unsigned int min, return 0; } +static int rbtree_all(const void *key, const struct rb_node *node) +{ + return 0; +} + /** * regcache_sync - Sync the register cache with the hardware. * @@ -351,6 +356,7 @@ int regcache_sync(struct regmap *map) unsigned int i; const char *name; bool bypass; + struct rb_node *node; if (WARN_ON(map->cache_type == REGCACHE_NONE)) return -EINVAL; @@ -392,6 +398,30 @@ int regcache_sync(struct regmap *map) /* Restore the bypass state */ map->cache_bypass = bypass; map->no_sync_defaults = false; + + /* + * If we did any paging with cache bypassed and a cached + * paging register then the register and cache state might + * have gone out of sync, force writes of all the paging + * registers. + */ + rb_for_each(node, 0, &map->range_tree, rbtree_all) { + struct regmap_range_node *this = + rb_entry(node, struct regmap_range_node, node); + + /* If there's nothing in the cache there's nothing to sync */ + ret = regcache_read(map, this->selector_reg, &i); + if (ret != 0) + continue; + + ret = _regmap_write(map, this->selector_reg, i); + if (ret != 0) { + dev_err(map->dev, "Failed to write %x = %x: %d\n", + this->selector_reg, i, ret); + break; + } + } + map->unlock(map->lock_arg); regmap_async_complete(map);

2 years

1
0
0 0

FAILED: patch "[PATCH] regmap: Ensure range selector registers are updated after" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 0ec7731655de196bc1e4af99e495b38778109d22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112257-fracture-enlisted-b500@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ec7731655de196bc1e4af99e495b38778109d22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Thu, 26 Oct 2023 16:49:19 +0100 Subject: [PATCH] regmap: Ensure range selector registers are updated after cache sync When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin <marcan(a)marcan.st> Cc: stable(a)vger.kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded8277… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index c5d151e9c481..92592f944a3d 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -334,6 +334,11 @@ static int regcache_default_sync(struct regmap *map, unsigned int min, return 0; } +static int rbtree_all(const void *key, const struct rb_node *node) +{ + return 0; +} + /** * regcache_sync - Sync the register cache with the hardware. * @@ -351,6 +356,7 @@ int regcache_sync(struct regmap *map) unsigned int i; const char *name; bool bypass; + struct rb_node *node; if (WARN_ON(map->cache_type == REGCACHE_NONE)) return -EINVAL; @@ -392,6 +398,30 @@ int regcache_sync(struct regmap *map) /* Restore the bypass state */ map->cache_bypass = bypass; map->no_sync_defaults = false; + + /* + * If we did any paging with cache bypassed and a cached + * paging register then the register and cache state might + * have gone out of sync, force writes of all the paging + * registers. + */ + rb_for_each(node, 0, &map->range_tree, rbtree_all) { + struct regmap_range_node *this = + rb_entry(node, struct regmap_range_node, node); + + /* If there's nothing in the cache there's nothing to sync */ + ret = regcache_read(map, this->selector_reg, &i); + if (ret != 0) + continue; + + ret = _regmap_write(map, this->selector_reg, i); + if (ret != 0) { + dev_err(map->dev, "Failed to write %x = %x: %d\n", + this->selector_reg, i, ret); + break; + } + } + map->unlock(map->lock_arg); regmap_async_complete(map);

2 years

1
0
0 0

FAILED: patch "[PATCH] regmap: Ensure range selector registers are updated after" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 0ec7731655de196bc1e4af99e495b38778109d22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112236-grumble-repose-10b5@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ec7731655de196bc1e4af99e495b38778109d22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Thu, 26 Oct 2023 16:49:19 +0100 Subject: [PATCH] regmap: Ensure range selector registers are updated after cache sync When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin <marcan(a)marcan.st> Cc: stable(a)vger.kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded8277… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index c5d151e9c481..92592f944a3d 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -334,6 +334,11 @@ static int regcache_default_sync(struct regmap *map, unsigned int min, return 0; } +static int rbtree_all(const void *key, const struct rb_node *node) +{ + return 0; +} + /** * regcache_sync - Sync the register cache with the hardware. * @@ -351,6 +356,7 @@ int regcache_sync(struct regmap *map) unsigned int i; const char *name; bool bypass; + struct rb_node *node; if (WARN_ON(map->cache_type == REGCACHE_NONE)) return -EINVAL; @@ -392,6 +398,30 @@ int regcache_sync(struct regmap *map) /* Restore the bypass state */ map->cache_bypass = bypass; map->no_sync_defaults = false; + + /* + * If we did any paging with cache bypassed and a cached + * paging register then the register and cache state might + * have gone out of sync, force writes of all the paging + * registers. + */ + rb_for_each(node, 0, &map->range_tree, rbtree_all) { + struct regmap_range_node *this = + rb_entry(node, struct regmap_range_node, node); + + /* If there's nothing in the cache there's nothing to sync */ + ret = regcache_read(map, this->selector_reg, &i); + if (ret != 0) + continue; + + ret = _regmap_write(map, this->selector_reg, i); + if (ret != 0) { + dev_err(map->dev, "Failed to write %x = %x: %d\n", + this->selector_reg, i, ret); + break; + } + } + map->unlock(map->lock_arg); regmap_async_complete(map);

2 years

1
0
0 0

FAILED: patch "[PATCH] regmap: Ensure range selector registers are updated after" failed to apply to 4.109-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.109-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.109.y git checkout FETCH_HEAD git cherry-pick -x 0ec7731655de196bc1e4af99e495b38778109d22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112233-huddle-harmony-d181@gregkh' --subject-prefix 'PATCH 4.109.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ec7731655de196bc1e4af99e495b38778109d22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Thu, 26 Oct 2023 16:49:19 +0100 Subject: [PATCH] regmap: Ensure range selector registers are updated after cache sync When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin <marcan(a)marcan.st> Cc: stable(a)vger.kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded8277… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index c5d151e9c481..92592f944a3d 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -334,6 +334,11 @@ static int regcache_default_sync(struct regmap *map, unsigned int min, return 0; } +static int rbtree_all(const void *key, const struct rb_node *node) +{ + return 0; +} + /** * regcache_sync - Sync the register cache with the hardware. * @@ -351,6 +356,7 @@ int regcache_sync(struct regmap *map) unsigned int i; const char *name; bool bypass; + struct rb_node *node; if (WARN_ON(map->cache_type == REGCACHE_NONE)) return -EINVAL; @@ -392,6 +398,30 @@ int regcache_sync(struct regmap *map) /* Restore the bypass state */ map->cache_bypass = bypass; map->no_sync_defaults = false; + + /* + * If we did any paging with cache bypassed and a cached + * paging register then the register and cache state might + * have gone out of sync, force writes of all the paging + * registers. + */ + rb_for_each(node, 0, &map->range_tree, rbtree_all) { + struct regmap_range_node *this = + rb_entry(node, struct regmap_range_node, node); + + /* If there's nothing in the cache there's nothing to sync */ + ret = regcache_read(map, this->selector_reg, &i); + if (ret != 0) + continue; + + ret = _regmap_write(map, this->selector_reg, i); + if (ret != 0) { + dev_err(map->dev, "Failed to write %x = %x: %d\n", + this->selector_reg, i, ret); + break; + } + } + map->unlock(map->lock_arg); regmap_async_complete(map);

2 years

1
0
0 0

FAILED: patch "[PATCH] regmap: Ensure range selector registers are updated after" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 0ec7731655de196bc1e4af99e495b38778109d22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112209-procreate-flop-2437@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ec7731655de196bc1e4af99e495b38778109d22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Thu, 26 Oct 2023 16:49:19 +0100 Subject: [PATCH] regmap: Ensure range selector registers are updated after cache sync When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin <marcan(a)marcan.st> Cc: stable(a)vger.kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded8277… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index c5d151e9c481..92592f944a3d 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -334,6 +334,11 @@ static int regcache_default_sync(struct regmap *map, unsigned int min, return 0; } +static int rbtree_all(const void *key, const struct rb_node *node) +{ + return 0; +} + /** * regcache_sync - Sync the register cache with the hardware. * @@ -351,6 +356,7 @@ int regcache_sync(struct regmap *map) unsigned int i; const char *name; bool bypass; + struct rb_node *node; if (WARN_ON(map->cache_type == REGCACHE_NONE)) return -EINVAL; @@ -392,6 +398,30 @@ int regcache_sync(struct regmap *map) /* Restore the bypass state */ map->cache_bypass = bypass; map->no_sync_defaults = false; + + /* + * If we did any paging with cache bypassed and a cached + * paging register then the register and cache state might + * have gone out of sync, force writes of all the paging + * registers. + */ + rb_for_each(node, 0, &map->range_tree, rbtree_all) { + struct regmap_range_node *this = + rb_entry(node, struct regmap_range_node, node); + + /* If there's nothing in the cache there's nothing to sync */ + ret = regcache_read(map, this->selector_reg, &i); + if (ret != 0) + continue; + + ret = _regmap_write(map, this->selector_reg, i); + if (ret != 0) { + dev_err(map->dev, "Failed to write %x = %x: %d\n", + this->selector_reg, i, ret); + break; + } + } + map->unlock(map->lock_arg); regmap_async_complete(map);

2 years

1
0
0 0

FAILED: patch "[PATCH] pmdomain: amlogic: Fix mask for the second NNA mem PD domain" failed to apply to 6.5-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.5-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.5.y git checkout FETCH_HEAD git cherry-pick -x b131329b9bfbd1b4c0c5e088cb0c6ec03a12930f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112207-docile-knoll-50f6@gregkh' --subject-prefix 'PATCH 6.5.y' HEAD^.. Possible dependencies: b131329b9bfb ("pmdomain: amlogic: Fix mask for the second NNA mem PD domain") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b131329b9bfbd1b4c0c5e088cb0c6ec03a12930f Mon Sep 17 00:00:00 2001 From: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> Date: Mon, 16 Oct 2023 10:02:04 +0200 Subject: [PATCH] pmdomain: amlogic: Fix mask for the second NNA mem PD domain Without this change, the NPU hangs when the 8th NN core is used. It matches what the out-of-tree driver does. Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> Fixes: 9a217b7e8953 ("soc: amlogic: meson-pwrc: Add NNA power domain for A311D") Acked-by: Neil Armstrong <neil.armstrong(a)linaro.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20231016080205.41982-2-tomeu@tomeuvizoso.net Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/pmdomain/amlogic/meson-ee-pwrc.c b/drivers/pmdomain/amlogic/meson-ee-pwrc.c index cfb796d40d9d..0dd71cd814c5 100644 --- a/drivers/pmdomain/amlogic/meson-ee-pwrc.c +++ b/drivers/pmdomain/amlogic/meson-ee-pwrc.c @@ -228,7 +228,7 @@ static struct meson_ee_pwrc_mem_domain sm1_pwrc_mem_audio[] = { static struct meson_ee_pwrc_mem_domain g12a_pwrc_mem_nna[] = { { G12A_HHI_NANOQ_MEM_PD_REG0, GENMASK(31, 0) }, - { G12A_HHI_NANOQ_MEM_PD_REG1, GENMASK(23, 0) }, + { G12A_HHI_NANOQ_MEM_PD_REG1, GENMASK(31, 0) }, }; #define VPU_PD(__name, __top_pd, __mem, __is_pwr_off, __resets, __clks) \

2 years

1
0
0 0

FAILED: patch "[PATCH] PCI: keystone: Don't discard .probe() callback" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 7994db905c0fd692cf04c527585f08a91b560144 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112204-jeeringly-remake-6ff6@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 7994db905c0f ("PCI: keystone: Don't discard .probe() callback") 18b0415bc802 ("PCI: keystone: Add support for PCIe RC in AM654x Platforms") 156c6fef75a4 ("PCI: keystone: Explicitly set the PCIe mode") b1dee41b7692 ("PCI: keystone: Move resources initialization to prepare for EP support") 2341ab4fd5d7 ("PCI: keystone: Use platform_get_resource_byname() to get memory resources") f3560a9f88ae ("PCI: keystone: Perform host initialization in a single function") 0790eb175ee0 ("PCI: keystone: Cleanup error_irq configuration") 1146c2953dcb ("PCI: keystone: Add separate functions for configuring MSI and legacy interrupt") 1beb55126937 ("PCI: keystone: Cleanup interrupt related macros") 261de72f0169 ("PCI: keystone: Cleanup macros defined in pci-keystone.c") c0b8558648c2 ("PCI: keystone: Reorder header file in alphabetical order") daaaa665ca01 ("PCI: keystone: Add debug error message for all errors") 0523cdc6e775 ("PCI: keystone: Use ERR_IRQ_STATUS instead of ERR_IRQ_STATUS_RAW to get interrupt status") 23fe5bd4be90 ("PCI: keystone: Cleanup ks_pcie_link_up()") f9127db9fbad ("PCI: keystone: Cleanup set_dbi_mode() and get_dbi_mode()") e75043ad9792 ("PCI: keystone: Cleanup outbound window configuration") b4f1af8352fd ("PCI: keystone: Get number of outbound windows from DT") 44c747af2be7 ("PCI: keystone: Cleanup configuration space access") 8047eb55129a ("PCI: keystone: Invoke runtime PM APIs to enable clock") 49229238ab47 ("PCI: keystone: Cleanup PHY handling") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7994db905c0fd692cf04c527585f08a91b560144 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Sun, 1 Oct 2023 19:02:54 +0200 Subject: [PATCH] PCI: keystone: Don't discard .probe() callback MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The __init annotation makes the ks_pcie_probe() function disappear after booting completes. However a device can also be bound later. In that case, we try to call ks_pcie_probe(), but the backing memory is likely already overwritten. The right thing to do is do always have the probe callback available. Note that the (wrong) __refdata annotation prevented this issue to be noticed by modpost. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Link: https://lore.kernel.org/r/20231001170254.2506508-5-u.kleine-koenig@pengutro… Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index eb3fa17b243f..0def919f89fa 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -1100,7 +1100,7 @@ static const struct of_device_id ks_pcie_of_match[] = { { }, }; -static int __init ks_pcie_probe(struct platform_device *pdev) +static int ks_pcie_probe(struct platform_device *pdev) { const struct dw_pcie_host_ops *host_ops; const struct dw_pcie_ep_ops *ep_ops; @@ -1318,7 +1318,7 @@ static int ks_pcie_remove(struct platform_device *pdev) return 0; } -static struct platform_driver ks_pcie_driver __refdata = { +static struct platform_driver ks_pcie_driver = { .probe = ks_pcie_probe, .remove = ks_pcie_remove, .driver = {

2 years

1
0
0 0

FAILED: patch "[PATCH] PCI: keystone: Don't discard .remove() callback" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 200bddbb3f5202bbce96444fdc416305de14f547 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023112236-scone-stinking-706f@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 200bddbb3f52 ("PCI: keystone: Don't discard .remove() callback") 49229238ab47 ("PCI: keystone: Cleanup PHY handling") b51a625b784a ("PCI: keystone: Use SYSCON APIs to get device ID from control module") b492aca35c98 ("PCI: keystone: Merge pci-keystone-dw.c and pci-keystone.c") 1f79f98f0575 ("PCI: keystone: Remove unused argument from ks_dw_pcie_host_init()") 00a2c4094f8e ("PCI: keystone: Use quirk to set MRRS for PCI host bridge") 6e0832fa432e ("PCI: Collect all native drivers under drivers/pci/controller/") e52d38f4abf4 ("Merge branch 'lorenzo/pci/rockchip'") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 200bddbb3f5202bbce96444fdc416305de14f547 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Sun, 1 Oct 2023 19:02:53 +0200 Subject: [PATCH] PCI: keystone: Don't discard .remove() callback MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit With CONFIG_PCIE_KEYSTONE=y and ks_pcie_remove() marked with __exit, the function is discarded from the driver. In this case a bound device can still get unbound, e.g via sysfs. Then no cleanup code is run resulting in resource leaks or worse. The right thing to do is do always have the remove callback available. Note that this driver cannot be compiled as a module, so ks_pcie_remove() was always discarded before this change and modpost couldn't warn about this issue. Furthermore the __ref annotation also prevents a warning. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Link: https://lore.kernel.org/r/20231001170254.2506508-4-u.kleine-koenig@pengutro… Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index 49aea6ce3e87..eb3fa17b243f 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -1302,7 +1302,7 @@ static int __init ks_pcie_probe(struct platform_device *pdev) return ret; } -static int __exit ks_pcie_remove(struct platform_device *pdev) +static int ks_pcie_remove(struct platform_device *pdev) { struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev); struct device_link **link = ks_pcie->link; @@ -1320,7 +1320,7 @@ static int __exit ks_pcie_remove(struct platform_device *pdev) static struct platform_driver ks_pcie_driver __refdata = { .probe = ks_pcie_probe, - .remove = __exit_p(ks_pcie_remove), + .remove = ks_pcie_remove, .driver = { .name = "keystone-pcie", .of_match_table = ks_pcie_of_match,

2 years

1
0
0 0

[PATCH 3/7] mips: Fix max_mapnr being uninitialized on early stages

by Serge Semin

max_mapnr variable is utilized in the pfn_valid() method in order to determine the upper PFN space boundary. Having it uninitialized effectively makes any PFN passed to that method invalid. That in its turn causes the kernel mm-subsystem occasion malfunctions even after the max_mapnr variable is actually properly updated. For instance, pfn_valid() is called in the init_unavailable_range() method in the framework of the calls-chain on MIPS: setup_arch() +-> paging_init() +-> free_area_init() +-> memmap_init() +-> memmap_init_zone_range() +-> init_unavailable_range() Since pfn_valid() always returns "false" value before max_mapnr is initialized in the mem_init() method, any flatmem page-holes will be left in the poisoned/uninitialized state including the IO-memory pages. Thus any further attempts to map/remap the IO-memory by using MMU may fail. In particular it happened in my case on attempt to map the SRAM region. The kernel bootup procedure just crashed on the unhandled unaligned access bug raised in the __update_cache() method: > Unhandled kernel unaligned access[#1]: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc1-00307-g0dff108838c9-dirty #2056 > ... > Call Trace: > [<8011ef9c>] __update_cache+0x88/0x1bc > [<80385944>] ioremap_page_range+0x110/0x2a4 > [<80126948>] ioremap_prot+0x17c/0x1f4 > [<80711b80>] __devm_ioremap+0x8c/0x120 > [<80711e0c>] __devm_ioremap_resource+0xf4/0x218 > [<808bf244>] sram_probe+0x4f4/0x930 > [<80889d20>] platform_probe+0x68/0xec > ... Let's fix the problem by initializing the max_mapnr variable as soon as the required data is available. In particular it can be done right in the paging_init() method before free_area_init() is called since all the PFN zone boundaries have already been calculated by that time. Cc: stable(a)vger.kernel.org Signed-off-by: Serge Semin <fancer.lancer(a)gmail.com> --- Note I don't really know since what point that problem actually exists. Based on the commits log it might had been persistent even before the boot_mem_map allocator was dropped. On the other hand I hadn't seen it actually come out before moving my working tree from kernel 6.5-rc4 to 6.7-rc1. So after updating the kernel I got the unhandled unaligned access BUG() due to the access to compound head pointer the __update_cache() method (see the commit log). After enabling the DEBUG_VM config I managed to find out that the IO-memory pages were just left uninitialized and poisoned: > page:81367080 is uninitialized and poisoned (pfn 8192) > page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) > Kernel bug detected[#1]: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc1-00298-g88721b1a9ad5-dirty > $ 0 : 00000000 812d0000 00000034 dced7cdf > $ 4 : dced7cdf 00594000 10000000 ffff00fe > $ 8 : 8196bfe0 00000000 00000001 818458c0 > $12 : 00000000 00000000 00000000 00000216 > $16 : 00002800 81227b80 00000000 00000000 > $20 : 00000000 00000000 00000000 00000000 > $24 : 0000022b 818458c0 > $28 : 81968000 8196be68 00000000 803a0920 > Hi : 00000000 > Lo : 00000000 > epc : 8039d2a4 BUG+0x0/0x4 > ra : 803a0920 post_alloc_hook+0x0/0x128 > Status: 10000003 KERNEL EXL IE > Cause : 00800424 (ExcCode 09) > PrId : 0001a830 (MIPS P5600) > Modules linked in: > Process swapper/0 (pid: 1, threadinfo=81968000, task=819a0000, tls=00000000) > Stack : 00000000 8101ccb0 00000000 8196bd00 00000000 80359768 818a8300 00000001 > 81139088 8114438c 8042e4f8 81297a2c 81297a2c 81255e90 819a1b50 dced7cdf > 81297a2c 81297a2c 00000000 81227b80 00000000 81241168 811394b0 00000000 > 81140000 80e2cee0 00000000 00000000 00000000 00000000 00000000 819b0000 > 81140000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ... > Call Trace: > [<8039d2a4>] BUG+0x0/0x4 > [<803a0920>] post_alloc_hook+0x0/0x128 > > Code: 01001025 03e00008 24020001 <000c000d> 2403003c 27bdffd0 afb2001c 3c12812f 8e4269e4 Which in its turn made me digging deeper into the way the MMIO-space pages are initialized. That's how I got into the pfn_valid() and init_unavailable_range() working improperly on my setup. Anyway none of the problems above I spotted on kernel 6.5-rc4. So what actually triggered having them finally popped up isn't that easy to be foundn seeing the involved code hasn't changed much. --- arch/mips/mm/init.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 5dcb525a8995..6e368a4658b5 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -422,7 +422,12 @@ void __init paging_init(void) (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10)); max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn; } + + max_mapnr = highend_pfn ? highend_pfn : max_low_pfn; +#else + max_mapnr = max_low_pfn; #endif + high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT); free_area_init(max_zone_pfns); } @@ -458,13 +463,6 @@ void __init mem_init(void) */ BUILD_BUG_ON(IS_ENABLED(CONFIG_32BIT) && (PFN_PTE_SHIFT > PAGE_SHIFT)); -#ifdef CONFIG_HIGHMEM - max_mapnr = highend_pfn ? highend_pfn : max_low_pfn; -#else - max_mapnr = max_low_pfn; -#endif - high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT); - maar_init(); memblock_free_all(); setup_zero_pages(); /* Setup zeroed pages. */ -- 2.42.1

2 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2023