[PATCH 00/19] amba: store owner from modules with amba_driver_register()

[PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

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>

[PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

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

[PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

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

[PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

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

[PATCH 02/19] coresight: cti: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 02/19] coresight: cti: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 03/19] coresight: catu: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 03/19] coresight: catu: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 04/19] coresight: etm3x: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 04/19] coresight: etm3x: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 05/19] coresight: etm4x: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 05/19] coresight: etm4x: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 06/19] coresight: funnel: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 06/19] coresight: funnel: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 07/19] coresight: replicator: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 07/19] coresight: replicator: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 08/19] coresight: etb10: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 08/19] coresight: etb10: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 09/19] coresight: stm: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 09/19] coresight: stm: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 10/19] coresight: tmc: drop owner assignment

[Krzysztof Kozlowski]

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-tmc-core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index 72005b0c633e..0d251cae814f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -602,7 +602,6 @@ MODULE_DEVICE_TABLE(amba, tmc_ids);
 static struct amba_driver tmc_driver = {
 	.drv = {
 		.name   = "coresight-tmc",
-		.owner  = THIS_MODULE,
 		.suppress_bind_attrs = true,
 	},
 	.probe		= tmc_probe,

-- 
2.34.1

[PATCH 10/19] coresight: tmc: drop owner assignment

[Krzysztof Kozlowski]

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-tmc-core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index 72005b0c633e..0d251cae814f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -602,7 +602,6 @@ MODULE_DEVICE_TABLE(amba, tmc_ids);
 static struct amba_driver tmc_driver = {
 	.drv = {
 		.name   = "coresight-tmc",
-		.owner  = THIS_MODULE,
 		.suppress_bind_attrs = true,
 	},
 	.probe		= tmc_probe,

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 11/19] coresight: tpda: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 11/19] coresight: tpda: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 12/19] coresight: tpdm: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 12/19] coresight: tpdm: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 13/19] coresight: tpiu: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 13/19] coresight: tpiu: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 14/19] i2c: nomadik: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 14/19] i2c: nomadik: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 15/19] hwrng: nomadik: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 15/19] hwrng: nomadik: drop owner assignment

[Krzysztof Kozlowski]

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

[PATCH 16/19] dmaengine: pl330: drop owner assignment

[Krzysztof Kozlowski]

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/dma/pl330.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 5f6d7f1e095f..b37ef28bb417 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3265,7 +3265,6 @@ MODULE_DEVICE_TABLE(amba, pl330_ids);
 
 static struct amba_driver pl330_driver = {
 	.drv = {
-		.owner = THIS_MODULE,
 		.name = "dma-pl330",
 		.pm = &pl330_pm,
 	},

-- 
2.34.1

[PATCH 16/19] dmaengine: pl330: drop owner assignment

[Krzysztof Kozlowski]

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/dma/pl330.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 5f6d7f1e095f..b37ef28bb417 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3265,7 +3265,6 @@ MODULE_DEVICE_TABLE(amba, pl330_ids);
 
 static struct amba_driver pl330_driver = {
 	.drv = {
-		.owner = THIS_MODULE,
 		.name = "dma-pl330",
 		.pm = &pl330_pm,
 	},

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 17/19] Input: ambakmi - drop owner assignment

[Krzysztof Kozlowski]

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/input/serio/ambakmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
index 8fbfa448be4a..496bb7a312d2 100644
--- a/drivers/input/serio/ambakmi.c
+++ b/drivers/input/serio/ambakmi.c
@@ -195,7 +195,6 @@ MODULE_DEVICE_TABLE(amba, amba_kmi_idtable);
 static struct amba_driver ambakmi_driver = {
 	.drv		= {
 		.name	= "kmi-pl050",
-		.owner	= THIS_MODULE,
 		.pm	= pm_sleep_ptr(&amba_kmi_dev_pm_ops),
 	},
 	.id_table	= amba_kmi_idtable,

-- 
2.34.1

[PATCH 17/19] Input: ambakmi - drop owner assignment

[Krzysztof Kozlowski]

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/input/serio/ambakmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
index 8fbfa448be4a..496bb7a312d2 100644
--- a/drivers/input/serio/ambakmi.c
+++ b/drivers/input/serio/ambakmi.c
@@ -195,7 +195,6 @@ MODULE_DEVICE_TABLE(amba, amba_kmi_idtable);
 static struct amba_driver ambakmi_driver = {
 	.drv		= {
 		.name	= "kmi-pl050",
-		.owner	= THIS_MODULE,
 		.pm	= pm_sleep_ptr(&amba_kmi_dev_pm_ops),
 	},
 	.id_table	= amba_kmi_idtable,

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 18/19] memory: pl353-smc: drop owner assignment

[Krzysztof Kozlowski]

Amba bus core already sets owner, so driver does not need to.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

As memory controllers maintainer: this has my Ack. :)

Depends on first amba patch.
---
 drivers/memory/pl353-smc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
index 48540817e046..56e51737c81f 100644
--- a/drivers/memory/pl353-smc.c
+++ b/drivers/memory/pl353-smc.c
@@ -154,7 +154,6 @@ MODULE_DEVICE_TABLE(amba, pl353_ids);
 
 static struct amba_driver pl353_smc_driver = {
 	.drv = {
-		.owner = THIS_MODULE,
 		.name = "pl353-smc",
 		.pm = &pl353_smc_dev_pm_ops,
 	},

-- 
2.34.1

[PATCH 18/19] memory: pl353-smc: drop owner assignment

[Krzysztof Kozlowski]

Amba bus core already sets owner, so driver does not need to.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

As memory controllers maintainer: this has my Ack. :)

Depends on first amba patch.
---
 drivers/memory/pl353-smc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
index 48540817e046..56e51737c81f 100644
--- a/drivers/memory/pl353-smc.c
+++ b/drivers/memory/pl353-smc.c
@@ -154,7 +154,6 @@ MODULE_DEVICE_TABLE(amba, pl353_ids);
 
 static struct amba_driver pl353_smc_driver = {
 	.drv = {
-		.owner = THIS_MODULE,
 		.name = "pl353-smc",
 		.pm = &pl353_smc_dev_pm_ops,
 	},

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 19/19] vfio: amba: drop owner assignment

[Krzysztof Kozlowski]

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/vfio/platform/vfio_amba.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
index 485c6f9161a9..ff8ff8480968 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -134,7 +134,6 @@ static struct amba_driver vfio_amba_driver = {
 	.id_table = vfio_amba_ids,
 	.drv = {
 		.name = "vfio-amba",
-		.owner = THIS_MODULE,
 	},
 	.driver_managed_dma = true,
 };

-- 
2.34.1

[PATCH 19/19] vfio: amba: drop owner assignment

[Krzysztof Kozlowski]

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/vfio/platform/vfio_amba.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
index 485c6f9161a9..ff8ff8480968 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -134,7 +134,6 @@ static struct amba_driver vfio_amba_driver = {
 	.id_table = vfio_amba_ids,
 	.drv = {
 		.name = "vfio-amba",
-		.owner = THIS_MODULE,
 	},
 	.driver_managed_dma = true,
 };

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

Hi Krzysztof

On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.

Are you able to provide a stable branch with these patches once you pull
them in to "one tree" here ? We have changes coming up in the coresight
tree, which would conflict with the changes here (horribly).

FWIW,

For patches 1 to 13 :

Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Suzuki

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

Hi Krzysztof

On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.

Are you able to provide a stable branch with these patches once you pull
them in to "one tree" here ? We have changes coming up in the coresight
tree, which would conflict with the changes here (horribly).

FWIW,

For patches 1 to 13 :

Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 00:24, Suzuki K Poulose wrote:
> Hi Krzysztof
> 
> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>> Merging
>> =======
>> All further patches depend on the first amba patch, therefore please ack
>> and this should go via one tree.
> 
> Are you able to provide a stable branch with these patches once you pull

I doubt I will be merging this. I think amba code goes through Russell.

> them in to "one tree" here ? We have changes coming up in the coresight
> tree, which would conflict with the changes here (horribly).
> 

You mean conflict with  coresight conversion to platform driver? Worst
case it is solveable: just drop .owner.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 00:24, Suzuki K Poulose wrote:
> Hi Krzysztof
> 
> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>> Merging
>> =======
>> All further patches depend on the first amba patch, therefore please ack
>> and this should go via one tree.
> 
> Are you able to provide a stable branch with these patches once you pull

I doubt I will be merging this. I think amba code goes through Russell.

> them in to "one tree" here ? We have changes coming up in the coresight
> tree, which would conflict with the changes here (horribly).
> 

You mean conflict with  coresight conversion to platform driver? Worst
case it is solveable: just drop .owner.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 18/19] memory: pl353-smc: drop owner assignment

[Miquel Raynal]

Hi Krzysztof,

krzysztof.kozlowski@linaro.org wrote on Tue, 26 Mar 2024 21:23:48 +0100:

> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl

Re: [PATCH 18/19] memory: pl353-smc: drop owner assignment

[Miquel Raynal]

Hi Krzysztof,

krzysztof.kozlowski@linaro.org wrote on Tue, 26 Mar 2024 21:23:48 +0100:

> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>> Hi Krzysztof
>>
>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>
>> Are you able to provide a stable branch with these patches once you pull
> 
> I doubt I will be merging this. I think amba code goes through Russell.
> 
>> them in to "one tree" here ? We have changes coming up in the coresight
>> tree, which would conflict with the changes here (horribly).
>>
> 
> You mean conflict with  coresight conversion to platform driver? Worst

Yes.

> case it is solveable: just drop .owner.

Or, we could merge the CoreSight changes (as they are really not
affected by the problem this series is trying to address) after the
base changes land in AMBA, via the CoreSight tree.


Suzuki

> 
> Best regards,
> Krzysztof
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>> Hi Krzysztof
>>
>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>
>> Are you able to provide a stable branch with these patches once you pull
> 
> I doubt I will be merging this. I think amba code goes through Russell.
> 
>> them in to "one tree" here ? We have changes coming up in the coresight
>> tree, which would conflict with the changes here (horribly).
>>
> 
> You mean conflict with  coresight conversion to platform driver? Worst

Yes.

> case it is solveable: just drop .owner.

Or, we could merge the CoreSight changes (as they are really not
affected by the problem this series is trying to address) after the
base changes land in AMBA, via the CoreSight tree.


Suzuki

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Andi Shyti]

Hi Krzysztof,

...

>  /**
> - *	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,

...

> +/*
> + * use a macro to avoid include chaining to get THIS_MODULE
> + */

Should the documentation be moved here? Well... I don't see any
documentation linking this file yet, but in case it comes we want
documented amba_driver_register() rather than
__amba_driver_register().

Andi

> +#define amba_driver_register(drv) \
> +	__amba_driver_register(drv, THIS_MODULE)
> +

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Andi Shyti]

Hi Krzysztof,

...

>  /**
> - *	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,

...

> +/*
> + * use a macro to avoid include chaining to get THIS_MODULE
> + */

Should the documentation be moved here? Well... I don't see any
documentation linking this file yet, but in case it comes we want
documented amba_driver_register() rather than
__amba_driver_register().

Andi

> +#define amba_driver_register(drv) \
> +	__amba_driver_register(drv, THIS_MODULE)
> +

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Andi Shyti]

Hi Krzysztof,

On Tue, Mar 26, 2024 at 09:23:44PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Andi Shyti <andi.shyti@kernel.org>

Andi

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Andi Shyti]

Hi Krzysztof,

On Tue, Mar 26, 2024 at 09:23:44PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Andi Shyti <andi.shyti@kernel.org>

Andi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 16/19] dmaengine: pl330: drop owner assignment

[Vinod Koul]

On 26-03-24, 21:23, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.

Acked-by: Vinod Koul <vkoul@kernel.org>

-- 
~Vinod

Re: [PATCH 16/19] dmaengine: pl330: drop owner assignment

[Vinod Koul]

On 26-03-24, 21:23, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.

Acked-by: Vinod Koul <vkoul@kernel.org>

-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 21:33, Andi Shyti wrote:
> Hi Krzysztof,
> 
> ...
> 
>>  /**
>> - *	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,
> 
> ...
> 
>> +/*
>> + * use a macro to avoid include chaining to get THIS_MODULE
>> + */
> 
> Should the documentation be moved here? Well... I don't see any
> documentation linking this file yet, but in case it comes we want
> documented amba_driver_register() rather than
> __amba_driver_register().
> 

That's just a wrapper, not API... why would we care to have kerneldoc
for it?

Best regards,
Krzysztof

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 21:33, Andi Shyti wrote:
> Hi Krzysztof,
> 
> ...
> 
>>  /**
>> - *	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,
> 
> ...
> 
>> +/*
>> + * use a macro to avoid include chaining to get THIS_MODULE
>> + */
> 
> Should the documentation be moved here? Well... I don't see any
> documentation linking this file yet, but in case it comes we want
> documented amba_driver_register() rather than
> __amba_driver_register().
> 

That's just a wrapper, not API... why would we care to have kerneldoc
for it?

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Linus Walleij]

On Tue, Mar 26, 2024 at 9:24 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Linus Walleij]

On Tue, Mar 26, 2024 at 9:24 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 19/19] vfio: amba: drop owner assignment

[Eric Auger]

Hi,

On 3/26/24 21:23, Krzysztof Kozlowski wrote:
> 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/vfio/platform/vfio_amba.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
> index 485c6f9161a9..ff8ff8480968 100644
> --- a/drivers/vfio/platform/vfio_amba.c
> +++ b/drivers/vfio/platform/vfio_amba.c
> @@ -134,7 +134,6 @@ static struct amba_driver vfio_amba_driver = {
>  	.id_table = vfio_amba_ids,
>  	.drv = {
>  		.name = "vfio-amba",
> -		.owner = THIS_MODULE,
>  	},
>  	.driver_managed_dma = true,
>  };
>
>

Reviewed-by: Eric Auger <eric.auger@redhat.com>

Thanks

Eric

Re: [PATCH 19/19] vfio: amba: drop owner assignment

[Eric Auger]

Hi,

On 3/26/24 21:23, Krzysztof Kozlowski wrote:
> 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/vfio/platform/vfio_amba.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
> index 485c6f9161a9..ff8ff8480968 100644
> --- a/drivers/vfio/platform/vfio_amba.c
> +++ b/drivers/vfio/platform/vfio_amba.c
> @@ -134,7 +134,6 @@ static struct amba_driver vfio_amba_driver = {
>  	.id_table = vfio_amba_ids,
>  	.drv = {
>  		.name = "vfio-amba",
> -		.owner = THIS_MODULE,
>  	},
>  	.driver_managed_dma = true,
>  };
>
>

Reviewed-by: Eric Auger <eric.auger@redhat.com>

Thanks

Eric


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Andi Shyti]

Hi Krzysztof,

> >>  /**
> >> - *	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,
> > 
> > ...
> > 
> >> +/*
> >> + * use a macro to avoid include chaining to get THIS_MODULE
> >> + */
> > 
> > Should the documentation be moved here? Well... I don't see any
> > documentation linking this file yet, but in case it comes we want
> > documented amba_driver_register() rather than
> > __amba_driver_register().
> > 
> 
> That's just a wrapper, not API... why would we care to have kerneldoc
> for it?

Because everyone should use the wrapper while the real function
will be used only once or twice.

I see also that this is a common practice which I don't surely
like.

In any case there is no documentation exported for AMBA so that
this discussion does not bring any tangible benefit.

So that, considering that it's a good improvement,

Reviewed-by: Andi Shyti <andi.shyti@kernel.org>

Andi

Re: [PATCH 01/19] amba: store owner from modules with amba_driver_register()

[Andi Shyti]

Hi Krzysztof,

> >>  /**
> >> - *	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,
> > 
> > ...
> > 
> >> +/*
> >> + * use a macro to avoid include chaining to get THIS_MODULE
> >> + */
> > 
> > Should the documentation be moved here? Well... I don't see any
> > documentation linking this file yet, but in case it comes we want
> > documented amba_driver_register() rather than
> > __amba_driver_register().
> > 
> 
> That's just a wrapper, not API... why would we care to have kerneldoc
> for it?

Because everyone should use the wrapper while the real function
will be used only once or twice.

I see also that this is a common practice which I don't surely
like.

In any case there is no documentation exported for AMBA so that
this discussion does not bring any tangible benefit.

So that, considering that it's a good improvement,

Reviewed-by: Andi Shyti <andi.shyti@kernel.org>

Andi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 17/19] Input: ambakmi - drop owner assignment

[Dmitry Torokhov]

On Tue, Mar 26, 2024 at 09:23:47PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 

Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Thanks.

-- 
Dmitry

Re: [PATCH 17/19] Input: ambakmi - drop owner assignment

[Dmitry Torokhov]

On Tue, Mar 26, 2024 at 09:23:47PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 

Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Thanks.

-- 
Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> 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,

I tried to submit this series to Russell patch tracker and failed. This
is ridiculous. It's 2024 and instead of normal process, like every other
maintainer, so b4 or Patchwork, we have some unusable system rejecting
standard patches.

First, it depends some weird, duplicated signed-off-by's. Second it
submitting patch-by-patch, all with clicking on some web (!!!) interface.

I did it, clicked 19 times and system was happy... but then on email
said the patches were rejected. Couldn't tell it after submitting first
patch via the web?

That's the response:
-------------
Your patch has not been logged because:

Error:   Please supply a summary subject line briefly describing
         your patch.


Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
"---".

Error:   the patch you are submitting has one or more missing or incorrect
         Signed-off-by lines:

         - author signoff <krzkreg@gmail.com> is missing.

         Please see the file Documentation/SubmittingPatches, section 11
         for details on signing off patches.


Please see https://www.armlinux.org.uk/developer/patches/info.shtml
for more information.
-------------

This is unbelievable waste of time. I am not going to use this tracker.
It's huge obstacle and huge waste of submitters time.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> 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,

I tried to submit this series to Russell patch tracker and failed. This
is ridiculous. It's 2024 and instead of normal process, like every other
maintainer, so b4 or Patchwork, we have some unusable system rejecting
standard patches.

First, it depends some weird, duplicated signed-off-by's. Second it
submitting patch-by-patch, all with clicking on some web (!!!) interface.

I did it, clicked 19 times and system was happy... but then on email
said the patches were rejected. Couldn't tell it after submitting first
patch via the web?

That's the response:
-------------
Your patch has not been logged because:

Error:   Please supply a summary subject line briefly describing
         your patch.


Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
"---".

Error:   the patch you are submitting has one or more missing or incorrect
         Signed-off-by lines:

         - author signoff <krzkreg@gmail.com> is missing.

         Please see the file Documentation/SubmittingPatches, section 11
         for details on signing off patches.


Please see https://www.armlinux.org.uk/developer/patches/info.shtml
for more information.
-------------

This is unbelievable waste of time. I am not going to use this tracker.
It's huge obstacle and huge waste of submitters time.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> 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,

I tried to submit this series to Russell patch tracker and failed. This
is ridiculous. It's 2024 and instead of normal process, like every other
maintainer, so b4 or Patchwork, we have some unusable system rejecting
standard patches.

First, it depends some weird, duplicated signed-off-by's. Second it
submitting patch-by-patch, all with clicking on some web (!!!) interface.

I did it, clicked 19 times and system was happy... but then on email
said the patches were rejected. Couldn't tell it after submitting first
patch via the web?

That's the response:
-------------
Your patch has not been logged because:

Error:   Please supply a summary subject line briefly describing
         your patch.


Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
"---".

Error:   the patch you are submitting has one or more missing or incorrect
         Signed-off-by lines:

         - author signoff <krzkreg@gmail.com> is missing.

         Please see the file Documentation/SubmittingPatches, section 11
         for details on signing off patches.


Please see https://www.armlinux.org.uk/developer/patches/info.shtml
for more information.
-------------

This is unbelievable waste of time. I am not going to use this tracker.
It's huge obstacle and huge waste of submitters time.

Best regards,
Krzysztof



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof


X-sender: <kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org>
X-Receiver: <martin.weber@secunet.com> ORCPT=rfc822;martin.weber@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAJuYHy0vkvxLoOu7fW2WcxcPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAF4AAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249V2ViZXIgTWFydGluOTU1BQALABcAvgAAALMpUnVJ4+pPsL47FHo+lvtDTj1EQjIsQ049RGF0YWJhc2VzLENOPUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpLENOPUFkbWluaXN0cmF0aXZlIEdyb3VwcyxDTj1zZWN1bmV0LENOPU1pY3Jvc29mdCBFeGNoYW5nZSxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXNlY3VuZXQsREM9ZGUFAA4AEQBACf3SYEkDT461FZzDv+B7BQAdAA8ADAAAAG1ieC1lc3Nlbi0wMQUAPAACAAAPADYAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0Lk1haWxSZWNpcGllbnQuRGlzcGxheU5hbWUPAA0AAABXZWJlciwgTWFydGluBQAMAAIAAAUAbAACAAAFAFgAFwBGAAAAm5gfLS+S/Eug67t9bZZzF0NOPVdlYmVyIE1hcnRpbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAJtXp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgA9AAAAmooAAAUABAAUIAEAAAAYAAAAbWFydGluLndlYmVyQHNlY3VuZXQuY29tBQAGAAIAAQUAKQACAAEPAAkAAABDSUF1ZGl0ZWQCAAEFAAIABwABAAAABQADAAcAAAAAAAUABQACAAEFAGQADwADAAAASHVi
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 19175
Received: from cas-essen-02.secunet.de (10.53.40.202) by
 mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Sat, 30 Mar 2024 13:19:27 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
 (10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Sat, 30 Mar 2024 13:19:27 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id 8E14520322
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:27 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
	MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
	SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5WslB2upGwc9 for <martin.weber@secunet.com>;
	Sat, 30 Mar 2024 13:19:27 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org; receiver=martin.weber@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com D48FF2025D
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id D48FF2025D
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:26 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ny.mirrors.kernel.org (Postfix) with ESMTPS id E49EB1C20DE9
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 12:19:25 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3E9FF38DDC;
	Sat, 30 Mar 2024 12:19:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
X-Original-To: kvm@vger.kernel.org
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6C3B2C68A
	for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711801151; cv=none; b=d6PD/glIB0e+aV4qe4FjDLsN6JJt4dnVYomxLVEDXRi6fJ6zZNDUZ/KV6bTMXyqD9HZIud2rK4IBVnYSGVICsgrmxJswGg4y7+jDJwNyNzo1EotyDaVuk3hz6nln38Tm//4wgHYyBv4odbXJA/sAZLX7tMZtqcU4U/JEFvGEhGQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711801151; c=relaxed/simple;
	bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.41
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-33ed4dd8659so2362095f8f.0
        for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
         bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
         hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
         Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
         QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
         I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711801148; x=1712405948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=nrEPfS8m/1Q8AAv+F6rrqA1pQVMNjiEpRL85VAehzxQcVpnkjpsleMxHXm8kOMRhVV
         iSLZ351P7D13Aivz5ssnue7RQ48O14GQjSFZGI7EXq7HCSMaP2kRO4cWXfEhCzD7zaCI
         GFwvDeB1q0t1XXuvwelGbRPC3OkkEkPw5WtfiuXP8dyyIExRMi5ik4mCewjvn15sKr8k
         Fy8eMWEGOfx2lAIW0lhw8n5ddOnu+QO37mAGtcMgFrbuqOSlBdRowi+QaO9mFlDE5gwY
         Ka/3gffnS/5JYEYvy6uCh5Xz8O3h2Q0UhssghW406N5rrsxWd3OmtJxWWUbm4kpXXgSd
         yAFw==
X-Forwarded-Encrypted: i=1; AJvYcCXH3yO8LUdZmKjRiLMtHQef13pO4YQJjFuFtue8+UJDLWQKRLIgPJ0xNw7FW2Vp2BuWAKUaiz0NkS0/hpSsfxQWyAxU
X-Gm-Message-State: AOJu0Yyu73rgiEIPrgi3GyTka1OR/FGILwL/NmhxKjX4mvZLR6p67Arh
	PYsX00nagjZCFP6nZtT8SPugth6Ot7ziZCiVulQ9IiypG3IFezpdXeDgLTZAP6A=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
        by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: kvm@vger.kernel.org
List-Id: <kvm.vger.kernel.org>
List-Subscribe: <mailto:kvm+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:kvm+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
 amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
 Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
 James Clark <james.clark@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
 Alexandre Torgue <alexandre.torgue@foss.st.com>,
 Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
 <andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
 Dmitry Torokhov <dmitry.torokhov@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
 Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
 linux-arm-kernel@lists.infradead.org,
 linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
 linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
 linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
 <3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
 <f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
 <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
 xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
 JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
 gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
 J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
 NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
 BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
 vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
 Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
 TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
 S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
 m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
 HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
 XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
 mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
 v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
 cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
 rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
 qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
 aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
 gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
 dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
 NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
 hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
 oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
 H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
 yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
 5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
 5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
 +HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
 FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
 5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
 DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
 oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
 59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
 Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
 qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
 /oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
 qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
 EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
 KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
 fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
 D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:27.6209
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: cb55eba9-97a5-4e15-7fd3-08dc50b3a4ee
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-dresden-01.secunet.de:TOTAL-HUB=0.422|SMR=0.342(SMRDE=0.035|SMRC=0.307(SMRCL=0.101|X-SMRCR=0.306))|CAT=0.078(CATOS=0.012
 (CATSM=0.012(CATSM-Malware
 Agent=0.011))|CATRESL=0.039(CATRESLP2R=0.036)|CATORES=0.024
 (CATRS=0.024(CATRS-Index Routing Agent=0.023)));2024-03-30T12:19:28.067Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 13859
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.024|SMR=0.007(SMRPI=0.004(SMRPI-FrontendProxyAgent=0.004))|SMS=0.018
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAVsDAAAPAAADH4sIAAAAAAAEAIVTzY8TNxT3bjL5GIhaVT
 30wOGJCyBFYRugSCuxaOmlaIVAcKg4OjOejLvOOLI9ibJ/Oqf+/DyT
 hW1LEysZP7/3+3h+82XyvqHly6dnz54uz5bP6dez8+VyTp/am/Za0x
 V9sK2xXtHe2aDOZ/kFfZt/9uL8xcs5Xbmbg78JtqIre2Ps3qP4WPKP
 GnA8/x4HKv7Qt5gcSeEI9NsRaAmgZ/9Hjqp3yq11s+52r9Kn210aQ1
 XrQq0cbWUoauWpVFvVlGQbQpgq7XwguVnJlDCPUacq6xRtjZJQLovr
 Dk6iLtTak6/hqqS1pZ2WgFIUnFKLr7xcov5gW5Irg0NLW2d3ugQY+c
 CxlZNNUdNehzpSgqcXaJsi1W5bYyIad/ktlbZdBfzvNVytFG2ScVa0
 QBz/zXWyUlhQrS3AQu1su67pY+u9MmbR411E0g3pJop72Dt4SNE8va
 Y/FdVyp6ioZbMGTGE3kardcgX6VqBBXq/r0IGheE77WkdL3JvCNpXR
 RTg6PGIxxePaOqdX5vDktmvs8zOMb5Rs7gDcEsaDnXJeW9a+NTLgtj
 ZUOo0wpFvcKKDiOH9WfpEeL6iId6kDxeuzZqfiLZzTXy2uv3R2Swu7
 b5Tr0um9g51oM3qJnVbs4Xeo+JRUdG4ey9hkdSAJV05JYw7U2CiAZF
 WpIqiSVgcuxgyAc9ONkHIa5XgK7sDXaEmWJUz6J6gMmFjURJhVFN7T
 mTiDuIPLd28u5zx938rq5nCWv32EKemnjifxzuSBr1KYuDg6exnfi0
 rJTm03LY/8LOepBCzegqjSH3xQG2Z4o9A6p9bSlX4+y796o+NXiFMx
 OD0RORYexGB4kmUnIhNY45EYn4jTsZhkIv9O2lTkWJm49y85d3HuIz
 4VP/9XZg81G4sHAzFECRbKkYNtJkZDkaU0BAciRxCRYwJvf+wfMgRR
 DuoRa+DaESJ44IQZjhDB7zF5yNtElBZr+CklnHbIOI2M6TSxJwFT8Q
 NOM14TMU1ECXYifkmqOD6ChZw7hu2IOzMQ93sWtOgeswNnBlJEEiZT
 5GMxTezYch/GE470XF1D0i+SuXCc1CaKIUMltCHrxBG2x14xY7w1BB
 M4JCVTI9Y2xk39DXCU4RO5BgAAAQKrDDw/eG1sIHZlcnNpb249IjEu
 MCIgZW5jb2Rpbmc9InV0Zi0xNiI/Pg0KPFRhc2tTZXQ+DQogIDxWZX
 JzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VGFza3M+DQogICAg
 PFRhc2sgU3RhcnRJbmRleD0iNjg3Ij4NCiAgICAgIDxUYXNrU3RyaW
 5nPiZndDsmZ3Q7IFlvdSBtZWFuIGNvbmZsaWN0IHdpdGggIGNvcmVz
 aWdodCBjb252ZXJzaW9uIHRvIHBsYXRmb3JtIGRyaXZlcj88L1Rhc2
 tTdHJpbmc+DQogICAgICA8QXNzaWduZWVzPg0KICAgICAgICA8RW1h
 aWxVc2VyIElkPSJzdXp1a2kucG91bG9zZUBhcm0uY29tIj5TdXp1a2
 kgSyBQb3Vsb3NlPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVz
 ZXIgSWQ9ImxpbnV4QGFybWxpbnV4Lm9yZy51ayI+UnVzc2VsbCBLaW
 5nPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im1p
 a2UubGVhY2hAbGluYXJvLm9yZyI+TWlrZSBMZWFjaDwvRW1haWxVc2
 VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJqYW1lcy5jbGFya0Bh
 cm0uY29tIj5KYW1lcyBDbGFyazwvRW1haWxVc2VyPg0KICAgICAgIC
 A8RW1haWxVc2VyIElkPSJhbGV4YW5kZXIuc2hpc2hraW5AbGludXgu
 aW50ZWwuY29tIj5BbGV4YW5kZXIgU2hpc2hraW48L0VtYWlsVXNlcj
 4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibWNvcXVlbGluLnN0bTMy
 QGdtYWlsLmNvbSI+TWF4aW1lIENvcXVlbGluPC9FbWFpbFVzZXI+DQ
 ogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXhhbmRyZS50b3JndWVA
 Zm9zcy5zdC5jb20iPkFsZXhhbmRyZSBUb3JndWU8L0VtYWlsVXNlcj
 4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibGludXMud2FsbGVpakBs
 aW5hcm8ub3JnIj5MaW51cyBXYWxsZWlqPC9FbWFpbFVzZXI+DQogIC
 AgICAgIDxFbWFpbFVzZXIgSWQ9ImFuZGkuc2h5dGlAa2VybmVsLm9y
 ZyI+QW5kaSBTaHl0aTwvRW1haWxVc2VyPg0KICAgICAgICA8RW1haW
 xVc2VyIElkPSJvbGl2aWFAc2VsZW5pYy5jb20iPk9saXZpYSBNYWNr
 YWxsPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im
 hlcmJlcnRAZ29uZG9yLmFwYW5hLm9yZy5hdSI+SGVyYmVydCBYdTwv
 RW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJ2a291bE
 BrZXJuZWwub3JnIj5WaW5vZCBLb3VsPC9FbWFpbFVzZXI+DQogICAg
 ICAgIDxFbWFpbFVzZXIgSWQ9ImRtaXRyeS50b3Jva2hvdkBnbWFpbC
 5jb20iPkRtaXRyeSBUb3Jva2hvdjwvRW1haWxVc2VyPg0KICAgICAg
 ICA8RW1haWxVc2VyIElkPSJtaXF1ZWwucmF5bmFsQGJvb3RsaW4uY2
 9tIj5NaXF1ZWwgUmF5bmFsPC9FbWFpbFVzZXI+DQogICAgICAgIDxF
 bWFpbFVzZXIgSWQ9Im1pY2hhbC5zaW1la0BhbWQuY29tIj5NaWNoYW
 wgU2ltZWs8L0VtYWlsVXNlcj4NCiAgICAgICAgPEVtYWlsVXNlciBJ
 ZD0iZXJpYy5hdWdlckByZWRoYXQuY29tIj5FcmljIEF1Z2VyPC9FbW
 FpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXgud2ls
 bGlhbXNvbkByZWRoYXQuY29tIj5BbGV4IFdpbGxpYW1zb248L0VtYW
 lsVXNlcj4NCiAgICAgIDwvQXNzaWduZWVzPg0KICAgIDwvVGFzaz4N
 CiAgPC9UYXNrcz4NCjwvVGFza1NldD4BDs8BUmV0cmlldmVyT3Blcm
 F0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3REb2NQ
 YXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVyYXRvci
 wxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwx
 MCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMS
 wwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE0
X-MS-Exchange-Forest-IndexAgent: 1 2664
X-MS-Exchange-Forest-EmailMessageHash: CDDC1A99
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof


X-sender: <kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org>
X-Receiver: <martin.weber@secunet.com> ORCPT=rfc822;martin.weber@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAJuYHy0vkvxLoOu7fW2WcxcPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAF4AAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249V2ViZXIgTWFydGluOTU1BQALABcAvgAAALMpUnVJ4+pPsL47FHo+lvtDTj1EQjIsQ049RGF0YWJhc2VzLENOPUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpLENOPUFkbWluaXN0cmF0aXZlIEdyb3VwcyxDTj1zZWN1bmV0LENOPU1pY3Jvc29mdCBFeGNoYW5nZSxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXNlY3VuZXQsREM9ZGUFAA4AEQBACf3SYEkDT461FZzDv+B7BQAdAA8ADAAAAG1ieC1lc3Nlbi0wMQUAPAACAAAPADYAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0Lk1haWxSZWNpcGllbnQuRGlzcGxheU5hbWUPAA0AAABXZWJlciwgTWFydGluBQAMAAIAAAUAbAACAAAFAFgAFwBGAAAAm5gfLS+S/Eug67t9bZZzF0NOPVdlYmVyIE1hcnRpbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAJtXp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgA9AAAAmooAAAUABAAUIAEAAAAYAAAAbWFydGluLndlYmVyQHNlY3VuZXQuY29tBQAGAAIAAQUAKQACAAEPAAkAAABDSUF1ZGl0ZWQCAAEFAAIABwABAAAABQADAAcAAAAAAAUABQACAAEFAGQADwADAAAASHVi
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 19175
Received: from cas-essen-02.secunet.de (10.53.40.202) by
 mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Sat, 30 Mar 2024 13:19:27 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
 (10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Sat, 30 Mar 2024 13:19:27 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id 8E14520322
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:27 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
	MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
	SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5WslB2upGwc9 for <martin.weber@secunet.com>;
	Sat, 30 Mar 2024 13:19:27 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org; receiver=martin.weber@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com D48FF2025D
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id D48FF2025D
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:26 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ny.mirrors.kernel.org (Postfix) with ESMTPS id E49EB1C20DE9
	for <martin.weber@secunet.com>; Sat, 30 Mar 2024 12:19:25 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3E9FF38DDC;
	Sat, 30 Mar 2024 12:19:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
X-Original-To: kvm@vger.kernel.org
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6C3B2C68A
	for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711801151; cv=none; b=d6PD/glIB0e+aV4qe4FjDLsN6JJt4dnVYomxLVEDXRi6fJ6zZNDUZ/KV6bTMXyqD9HZIud2rK4IBVnYSGVICsgrmxJswGg4y7+jDJwNyNzo1EotyDaVuk3hz6nln38Tm//4wgHYyBv4odbXJA/sAZLX7tMZtqcU4U/JEFvGEhGQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711801151; c=relaxed/simple;
	bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.41
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-33ed4dd8659so2362095f8f.0
        for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
         bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
         hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
         Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
         QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
         I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711801148; x=1712405948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=nrEPfS8m/1Q8AAv+F6rrqA1pQVMNjiEpRL85VAehzxQcVpnkjpsleMxHXm8kOMRhVV
         iSLZ351P7D13Aivz5ssnue7RQ48O14GQjSFZGI7EXq7HCSMaP2kRO4cWXfEhCzD7zaCI
         GFwvDeB1q0t1XXuvwelGbRPC3OkkEkPw5WtfiuXP8dyyIExRMi5ik4mCewjvn15sKr8k
         Fy8eMWEGOfx2lAIW0lhw8n5ddOnu+QO37mAGtcMgFrbuqOSlBdRowi+QaO9mFlDE5gwY
         Ka/3gffnS/5JYEYvy6uCh5Xz8O3h2Q0UhssghW406N5rrsxWd3OmtJxWWUbm4kpXXgSd
         yAFw==
X-Forwarded-Encrypted: i=1; AJvYcCXH3yO8LUdZmKjRiLMtHQef13pO4YQJjFuFtue8+UJDLWQKRLIgPJ0xNw7FW2Vp2BuWAKUaiz0NkS0/hpSsfxQWyAxU
X-Gm-Message-State: AOJu0Yyu73rgiEIPrgi3GyTka1OR/FGILwL/NmhxKjX4mvZLR6p67Arh
	PYsX00nagjZCFP6nZtT8SPugth6Ot7ziZCiVulQ9IiypG3IFezpdXeDgLTZAP6A=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
        by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: kvm@vger.kernel.org
List-Id: <kvm.vger.kernel.org>
List-Subscribe: <mailto:kvm+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:kvm+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
 amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
 Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
 James Clark <james.clark@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
 Alexandre Torgue <alexandre.torgue@foss.st.com>,
 Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
 <andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
 Dmitry Torokhov <dmitry.torokhov@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
 Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
 linux-arm-kernel@lists.infradead.org,
 linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
 linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
 linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
 <3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
 <f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
 <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
 xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
 JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
 gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
 J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
 NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
 BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
 vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
 Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
 TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
 S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
 m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
 HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
 XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
 mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
 v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
 cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
 rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
 qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
 aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
 gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
 dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
 NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
 hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
 oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
 H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
 yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
 5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
 5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
 +HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
 FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
 5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
 DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
 oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
 59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
 Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
 qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
 /oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
 qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
 EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
 KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
 fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
 D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:27.6209
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: cb55eba9-97a5-4e15-7fd3-08dc50b3a4ee
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-dresden-01.secunet.de:TOTAL-HUB=0.422|SMR=0.342(SMRDE=0.035|SMRC=0.307(SMRCL=0.101|X-SMRCR=0.306))|CAT=0.078(CATOS=0.012
 (CATSM=0.012(CATSM-Malware
 Agent=0.011))|CATRESL=0.039(CATRESLP2R=0.036)|CATORES=0.024
 (CATRS=0.024(CATRS-Index Routing Agent=0.023)));2024-03-30T12:19:28.067Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 13859
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.024|SMR=0.007(SMRPI=0.004(SMRPI-FrontendProxyAgent=0.004))|SMS=0.018
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAVsDAAAPAAADH4sIAAAAAAAEAIVTzY8TNxT3bjL5GIhaVT
 30wOGJCyBFYRugSCuxaOmlaIVAcKg4OjOejLvOOLI9ibJ/Oqf+/DyT
 hW1LEysZP7/3+3h+82XyvqHly6dnz54uz5bP6dez8+VyTp/am/Za0x
 V9sK2xXtHe2aDOZ/kFfZt/9uL8xcs5Xbmbg78JtqIre2Ps3qP4WPKP
 GnA8/x4HKv7Qt5gcSeEI9NsRaAmgZ/9Hjqp3yq11s+52r9Kn210aQ1
 XrQq0cbWUoauWpVFvVlGQbQpgq7XwguVnJlDCPUacq6xRtjZJQLovr
 Dk6iLtTak6/hqqS1pZ2WgFIUnFKLr7xcov5gW5Irg0NLW2d3ugQY+c
 CxlZNNUdNehzpSgqcXaJsi1W5bYyIad/ktlbZdBfzvNVytFG2ScVa0
 QBz/zXWyUlhQrS3AQu1su67pY+u9MmbR411E0g3pJop72Dt4SNE8va
 Y/FdVyp6ioZbMGTGE3kardcgX6VqBBXq/r0IGheE77WkdL3JvCNpXR
 RTg6PGIxxePaOqdX5vDktmvs8zOMb5Rs7gDcEsaDnXJeW9a+NTLgtj
 ZUOo0wpFvcKKDiOH9WfpEeL6iId6kDxeuzZqfiLZzTXy2uv3R2Swu7
 b5Tr0um9g51oM3qJnVbs4Xeo+JRUdG4ey9hkdSAJV05JYw7U2CiAZF
 WpIqiSVgcuxgyAc9ONkHIa5XgK7sDXaEmWJUz6J6gMmFjURJhVFN7T
 mTiDuIPLd28u5zx938rq5nCWv32EKemnjifxzuSBr1KYuDg6exnfi0
 rJTm03LY/8LOepBCzegqjSH3xQG2Z4o9A6p9bSlX4+y796o+NXiFMx
 OD0RORYexGB4kmUnIhNY45EYn4jTsZhkIv9O2lTkWJm49y85d3HuIz
 4VP/9XZg81G4sHAzFECRbKkYNtJkZDkaU0BAciRxCRYwJvf+wfMgRR
 DuoRa+DaESJ44IQZjhDB7zF5yNtElBZr+CklnHbIOI2M6TSxJwFT8Q
 NOM14TMU1ECXYifkmqOD6ChZw7hu2IOzMQ93sWtOgeswNnBlJEEiZT
 5GMxTezYch/GE470XF1D0i+SuXCc1CaKIUMltCHrxBG2x14xY7w1BB
 M4JCVTI9Y2xk39DXCU4RO5BgAAAQKrDDw/eG1sIHZlcnNpb249IjEu
 MCIgZW5jb2Rpbmc9InV0Zi0xNiI/Pg0KPFRhc2tTZXQ+DQogIDxWZX
 JzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VGFza3M+DQogICAg
 PFRhc2sgU3RhcnRJbmRleD0iNjg3Ij4NCiAgICAgIDxUYXNrU3RyaW
 5nPiZndDsmZ3Q7IFlvdSBtZWFuIGNvbmZsaWN0IHdpdGggIGNvcmVz
 aWdodCBjb252ZXJzaW9uIHRvIHBsYXRmb3JtIGRyaXZlcj88L1Rhc2
 tTdHJpbmc+DQogICAgICA8QXNzaWduZWVzPg0KICAgICAgICA8RW1h
 aWxVc2VyIElkPSJzdXp1a2kucG91bG9zZUBhcm0uY29tIj5TdXp1a2
 kgSyBQb3Vsb3NlPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVz
 ZXIgSWQ9ImxpbnV4QGFybWxpbnV4Lm9yZy51ayI+UnVzc2VsbCBLaW
 5nPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im1p
 a2UubGVhY2hAbGluYXJvLm9yZyI+TWlrZSBMZWFjaDwvRW1haWxVc2
 VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJqYW1lcy5jbGFya0Bh
 cm0uY29tIj5KYW1lcyBDbGFyazwvRW1haWxVc2VyPg0KICAgICAgIC
 A8RW1haWxVc2VyIElkPSJhbGV4YW5kZXIuc2hpc2hraW5AbGludXgu
 aW50ZWwuY29tIj5BbGV4YW5kZXIgU2hpc2hraW48L0VtYWlsVXNlcj
 4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibWNvcXVlbGluLnN0bTMy
 QGdtYWlsLmNvbSI+TWF4aW1lIENvcXVlbGluPC9FbWFpbFVzZXI+DQ
 ogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXhhbmRyZS50b3JndWVA
 Zm9zcy5zdC5jb20iPkFsZXhhbmRyZSBUb3JndWU8L0VtYWlsVXNlcj
 4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibGludXMud2FsbGVpakBs
 aW5hcm8ub3JnIj5MaW51cyBXYWxsZWlqPC9FbWFpbFVzZXI+DQogIC
 AgICAgIDxFbWFpbFVzZXIgSWQ9ImFuZGkuc2h5dGlAa2VybmVsLm9y
 ZyI+QW5kaSBTaHl0aTwvRW1haWxVc2VyPg0KICAgICAgICA8RW1haW
 xVc2VyIElkPSJvbGl2aWFAc2VsZW5pYy5jb20iPk9saXZpYSBNYWNr
 YWxsPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im
 hlcmJlcnRAZ29uZG9yLmFwYW5hLm9yZy5hdSI+SGVyYmVydCBYdTwv
 RW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJ2a291bE
 BrZXJuZWwub3JnIj5WaW5vZCBLb3VsPC9FbWFpbFVzZXI+DQogICAg
 ICAgIDxFbWFpbFVzZXIgSWQ9ImRtaXRyeS50b3Jva2hvdkBnbWFpbC
 5jb20iPkRtaXRyeSBUb3Jva2hvdjwvRW1haWxVc2VyPg0KICAgICAg
 ICA8RW1haWxVc2VyIElkPSJtaXF1ZWwucmF5bmFsQGJvb3RsaW4uY2
 9tIj5NaXF1ZWwgUmF5bmFsPC9FbWFpbFVzZXI+DQogICAgICAgIDxF
 bWFpbFVzZXIgSWQ9Im1pY2hhbC5zaW1la0BhbWQuY29tIj5NaWNoYW
 wgU2ltZWs8L0VtYWlsVXNlcj4NCiAgICAgICAgPEVtYWlsVXNlciBJ
 ZD0iZXJpYy5hdWdlckByZWRoYXQuY29tIj5FcmljIEF1Z2VyPC9FbW
 FpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXgud2ls
 bGlhbXNvbkByZWRoYXQuY29tIj5BbGV4IFdpbGxpYW1zb248L0VtYW
 lsVXNlcj4NCiAgICAgIDwvQXNzaWduZWVzPg0KICAgIDwvVGFzaz4N
 CiAgPC9UYXNrcz4NCjwvVGFza1NldD4BDs8BUmV0cmlldmVyT3Blcm
 F0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3REb2NQ
 YXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVyYXRvci
 wxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwx
 MCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMS
 wwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE0
X-MS-Exchange-Forest-IndexAgent: 1 2664
X-MS-Exchange-Forest-EmailMessageHash: CDDC1A99
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof


X-sender: <linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-essen-01.secunet.de
X-ExtendedProps: BQBjAAoAh4ymlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.197
X-EndOfInjectedXHeaders: 14356
Received: from mbx-essen-01.secunet.de (10.53.40.197) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Sat, 30 Mar 2024 13:19:38 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Sat, 30 Mar 2024 13:19:38 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id B23AF20322
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
	MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
	SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 1O3XCRA_zcxq for <steffen.klassert@secunet.com>;
	Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 116D82025D
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 116D82025D
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ny.mirrors.kernel.org (Postfix) with ESMTPS id D1F5C1C21191
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 12:19:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3604138FA0;
	Sat, 30 Mar 2024 12:19:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CAFA2BB14
	for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711801151; cv=none; b=ixWxAGCKInnwN9unufhlFm4eAhpYUIq+/6LEl1krKKFhGpqzIW5e+Y9A3K0uVDPfwZRETY/bp/yIu8C4oSkudbcxI9GyR73I1UGo4plKoJMQbj+1vTT9AsLo1kCO6VLsJHW4NCEw/RaL21NQSxLjgXQetxtfysU8jtSss5eZpOA=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711801151; c=relaxed/simple;
	bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.42
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-33ddd1624beso1664582f8f.1
        for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
         bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
         hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
         Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
         QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
         I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711801148; x=1712405948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=Uyrhl0iS+HHVPcHD9JlplLUc3LKvZC+9zSGrS2p4ngVUqA6Loz5ajRMtwiNehHz8ce
         7ZWBmNfUzCuFmBy1kU8kDWGP2aTESYuKYABKEI1oUkOKzhtQJfLz7u2czRFbTK/5KxCT
         X0x4hsD7Xbxk4oj6Lb+MYe4iq+Ybpt9ja83fE4NRPcMWBltsCZ/RQqbWpPlry1/K+YsV
         WSChQjhDeFn3PozhiA4eVndXL3m5YAy/R9mJqfnGg7ztADohvFX02HnZbGAm5bZubyhg
         IKaaInkPEzpN+ptYDCcu/nzP6K+caGfu3zhYn/Jtc5zC9qnAz+3pvhkSPaPrss1uFl7/
         2ybw==
X-Gm-Message-State: AOJu0YxZ4OKcnV48ikILJpVo5WNPXxvrQrDAoY76tNm4EwGlI8iPL9Bi
	8IxHqIZkR/GrquTBwdosOuZ+cANUxsESnEUWp8mQ1Ss2/sTp/7VUYlbF+HKGiLQ=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
        by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
 amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
 Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
 James Clark <james.clark@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
 Alexandre Torgue <alexandre.torgue@foss.st.com>,
 Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
 <andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
 Dmitry Torokhov <dmitry.torokhov@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
 Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
 linux-arm-kernel@lists.infradead.org,
 linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
 linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
 linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
 <3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
 <f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
 <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
 xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
 JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
 gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
 J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
 NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
 BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
 vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
 Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
 TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
 S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
 m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
 HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
 XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
 mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
 v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
 cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
 rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
 qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
 aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
 gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
 dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
 NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
 hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
 oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
 H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
 yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
 5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
 5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
 +HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
 FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
 5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
 DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
 oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
 59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
 Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
 qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
 /oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
 qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
 EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
 KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
 fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
 D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:38.7569
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: 9ded166d-4895-4afd-90c2-08dc50b3ab91
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=cas-essen-01.secunet.de:TOTAL-FE=0.004|SMR=0.004(SMRPI=0.002(SMRPI-FrontendProxyAgent=0.002));2024-03-30T12:19:38.760Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 13811
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof


X-sender: <linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-essen-01.secunet.de
X-ExtendedProps: BQBjAAoAh4ymlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.197
X-EndOfInjectedXHeaders: 14356
Received: from mbx-essen-01.secunet.de (10.53.40.197) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Sat, 30 Mar 2024 13:19:38 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Sat, 30 Mar 2024 13:19:38 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id B23AF20322
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
	MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
	SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 1O3XCRA_zcxq for <steffen.klassert@secunet.com>;
	Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 116D82025D
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 116D82025D
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ny.mirrors.kernel.org (Postfix) with ESMTPS id D1F5C1C21191
	for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 12:19:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3604138FA0;
	Sat, 30 Mar 2024 12:19:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CAFA2BB14
	for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711801151; cv=none; b=ixWxAGCKInnwN9unufhlFm4eAhpYUIq+/6LEl1krKKFhGpqzIW5e+Y9A3K0uVDPfwZRETY/bp/yIu8C4oSkudbcxI9GyR73I1UGo4plKoJMQbj+1vTT9AsLo1kCO6VLsJHW4NCEw/RaL21NQSxLjgXQetxtfysU8jtSss5eZpOA=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711801151; c=relaxed/simple;
	bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.42
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-33ddd1624beso1664582f8f.1
        for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
         bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
         hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
         Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
         QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
         I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711801148; x=1712405948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
        b=Uyrhl0iS+HHVPcHD9JlplLUc3LKvZC+9zSGrS2p4ngVUqA6Loz5ajRMtwiNehHz8ce
         7ZWBmNfUzCuFmBy1kU8kDWGP2aTESYuKYABKEI1oUkOKzhtQJfLz7u2czRFbTK/5KxCT
         X0x4hsD7Xbxk4oj6Lb+MYe4iq+Ybpt9ja83fE4NRPcMWBltsCZ/RQqbWpPlry1/K+YsV
         WSChQjhDeFn3PozhiA4eVndXL3m5YAy/R9mJqfnGg7ztADohvFX02HnZbGAm5bZubyhg
         IKaaInkPEzpN+ptYDCcu/nzP6K+caGfu3zhYn/Jtc5zC9qnAz+3pvhkSPaPrss1uFl7/
         2ybw==
X-Gm-Message-State: AOJu0YxZ4OKcnV48ikILJpVo5WNPXxvrQrDAoY76tNm4EwGlI8iPL9Bi
	8IxHqIZkR/GrquTBwdosOuZ+cANUxsESnEUWp8mQ1Ss2/sTp/7VUYlbF+HKGiLQ=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
        by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
 amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
 Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
 James Clark <james.clark@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
 Alexandre Torgue <alexandre.torgue@foss.st.com>,
 Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
 <andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
 Dmitry Torokhov <dmitry.torokhov@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
 Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
 linux-arm-kernel@lists.infradead.org,
 linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
 linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
 linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
 <3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
 <f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
 <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
 xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
 JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
 gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
 J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
 NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
 BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
 vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
 Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
 TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
 S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
 m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
 HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
 XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
 mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
 v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
 cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
 rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
 qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
 aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
 gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
 dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
 NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
 hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
 oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
 H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
 yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
 5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
 5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
 +HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
 FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
 5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
 DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
 oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
 59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
 Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
 qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
 /oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
 qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
 EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
 KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
 fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
 D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:38.7569
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: 9ded166d-4895-4afd-90c2-08dc50b3ab91
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=cas-essen-01.secunet.de:TOTAL-FE=0.004|SMR=0.004(SMRPI=0.002(SMRPI-FrontendProxyAgent=0.002));2024-03-30T12:19:38.760Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 13811
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy

On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with  coresight conversion to platform driver? Worst
> 
> Yes.
> 
>> case it is solveable: just drop .owner.
> 
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.

I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.

Best regards,
Krzysztof



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
> 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.
> 
> [...]

Applied, thanks!

[01/19] amba: store owner from modules with amba_driver_register()
        (no commit info)
[02/19] coresight: cti: drop owner assignment
        (no commit info)
[03/19] coresight: catu: drop owner assignment
        (no commit info)
[04/19] coresight: etm3x: drop owner assignment
        (no commit info)
[05/19] coresight: etm4x: drop owner assignment
        (no commit info)
[06/19] coresight: funnel: drop owner assignment
        (no commit info)
[07/19] coresight: replicator: drop owner assignment
        (no commit info)
[08/19] coresight: etb10: drop owner assignment
        (no commit info)
[09/19] coresight: stm: drop owner assignment
        (no commit info)
[10/19] coresight: tmc: drop owner assignment
        (no commit info)
[11/19] coresight: tpda: drop owner assignment
        (no commit info)
[12/19] coresight: tpdm: drop owner assignment
        (no commit info)
[13/19] coresight: tpiu: drop owner assignment
        (no commit info)
[14/19] i2c: nomadik: drop owner assignment
        (no commit info)
[15/19] hwrng: nomadik: drop owner assignment
        (no commit info)
[16/19] dmaengine: pl330: drop owner assignment
        (no commit info)
[17/19] Input: ambakmi - drop owner assignment
        (no commit info)
[18/19] memory: pl353-smc: drop owner assignment
        (no commit info)
[19/19] vfio: amba: drop owner assignment
        (no commit info)

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
> 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.
> 
> [...]

Applied, thanks!

[01/19] amba: store owner from modules with amba_driver_register()
        (no commit info)
[02/19] coresight: cti: drop owner assignment
        (no commit info)
[03/19] coresight: catu: drop owner assignment
        (no commit info)
[04/19] coresight: etm3x: drop owner assignment
        (no commit info)
[05/19] coresight: etm4x: drop owner assignment
        (no commit info)
[06/19] coresight: funnel: drop owner assignment
        (no commit info)
[07/19] coresight: replicator: drop owner assignment
        (no commit info)
[08/19] coresight: etb10: drop owner assignment
        (no commit info)
[09/19] coresight: stm: drop owner assignment
        (no commit info)
[10/19] coresight: tmc: drop owner assignment
        (no commit info)
[11/19] coresight: tpda: drop owner assignment
        (no commit info)
[12/19] coresight: tpdm: drop owner assignment
        (no commit info)
[13/19] coresight: tpiu: drop owner assignment
        (no commit info)
[14/19] i2c: nomadik: drop owner assignment
        (no commit info)
[15/19] hwrng: nomadik: drop owner assignment
        (no commit info)
[16/19] dmaengine: pl330: drop owner assignment
        (no commit info)
[17/19] Input: ambakmi - drop owner assignment
        (no commit info)
[18/19] memory: pl353-smc: drop owner assignment
        (no commit info)
[19/19] vfio: amba: drop owner assignment
        (no commit info)

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

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
> 
> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>> 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.
>>
>> [...]
> 
> Applied, thanks!
> 
> [01/19] amba: store owner from modules with amba_driver_register()
>         (no commit info)

Patchset applied here:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
> 
> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>> 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.
>>
>> [...]
> 
> Applied, thanks!
> 
> [01/19] amba: store owner from modules with amba_driver_register()
>         (no commit info)

Patchset applied here:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > 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,
> 
> I tried to submit this series to Russell patch tracker and failed. This
> is ridiculous. It's 2024 and instead of normal process, like every other
> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> standard patches.

Sorry but no. Stop being offensive.

> First, it depends some weird, duplicated signed-off-by's.

Eh? There is no such logic in there.

> Second it > submitting patch-by-patch, all with clicking on some web
> (!!!) interface.

Again, no it doesn't, and you're just throwing crap out because you
failed. Unlike most of the "normal" processes, the patch system allows
you to submit both by *email* and also by *web* for those cases where
the emails get screwed up by ones company mail server. That's why the
web interface exists - to give people *flexibility*.

The fact is, the web interface is merely a front end interface that
generates an email and submits it in the usual way by email - an
email that you can perfectly well generate that is *very* close to
the standard email that git format-patch generates.

The *only* difference is that the patch system wants a KernelVersion:
tag in the email _somewhere_ and it doesn't matter where it appears.
Git even has support to do this.

  git format-patch --add-header="KernelVersion: $foo"

Why does it want the kernel version? Because when we were running 2.4
and 2.5 kernel versions in parallel, it was important to know which
tree the patch was being submitted for. It has continued to be required
because it means when there's problems applying a patch, it gives me
the additional information about the base used for the patch (and it
keeps on being useful to have.)

> That's the response:
> -------------
> Your patch has not been logged because:
> 
> Error:   Please supply a summary subject line briefly describing
>          your patch.
> 
> 
> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> "---".
> 
> Error:   the patch you are submitting has one or more missing or incorrect
>          Signed-off-by lines:
> 
>          - author signoff <krzkreg@gmail.com> is missing.
> 
>          Please see the file Documentation/SubmittingPatches, section 11
>          for details on signing off patches.

Lots of people use it without a problem. I've just run the parser
through its offline tests, and it parses email content correctly.
I've no idea what you're doing wrong, but it looks like something
pretty serious if it didn't parse the subject line.

Rather than getting stressed about it, why don't you send me an email
the first time something goes wrong so I can investigate, turn on
debugging to capture the problem email?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > 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,
> 
> I tried to submit this series to Russell patch tracker and failed. This
> is ridiculous. It's 2024 and instead of normal process, like every other
> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> standard patches.

Sorry but no. Stop being offensive.

> First, it depends some weird, duplicated signed-off-by's.

Eh? There is no such logic in there.

> Second it > submitting patch-by-patch, all with clicking on some web
> (!!!) interface.

Again, no it doesn't, and you're just throwing crap out because you
failed. Unlike most of the "normal" processes, the patch system allows
you to submit both by *email* and also by *web* for those cases where
the emails get screwed up by ones company mail server. That's why the
web interface exists - to give people *flexibility*.

The fact is, the web interface is merely a front end interface that
generates an email and submits it in the usual way by email - an
email that you can perfectly well generate that is *very* close to
the standard email that git format-patch generates.

The *only* difference is that the patch system wants a KernelVersion:
tag in the email _somewhere_ and it doesn't matter where it appears.
Git even has support to do this.

  git format-patch --add-header="KernelVersion: $foo"

Why does it want the kernel version? Because when we were running 2.4
and 2.5 kernel versions in parallel, it was important to know which
tree the patch was being submitted for. It has continued to be required
because it means when there's problems applying a patch, it gives me
the additional information about the base used for the patch (and it
keeps on being useful to have.)

> That's the response:
> -------------
> Your patch has not been logged because:
> 
> Error:   Please supply a summary subject line briefly describing
>          your patch.
> 
> 
> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> "---".
> 
> Error:   the patch you are submitting has one or more missing or incorrect
>          Signed-off-by lines:
> 
>          - author signoff <krzkreg@gmail.com> is missing.
> 
>          Please see the file Documentation/SubmittingPatches, section 11
>          for details on signing off patches.

Lots of people use it without a problem. I've just run the parser
through its offline tests, and it parses email content correctly.
I've no idea what you're doing wrong, but it looks like something
pretty serious if it didn't parse the subject line.

Rather than getting stressed about it, why don't you send me an email
the first time something goes wrong so I can investigate, turn on
debugging to capture the problem email?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> > On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > > 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,
> > 
> > I tried to submit this series to Russell patch tracker and failed. This
> > is ridiculous. It's 2024 and instead of normal process, like every other
> > maintainer, so b4 or Patchwork, we have some unusable system rejecting
> > standard patches.
> 
> Sorry but no. Stop being offensive.
> 
> > First, it depends some weird, duplicated signed-off-by's.
> 
> Eh? There is no such logic in there.
> 
> > Second it > submitting patch-by-patch, all with clicking on some web
> > (!!!) interface.
> 
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where
> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.
> 
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
> 
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
> 
>   git format-patch --add-header="KernelVersion: $foo"
> 
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required
> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
> 
> > That's the response:
> > -------------
> > Your patch has not been logged because:
> > 
> > Error:   Please supply a summary subject line briefly describing
> >          your patch.
> > 
> > 
> > Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> > "---".
> > 
> > Error:   the patch you are submitting has one or more missing or incorrect
> >          Signed-off-by lines:
> > 
> >          - author signoff <krzkreg@gmail.com> is missing.
> > 
> >          Please see the file Documentation/SubmittingPatches, section 11
> >          for details on signing off patches.
> 
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
> 
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?

... and I'll also point out one of the biggest problems is people.
People who think it's more complex than it is, or who can't read
instructions.

For example, trying to tell people to use the standard format subject
line:

	[PATCH ...] blah

has proven to be hopeless - unless one states to them the exact
sequence of keys on their keyboard to press - yes, it *really* takes
that patronising level to get everyone to understand. If one tries to
do it any other way, then you get stuff like:

	"[PATCH ...] ..."

with the quotes. Or some other stupid variation.

The patch system is as forgiving as possible. It takes standard git
formatted patches (with the exception of wanting an additional tag).

It is possible that bugs creep in - particularly when Debian updates
get applied and change the way Perl works, but I don't think that's
what has happened with your situation.

I _guess_ you're putting the entire email-like output from git
format-patch as the patch file. That won't work - that isn't a "patch
file", that is an email/email template, and the patch system will
attempt to parse that as the patch itself.

I suppose you term "patch" to be the email as well, rather than what
I interpret it to be, which is only the output of "diff" - call me
old fashioned but that's what a patch file used to be before the
waters got muddied by git "patch files".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> > On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > > 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,
> > 
> > I tried to submit this series to Russell patch tracker and failed. This
> > is ridiculous. It's 2024 and instead of normal process, like every other
> > maintainer, so b4 or Patchwork, we have some unusable system rejecting
> > standard patches.
> 
> Sorry but no. Stop being offensive.
> 
> > First, it depends some weird, duplicated signed-off-by's.
> 
> Eh? There is no such logic in there.
> 
> > Second it > submitting patch-by-patch, all with clicking on some web
> > (!!!) interface.
> 
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where
> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.
> 
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
> 
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
> 
>   git format-patch --add-header="KernelVersion: $foo"
> 
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required
> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
> 
> > That's the response:
> > -------------
> > Your patch has not been logged because:
> > 
> > Error:   Please supply a summary subject line briefly describing
> >          your patch.
> > 
> > 
> > Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> > "---".
> > 
> > Error:   the patch you are submitting has one or more missing or incorrect
> >          Signed-off-by lines:
> > 
> >          - author signoff <krzkreg@gmail.com> is missing.
> > 
> >          Please see the file Documentation/SubmittingPatches, section 11
> >          for details on signing off patches.
> 
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
> 
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?

... and I'll also point out one of the biggest problems is people.
People who think it's more complex than it is, or who can't read
instructions.

For example, trying to tell people to use the standard format subject
line:

	[PATCH ...] blah

has proven to be hopeless - unless one states to them the exact
sequence of keys on their keyboard to press - yes, it *really* takes
that patronising level to get everyone to understand. If one tries to
do it any other way, then you get stuff like:

	"[PATCH ...] ..."

with the quotes. Or some other stupid variation.

The patch system is as forgiving as possible. It takes standard git
formatted patches (with the exception of wanting an additional tag).

It is possible that bugs creep in - particularly when Debian updates
get applied and change the way Perl works, but I don't think that's
what has happened with your situation.

I _guess_ you're putting the entire email-like output from git
format-patch as the patch file. That won't work - that isn't a "patch
file", that is an email/email template, and the patch system will
attempt to parse that as the patch itself.

I suppose you term "patch" to be the email as well, rather than what
I interpret it to be, which is only the output of "diff" - call me
old fashioned but that's what a patch file used to be before the
waters got muddied by git "patch files".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 10:56, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>> 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,
>>
>> I tried to submit this series to Russell patch tracker and failed. This
>> is ridiculous. It's 2024 and instead of normal process, like every other
>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>> standard patches.
> 
> Sorry but no. Stop being offensive.
> 
>> First, it depends some weird, duplicated signed-off-by's.
> 
> Eh? There is no such logic in there.

In the web system there is - read the error message I pasted. It wants
another SoB from the unrelated email account, the one used purely for
registering in some web system, not the one used for code handling.

> 
>> Second it > submitting patch-by-patch, all with clicking on some web
>> (!!!) interface.
> 
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where

The email one requires additional steps, so this is unnecessary work
confusing submitters. I submit dozens or hundreds of patches every
release cycle. That's the only subsystem which is odd to use.

> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.

No, they are not. None of my emails are screwed by my company system.

> 
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
> 
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
> 
>   git format-patch --add-header="KernelVersion: $foo"
> 
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required

Which is absolutely ridiculous now. Expecting submitters to adhere to
some rule for 20 year old kernel is not reasonable.

> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
> 
>> That's the response:
>> -------------
>> Your patch has not been logged because:
>>
>> Error:   Please supply a summary subject line briefly describing
>>          your patch.
>>
>>
>> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>> "---".
>>
>> Error:   the patch you are submitting has one or more missing or incorrect
>>          Signed-off-by lines:
>>
>>          - author signoff <krzkreg@gmail.com> is missing.

^^^ here you have additional SoB expectation.

>>
>>          Please see the file Documentation/SubmittingPatches, section 11
>>          for details on signing off patches.
> 
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
> 
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?

I don't know any person who enjoyed working with your patch workflow.
From few people I talked, it was always "now I have to learn this weird
system" or "I need to get through this process which is different than
everything in the kernel".

Plus you entirely ignored poor usability of this system which:
1. Allows submitting patches only 1-by-1, so 19 useless steps in my case.
2. Accepts the first/second/all patches without problem encouraging me
to submit the rest... and then tells me via email they were wrong and
could not be accepted.

This is the poorest user-experience one can imagine. If you put effort
into some web form, make it at least helpful so reject the patch if it
does not match your expectations.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 10:56, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>> 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,
>>
>> I tried to submit this series to Russell patch tracker and failed. This
>> is ridiculous. It's 2024 and instead of normal process, like every other
>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>> standard patches.
> 
> Sorry but no. Stop being offensive.
> 
>> First, it depends some weird, duplicated signed-off-by's.
> 
> Eh? There is no such logic in there.

In the web system there is - read the error message I pasted. It wants
another SoB from the unrelated email account, the one used purely for
registering in some web system, not the one used for code handling.

> 
>> Second it > submitting patch-by-patch, all with clicking on some web
>> (!!!) interface.
> 
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where

The email one requires additional steps, so this is unnecessary work
confusing submitters. I submit dozens or hundreds of patches every
release cycle. That's the only subsystem which is odd to use.

> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.

No, they are not. None of my emails are screwed by my company system.

> 
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
> 
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
> 
>   git format-patch --add-header="KernelVersion: $foo"
> 
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required

Which is absolutely ridiculous now. Expecting submitters to adhere to
some rule for 20 year old kernel is not reasonable.

> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
> 
>> That's the response:
>> -------------
>> Your patch has not been logged because:
>>
>> Error:   Please supply a summary subject line briefly describing
>>          your patch.
>>
>>
>> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>> "---".
>>
>> Error:   the patch you are submitting has one or more missing or incorrect
>>          Signed-off-by lines:
>>
>>          - author signoff <krzkreg@gmail.com> is missing.

^^^ here you have additional SoB expectation.

>>
>>          Please see the file Documentation/SubmittingPatches, section 11
>>          for details on signing off patches.
> 
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
> 
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?

I don't know any person who enjoyed working with your patch workflow.
From few people I talked, it was always "now I have to learn this weird
system" or "I need to get through this process which is different than
everything in the kernel".

Plus you entirely ignored poor usability of this system which:
1. Allows submitting patches only 1-by-1, so 19 useless steps in my case.
2. Accepts the first/second/all patches without problem encouraging me
to submit the rest... and then tells me via email they were wrong and
could not be accepted.

This is the poorest user-experience one can imagine. If you put effort
into some web form, make it at least helpful so reject the patch if it
does not match your expectations.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 11:06, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>> 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,
>>>
>>> I tried to submit this series to Russell patch tracker and failed. This
>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>> standard patches.
>>
>> Sorry but no. Stop being offensive.
>>
>>> First, it depends some weird, duplicated signed-off-by's.
>>
>> Eh? There is no such logic in there.
>>
>>> Second it > submitting patch-by-patch, all with clicking on some web
>>> (!!!) interface.
>>
>> Again, no it doesn't, and you're just throwing crap out because you
>> failed. Unlike most of the "normal" processes, the patch system allows
>> you to submit both by *email* and also by *web* for those cases where
>> the emails get screwed up by ones company mail server. That's why the
>> web interface exists - to give people *flexibility*.
>>
>> The fact is, the web interface is merely a front end interface that
>> generates an email and submits it in the usual way by email - an
>> email that you can perfectly well generate that is *very* close to
>> the standard email that git format-patch generates.
>>
>> The *only* difference is that the patch system wants a KernelVersion:
>> tag in the email _somewhere_ and it doesn't matter where it appears.
>> Git even has support to do this.
>>
>>   git format-patch --add-header="KernelVersion: $foo"
>>
>> Why does it want the kernel version? Because when we were running 2.4
>> and 2.5 kernel versions in parallel, it was important to know which
>> tree the patch was being submitted for. It has continued to be required
>> because it means when there's problems applying a patch, it gives me
>> the additional information about the base used for the patch (and it
>> keeps on being useful to have.)
>>
>>> That's the response:
>>> -------------
>>> Your patch has not been logged because:
>>>
>>> Error:   Please supply a summary subject line briefly describing
>>>          your patch.
>>>
>>>
>>> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>>> "---".
>>>
>>> Error:   the patch you are submitting has one or more missing or incorrect
>>>          Signed-off-by lines:
>>>
>>>          - author signoff <krzkreg@gmail.com> is missing.
>>>
>>>          Please see the file Documentation/SubmittingPatches, section 11
>>>          for details on signing off patches.
>>
>> Lots of people use it without a problem. I've just run the parser
>> through its offline tests, and it parses email content correctly.
>> I've no idea what you're doing wrong, but it looks like something
>> pretty serious if it didn't parse the subject line.
>>
>> Rather than getting stressed about it, why don't you send me an email
>> the first time something goes wrong so I can investigate, turn on
>> debugging to capture the problem email?
> 
> ... and I'll also point out one of the biggest problems is people.
> People who think it's more complex than it is, or who can't read
> instructions.

We all read submitting-patches instructions (and many more). A need to
learn one more set of instructions for one more process leads to people
needing to learn 100 different processes for 100 different subsystems.

That's not the way how people should be contributing to Linux kernel.

> 
> For example, trying to tell people to use the standard format subject
> line:
> 
> 	[PATCH ...] blah
> 
> has proven to be hopeless - unless one states to them the exact
> sequence of keys on their keyboard to press - yes, it *really* takes
> that patronising level to get everyone to understand. If one tries to
> do it any other way, then you get stuff like:
> 
> 	"[PATCH ...] ..."
> 
> with the quotes. Or some other stupid variation.
> 
> The patch system is as forgiving as possible. It takes standard git
> formatted patches (with the exception of wanting an additional tag).

The additional tag about kernel version is redundant and not helping
anyone. I doubt you apply patches on top of linux-next or top of
previous release (e.g. v6.8-rc1). Almost every maintainer applies on top
of current RC, so v6.9-rc1 currently, thus version is just unnecessary
obstacle.

> 
> It is possible that bugs creep in - particularly when Debian updates
> get applied and change the way Perl works, but I don't think that's
> what has happened with your situation.
> 
> I _guess_ you're putting the entire email-like output from git
> format-patch as the patch file. That won't work - that isn't a "patch
> file", that is an email/email template, and the patch system will
> attempt to parse that as the patch itself.

Yes, that's what every sane person's workflow is. git format-patch -19
(cover letter goes from branch description).

> 
> I suppose you term "patch" to be the email as well, rather than what
> I interpret it to be, which is only the output of "diff" - call me
> old fashioned but that's what a patch file used to be before the
> waters got muddied by git "patch files".

Well, world is now using git as a standard. It's true there is quilt out
there, but even Andrew I think is going slowly towards git in some parts
of his workflow.

But then even Andrew accepted standard patch from the mailing lists. No
need for any other step, no need for any double submission (one public,
second to patches@armlinux or webform) with any other requirement.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 11:06, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>> 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,
>>>
>>> I tried to submit this series to Russell patch tracker and failed. This
>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>> standard patches.
>>
>> Sorry but no. Stop being offensive.
>>
>>> First, it depends some weird, duplicated signed-off-by's.
>>
>> Eh? There is no such logic in there.
>>
>>> Second it > submitting patch-by-patch, all with clicking on some web
>>> (!!!) interface.
>>
>> Again, no it doesn't, and you're just throwing crap out because you
>> failed. Unlike most of the "normal" processes, the patch system allows
>> you to submit both by *email* and also by *web* for those cases where
>> the emails get screwed up by ones company mail server. That's why the
>> web interface exists - to give people *flexibility*.
>>
>> The fact is, the web interface is merely a front end interface that
>> generates an email and submits it in the usual way by email - an
>> email that you can perfectly well generate that is *very* close to
>> the standard email that git format-patch generates.
>>
>> The *only* difference is that the patch system wants a KernelVersion:
>> tag in the email _somewhere_ and it doesn't matter where it appears.
>> Git even has support to do this.
>>
>>   git format-patch --add-header="KernelVersion: $foo"
>>
>> Why does it want the kernel version? Because when we were running 2.4
>> and 2.5 kernel versions in parallel, it was important to know which
>> tree the patch was being submitted for. It has continued to be required
>> because it means when there's problems applying a patch, it gives me
>> the additional information about the base used for the patch (and it
>> keeps on being useful to have.)
>>
>>> That's the response:
>>> -------------
>>> Your patch has not been logged because:
>>>
>>> Error:   Please supply a summary subject line briefly describing
>>>          your patch.
>>>
>>>
>>> Error:   Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>>> "---".
>>>
>>> Error:   the patch you are submitting has one or more missing or incorrect
>>>          Signed-off-by lines:
>>>
>>>          - author signoff <krzkreg@gmail.com> is missing.
>>>
>>>          Please see the file Documentation/SubmittingPatches, section 11
>>>          for details on signing off patches.
>>
>> Lots of people use it without a problem. I've just run the parser
>> through its offline tests, and it parses email content correctly.
>> I've no idea what you're doing wrong, but it looks like something
>> pretty serious if it didn't parse the subject line.
>>
>> Rather than getting stressed about it, why don't you send me an email
>> the first time something goes wrong so I can investigate, turn on
>> debugging to capture the problem email?
> 
> ... and I'll also point out one of the biggest problems is people.
> People who think it's more complex than it is, or who can't read
> instructions.

We all read submitting-patches instructions (and many more). A need to
learn one more set of instructions for one more process leads to people
needing to learn 100 different processes for 100 different subsystems.

That's not the way how people should be contributing to Linux kernel.

> 
> For example, trying to tell people to use the standard format subject
> line:
> 
> 	[PATCH ...] blah
> 
> has proven to be hopeless - unless one states to them the exact
> sequence of keys on their keyboard to press - yes, it *really* takes
> that patronising level to get everyone to understand. If one tries to
> do it any other way, then you get stuff like:
> 
> 	"[PATCH ...] ..."
> 
> with the quotes. Or some other stupid variation.
> 
> The patch system is as forgiving as possible. It takes standard git
> formatted patches (with the exception of wanting an additional tag).

The additional tag about kernel version is redundant and not helping
anyone. I doubt you apply patches on top of linux-next or top of
previous release (e.g. v6.8-rc1). Almost every maintainer applies on top
of current RC, so v6.9-rc1 currently, thus version is just unnecessary
obstacle.

> 
> It is possible that bugs creep in - particularly when Debian updates
> get applied and change the way Perl works, but I don't think that's
> what has happened with your situation.
> 
> I _guess_ you're putting the entire email-like output from git
> format-patch as the patch file. That won't work - that isn't a "patch
> file", that is an email/email template, and the patch system will
> attempt to parse that as the patch itself.

Yes, that's what every sane person's workflow is. git format-patch -19
(cover letter goes from branch description).

> 
> I suppose you term "patch" to be the email as well, rather than what
> I interpret it to be, which is only the output of "diff" - call me
> old fashioned but that's what a patch file used to be before the
> waters got muddied by git "patch files".

Well, world is now using git as a standard. It's true there is quilt out
there, but even Andrew I think is going slowly towards git in some parts
of his workflow.

But then even Andrew accepted standard patch from the mailing lists. No
need for any other step, no need for any double submission (one public,
second to patches@armlinux or webform) with any other requirement.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 10:56, Russell King (Oracle) wrote:
> > On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> >>> 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,
> >>
> >> I tried to submit this series to Russell patch tracker and failed. This
> >> is ridiculous. It's 2024 and instead of normal process, like every other
> >> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> >> standard patches.
> > 
> > Sorry but no. Stop being offensive.
> > 
> >> First, it depends some weird, duplicated signed-off-by's.
> > 
> > Eh? There is no such logic in there.
> 
> In the web system there is - read the error message I pasted. It wants
> another SoB from the unrelated email account, the one used purely for
> registering in some web system, not the one used for code handling.

So you're disagreeing with the author of this system. Of course you
know best, you know the code behind it. I have only one word for
that kind of attitude: idiotic.

> >> Second it > submitting patch-by-patch, all with clicking on some web
> >> (!!!) interface.
> > 
> > Again, no it doesn't, and you're just throwing crap out because you
> > failed. Unlike most of the "normal" processes, the patch system allows
> > you to submit both by *email* and also by *web* for those cases where
> 
> The email one requires additional steps, so this is unnecessary work
> confusing submitters. I submit dozens or hundreds of patches every
> release cycle. That's the only subsystem which is odd to use.

Lots of people use it without issue. People even send patches to the
mailing list copied to the patch system.

> > the emails get screwed up by ones company mail server. That's why the
> > web interface exists - to give people *flexibility*.
> 
> No, they are not. None of my emails are screwed by my company system.

So why are you using the web interface?

> > Why does it want the kernel version? Because when we were running 2.4
> > and 2.5 kernel versions in parallel, it was important to know which
> > tree the patch was being submitted for. It has continued to be required
> 
> Which is absolutely ridiculous now. Expecting submitters to adhere to
> some rule for 20 year old kernel is not reasonable.

You aren't listening to me, so it's pointless discussing this further.
You have a bee in your bonet and you want to make it a huge issue
rather than work constructively. Sorry but no, I'm not going to continue
this confrontational exchange.

You clearly don't want to understand anything.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 10:56, Russell King (Oracle) wrote:
> > On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> >>> 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,
> >>
> >> I tried to submit this series to Russell patch tracker and failed. This
> >> is ridiculous. It's 2024 and instead of normal process, like every other
> >> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> >> standard patches.
> > 
> > Sorry but no. Stop being offensive.
> > 
> >> First, it depends some weird, duplicated signed-off-by's.
> > 
> > Eh? There is no such logic in there.
> 
> In the web system there is - read the error message I pasted. It wants
> another SoB from the unrelated email account, the one used purely for
> registering in some web system, not the one used for code handling.

So you're disagreeing with the author of this system. Of course you
know best, you know the code behind it. I have only one word for
that kind of attitude: idiotic.

> >> Second it > submitting patch-by-patch, all with clicking on some web
> >> (!!!) interface.
> > 
> > Again, no it doesn't, and you're just throwing crap out because you
> > failed. Unlike most of the "normal" processes, the patch system allows
> > you to submit both by *email* and also by *web* for those cases where
> 
> The email one requires additional steps, so this is unnecessary work
> confusing submitters. I submit dozens or hundreds of patches every
> release cycle. That's the only subsystem which is odd to use.

Lots of people use it without issue. People even send patches to the
mailing list copied to the patch system.

> > the emails get screwed up by ones company mail server. That's why the
> > web interface exists - to give people *flexibility*.
> 
> No, they are not. None of my emails are screwed by my company system.

So why are you using the web interface?

> > Why does it want the kernel version? Because when we were running 2.4
> > and 2.5 kernel versions in parallel, it was important to know which
> > tree the patch was being submitted for. It has continued to be required
> 
> Which is absolutely ridiculous now. Expecting submitters to adhere to
> some rule for 20 year old kernel is not reasonable.

You aren't listening to me, so it's pointless discussing this further.
You have a bee in your bonet and you want to make it a huge issue
rather than work constructively. Sorry but no, I'm not going to continue
this confrontational exchange.

You clearly don't want to understand anything.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 11:57, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 10:56, Russell King (Oracle) wrote:
>>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>>> 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,
>>>>
>>>> I tried to submit this series to Russell patch tracker and failed. This
>>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>>> standard patches.
>>>
>>> Sorry but no. Stop being offensive.
>>>
>>>> First, it depends some weird, duplicated signed-off-by's.
>>>
>>> Eh? There is no such logic in there.
>>
>> In the web system there is - read the error message I pasted. It wants
>> another SoB from the unrelated email account, the one used purely for
>> registering in some web system, not the one used for code handling.
> 
> So you're disagreeing with the author of this system. Of course you
> know best, you know the code behind it. I have only one word for
> that kind of attitude: idiotic.

I pasted you the error which the system reported to me.

> 
>>>> Second it > submitting patch-by-patch, all with clicking on some web
>>>> (!!!) interface.
>>>
>>> Again, no it doesn't, and you're just throwing crap out because you
>>> failed. Unlike most of the "normal" processes, the patch system allows
>>> you to submit both by *email* and also by *web* for those cases where
>>
>> The email one requires additional steps, so this is unnecessary work
>> confusing submitters. I submit dozens or hundreds of patches every
>> release cycle. That's the only subsystem which is odd to use.
> 
> Lots of people use it without issue. People even send patches to the
> mailing list copied to the patch system.
> 

I will try that.


>>> the emails get screwed up by ones company mail server. That's why the
>>> web interface exists - to give people *flexibility*.
>>
>> No, they are not. None of my emails are screwed by my company system.
> 
> So why are you using the web interface?
> 
>>> Why does it want the kernel version? Because when we were running 2.4
>>> and 2.5 kernel versions in parallel, it was important to know which
>>> tree the patch was being submitted for. It has continued to be required
>>
>> Which is absolutely ridiculous now. Expecting submitters to adhere to
>> some rule for 20 year old kernel is not reasonable.
> 
> You aren't listening to me, so it's pointless discussing this further.
> You have a bee in your bonet and you want to make it a huge issue

Well, all my comments were about the actual topic - patch submission
process made for ARM subsystem by you. Your replies include comments
about me and what do I have in my bonet.

You brought no argument for keeping the kernel-version-header
requirement nowadays, yet you call me of not working constructively. I
brought that argument - it is redundant and it is an obstacle for the
contributor.

> rather than work constructively. Sorry but no, I'm not going to continue
> this confrontational exchange.
> 
> You clearly don't want to understand anything.

I understood a lot, although I did not answer under every point "I
understand this part, I disagree here".

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 02/04/2024 11:57, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 10:56, Russell King (Oracle) wrote:
>>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>>> 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,
>>>>
>>>> I tried to submit this series to Russell patch tracker and failed. This
>>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>>> standard patches.
>>>
>>> Sorry but no. Stop being offensive.
>>>
>>>> First, it depends some weird, duplicated signed-off-by's.
>>>
>>> Eh? There is no such logic in there.
>>
>> In the web system there is - read the error message I pasted. It wants
>> another SoB from the unrelated email account, the one used purely for
>> registering in some web system, not the one used for code handling.
> 
> So you're disagreeing with the author of this system. Of course you
> know best, you know the code behind it. I have only one word for
> that kind of attitude: idiotic.

I pasted you the error which the system reported to me.

> 
>>>> Second it > submitting patch-by-patch, all with clicking on some web
>>>> (!!!) interface.
>>>
>>> Again, no it doesn't, and you're just throwing crap out because you
>>> failed. Unlike most of the "normal" processes, the patch system allows
>>> you to submit both by *email* and also by *web* for those cases where
>>
>> The email one requires additional steps, so this is unnecessary work
>> confusing submitters. I submit dozens or hundreds of patches every
>> release cycle. That's the only subsystem which is odd to use.
> 
> Lots of people use it without issue. People even send patches to the
> mailing list copied to the patch system.
> 

I will try that.


>>> the emails get screwed up by ones company mail server. That's why the
>>> web interface exists - to give people *flexibility*.
>>
>> No, they are not. None of my emails are screwed by my company system.
> 
> So why are you using the web interface?
> 
>>> Why does it want the kernel version? Because when we were running 2.4
>>> and 2.5 kernel versions in parallel, it was important to know which
>>> tree the patch was being submitted for. It has continued to be required
>>
>> Which is absolutely ridiculous now. Expecting submitters to adhere to
>> some rule for 20 year old kernel is not reasonable.
> 
> You aren't listening to me, so it's pointless discussing this further.
> You have a bee in your bonet and you want to make it a huge issue

Well, all my comments were about the actual topic - patch submission
process made for ARM subsystem by you. Your replies include comments
about me and what do I have in my bonet.

You brought no argument for keeping the kernel-version-header
requirement nowadays, yet you call me of not working constructively. I
brought that argument - it is redundant and it is an obstacle for the
contributor.

> rather than work constructively. Sorry but no, I'm not going to continue
> this confrontational exchange.
> 
> You clearly don't want to understand anything.

I understood a lot, although I did not answer under every point "I
understand this part, I disagree here".

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> You brought no argument for keeping the kernel-version-header
> requirement nowadays, yet you call me of not working constructively. I

So add inability to read to your failings, because I _did_ state that
_I_ still _use_ it.

End of discussion, I'm not engaging with you in your current
confrontational mood where you clearly don't want to understand
anything (or intentionally misinterpreting) I'm writing - making it
pointless to continue.

I even think you're intentionally misinterpreting the responses
from the patch system.

Overall, I can only draw the conclusion that you are playing politics
and want the patch system gone, and you want me to use "standard"
tooling that will _increase_ the amount of effort I need to put in.
No, that's not going to happen.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> You brought no argument for keeping the kernel-version-header
> requirement nowadays, yet you call me of not working constructively. I

So add inability to read to your failings, because I _did_ state that
_I_ still _use_ it.

End of discussion, I'm not engaging with you in your current
confrontational mood where you clearly don't want to understand
anything (or intentionally misinterpreting) I'm writing - making it
pointless to continue.

I even think you're intentionally misinterpreting the responses
from the patch system.

Overall, I can only draw the conclusion that you are playing politics
and want the patch system gone, and you want me to use "standard"
tooling that will _increase_ the amount of effort I need to put in.
No, that's not going to happen.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 11:12:36AM +0100, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> > You brought no argument for keeping the kernel-version-header
> > requirement nowadays, yet you call me of not working constructively. I
> 
> So add inability to read to your failings, because I _did_ state that
> _I_ still _use_ it.
> 
> End of discussion, I'm not engaging with you in your current
> confrontational mood where you clearly don't want to understand
> anything (or intentionally misinterpreting) I'm writing - making it
> pointless to continue.
> 
> I even think you're intentionally misinterpreting the responses
> from the patch system.
> 
> Overall, I can only draw the conclusion that you are playing politics
> and want the patch system gone, and you want me to use "standard"
> tooling that will _increase_ the amount of effort I need to put in.
> No, that's not going to happen.

... and this is your final chance to change to a constructive discourse,
if not, you are going to end up in my kill file. Whether you do is
entirely up to the tone of your reply to this email.

I am always more than willing to work with a submitter to diagnose
what the problem is, but the tone of your emails make me want to
ignore you.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Tue, Apr 02, 2024 at 11:12:36AM +0100, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> > You brought no argument for keeping the kernel-version-header
> > requirement nowadays, yet you call me of not working constructively. I
> 
> So add inability to read to your failings, because I _did_ state that
> _I_ still _use_ it.
> 
> End of discussion, I'm not engaging with you in your current
> confrontational mood where you clearly don't want to understand
> anything (or intentionally misinterpreting) I'm writing - making it
> pointless to continue.
> 
> I even think you're intentionally misinterpreting the responses
> from the patch system.
> 
> Overall, I can only draw the conclusion that you are playing politics
> and want the patch system gone, and you want me to use "standard"
> tooling that will _increase_ the amount of effort I need to put in.
> No, that's not going to happen.

... and this is your final chance to change to a constructive discourse,
if not, you are going to end up in my kill file. Whether you do is
entirely up to the tone of your reply to this email.

I am always more than willing to work with a submitter to diagnose
what the problem is, but the tone of your emails make me want to
ignore you.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/19] hwrng: nomadik: drop owner assignment

[Linus Walleij]

On Tue, Mar 26, 2024 at 9:24 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 15/19] hwrng: nomadik: drop owner assignment

[Linus Walleij]

On Tue, Mar 26, 2024 at 9:24 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Tue, Mar 26, 2024 at 09:23:44PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 14/19] i2c: nomadik: drop owner assignment

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 277 bytes --]

On Tue, Mar 26, 2024 at 09:23:44PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

+ Greg


Hi Krzysztof,

On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>
>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>> 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.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/19] amba: store owner from modules with amba_driver_register()
>>          (no commit info)
> 
> Patchset applied here:
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba

How do you plan to push this ? Given this affects most of the drivers/, 
do you plan to send this to Greg ? We have changes in the coresight
tree that would conflict with this "tag" ( I haven't merged them yet, 
but is in my local queue). I want to make sure we can avoid the
conflicts. I am happy to merge this to my local tree and base the
changes on this, if this is going in for v6.10 and all are in agreement.

Kind regards
Suzuki




> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Suzuki K Poulose]

+ Greg


Hi Krzysztof,

On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>
>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>> 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.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/19] amba: store owner from modules with amba_driver_register()
>>          (no commit info)
> 
> Patchset applied here:
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba

How do you plan to push this ? Given this affects most of the drivers/, 
do you plan to send this to Greg ? We have changes in the coresight
tree that would conflict with this "tag" ( I haven't merged them yet, 
but is in my local queue). I want to make sure we can avoid the
conflicts. I am happy to merge this to my local tree and base the
changes on this, if this is going in for v6.10 and all are in agreement.

Kind regards
Suzuki




> 
> Best regards,
> Krzysztof
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 16/04/2024 12:41, Suzuki K Poulose wrote:
> + Greg
> 
> 
> Hi Krzysztof,
> 
> On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
>> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>>
>>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>>> 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.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [01/19] amba: store owner from modules with amba_driver_register()
>>>          (no commit info)
>>
>> Patchset applied here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
> 
> How do you plan to push this ? Given this affects most of the drivers/, 
> do you plan to send this to Greg ? We have changes in the coresight
> tree that would conflict with this "tag" ( I haven't merged them yet, 
> but is in my local queue). I want to make sure we can avoid the
> conflicts. I am happy to merge this to my local tree and base the
> changes on this, if this is going in for v6.10 and all are in agreement.

I pushed it to arm-linux patches but it hasn't been picked up.

I propose you take entire set then.

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 16/04/2024 12:41, Suzuki K Poulose wrote:
> + Greg
> 
> 
> Hi Krzysztof,
> 
> On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
>> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>>
>>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>>> 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.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [01/19] amba: store owner from modules with amba_driver_register()
>>>          (no commit info)
>>
>> Patchset applied here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
> 
> How do you plan to push this ? Given this affects most of the drivers/, 
> do you plan to send this to Greg ? We have changes in the coresight
> tree that would conflict with this "tag" ( I haven't merged them yet, 
> but is in my local queue). I want to make sure we can avoid the
> conflicts. I am happy to merge this to my local tree and base the
> changes on this, if this is going in for v6.10 and all are in agreement.

I pushed it to arm-linux patches but it hasn't been picked up.

I propose you take entire set then.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Wed, Apr 17, 2024 at 03:29:26PM +0200, Krzysztof Kozlowski wrote:
> On 16/04/2024 12:41, Suzuki K Poulose wrote:
> > + Greg
> > 
> > 
> > Hi Krzysztof,
> > 
> > On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
> >> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
> >>>
> >>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
> >>>> 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.
> >>>>
> >>>> [...]
> >>>
> >>> Applied, thanks!
> >>>
> >>> [01/19] amba: store owner from modules with amba_driver_register()
> >>>          (no commit info)
> >>
> >> Patchset applied here:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
> > 
> > How do you plan to push this ? Given this affects most of the drivers/, 
> > do you plan to send this to Greg ? We have changes in the coresight
> > tree that would conflict with this "tag" ( I haven't merged them yet, 
> > but is in my local queue). I want to make sure we can avoid the
> > conflicts. I am happy to merge this to my local tree and base the
> > changes on this, if this is going in for v6.10 and all are in agreement.
> 
> I pushed it to arm-linux patches but it hasn't been picked up.
> 
> I propose you take entire set then.

You are again being, IMHO, abrasive with your attitude. So far, every
interaction with you has been abrasive and bordering on abusive.

You haven't asked me whether I will take them. I will - just not at the
moment because 

I HAVE MEDICAL APPOINTMENTS LAST WEEK AND THIS WEEK WHICH MEAN I AM
NOT SPENDING ALL MY TIME ON THE KERNEL.

Have some bloody patience rather than behaving in your standard
objectionable manner.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Russell King (Oracle)]

On Wed, Apr 17, 2024 at 03:29:26PM +0200, Krzysztof Kozlowski wrote:
> On 16/04/2024 12:41, Suzuki K Poulose wrote:
> > + Greg
> > 
> > 
> > Hi Krzysztof,
> > 
> > On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
> >> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
> >>>
> >>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
> >>>> 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.
> >>>>
> >>>> [...]
> >>>
> >>> Applied, thanks!
> >>>
> >>> [01/19] amba: store owner from modules with amba_driver_register()
> >>>          (no commit info)
> >>
> >> Patchset applied here:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
> > 
> > How do you plan to push this ? Given this affects most of the drivers/, 
> > do you plan to send this to Greg ? We have changes in the coresight
> > tree that would conflict with this "tag" ( I haven't merged them yet, 
> > but is in my local queue). I want to make sure we can avoid the
> > conflicts. I am happy to merge this to my local tree and base the
> > changes on this, if this is going in for v6.10 and all are in agreement.
> 
> I pushed it to arm-linux patches but it hasn't been picked up.
> 
> I propose you take entire set then.

You are again being, IMHO, abrasive with your attitude. So far, every
interaction with you has been abrasive and bordering on abusive.

You haven't asked me whether I will take them. I will - just not at the
moment because 

I HAVE MEDICAL APPOINTMENTS LAST WEEK AND THIS WEEK WHICH MEAN I AM
NOT SPENDING ALL MY TIME ON THE KERNEL.

Have some bloody patience rather than behaving in your standard
objectionable manner.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 17/04/2024 15:50, Russell King (Oracle) wrote:
> On Wed, Apr 17, 2024 at 03:29:26PM +0200, Krzysztof Kozlowski wrote:
>> On 16/04/2024 12:41, Suzuki K Poulose wrote:
>>> + Greg
>>>
>>>
>>> Hi Krzysztof,
>>>
>>> On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
>>>> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>>>>
>>>>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>>>>> 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.
>>>>>>
>>>>>> [...]
>>>>>
>>>>> Applied, thanks!
>>>>>
>>>>> [01/19] amba: store owner from modules with amba_driver_register()
>>>>>          (no commit info)
>>>>
>>>> Patchset applied here:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
>>>
>>> How do you plan to push this ? Given this affects most of the drivers/, 
>>> do you plan to send this to Greg ? We have changes in the coresight
>>> tree that would conflict with this "tag" ( I haven't merged them yet, 
>>> but is in my local queue). I want to make sure we can avoid the
>>> conflicts. I am happy to merge this to my local tree and base the
>>> changes on this, if this is going in for v6.10 and all are in agreement.
>>
>> I pushed it to arm-linux patches but it hasn't been picked up.
>>
>> I propose you take entire set then.
> 
> You are again being, IMHO, abrasive with your attitude. So far, every
> interaction with you has been abrasive and bordering on abusive.
> 
> You haven't asked me whether I will take them. I will - just not at the
> moment because 

Thanks for confirming, I wanted to ping you because there was no feedback.

Can you provide stable tag for coresight tree?

Best regards,
Krzysztof

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

[Krzysztof Kozlowski]

On 17/04/2024 15:50, Russell King (Oracle) wrote:
> On Wed, Apr 17, 2024 at 03:29:26PM +0200, Krzysztof Kozlowski wrote:
>> On 16/04/2024 12:41, Suzuki K Poulose wrote:
>>> + Greg
>>>
>>>
>>> Hi Krzysztof,
>>>
>>> On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
>>>> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>>>>
>>>>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>>>>> 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.
>>>>>>
>>>>>> [...]
>>>>>
>>>>> Applied, thanks!
>>>>>
>>>>> [01/19] amba: store owner from modules with amba_driver_register()
>>>>>          (no commit info)
>>>>
>>>> Patchset applied here:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
>>>
>>> How do you plan to push this ? Given this affects most of the drivers/, 
>>> do you plan to send this to Greg ? We have changes in the coresight
>>> tree that would conflict with this "tag" ( I haven't merged them yet, 
>>> but is in my local queue). I want to make sure we can avoid the
>>> conflicts. I am happy to merge this to my local tree and base the
>>> changes on this, if this is going in for v6.10 and all are in agreement.
>>
>> I pushed it to arm-linux patches but it hasn't been picked up.
>>
>> I propose you take entire set then.
> 
> You are again being, IMHO, abrasive with your attitude. So far, every
> interaction with you has been abrasive and bordering on abusive.
> 
> You haven't asked me whether I will take them. I will - just not at the
> moment because 

Thanks for confirming, I wanted to ping you because there was no feedback.

Can you provide stable tag for coresight tree?

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel