* [PATCH 08/19] coresight: etb10: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-etb10.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 3aab182b562f..7edd3f1d0d46 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -844,7 +844,6 @@ MODULE_DEVICE_TABLE(amba, etb_ids);
static struct amba_driver etb_driver = {
.drv = {
.name = "coresight-etb10",
- .owner = THIS_MODULE,
.pm = &etb_dev_pm_ops,
.suppress_bind_attrs = true,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/19] coresight: stm: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-stm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 974d37e5f94c..15b52358965c 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -954,7 +954,6 @@ MODULE_DEVICE_TABLE(amba, stm_ids);
static struct amba_driver stm_driver = {
.drv = {
.name = "coresight-stm",
- .owner = THIS_MODULE,
.pm = &stm_dev_pm_ops,
.suppress_bind_attrs = true,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 14/19] i2c: nomadik: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/i2c/busses/i2c-nomadik.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 4f41a3c7824d..17fb313565b8 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -1194,7 +1194,6 @@ MODULE_DEVICE_TABLE(amba, nmk_i2c_ids);
static struct amba_driver nmk_i2c_driver = {
.drv = {
- .owner = THIS_MODULE,
.name = DRIVER_NAME,
.pm = pm_ptr(&nmk_i2c_pm),
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 15/19] hwrng: nomadik: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/char/hw_random/nomadik-rng.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/nomadik-rng.c b/drivers/char/hw_random/nomadik-rng.c
index a2009fc4ad3c..f2a2aa7a531c 100644
--- a/drivers/char/hw_random/nomadik-rng.c
+++ b/drivers/char/hw_random/nomadik-rng.c
@@ -78,7 +78,6 @@ MODULE_DEVICE_TABLE(amba, nmk_rng_ids);
static struct amba_driver nmk_rng_driver = {
.drv = {
- .owner = THIS_MODULE,
.name = "rng",
},
.probe = nmk_rng_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 12/19] coresight: tpdm: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-tpdm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index a9708ab0d488..0726f8842552 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -1310,7 +1310,6 @@ static struct amba_id tpdm_ids[] = {
static struct amba_driver tpdm_driver = {
.drv = {
.name = "coresight-tpdm",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = tpdm_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 13/19] coresight: tpiu: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-tpiu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 29024f880fda..7dc9ea564bca 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -236,7 +236,6 @@ MODULE_DEVICE_TABLE(amba, tpiu_ids);
static struct amba_driver tpiu_driver = {
.drv = {
.name = "coresight-tpiu",
- .owner = THIS_MODULE,
.pm = &tpiu_dev_pm_ops,
.suppress_bind_attrs = true,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 11/19] coresight: tpda: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-tpda.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
index 7739bc7adc44..bfca103f9f84 100644
--- a/drivers/hwtracing/coresight/coresight-tpda.c
+++ b/drivers/hwtracing/coresight/coresight-tpda.c
@@ -333,7 +333,6 @@ static struct amba_id tpda_ids[] = {
static struct amba_driver tpda_driver = {
.drv = {
.name = "coresight-tpda",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = tpda_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/19] coresight: replicator: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-replicator.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 73452d9dc13b..2bb9ba66e3c0 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -406,7 +406,6 @@ static struct amba_driver dynamic_replicator_driver = {
.drv = {
.name = "coresight-dynamic-replicator",
.pm = &replicator_dev_pm_ops,
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = dynamic_replicator_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/19] coresight: funnel: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-funnel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index ef1a0abfee4e..5ab1f592917a 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -399,7 +399,6 @@ MODULE_DEVICE_TABLE(amba, dynamic_funnel_ids);
static struct amba_driver dynamic_funnel_driver = {
.drv = {
.name = "coresight-dynamic-funnel",
- .owner = THIS_MODULE,
.pm = &funnel_dev_pm_ops,
.suppress_bind_attrs = true,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/19] coresight: etm4x: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index c2ca4a02dfce..e6cd9705596c 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2344,7 +2344,6 @@ MODULE_DEVICE_TABLE(amba, etm4_ids);
static struct amba_driver etm4x_amba_driver = {
.drv = {
.name = "coresight-etm4x",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = etm4_probe_amba,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/19] coresight: etm3x: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm3x-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index 9d5c1391ffb1..8b362605d242 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -1008,7 +1008,6 @@ MODULE_DEVICE_TABLE(amba, etm_ids);
static struct amba_driver etm_driver = {
.drv = {
.name = "coresight-etm3x",
- .owner = THIS_MODULE,
.pm = &etm_dev_pm_ops,
.suppress_bind_attrs = true,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 01/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Modules registering driver with amba_driver_register() often forget to
set .owner field. The field is used by some of other kernel parts for
reference counting (try_module_get()), so it is expected that drivers
will set it.
Solve the problem by moving this task away from the drivers to the core
amba bus code, just like we did for platform_driver in
commit 9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register").
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/amba/bus.c | 11 +++++++----
include/linux/amba/bus.h | 11 +++++++++--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index a24c152bfaac..aba3aa95b224 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -488,28 +488,31 @@ static int __init amba_stub_drv_init(void)
* waiting on amba_match(). So, register a stub driver to make sure
* amba_match() is called even if no amba driver has been registered.
*/
- return amba_driver_register(&amba_proxy_drv);
+ return __amba_driver_register(&amba_proxy_drv, NULL);
}
late_initcall_sync(amba_stub_drv_init);
/**
- * amba_driver_register - register an AMBA device driver
+ * __amba_driver_register - register an AMBA device driver
* @drv: amba device driver structure
+ * @owner: owning module/driver
*
* Register an AMBA device driver with the Linux device model
* core. If devices pre-exist, the drivers probe function will
* be called.
*/
-int amba_driver_register(struct amba_driver *drv)
+int __amba_driver_register(struct amba_driver *drv,
+ struct module *owner)
{
if (!drv->probe)
return -EINVAL;
+ drv->drv.owner = owner;
drv->drv.bus = &amba_bustype;
return driver_register(&drv->drv);
}
-EXPORT_SYMBOL(amba_driver_register);
+EXPORT_SYMBOL(__amba_driver_register);
/**
* amba_driver_unregister - remove an AMBA device driver
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index c60a6a14638c..958a55bcc708 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -112,11 +112,18 @@ extern struct bus_type amba_bustype;
#define amba_get_drvdata(d) dev_get_drvdata(&d->dev)
#define amba_set_drvdata(d,p) dev_set_drvdata(&d->dev, p)
+/*
+ * use a macro to avoid include chaining to get THIS_MODULE
+ */
+#define amba_driver_register(drv) \
+ __amba_driver_register(drv, THIS_MODULE)
+
#ifdef CONFIG_ARM_AMBA
-int amba_driver_register(struct amba_driver *);
+int __amba_driver_register(struct amba_driver *, struct module *);
void amba_driver_unregister(struct amba_driver *);
#else
-static inline int amba_driver_register(struct amba_driver *drv)
+static inline int __amba_driver_register(struct amba_driver *drv,
+ struct module *owner)
{
return -EINVAL;
}
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/19] coresight: catu: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-catu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index 3949ded0d4fa..375bd0d89b0c 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -590,7 +590,6 @@ MODULE_DEVICE_TABLE(amba, catu_ids);
static struct amba_driver catu_driver = {
.drv = {
.name = "coresight-catu",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = catu_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/19] coresight: cti: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/hwtracing/coresight/coresight-cti-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
index e805617020d0..d2b5a5718c29 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -982,7 +982,6 @@ MODULE_DEVICE_TABLE(amba, cti_ids);
static struct amba_driver cti_driver = {
.drv = {
.name = "coresight-cti",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = cti_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
Merging
=======
All further patches depend on the first amba patch, therefore please ack
and this should go via one tree.
Description
===========
Modules registering driver with amba_driver_register() often forget to
set .owner field.
Solve the problem by moving this task away from the drivers to the core
amba bus code, just like we did for platform_driver in commit
9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register").
Best regards,
Krzysztof
---
Krzysztof Kozlowski (19):
amba: store owner from modules with amba_driver_register()
coresight: cti: drop owner assignment
coresight: catu: drop owner assignment
coresight: etm3x: drop owner assignment
coresight: etm4x: drop owner assignment
coresight: funnel: drop owner assignment
coresight: replicator: drop owner assignment
coresight: etb10: drop owner assignment
coresight: stm: drop owner assignment
coresight: tmc: drop owner assignment
coresight: tpda: drop owner assignment
coresight: tpdm: drop owner assignment
coresight: tpiu: drop owner assignment
i2c: nomadik: drop owner assignment
hwrng: nomadik: drop owner assignment
dmaengine: pl330: drop owner assignment
Input: ambakmi - drop owner assignment
memory: pl353-smc: drop owner assignment
vfio: amba: drop owner assignment
drivers/amba/bus.c | 11 +++++++----
drivers/char/hw_random/nomadik-rng.c | 1 -
drivers/dma/pl330.c | 1 -
drivers/hwtracing/coresight/coresight-catu.c | 1 -
drivers/hwtracing/coresight/coresight-cti-core.c | 1 -
drivers/hwtracing/coresight/coresight-etb10.c | 1 -
drivers/hwtracing/coresight/coresight-etm3x-core.c | 1 -
drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 -
drivers/hwtracing/coresight/coresight-funnel.c | 1 -
drivers/hwtracing/coresight/coresight-replicator.c | 1 -
drivers/hwtracing/coresight/coresight-stm.c | 1 -
drivers/hwtracing/coresight/coresight-tmc-core.c | 1 -
drivers/hwtracing/coresight/coresight-tpda.c | 1 -
drivers/hwtracing/coresight/coresight-tpdm.c | 1 -
drivers/hwtracing/coresight/coresight-tpiu.c | 1 -
drivers/i2c/busses/i2c-nomadik.c | 1 -
drivers/input/serio/ambakmi.c | 1 -
drivers/memory/pl353-smc.c | 1 -
drivers/vfio/platform/vfio_amba.c | 1 -
include/linux/amba/bus.h | 11 +++++++++--
20 files changed, 16 insertions(+), 24 deletions(-)
---
base-commit: 1fdad13606e104ff103ca19d2d660830cb36d43e
change-id: 20240326-module-owner-amba-3ebb65256be7
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] arm64: dts: ti: k3-am65: Remove UART baud rate selection
From: Nishanth Menon @ 2024-03-26 20:21 UTC (permalink / raw)
To: Andrew Davis
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240326185441.29656-1-afd@ti.com>
On 13:54-20240326, Andrew Davis wrote:
> As described in the binding document for the "current-speed" property:
>
> "This should only be present in case a driver has no chance to know the
> baud rate of the slave device."
>
> This is not the case for the UART used in K3 devices, the current
> baud-rate can be calculated from the registers. Having this property
I do not understand the explanation above -> how does one do this?
If you are talking of the 8250 divider registers, someone has to program
those - how do you compute the baud rate from registers that aren't
programmed? Note: I am not commenting on the rationale of removing the
property, just trying to understand the assertion above.
> has the effect of actually skipping the baud-rate setup in some drivers
> as it assumes it will already be set to this rate, which may not always
> be the case.
>
> It seems this property's purpose was mistaken as selecting the desired
> baud-rate, which it does not. It would have been wrong to select that
> here anyway as DT is not the place for configuration, especially when
> there are already more standard ways to set serial baud-rates.
>
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 -
> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 1 -
> arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index ff857117d7193..670557c89f756 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -89,7 +89,6 @@ main_uart0: serial@2800000 {
> reg = <0x00 0x02800000 0x00 0x100>;
> interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <48000000>;
> - current-speed = <115200>;
> power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
> status = "disabled";
> };
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> index 6ff3ccc39fb44..4f808e5089755 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> @@ -43,7 +43,6 @@ mcu_uart0: serial@40a00000 {
> reg = <0x00 0x40a00000 0x00 0x100>;
> interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <96000000>;
> - current-speed = <115200>;
> power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
> status = "disabled";
> };
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> index 37527890ddeaf..eee072e44a42f 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> @@ -59,7 +59,6 @@ wkup_uart0: serial@42300000 {
> reg = <0x42300000 0x100>;
> interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <48000000>;
> - current-speed = <115200>;
> power-domains = <&k3_pds 150 TI_SCI_PD_EXCLUSIVE>;
> status = "disabled";
> };
> --
> 2.39.2
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
From: Andy Shevchenko @ 2024-03-26 20:17 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <ccb80185-0862-4d84-a0bf-0cc349a609fe@sirena.org.uk>
On Tue, Mar 26, 2024 at 08:12:09PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 10:04:43PM +0200, Andy Shevchenko wrote:
>
> > There is currently a dependency among others PCI || ACPI || COMPILE_TEST
>
> > From the point of view of the real platforms it means that if there is
> > a PCI compiled we support PCI devices that use this "platform" driver.
> > Similar with ACPI.
>
> > What you want is to hide this in the menuconfig for the irrelevant platforms
> > which have PCI _or_ ACPI enabled, correct?
>
> > But if we add x86 dependency to that, it will drop the support for non-x86
> > ACPI-based platforms with this device. I have no clue what are those.
>
> Given the history I would be surprised to learn of any platforms that
> have used this other than PXA, MMP or x86. It's possible Intel shipped
> the IP directly exposed on a PCI card of some kind but it'd be pretty
> surprising given the way it tends to get used and the idiom for PCI
> cards, Marvell having done that would be even more surprising. The x86
> uses I'm aware of are integrated into the chipset rather than something
> meaingfully separate to the SoC.
Okay, do you want to have an experimental (that we might revert in the future
if any regression being reported) patch to narrow this dependencies as I
described above?
I can prepend the v2 with a such.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 4/4] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
From: Lukasz Luba @ 2024-03-26 20:12 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
rafael, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel, linux-pm
In-Reply-To: <59d37960-cf19-4b10-802f-59d42496c133@arm.com>
Hi Dietmar,
On 3/26/24 11:20, Dietmar Eggemann wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
>
> [...]
>
>> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct exynos_asv *asv)
>> last_opp_table = opp_table;
>>
>> ret = exynos_asv_update_cpu_opps(asv, cpu);
>> - if (ret < 0)
>> + if (!ret) {
>> + /*
>> + * When the voltage for OPPs successfully
>> + * changed, update the EM power values to
>> + * reflect the reality and not use stale data
>
> At this point, can we really say that the voltage has changed?
>
> exynos_asv_update_cpu_opps()
>
> ...
> ret = dev_pm_opp_adjust_voltage()
> if (!ret)
> em_dev_update_chip_binning()
> ...
>
> dev_pm_opp_adjust_voltage() also returns 0 when the voltage value stays
> the same?
>
> [...]
The comment for the dev_pm_opp_adjust_voltage() says that it
returns 0 if no modification was done or modification was
successful. So I cannot distinguish in that driver code, but
also there is no additional need to do it IMO (even framework
doesn't do this).
Regards,
Lukasz
[1]
https://elixir.bootlin.com/linux/v6.9-rc1/source/drivers/opp/core.c#L2950
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
From: Andy Shevchenko @ 2024-03-26 20:12 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <c18186c0-63d8-4406-add0-980f723e3528@sirena.org.uk>
On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:50:04PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> > > On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
>
> > > > Since driver can parse num-cs device property, replace platform data
> > > > with this new approach.
>
> > > But why?
>
> > To be able to hide the header's contents from public.
> > Should I update the commit message?
>
> That would definitely help, but it's hard to see what the actual benefit
> is here. It's removing platform data without doing the more difficult
> bit where the platform gets converted to DT.
Will do in v2.
> > > > +static const struct property_entry spitz_spi_properties[] = {
> > > > + PROPERTY_ENTRY_U32("num-cs", 3),
> > > > + { }
> > > > +};
>
> > > This is just platform data with less validation AFAICT.
>
> > I'm not sure what validation you are expecting here. It should be done via
>
> Well, the problem with swnode is that there's no validation to expect -
> it's an inherent problem with swnode.
I do not object this.
> > DT schema ideally when the platform gets converted to DT. This change is
> > an interim to that (at least it makes kernel side better). After the platform
> > code may be gone completely or converted. If the latter happens, we got
> > the validation back.
>
> It is not clear to me that this makes the kernel side better, it just
> seems to be rewriting the platform data for the sake of it. If it was
> converting to DT there'd be some stuff from it being DT but this keeps
> everything as in kernel as board files, just in a more complex form.
Not really. The benefits with swnode conversion are the following:
- reducing custom APIs / data types between _shared_ (in a sense of
supporting zillion different platforms) driver and a certain board
file
- as an effect of the above, reducing kernel code base, and as the result
make maintenance easier and bug-free for that parts
- preparing a driver to be ready for any old board file conversion to DT
as it reduces that churn (you won't need to touch the driver code)
- ...anything else I forgot to mention...
> > In any case it's not worse than plain DT property handling in the kernel.
> > The validation in that case is done elsewhere. Since the property is defined
> > in board files the assumed validation is done during development/review
> > stages. But OTOH for the legacy code we need not to touch the property
> > provider more than once. We are _not_ expecting this to be spread.
>
> I'm guessing you're just checking this by inspection though...
Yes, we seems do not have any tool to perform a such against software nodes.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
From: Mark Brown @ 2024-03-26 20:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <ZgMqW6TSHYJ2NOPq@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]
On Tue, Mar 26, 2024 at 10:04:43PM +0200, Andy Shevchenko wrote:
> There is currently a dependency among others PCI || ACPI || COMPILE_TEST
> From the point of view of the real platforms it means that if there is
> a PCI compiled we support PCI devices that use this "platform" driver.
> Similar with ACPI.
> What you want is to hide this in the menuconfig for the irrelevant platforms
> which have PCI _or_ ACPI enabled, correct?
> But if we add x86 dependency to that, it will drop the support for non-x86
> ACPI-based platforms with this device. I have no clue what are those.
Given the history I would be surprised to learn of any platforms that
have used this other than PXA, MMP or x86. It's possible Intel shipped
the IP directly exposed on a PCI card of some kind but it'd be pretty
surprising given the way it tends to get used and the idiom for PCI
cards, Marvell having done that would be even more surprising. The x86
uses I'm aware of are integrated into the chipset rather than something
meaingfully separate to the SoC.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] iommu/arm-smmu-v3: support suspend/resume
From: Thomas Gleixner @ 2024-03-26 20:11 UTC (permalink / raw)
To: Jason Gunthorpe, Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Marc Zyngier, Bixuan Cui,
linux-arm-kernel, iommu, linux-kernel, Peng Fan
In-Reply-To: <87bk72fcf4.ffs@tglx>
On Mon, Mar 25 2024 at 18:29, Thomas Gleixner wrote:
> On Mon, Mar 25 2024 at 10:48, Jason Gunthorpe wrote:
>> On Sun, Mar 24, 2024 at 08:29:00PM +0800, Peng Fan (OSS) wrote:
>>> + if (smmu->features & ARM_SMMU_FEAT_PRI) {
>>> + desc = irq_get_msi_desc(smmu->priq.q.irq);
>>> + if (desc) {
>>> + get_cached_msi_msg(smmu->priq.q.irq, &msg);
>>> + arm_smmu_write_msi_msg(desc, &msg);
>>> + }
>>> + }
>>> +}
>>
>> I wonder if this should be done instead by converting the driver away
>> from platform MSI to the new MSI mechanism?
>
> There is work in progress for that. Should come around in the next
> weeks.
But that won't solve it. The above is a horrible hack and I think this
should be solved completely differently.
On suspend the core interrupt code disables all interrupts which are not
marked as wakeup interrupts. On resume it reenables them including
restoring the affinity setting.
So this just should work, but it does not because the MSI message is
only written once, when the interrupt is activated. Further affinity
changes affect only the ITS table and do not result in a message write.
The most trivial way w/o changing any core code for it, would be to free
the interrupts on suspend and request them on resume again, because that
would deactivate and reactivate it.
Though that does not work if the IOMMU is resumed in the early resume
path. But we can enforce writing the message in the resume path.
See the untested below.
Thanks,
tglx
---
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -223,6 +223,7 @@ struct irq_data {
* irqchip have flag IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
* IRQD_RESEND_WHEN_IN_PROGRESS - Interrupt may fire when already in progress in which
* case it must be resent at the next available opportunity.
+ * IRQD_RESUMING - Interrupt is resumed after suspend
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -249,6 +250,7 @@ enum {
IRQD_AFFINITY_ON_ACTIVATE = BIT(28),
IRQD_IRQ_ENABLED_ON_SUSPEND = BIT(29),
IRQD_RESEND_WHEN_IN_PROGRESS = BIT(30),
+ IRQD_RESUMING = BIT(31),
};
#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -443,6 +445,11 @@ static inline bool irqd_needs_resend_whe
return __irqd_to_state(d) & IRQD_RESEND_WHEN_IN_PROGRESS;
}
+static inline bool irqd_resuming(struct irq_data *d)
+{
+ return __irqd_to_state(d) & IRQD_RESUMING;
+}
+
#undef __irqd_to_state
static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -617,6 +617,7 @@ static unsigned int msi_domain_get_hwsiz
static inline void irq_chip_write_msi_msg(struct irq_data *data,
struct msi_msg *msg)
{
+ irq_data_get_msi_desc(data)->msg = *msg;
data->chip->irq_write_msi_msg(data, msg);
}
@@ -652,7 +653,10 @@ int msi_domain_set_affinity(struct irq_d
int ret;
ret = parent->chip->irq_set_affinity(parent, mask, force);
- if (ret >= 0 && ret != IRQ_SET_MASK_OK_DONE) {
+ if (ret < 0)
+ return ret;
+
+ if (ret != IRQ_SET_MASK_OK_DONE || irqd_resuming(irq_data)) {
BUG_ON(irq_chip_compose_msi_msg(irq_data, msg));
msi_check_level(irq_data->domain, msg);
irq_chip_write_msi_msg(irq_data, msg);
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -177,7 +177,13 @@ static void resume_irq(struct irq_desc *
irq_state_set_masked(desc);
resume:
desc->istate &= ~IRQS_SUSPENDED;
+ /*
+ * Ensure that MSI messages get rewritten on resume. The device
+ * might have lost it due to power disabling.
+ */
+ irqd_set(&desc->irq_data, IRQD_RESUMING);
__enable_irq(desc);
+ irqd_clear(&desc->irq_data, IRQD_RESUMING);
}
static void resume_irqs(bool want_early)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
From: Andy Shevchenko @ 2024-03-26 20:04 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <a30da48d-f801-4d0a-9db7-9c9bb159ca6b@sirena.org.uk>
On Tue, Mar 26, 2024 at 07:32:47PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 09:20:05PM +0200, Andy Shevchenko wrote:
>
> > For my knowledge there is none of the ACPI-based platform where CONFIG_ACPI
> > needs to be 'n' while having the real device (as per ACPI ID table) to be on.
> > That's why I answered purely from the compilation point of view.
>
> I don't understand the relevance of that, and frankly can't make much
> sense of it.
It's relevant to the ID table presence at run-time. But it seems I wrongly got
your point (see below).
> > Personally I see that dependency more confusing than hinting about anything.
>
> When you don't have a dependency in Kconfig then people get offered the
> device even if it is impossible for it to be useful on their platform.
There is currently a dependency among others PCI || ACPI || COMPILE_TEST
From the point of view of the real platforms it means that if there is
a PCI compiled we support PCI devices that use this "platform" driver.
Similar with ACPI.
What you want is to hide this in the menuconfig for the irrelevant platforms
which have PCI _or_ ACPI enabled, correct?
But if we add x86 dependency to that, it will drop the support for non-x86
ACPI-based platforms with this device. I have no clue what are those.
Yes, we may try to have ((PCI || ACPI) && X86) at the end, but I believe
this will have a good regression effect.
> The purpose of any || COMPILE_TEST dependency is to improve the
> usability of Kconfig.
Right, when I see FOO || COMPILE_TEST I interpret FOO as *functional*
dependency, meaning that without FOO the certain driver makes no sense
from functional point of view.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
From: Mark Brown @ 2024-03-26 20:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <ZgMY3AeC1Jnh1Oru@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1955 bytes --]
On Tue, Mar 26, 2024 at 08:50:04PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> > On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
> > > Since driver can parse num-cs device property, replace platform data
> > > with this new approach.
> > But why?
> To be able to hide the header's contents from public.
> Should I update the commit message?
That would definitely help, but it's hard to see what the actual benefit
is here. It's removing platform data without doing the more difficult
bit where the platform gets converted to DT.
> > > +static const struct property_entry spitz_spi_properties[] = {
> > > + PROPERTY_ENTRY_U32("num-cs", 3),
> > > + { }
> > > +};
> > This is just platform data with less validation AFAICT.
> I'm not sure what validation you are expecting here. It should be done via
Well, the problem with swnode is that there's no validation to expect -
it's an inherent problem with swnode.
> DT schema ideally when the platform gets converted to DT. This change is
> an interim to that (at least it makes kernel side better). After the platform
> code may be gone completely or converted. If the latter happens, we got
> the validation back.
It is not clear to me that this makes the kernel side better, it just
seems to be rewriting the platform data for the sake of it. If it was
converting to DT there'd be some stuff from it being DT but this keeps
everything as in kernel as board files, just in a more complex form.
> In any case it's not worse than plain DT property handling in the kernel.
> The validation in that case is done elsewhere. Since the property is defined
> in board files the assumed validation is done during development/review
> stages. But OTOH for the legacy code we need not to touch the property
> provider more than once. We are _not_ expecting this to be spread.
I'm guessing you're just checking this by inspection though...
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware node
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Nicolas Saenz Julienne,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-1-laurent.pinchart@ideasonboard.com>
The firmware node contains a "dma-ranges" property to enable usage of
the DMA mapping API with its child devices, along with "#address-cells"
and "#size-cells" properties to support the dma-ranges. This was needed
due to usage of the incorrect device to perform the DMA mapping in
drivers. Now that this has been fixed, drop the properties.
This effectively reverts commits be08d278eb09 ("ARM: dts: bcm283x: Add
cells encoding format to firmware bus") and 55c7c0621078 ("ARM: dts:
bcm283x: Fix vc4's firmware bus DMA limitations").
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
index f0acc9390f31..761a9da97bd0 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -4,11 +4,7 @@ / {
soc {
firmware: firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
-
mboxes = <&mailbox>;
- dma-ranges;
};
power: power {
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/3] firmware: raspberrypi: Use correct device for DMA mappings
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Nicolas Saenz Julienne,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-1-laurent.pinchart@ideasonboard.com>
The buffer used to transfer data over the mailbox interface is mapped
using the client's device. This is incorrect, as the device performing
the DMA transfer is the mailbox itself. Fix it by using the mailbox
controller device instead.
This requires including the mailbox_controller.h header to dereference
the mbox_chan and mbox_controller structures. The header is not meant to
be included by clients. This could be fixed by extending the client API
with a function to access the controller's device.
Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/firmware/raspberrypi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 322aada20f74..ac34876a97f8 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -9,6 +9,7 @@
#include <linux/dma-mapping.h>
#include <linux/kref.h>
#include <linux/mailbox_client.h>
+#include <linux/mailbox_controller.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -97,8 +98,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
if (size & 3)
return -EINVAL;
- buf = dma_alloc_coherent(fw->cl.dev, PAGE_ALIGN(size), &bus_addr,
- GFP_ATOMIC);
+ buf = dma_alloc_coherent(fw->chan->mbox->dev, PAGE_ALIGN(size),
+ &bus_addr, GFP_ATOMIC);
if (!buf)
return -ENOMEM;
@@ -126,7 +127,7 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
ret = -EINVAL;
}
- dma_free_coherent(fw->cl.dev, PAGE_ALIGN(size), buf, bus_addr);
+ dma_free_coherent(fw->chan->mbox->dev, PAGE_ALIGN(size), buf, bus_addr);
return ret;
}
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox