* [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: Saravana Kannan, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, Hanks Chen, CC Hwang, Loda Chou Made a series out of the previous v2 patch + some example uses of the macros. Not sure if the MTK changes work (just compile tested), but saw that Hanks was trying to make those drivers into tristate. So I assume they'll work as platform drivers. Please wait for MTK Ack before picking up patches 3 and 4. v1-v2: - Instead of redifining IRQCHIP_DECLARE, created new macros. - Added more checks in the probe helper function to ensure topological probe ordering when fw_devlink is not "on". v2->v3: - Added comments - Changed IRQCHIP_PLATFORM_DRIVER_BEGIN macro parameters Saravana Kannan (4): irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros irqchip/mtk-sysirq: Convert to a platform driver irqchip/mtk-cirq: Convert to a platform driver drivers/irqchip/irq-mtk-cirq.c | 4 +++- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ drivers/irqchip/qcom-pdc.c | 26 +++----------------------- include/linux/irqchip.h | 23 +++++++++++++++++++++++ 5 files changed, 61 insertions(+), 25 deletions(-) -- 2.28.0.rc0.105.gf9edc3c819-goog ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Made a series out of the previous v2 patch + some example uses of the macros. Not sure if the MTK changes work (just compile tested), but saw that Hanks was trying to make those drivers into tristate. So I assume they'll work as platform drivers. Please wait for MTK Ack before picking up patches 3 and 4. v1-v2: - Instead of redifining IRQCHIP_DECLARE, created new macros. - Added more checks in the probe helper function to ensure topological probe ordering when fw_devlink is not "on". v2->v3: - Added comments - Changed IRQCHIP_PLATFORM_DRIVER_BEGIN macro parameters Saravana Kannan (4): irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros irqchip/mtk-sysirq: Convert to a platform driver irqchip/mtk-cirq: Convert to a platform driver drivers/irqchip/irq-mtk-cirq.c | 4 +++- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ drivers/irqchip/qcom-pdc.c | 26 +++----------------------- include/linux/irqchip.h | 23 +++++++++++++++++++++++ 5 files changed, 61 insertions(+), 25 deletions(-) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Made a series out of the previous v2 patch + some example uses of the macros. Not sure if the MTK changes work (just compile tested), but saw that Hanks was trying to make those drivers into tristate. So I assume they'll work as platform drivers. Please wait for MTK Ack before picking up patches 3 and 4. v1-v2: - Instead of redifining IRQCHIP_DECLARE, created new macros. - Added more checks in the probe helper function to ensure topological probe ordering when fw_devlink is not "on". v2->v3: - Added comments - Changed IRQCHIP_PLATFORM_DRIVER_BEGIN macro parameters Saravana Kannan (4): irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros irqchip/mtk-sysirq: Convert to a platform driver irqchip/mtk-cirq: Convert to a platform driver drivers/irqchip/irq-mtk-cirq.c | 4 +++- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ drivers/irqchip/qcom-pdc.c | 26 +++----------------------- include/linux/irqchip.h | 23 +++++++++++++++++++++++ 5 files changed, 61 insertions(+), 25 deletions(-) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-18 0:06 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: Saravana Kannan, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, Hanks Chen, CC Hwang, Loda Chou Compiling an irqchip driver as a platform driver needs to bunch of things to be done right: - Making sure the parent domain is initialized first - Making sure the device can't be unbound from sysfs - Disallowing module unload if it's built as a module - Finding the parent node - Etc. Instead of trying to make sure all future irqchip platform drivers get this right, provide boilerplate macros that take care of all of this. An example use would look something like this. Where acme_foo_init and acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE. IRQCHIP_PLATFORM_DRIVER_BEGIN(acme_irq) IRQCHIP_MATCH("acme,foo", acme_foo_init) IRQCHIP_MATCH("acme,bar", acme_bar_init) IRQCHIP_PLATFORM_DRIVER_END(acme_irq) Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ include/linux/irqchip.h | 23 +++++++++++++++++++++++ 2 files changed, 52 insertions(+) diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 2b35e68bea82..1bb0e36c2bf3 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -10,8 +10,10 @@ #include <linux/acpi.h> #include <linux/init.h> +#include <linux/of_device.h> #include <linux/of_irq.h> #include <linux/irqchip.h> +#include <linux/platform_device.h> /* * This special of_device_id is the sentinel at the end of the @@ -29,3 +31,30 @@ void __init irqchip_init(void) of_irq_init(__irqchip_of_table); acpi_probe_device_table(irqchip); } + +int platform_irqchip_probe(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct device_node *par_np = of_irq_find_parent(np); + of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev); + + if (!irq_init_cb) + return -EINVAL; + + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; + + return irq_init_cb(np, par_np); +} +EXPORT_SYMBOL_GPL(platform_irqchip_probe); diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h index 447f22880a69..8e754d8b8155 100644 --- a/include/linux/irqchip.h +++ b/include/linux/irqchip.h @@ -13,6 +13,7 @@ #include <linux/acpi.h> #include <linux/of.h> +#include <linux/platform_device.h> /* * This macro must be used by the different irqchip drivers to declare @@ -26,6 +27,28 @@ */ #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn) +extern int platform_irqchip_probe(struct platform_device *pdev); + +#define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \ +static const struct of_device_id drv_name##_irqchip_match_table[] = { + +#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn }, + +#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \ + {}, \ +}; \ +MODULE_DEVICE_TABLE(of, drv_name##_irqchip_match_table); \ +static struct platform_driver drv_name##_driver = { \ + .probe = platform_irqchip_probe, \ + .driver = { \ + .name = #drv_name, \ + .owner = THIS_MODULE, \ + .of_match_table = drv_name##_irqchip_match_table, \ + .suppress_bind_attrs = true, \ + }, \ +}; \ +builtin_platform_driver(drv_name##_driver) + /* * This macro must be used by the different irqchip drivers to declare * the association between their version and their initialization function. -- 2.28.0.rc0.105.gf9edc3c819-goog ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Compiling an irqchip driver as a platform driver needs to bunch of things to be done right: - Making sure the parent domain is initialized first - Making sure the device can't be unbound from sysfs - Disallowing module unload if it's built as a module - Finding the parent node - Etc. Instead of trying to make sure all future irqchip platform drivers get this right, provide boilerplate macros that take care of all of this. An example use would look something like this. Where acme_foo_init and acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE. IRQCHIP_PLATFORM_DRIVER_BEGIN(acme_irq) IRQCHIP_MATCH("acme,foo", acme_foo_init) IRQCHIP_MATCH("acme,bar", acme_bar_init) IRQCHIP_PLATFORM_DRIVER_END(acme_irq) Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ include/linux/irqchip.h | 23 +++++++++++++++++++++++ 2 files changed, 52 insertions(+) diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 2b35e68bea82..1bb0e36c2bf3 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -10,8 +10,10 @@ #include <linux/acpi.h> #include <linux/init.h> +#include <linux/of_device.h> #include <linux/of_irq.h> #include <linux/irqchip.h> +#include <linux/platform_device.h> /* * This special of_device_id is the sentinel at the end of the @@ -29,3 +31,30 @@ void __init irqchip_init(void) of_irq_init(__irqchip_of_table); acpi_probe_device_table(irqchip); } + +int platform_irqchip_probe(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct device_node *par_np = of_irq_find_parent(np); + of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev); + + if (!irq_init_cb) + return -EINVAL; + + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; + + return irq_init_cb(np, par_np); +} +EXPORT_SYMBOL_GPL(platform_irqchip_probe); diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h index 447f22880a69..8e754d8b8155 100644 --- a/include/linux/irqchip.h +++ b/include/linux/irqchip.h @@ -13,6 +13,7 @@ #include <linux/acpi.h> #include <linux/of.h> +#include <linux/platform_device.h> /* * This macro must be used by the different irqchip drivers to declare @@ -26,6 +27,28 @@ */ #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn) +extern int platform_irqchip_probe(struct platform_device *pdev); + +#define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \ +static const struct of_device_id drv_name##_irqchip_match_table[] = { + +#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn }, + +#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \ + {}, \ +}; \ +MODULE_DEVICE_TABLE(of, drv_name##_irqchip_match_table); \ +static struct platform_driver drv_name##_driver = { \ + .probe = platform_irqchip_probe, \ + .driver = { \ + .name = #drv_name, \ + .owner = THIS_MODULE, \ + .of_match_table = drv_name##_irqchip_match_table, \ + .suppress_bind_attrs = true, \ + }, \ +}; \ +builtin_platform_driver(drv_name##_driver) + /* * This macro must be used by the different irqchip drivers to declare * the association between their version and their initialization function. -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Compiling an irqchip driver as a platform driver needs to bunch of things to be done right: - Making sure the parent domain is initialized first - Making sure the device can't be unbound from sysfs - Disallowing module unload if it's built as a module - Finding the parent node - Etc. Instead of trying to make sure all future irqchip platform drivers get this right, provide boilerplate macros that take care of all of this. An example use would look something like this. Where acme_foo_init and acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE. IRQCHIP_PLATFORM_DRIVER_BEGIN(acme_irq) IRQCHIP_MATCH("acme,foo", acme_foo_init) IRQCHIP_MATCH("acme,bar", acme_bar_init) IRQCHIP_PLATFORM_DRIVER_END(acme_irq) Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irqchip.c | 29 +++++++++++++++++++++++++++++ include/linux/irqchip.h | 23 +++++++++++++++++++++++ 2 files changed, 52 insertions(+) diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 2b35e68bea82..1bb0e36c2bf3 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -10,8 +10,10 @@ #include <linux/acpi.h> #include <linux/init.h> +#include <linux/of_device.h> #include <linux/of_irq.h> #include <linux/irqchip.h> +#include <linux/platform_device.h> /* * This special of_device_id is the sentinel at the end of the @@ -29,3 +31,30 @@ void __init irqchip_init(void) of_irq_init(__irqchip_of_table); acpi_probe_device_table(irqchip); } + +int platform_irqchip_probe(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct device_node *par_np = of_irq_find_parent(np); + of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev); + + if (!irq_init_cb) + return -EINVAL; + + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; + + return irq_init_cb(np, par_np); +} +EXPORT_SYMBOL_GPL(platform_irqchip_probe); diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h index 447f22880a69..8e754d8b8155 100644 --- a/include/linux/irqchip.h +++ b/include/linux/irqchip.h @@ -13,6 +13,7 @@ #include <linux/acpi.h> #include <linux/of.h> +#include <linux/platform_device.h> /* * This macro must be used by the different irqchip drivers to declare @@ -26,6 +27,28 @@ */ #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn) +extern int platform_irqchip_probe(struct platform_device *pdev); + +#define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \ +static const struct of_device_id drv_name##_irqchip_match_table[] = { + +#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn }, + +#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \ + {}, \ +}; \ +MODULE_DEVICE_TABLE(of, drv_name##_irqchip_match_table); \ +static struct platform_driver drv_name##_driver = { \ + .probe = platform_irqchip_probe, \ + .driver = { \ + .name = #drv_name, \ + .owner = THIS_MODULE, \ + .of_match_table = drv_name##_irqchip_match_table, \ + .suppress_bind_attrs = true, \ + }, \ +}; \ +builtin_platform_driver(drv_name##_driver) + /* * This macro must be used by the different irqchip drivers to declare * the association between their version and their initialization function. -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-18 0:06 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: Saravana Kannan, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, Hanks Chen, CC Hwang, Loda Chou Switch the driver to use the helper macros. In addition to reducing the number of lines, this also adds module unload protection (if the driver is compiled as a module) by switching from module_platform_driver to builtin_platform_driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/qcom-pdc.c | 26 +++----------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c index 5b624e3295e4..c1c5dfad57cc 100644 --- a/drivers/irqchip/qcom-pdc.c +++ b/drivers/irqchip/qcom-pdc.c @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) return ret; } -static int qcom_pdc_probe(struct platform_device *pdev) -{ - struct device_node *np = pdev->dev.of_node; - struct device_node *parent = of_irq_find_parent(np); - - return qcom_pdc_init(np, parent); -} - -static const struct of_device_id qcom_pdc_match_table[] = { - { .compatible = "qcom,pdc" }, - {} -}; -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); - -static struct platform_driver qcom_pdc_driver = { - .probe = qcom_pdc_probe, - .driver = { - .name = "qcom-pdc", - .of_match_table = qcom_pdc_match_table, - .suppress_bind_attrs = true, - }, -}; -module_platform_driver(qcom_pdc_driver); +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); MODULE_LICENSE("GPL v2"); -- 2.28.0.rc0.105.gf9edc3c819-goog ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Switch the driver to use the helper macros. In addition to reducing the number of lines, this also adds module unload protection (if the driver is compiled as a module) by switching from module_platform_driver to builtin_platform_driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/qcom-pdc.c | 26 +++----------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c index 5b624e3295e4..c1c5dfad57cc 100644 --- a/drivers/irqchip/qcom-pdc.c +++ b/drivers/irqchip/qcom-pdc.c @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) return ret; } -static int qcom_pdc_probe(struct platform_device *pdev) -{ - struct device_node *np = pdev->dev.of_node; - struct device_node *parent = of_irq_find_parent(np); - - return qcom_pdc_init(np, parent); -} - -static const struct of_device_id qcom_pdc_match_table[] = { - { .compatible = "qcom,pdc" }, - {} -}; -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); - -static struct platform_driver qcom_pdc_driver = { - .probe = qcom_pdc_probe, - .driver = { - .name = "qcom-pdc", - .of_match_table = qcom_pdc_match_table, - .suppress_bind_attrs = true, - }, -}; -module_platform_driver(qcom_pdc_driver); +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); MODULE_LICENSE("GPL v2"); -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel Switch the driver to use the helper macros. In addition to reducing the number of lines, this also adds module unload protection (if the driver is compiled as a module) by switching from module_platform_driver to builtin_platform_driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/qcom-pdc.c | 26 +++----------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c index 5b624e3295e4..c1c5dfad57cc 100644 --- a/drivers/irqchip/qcom-pdc.c +++ b/drivers/irqchip/qcom-pdc.c @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) return ret; } -static int qcom_pdc_probe(struct platform_device *pdev) -{ - struct device_node *np = pdev->dev.of_node; - struct device_node *parent = of_irq_find_parent(np); - - return qcom_pdc_init(np, parent); -} - -static const struct of_device_id qcom_pdc_match_table[] = { - { .compatible = "qcom,pdc" }, - {} -}; -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); - -static struct platform_driver qcom_pdc_driver = { - .probe = qcom_pdc_probe, - .driver = { - .name = "qcom-pdc", - .of_match_table = qcom_pdc_match_table, - .suppress_bind_attrs = true, - }, -}; -module_platform_driver(qcom_pdc_driver); +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); MODULE_LICENSE("GPL v2"); -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-08-05 7:44 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 7:44 UTC (permalink / raw) To: Saravana Kannan Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, linux-mediatek, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > Switch the driver to use the helper macros. In addition to reducing the > number of lines, this also adds module unload protection (if the driver > is compiled as a module) by switching from module_platform_driver to > builtin_platform_driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > 1 file changed, 3 insertions(+), 23 deletions(-) > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > index 5b624e3295e4..c1c5dfad57cc 100644 > --- a/drivers/irqchip/qcom-pdc.c > +++ b/drivers/irqchip/qcom-pdc.c > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > return ret; > } > > -static int qcom_pdc_probe(struct platform_device *pdev) > -{ > - struct device_node *np = pdev->dev.of_node; > - struct device_node *parent = of_irq_find_parent(np); > - > - return qcom_pdc_init(np, parent); > -} > - > -static const struct of_device_id qcom_pdc_match_table[] = { > - { .compatible = "qcom,pdc" }, > - {} > -}; > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > - > -static struct platform_driver qcom_pdc_driver = { > - .probe = qcom_pdc_probe, > - .driver = { > - .name = "qcom-pdc", > - .of_match_table = qcom_pdc_match_table, > - .suppress_bind_attrs = true, > - }, > -}; > -module_platform_driver(qcom_pdc_driver); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > MODULE_LICENSE("GPL v2"); <sigh> So this is where I bashfully admit I didn't get a chance to try this patch series out, as I had success with a much older version of Saravana's macro magic. But unfortunately, now that this has landed in mainline, I'm seeing boot regressions on db845c. :( This is in the non-modular case, building the driver in. I managed to bisect it down to this patch, and reverting it avoids the issue. I don't see what is wrong right off, but I really need to get to bed, so I'll dig further tomorrow. Saravana: Apologies for not getting around to testing this beforehand! thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 7:44 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 7:44 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > Switch the driver to use the helper macros. In addition to reducing the > number of lines, this also adds module unload protection (if the driver > is compiled as a module) by switching from module_platform_driver to > builtin_platform_driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > 1 file changed, 3 insertions(+), 23 deletions(-) > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > index 5b624e3295e4..c1c5dfad57cc 100644 > --- a/drivers/irqchip/qcom-pdc.c > +++ b/drivers/irqchip/qcom-pdc.c > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > return ret; > } > > -static int qcom_pdc_probe(struct platform_device *pdev) > -{ > - struct device_node *np = pdev->dev.of_node; > - struct device_node *parent = of_irq_find_parent(np); > - > - return qcom_pdc_init(np, parent); > -} > - > -static const struct of_device_id qcom_pdc_match_table[] = { > - { .compatible = "qcom,pdc" }, > - {} > -}; > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > - > -static struct platform_driver qcom_pdc_driver = { > - .probe = qcom_pdc_probe, > - .driver = { > - .name = "qcom-pdc", > - .of_match_table = qcom_pdc_match_table, > - .suppress_bind_attrs = true, > - }, > -}; > -module_platform_driver(qcom_pdc_driver); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > MODULE_LICENSE("GPL v2"); <sigh> So this is where I bashfully admit I didn't get a chance to try this patch series out, as I had success with a much older version of Saravana's macro magic. But unfortunately, now that this has landed in mainline, I'm seeing boot regressions on db845c. :( This is in the non-modular case, building the driver in. I managed to bisect it down to this patch, and reverting it avoids the issue. I don't see what is wrong right off, but I really need to get to bed, so I'll dig further tomorrow. Saravana: Apologies for not getting around to testing this beforehand! thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 7:44 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 7:44 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > Switch the driver to use the helper macros. In addition to reducing the > number of lines, this also adds module unload protection (if the driver > is compiled as a module) by switching from module_platform_driver to > builtin_platform_driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > 1 file changed, 3 insertions(+), 23 deletions(-) > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > index 5b624e3295e4..c1c5dfad57cc 100644 > --- a/drivers/irqchip/qcom-pdc.c > +++ b/drivers/irqchip/qcom-pdc.c > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > return ret; > } > > -static int qcom_pdc_probe(struct platform_device *pdev) > -{ > - struct device_node *np = pdev->dev.of_node; > - struct device_node *parent = of_irq_find_parent(np); > - > - return qcom_pdc_init(np, parent); > -} > - > -static const struct of_device_id qcom_pdc_match_table[] = { > - { .compatible = "qcom,pdc" }, > - {} > -}; > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > - > -static struct platform_driver qcom_pdc_driver = { > - .probe = qcom_pdc_probe, > - .driver = { > - .name = "qcom-pdc", > - .of_match_table = qcom_pdc_match_table, > - .suppress_bind_attrs = true, > - }, > -}; > -module_platform_driver(qcom_pdc_driver); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > MODULE_LICENSE("GPL v2"); <sigh> So this is where I bashfully admit I didn't get a chance to try this patch series out, as I had success with a much older version of Saravana's macro magic. But unfortunately, now that this has landed in mainline, I'm seeing boot regressions on db845c. :( This is in the non-modular case, building the driver in. I managed to bisect it down to this patch, and reverting it avoids the issue. I don't see what is wrong right off, but I really need to get to bed, so I'll dig further tomorrow. Saravana: Apologies for not getting around to testing this beforehand! thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 7:44 ` John Stultz (?) @ 2020-08-05 20:19 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-05 20:19 UTC (permalink / raw) To: John Stultz Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > Switch the driver to use the helper macros. In addition to reducing the > > number of lines, this also adds module unload protection (if the driver > > is compiled as a module) by switching from module_platform_driver to > > builtin_platform_driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > index 5b624e3295e4..c1c5dfad57cc 100644 > > --- a/drivers/irqchip/qcom-pdc.c > > +++ b/drivers/irqchip/qcom-pdc.c > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > return ret; > > } > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > -{ > > - struct device_node *np = pdev->dev.of_node; > > - struct device_node *parent = of_irq_find_parent(np); > > - > > - return qcom_pdc_init(np, parent); > > -} > > - > > -static const struct of_device_id qcom_pdc_match_table[] = { > > - { .compatible = "qcom,pdc" }, > > - {} > > -}; > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > - > > -static struct platform_driver qcom_pdc_driver = { > > - .probe = qcom_pdc_probe, > > - .driver = { > > - .name = "qcom-pdc", > > - .of_match_table = qcom_pdc_match_table, > > - .suppress_bind_attrs = true, > > - }, > > -}; > > -module_platform_driver(qcom_pdc_driver); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > MODULE_LICENSE("GPL v2"); > > <sigh> > So this is where I bashfully admit I didn't get a chance to try this > patch series out, as I had success with a much older version of > Saravana's macro magic. > > But unfortunately, now that this has landed in mainline, I'm seeing > boot regressions on db845c. :( This is in the non-modular case, > building the driver in. Does that mean the modular version is working? Or you haven't tried that yet? I'll wait for your reply before I try to fix it. I don't have the hardware, but it should be easy to guess this issue looking at the code delta. The only significant change from what your probe function is doing is this snippet. But it'd be surprising if this only affects the builtin case. + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; > I managed to bisect it down to this patch, and reverting it avoids the > issue. I don't see what is wrong right off, but I really need to get > to bed, so I'll dig further tomorrow. > > Saravana: Apologies for not getting around to testing this beforehand! No worries. Apologies for breaking it accidentally. -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 20:19 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-05 20:19 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > Switch the driver to use the helper macros. In addition to reducing the > > number of lines, this also adds module unload protection (if the driver > > is compiled as a module) by switching from module_platform_driver to > > builtin_platform_driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > index 5b624e3295e4..c1c5dfad57cc 100644 > > --- a/drivers/irqchip/qcom-pdc.c > > +++ b/drivers/irqchip/qcom-pdc.c > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > return ret; > > } > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > -{ > > - struct device_node *np = pdev->dev.of_node; > > - struct device_node *parent = of_irq_find_parent(np); > > - > > - return qcom_pdc_init(np, parent); > > -} > > - > > -static const struct of_device_id qcom_pdc_match_table[] = { > > - { .compatible = "qcom,pdc" }, > > - {} > > -}; > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > - > > -static struct platform_driver qcom_pdc_driver = { > > - .probe = qcom_pdc_probe, > > - .driver = { > > - .name = "qcom-pdc", > > - .of_match_table = qcom_pdc_match_table, > > - .suppress_bind_attrs = true, > > - }, > > -}; > > -module_platform_driver(qcom_pdc_driver); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > MODULE_LICENSE("GPL v2"); > > <sigh> > So this is where I bashfully admit I didn't get a chance to try this > patch series out, as I had success with a much older version of > Saravana's macro magic. > > But unfortunately, now that this has landed in mainline, I'm seeing > boot regressions on db845c. :( This is in the non-modular case, > building the driver in. Does that mean the modular version is working? Or you haven't tried that yet? I'll wait for your reply before I try to fix it. I don't have the hardware, but it should be easy to guess this issue looking at the code delta. The only significant change from what your probe function is doing is this snippet. But it'd be surprising if this only affects the builtin case. + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; > I managed to bisect it down to this patch, and reverting it avoids the > issue. I don't see what is wrong right off, but I really need to get > to bed, so I'll dig further tomorrow. > > Saravana: Apologies for not getting around to testing this beforehand! No worries. Apologies for breaking it accidentally. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 20:19 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-05 20:19 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > Switch the driver to use the helper macros. In addition to reducing the > > number of lines, this also adds module unload protection (if the driver > > is compiled as a module) by switching from module_platform_driver to > > builtin_platform_driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > index 5b624e3295e4..c1c5dfad57cc 100644 > > --- a/drivers/irqchip/qcom-pdc.c > > +++ b/drivers/irqchip/qcom-pdc.c > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > return ret; > > } > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > -{ > > - struct device_node *np = pdev->dev.of_node; > > - struct device_node *parent = of_irq_find_parent(np); > > - > > - return qcom_pdc_init(np, parent); > > -} > > - > > -static const struct of_device_id qcom_pdc_match_table[] = { > > - { .compatible = "qcom,pdc" }, > > - {} > > -}; > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > - > > -static struct platform_driver qcom_pdc_driver = { > > - .probe = qcom_pdc_probe, > > - .driver = { > > - .name = "qcom-pdc", > > - .of_match_table = qcom_pdc_match_table, > > - .suppress_bind_attrs = true, > > - }, > > -}; > > -module_platform_driver(qcom_pdc_driver); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > MODULE_LICENSE("GPL v2"); > > <sigh> > So this is where I bashfully admit I didn't get a chance to try this > patch series out, as I had success with a much older version of > Saravana's macro magic. > > But unfortunately, now that this has landed in mainline, I'm seeing > boot regressions on db845c. :( This is in the non-modular case, > building the driver in. Does that mean the modular version is working? Or you haven't tried that yet? I'll wait for your reply before I try to fix it. I don't have the hardware, but it should be easy to guess this issue looking at the code delta. The only significant change from what your probe function is doing is this snippet. But it'd be surprising if this only affects the builtin case. + if (par_np == np) + par_np = NULL; + + /* + * If there's a parent interrupt controller and none of the parent irq + * domains have been registered, that means the parent interrupt + * controller has not been initialized yet. it's not time for this + * interrupt controller to initialize. So, defer probe of this + * interrupt controller. The actual initialization callback of this + * interrupt controller can check for specific domains as necessary. + */ + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + return -EPROBE_DEFER; > I managed to bisect it down to this patch, and reverting it avoids the > issue. I don't see what is wrong right off, but I really need to get > to bed, so I'll dig further tomorrow. > > Saravana: Apologies for not getting around to testing this beforehand! No worries. Apologies for breaking it accidentally. -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 20:19 ` Saravana Kannan (?) @ 2020-08-05 21:16 ` Steev Klimaszewski -1 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:16 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On 8/5/20 3:19 PM, Saravana Kannan wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >> <sigh> >> So this is where I bashfully admit I didn't get a chance to try this >> patch series out, as I had success with a much older version of >> Saravana's macro magic. >> >> But unfortunately, now that this has landed in mainline, I'm seeing >> boot regressions on db845c. :( This is in the non-modular case, >> building the driver in. > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. For what it's worth, I saw this too on the Lenovo C630 (started on -next around 20200727, but I didn't track it down as, well, there's less way to get debug output on the C630. In my testing, module or built-in doesn't matter, but reverting does allow me to boot again. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; > >> I managed to bisect it down to this patch, and reverting it avoids the >> issue. I don't see what is wrong right off, but I really need to get >> to bed, so I'll dig further tomorrow. >> >> Saravana: Apologies for not getting around to testing this beforehand! > No worries. Apologies for breaking it accidentally. > > -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:16 ` Steev Klimaszewski 0 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:16 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 8/5/20 3:19 PM, Saravana Kannan wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >> <sigh> >> So this is where I bashfully admit I didn't get a chance to try this >> patch series out, as I had success with a much older version of >> Saravana's macro magic. >> >> But unfortunately, now that this has landed in mainline, I'm seeing >> boot regressions on db845c. :( This is in the non-modular case, >> building the driver in. > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. For what it's worth, I saw this too on the Lenovo C630 (started on -next around 20200727, but I didn't track it down as, well, there's less way to get debug output on the C630. In my testing, module or built-in doesn't matter, but reverting does allow me to boot again. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; > >> I managed to bisect it down to this patch, and reverting it avoids the >> issue. I don't see what is wrong right off, but I really need to get >> to bed, so I'll dig further tomorrow. >> >> Saravana: Apologies for not getting around to testing this beforehand! > No worries. Apologies for breaking it accidentally. > > -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:16 ` Steev Klimaszewski 0 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:16 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 8/5/20 3:19 PM, Saravana Kannan wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >> <sigh> >> So this is where I bashfully admit I didn't get a chance to try this >> patch series out, as I had success with a much older version of >> Saravana's macro magic. >> >> But unfortunately, now that this has landed in mainline, I'm seeing >> boot regressions on db845c. :( This is in the non-modular case, >> building the driver in. > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. For what it's worth, I saw this too on the Lenovo C630 (started on -next around 20200727, but I didn't track it down as, well, there's less way to get debug output on the C630. In my testing, module or built-in doesn't matter, but reverting does allow me to boot again. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; > >> I managed to bisect it down to this patch, and reverting it avoids the >> issue. I don't see what is wrong right off, but I really need to get >> to bed, so I'll dig further tomorrow. >> >> Saravana: Apologies for not getting around to testing this beforehand! > No worries. Apologies for breaking it accidentally. > > -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 21:16 ` Steev Klimaszewski (?) @ 2020-08-05 21:47 ` Steev Klimaszewski -1 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:47 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > On 8/5/20 3:19 PM, Saravana Kannan wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >>> <sigh> >>> So this is where I bashfully admit I didn't get a chance to try this >>> patch series out, as I had success with a much older version of >>> Saravana's macro magic. >>> >>> But unfortunately, now that this has landed in mainline, I'm seeing >>> boot regressions on db845c. :( This is in the non-modular case, >>> building the driver in. >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > For what it's worth, I saw this too on the Lenovo C630 (started on -next > around 20200727, but I didn't track it down as, well, there's less way > to get debug output on the C630. > > In my testing, module or built-in doesn't matter, but reverting does > allow me to boot again. > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted boots, however, module (on the c630 at least) doesn't boot whether it's a module or built-in. >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; >> >>> I managed to bisect it down to this patch, and reverting it avoids the >>> issue. I don't see what is wrong right off, but I really need to get >>> to bed, so I'll dig further tomorrow. >>> >>> Saravana: Apologies for not getting around to testing this beforehand! >> No worries. Apologies for breaking it accidentally. >> >> -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:47 ` Steev Klimaszewski 0 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:47 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > On 8/5/20 3:19 PM, Saravana Kannan wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >>> <sigh> >>> So this is where I bashfully admit I didn't get a chance to try this >>> patch series out, as I had success with a much older version of >>> Saravana's macro magic. >>> >>> But unfortunately, now that this has landed in mainline, I'm seeing >>> boot regressions on db845c. :( This is in the non-modular case, >>> building the driver in. >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > For what it's worth, I saw this too on the Lenovo C630 (started on -next > around 20200727, but I didn't track it down as, well, there's less way > to get debug output on the C630. > > In my testing, module or built-in doesn't matter, but reverting does > allow me to boot again. > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted boots, however, module (on the c630 at least) doesn't boot whether it's a module or built-in. >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; >> >>> I managed to bisect it down to this patch, and reverting it avoids the >>> issue. I don't see what is wrong right off, but I really need to get >>> to bed, so I'll dig further tomorrow. >>> >>> Saravana: Apologies for not getting around to testing this beforehand! >> No worries. Apologies for breaking it accidentally. >> >> -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:47 ` Steev Klimaszewski 0 siblings, 0 replies; 93+ messages in thread From: Steev Klimaszewski @ 2020-08-05 21:47 UTC (permalink / raw) To: Saravana Kannan, John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > On 8/5/20 3:19 PM, Saravana Kannan wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: >>> <sigh> >>> So this is where I bashfully admit I didn't get a chance to try this >>> patch series out, as I had success with a much older version of >>> Saravana's macro magic. >>> >>> But unfortunately, now that this has landed in mainline, I'm seeing >>> boot regressions on db845c. :( This is in the non-modular case, >>> building the driver in. >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > For what it's worth, I saw this too on the Lenovo C630 (started on -next > around 20200727, but I didn't track it down as, well, there's less way > to get debug output on the C630. > > In my testing, module or built-in doesn't matter, but reverting does > allow me to boot again. > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted boots, however, module (on the c630 at least) doesn't boot whether it's a module or built-in. >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; >> >>> I managed to bisect it down to this patch, and reverting it avoids the >>> issue. I don't see what is wrong right off, but I really need to get >>> to bed, so I'll dig further tomorrow. >>> >>> Saravana: Apologies for not getting around to testing this beforehand! >> No worries. Apologies for breaking it accidentally. >> >> -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 21:47 ` Steev Klimaszewski (?) @ 2020-08-05 21:57 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 21:57 UTC (permalink / raw) To: Steev Klimaszewski Cc: Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > >>> <sigh> > >>> So this is where I bashfully admit I didn't get a chance to try this > >>> patch series out, as I had success with a much older version of > >>> Saravana's macro magic. > >>> > >>> But unfortunately, now that this has landed in mainline, I'm seeing > >>> boot regressions on db845c. :( This is in the non-modular case, > >>> building the driver in. > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > around 20200727, but I didn't track it down as, well, there's less way > > to get debug output on the C630. > > > > In my testing, module or built-in doesn't matter, but reverting does > > allow me to boot again. > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > boots, however, module (on the c630 at least) doesn't boot whether it's > a module or built-in. You may need to set deferred_probe_timeout=30 to give things a bit more grace time to load. (I've mostly recently used qcom-pdc as a module with the android tree, so the fw_devlink bits help there, but I need to re-check the state of that upstream.) I'll dbl check this and dig more on the issue with the patch in question once I can get back in my office later today. thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:57 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 21:57 UTC (permalink / raw) To: Steev Klimaszewski Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > >>> <sigh> > >>> So this is where I bashfully admit I didn't get a chance to try this > >>> patch series out, as I had success with a much older version of > >>> Saravana's macro magic. > >>> > >>> But unfortunately, now that this has landed in mainline, I'm seeing > >>> boot regressions on db845c. :( This is in the non-modular case, > >>> building the driver in. > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > around 20200727, but I didn't track it down as, well, there's less way > > to get debug output on the C630. > > > > In my testing, module or built-in doesn't matter, but reverting does > > allow me to boot again. > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > boots, however, module (on the c630 at least) doesn't boot whether it's > a module or built-in. You may need to set deferred_probe_timeout=30 to give things a bit more grace time to load. (I've mostly recently used qcom-pdc as a module with the android tree, so the fw_devlink bits help there, but I need to re-check the state of that upstream.) I'll dbl check this and dig more on the issue with the patch in question once I can get back in my office later today. thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-05 21:57 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-05 21:57 UTC (permalink / raw) To: Steev Klimaszewski Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > >>> <sigh> > >>> So this is where I bashfully admit I didn't get a chance to try this > >>> patch series out, as I had success with a much older version of > >>> Saravana's macro magic. > >>> > >>> But unfortunately, now that this has landed in mainline, I'm seeing > >>> boot regressions on db845c. :( This is in the non-modular case, > >>> building the driver in. > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > around 20200727, but I didn't track it down as, well, there's less way > > to get debug output on the C630. > > > > In my testing, module or built-in doesn't matter, but reverting does > > allow me to boot again. > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > boots, however, module (on the c630 at least) doesn't boot whether it's > a module or built-in. You may need to set deferred_probe_timeout=30 to give things a bit more grace time to load. (I've mostly recently used qcom-pdc as a module with the android tree, so the fw_devlink bits help there, but I need to re-check the state of that upstream.) I'll dbl check this and dig more on the issue with the patch in question once I can get back in my office later today. thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 21:57 ` John Stultz (?) @ 2020-08-07 0:40 ` Bjorn Andersson -1 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 0:40 UTC (permalink / raw) To: John Stultz Cc: Steev Klimaszewski, Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > >>> <sigh> > > >>> So this is where I bashfully admit I didn't get a chance to try this > > >>> patch series out, as I had success with a much older version of > > >>> Saravana's macro magic. > > >>> > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > >>> boot regressions on db845c. :( This is in the non-modular case, > > >>> building the driver in. > > >> Does that mean the modular version is working? Or you haven't tried > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > >> have the hardware, but it should be easy to guess this issue looking > > >> at the code delta. > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > around 20200727, but I didn't track it down as, well, there's less way > > > to get debug output on the C630. > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > allow me to boot again. > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > boots, however, module (on the c630 at least) doesn't boot whether it's > > a module or built-in. > > You may need to set deferred_probe_timeout=30 to give things a bit > more grace time to load. With the risk of me reading more into this than what you're saying, please don't upstream anything that depend this parameter to be increased. Compiling any of these drivers as module should not require the user to pass additional kernel command line parameters in order to get their device to boot. Regards, Bjorn > (I've mostly recently used qcom-pdc as a module with the android tree, > so the fw_devlink bits help there, but I need to re-check the state of > that upstream.) > > I'll dbl check this and dig more on the issue with the patch in > question once I can get back in my office later today. > > thanks > -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 0:40 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 0:40 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > >>> <sigh> > > >>> So this is where I bashfully admit I didn't get a chance to try this > > >>> patch series out, as I had success with a much older version of > > >>> Saravana's macro magic. > > >>> > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > >>> boot regressions on db845c. :( This is in the non-modular case, > > >>> building the driver in. > > >> Does that mean the modular version is working? Or you haven't tried > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > >> have the hardware, but it should be easy to guess this issue looking > > >> at the code delta. > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > around 20200727, but I didn't track it down as, well, there's less way > > > to get debug output on the C630. > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > allow me to boot again. > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > boots, however, module (on the c630 at least) doesn't boot whether it's > > a module or built-in. > > You may need to set deferred_probe_timeout=30 to give things a bit > more grace time to load. With the risk of me reading more into this than what you're saying, please don't upstream anything that depend this parameter to be increased. Compiling any of these drivers as module should not require the user to pass additional kernel command line parameters in order to get their device to boot. Regards, Bjorn > (I've mostly recently used qcom-pdc as a module with the android tree, > so the fw_devlink bits help there, but I need to re-check the state of > that upstream.) > > I'll dbl check this and dig more on the issue with the patch in > question once I can get back in my office later today. > > thanks > -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 0:40 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 0:40 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > >>> <sigh> > > >>> So this is where I bashfully admit I didn't get a chance to try this > > >>> patch series out, as I had success with a much older version of > > >>> Saravana's macro magic. > > >>> > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > >>> boot regressions on db845c. :( This is in the non-modular case, > > >>> building the driver in. > > >> Does that mean the modular version is working? Or you haven't tried > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > >> have the hardware, but it should be easy to guess this issue looking > > >> at the code delta. > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > around 20200727, but I didn't track it down as, well, there's less way > > > to get debug output on the C630. > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > allow me to boot again. > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > boots, however, module (on the c630 at least) doesn't boot whether it's > > a module or built-in. > > You may need to set deferred_probe_timeout=30 to give things a bit > more grace time to load. With the risk of me reading more into this than what you're saying, please don't upstream anything that depend this parameter to be increased. Compiling any of these drivers as module should not require the user to pass additional kernel command line parameters in order to get their device to boot. Regards, Bjorn > (I've mostly recently used qcom-pdc as a module with the android tree, > so the fw_devlink bits help there, but I need to re-check the state of > that upstream.) > > I'll dbl check this and dig more on the issue with the patch in > question once I can get back in my office later today. > > thanks > -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 0:40 ` Bjorn Andersson (?) @ 2020-08-07 1:22 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 1:22 UTC (permalink / raw) To: Bjorn Andersson Cc: Steev Klimaszewski, Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > >>> <sigh> > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > >>> patch series out, as I had success with a much older version of > > > >>> Saravana's macro magic. > > > >>> > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > >>> building the driver in. > > > >> Does that mean the modular version is working? Or you haven't tried > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > >> have the hardware, but it should be easy to guess this issue looking > > > >> at the code delta. > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > to get debug output on the C630. > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > allow me to boot again. > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > a module or built-in. > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > more grace time to load. > > With the risk of me reading more into this than what you're saying, > please don't upstream anything that depend this parameter to be > increased. > > Compiling any of these drivers as module should not require the user to > pass additional kernel command line parameters in order to get their > device to boot. So, ideally I agree, and Saravana's fw_devlink work should allow us to avoid it. But the reality is that it is already required (at least in configurations heavily using modules) to give more time for modules loaded to resolve missing dependencies after init begins (due to changes in the driver core to fail loading after init so that optional dt links aren't eternally looked for). This was seen when trying to enable the qualcom clk drivers to modules. It doesn't seem necessary in this case, but I suggested it here as I've got it enabled by default in my AOSP builds so that the module-heavy configs for GKI boot properly (even if Saravana's fw_devlink work is disabled). thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 1:22 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 1:22 UTC (permalink / raw) To: Bjorn Andersson Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > >>> <sigh> > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > >>> patch series out, as I had success with a much older version of > > > >>> Saravana's macro magic. > > > >>> > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > >>> building the driver in. > > > >> Does that mean the modular version is working? Or you haven't tried > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > >> have the hardware, but it should be easy to guess this issue looking > > > >> at the code delta. > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > to get debug output on the C630. > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > allow me to boot again. > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > a module or built-in. > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > more grace time to load. > > With the risk of me reading more into this than what you're saying, > please don't upstream anything that depend this parameter to be > increased. > > Compiling any of these drivers as module should not require the user to > pass additional kernel command line parameters in order to get their > device to boot. So, ideally I agree, and Saravana's fw_devlink work should allow us to avoid it. But the reality is that it is already required (at least in configurations heavily using modules) to give more time for modules loaded to resolve missing dependencies after init begins (due to changes in the driver core to fail loading after init so that optional dt links aren't eternally looked for). This was seen when trying to enable the qualcom clk drivers to modules. It doesn't seem necessary in this case, but I suggested it here as I've got it enabled by default in my AOSP builds so that the module-heavy configs for GKI boot properly (even if Saravana's fw_devlink work is disabled). thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 1:22 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 1:22 UTC (permalink / raw) To: Bjorn Andersson Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > >>> <sigh> > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > >>> patch series out, as I had success with a much older version of > > > >>> Saravana's macro magic. > > > >>> > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > >>> building the driver in. > > > >> Does that mean the modular version is working? Or you haven't tried > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > >> have the hardware, but it should be easy to guess this issue looking > > > >> at the code delta. > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > to get debug output on the C630. > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > allow me to boot again. > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > a module or built-in. > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > more grace time to load. > > With the risk of me reading more into this than what you're saying, > please don't upstream anything that depend this parameter to be > increased. > > Compiling any of these drivers as module should not require the user to > pass additional kernel command line parameters in order to get their > device to boot. So, ideally I agree, and Saravana's fw_devlink work should allow us to avoid it. But the reality is that it is already required (at least in configurations heavily using modules) to give more time for modules loaded to resolve missing dependencies after init begins (due to changes in the driver core to fail loading after init so that optional dt links aren't eternally looked for). This was seen when trying to enable the qualcom clk drivers to modules. It doesn't seem necessary in this case, but I suggested it here as I've got it enabled by default in my AOSP builds so that the module-heavy configs for GKI boot properly (even if Saravana's fw_devlink work is disabled). thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 1:22 ` John Stultz (?) @ 2020-08-07 1:39 ` Bjorn Andersson -1 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 1:39 UTC (permalink / raw) To: John Stultz Cc: Steev Klimaszewski, Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > >>> <sigh> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 1:39 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 1:39 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > >>> <sigh> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 1:39 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 1:39 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > >>> <sigh> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 1:39 ` Bjorn Andersson (?) @ 2020-08-07 2:48 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 2:48 UTC (permalink / raw) To: Bjorn Andersson Cc: Steev Klimaszewski, Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > >>> <sigh> > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > >>> patch series out, as I had success with a much older version of > > > > > >>> Saravana's macro magic. > > > > > >>> > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > >>> building the driver in. > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > >> at the code delta. > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > to get debug output on the C630. > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > allow me to boot again. > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > a module or built-in. > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > more grace time to load. > > > > > > With the risk of me reading more into this than what you're saying, > > > please don't upstream anything that depend this parameter to be > > > increased. > > > > > > Compiling any of these drivers as module should not require the user to > > > pass additional kernel command line parameters in order to get their > > > device to boot. > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > avoid it. But the reality is that it is already required (at least in > > configurations heavily using modules) to give more time for modules > > loaded to resolve missing dependencies after init begins (due to > > changes in the driver core to fail loading after init so that optional > > dt links aren't eternally looked for). This was seen when trying to > > enable the qualcom clk drivers to modules. > > > > So to clarify what you're saying, any system that boots successfully > with the default options is a sign of pure luck - regardless of being > builtin or modules. > > > And there you have my exact argument against the deferred timeout magic > going on in the driver core. But as you know people insist that it's > more important to be able to boot some defunct system from NFS than a > properly configured one reliably. I'd agree, but the NFS case was in use before, and when the original deferred timeout/optional link handling stuff landed no one complained they were broken by it (at least at the point where it landed). Only later when we started enabling more lower-level core drivers as modules did the shortened dependency resolution time start to bite folks. My attempt to set the default to be 30 seconds helped there, but caused trouble and delays for the NFS case, and "don't break existing users" seemed to rule, so I set the default timeout back to 0. > > It doesn't seem necessary in this case, but I suggested it here as > > I've got it enabled by default in my AOSP builds so that the > > module-heavy configs for GKI boot properly (even if Saravana's > > fw_devlink work is disabled). > > > > With all due respect, that's your downstream kernel, the upstream kernel > should not rely on luck, out-of-tree patches or kernel parameters. I agree that would be preferred. But kernel parameters are often there for these sorts of cases where we can't always do the right thing. As for out-of-tree patches, broken things don't get fixed until out-of-tree patches are developed and upstreamed, and I know Saravana is doing exactly that, and I hope his fw_devlink work helps fix it so the module loading is not just a matter of luck. Also I think Thierry's comments in the other thread today are also good ideas for ways to better handle the optional dt link handling (rather than using a timeout). thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 2:48 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 2:48 UTC (permalink / raw) To: Bjorn Andersson Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > >>> <sigh> > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > >>> patch series out, as I had success with a much older version of > > > > > >>> Saravana's macro magic. > > > > > >>> > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > >>> building the driver in. > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > >> at the code delta. > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > to get debug output on the C630. > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > allow me to boot again. > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > a module or built-in. > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > more grace time to load. > > > > > > With the risk of me reading more into this than what you're saying, > > > please don't upstream anything that depend this parameter to be > > > increased. > > > > > > Compiling any of these drivers as module should not require the user to > > > pass additional kernel command line parameters in order to get their > > > device to boot. > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > avoid it. But the reality is that it is already required (at least in > > configurations heavily using modules) to give more time for modules > > loaded to resolve missing dependencies after init begins (due to > > changes in the driver core to fail loading after init so that optional > > dt links aren't eternally looked for). This was seen when trying to > > enable the qualcom clk drivers to modules. > > > > So to clarify what you're saying, any system that boots successfully > with the default options is a sign of pure luck - regardless of being > builtin or modules. > > > And there you have my exact argument against the deferred timeout magic > going on in the driver core. But as you know people insist that it's > more important to be able to boot some defunct system from NFS than a > properly configured one reliably. I'd agree, but the NFS case was in use before, and when the original deferred timeout/optional link handling stuff landed no one complained they were broken by it (at least at the point where it landed). Only later when we started enabling more lower-level core drivers as modules did the shortened dependency resolution time start to bite folks. My attempt to set the default to be 30 seconds helped there, but caused trouble and delays for the NFS case, and "don't break existing users" seemed to rule, so I set the default timeout back to 0. > > It doesn't seem necessary in this case, but I suggested it here as > > I've got it enabled by default in my AOSP builds so that the > > module-heavy configs for GKI boot properly (even if Saravana's > > fw_devlink work is disabled). > > > > With all due respect, that's your downstream kernel, the upstream kernel > should not rely on luck, out-of-tree patches or kernel parameters. I agree that would be preferred. But kernel parameters are often there for these sorts of cases where we can't always do the right thing. As for out-of-tree patches, broken things don't get fixed until out-of-tree patches are developed and upstreamed, and I know Saravana is doing exactly that, and I hope his fw_devlink work helps fix it so the module loading is not just a matter of luck. Also I think Thierry's comments in the other thread today are also good ideas for ways to better handle the optional dt link handling (rather than using a timeout). thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 2:48 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 2:48 UTC (permalink / raw) To: Bjorn Andersson Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > >>> <sigh> > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > >>> patch series out, as I had success with a much older version of > > > > > >>> Saravana's macro magic. > > > > > >>> > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > >>> building the driver in. > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > >> at the code delta. > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > to get debug output on the C630. > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > allow me to boot again. > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > a module or built-in. > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > more grace time to load. > > > > > > With the risk of me reading more into this than what you're saying, > > > please don't upstream anything that depend this parameter to be > > > increased. > > > > > > Compiling any of these drivers as module should not require the user to > > > pass additional kernel command line parameters in order to get their > > > device to boot. > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > avoid it. But the reality is that it is already required (at least in > > configurations heavily using modules) to give more time for modules > > loaded to resolve missing dependencies after init begins (due to > > changes in the driver core to fail loading after init so that optional > > dt links aren't eternally looked for). This was seen when trying to > > enable the qualcom clk drivers to modules. > > > > So to clarify what you're saying, any system that boots successfully > with the default options is a sign of pure luck - regardless of being > builtin or modules. > > > And there you have my exact argument against the deferred timeout magic > going on in the driver core. But as you know people insist that it's > more important to be able to boot some defunct system from NFS than a > properly configured one reliably. I'd agree, but the NFS case was in use before, and when the original deferred timeout/optional link handling stuff landed no one complained they were broken by it (at least at the point where it landed). Only later when we started enabling more lower-level core drivers as modules did the shortened dependency resolution time start to bite folks. My attempt to set the default to be 30 seconds helped there, but caused trouble and delays for the NFS case, and "don't break existing users" seemed to rule, so I set the default timeout back to 0. > > It doesn't seem necessary in this case, but I suggested it here as > > I've got it enabled by default in my AOSP builds so that the > > module-heavy configs for GKI boot properly (even if Saravana's > > fw_devlink work is disabled). > > > > With all due respect, that's your downstream kernel, the upstream kernel > should not rely on luck, out-of-tree patches or kernel parameters. I agree that would be preferred. But kernel parameters are often there for these sorts of cases where we can't always do the right thing. As for out-of-tree patches, broken things don't get fixed until out-of-tree patches are developed and upstreamed, and I know Saravana is doing exactly that, and I hope his fw_devlink work helps fix it so the module loading is not just a matter of luck. Also I think Thierry's comments in the other thread today are also good ideas for ways to better handle the optional dt link handling (rather than using a timeout). thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 2:48 ` John Stultz (?) @ 2020-08-07 3:02 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:02 UTC (permalink / raw) To: John Stultz Cc: Bjorn Andersson, Steev Klimaszewski, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). Only > later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. As > for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. Btw, the only downstream fw_devlink change is setting itto =on (vs =permissive in upstream). > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). Could you please give me a lore link to this thread? Just curious. -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:02 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:02 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). Only > later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. As > for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. Btw, the only downstream fw_devlink change is setting itto =on (vs =permissive in upstream). > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). Could you please give me a lore link to this thread? Just curious. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:02 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:02 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). Only > later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. As > for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. Btw, the only downstream fw_devlink change is setting itto =on (vs =permissive in upstream). > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). Could you please give me a lore link to this thread? Just curious. -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 3:02 ` Saravana Kannan (?) @ 2020-08-07 3:09 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 3:09 UTC (permalink / raw) To: Saravana Kannan Cc: Bjorn Andersson, Steev Klimaszewski, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. As > > for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > Btw, the only downstream fw_devlink change is setting itto =on (vs > =permissive in upstream). I thought there was the clk_sync_state stuff as well? > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > Could you please give me a lore link to this thread? Just curious. Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:09 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 3:09 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. As > > for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > Btw, the only downstream fw_devlink change is setting itto =on (vs > =permissive in upstream). I thought there was the clk_sync_state stuff as well? > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > Could you please give me a lore link to this thread? Just curious. Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:09 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-07 3:09 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. As > > for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > Btw, the only downstream fw_devlink change is setting itto =on (vs > =permissive in upstream). I thought there was the clk_sync_state stuff as well? > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > Could you please give me a lore link to this thread? Just curious. Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 3:09 ` John Stultz (?) @ 2020-08-07 3:12 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:12 UTC (permalink / raw) To: John Stultz Cc: Bjorn Andersson, Steev Klimaszewski, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding On Thu, Aug 6, 2020 at 8:09 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > > > I agree that would be preferred. But kernel parameters are often there > > > for these sorts of cases where we can't always do the right thing. As > > > for out-of-tree patches, broken things don't get fixed until > > > out-of-tree patches are developed and upstreamed, and I know Saravana > > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > > the module loading is not just a matter of luck. > > > > Btw, the only downstream fw_devlink change is setting itto =on (vs > > =permissive in upstream). > > I thought there was the clk_sync_state stuff as well? That's not needed to solve the module load ordering issues and deferred probe issues. That's only needed to keep clocks on till some of the modules are loaded and it depends on fw_devlink, but not really a part of fw_devlink IMHO. And yes, that's on my list of things to upstream. > > > Also I think Thierry's comments in the other thread today are also > > > good ideas for ways to better handle the optional dt link handling > > > (rather than using a timeout). > > > > Could you please give me a lore link to this thread? Just curious. > > Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ Thanks. -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:12 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:12 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 8:09 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > > > I agree that would be preferred. But kernel parameters are often there > > > for these sorts of cases where we can't always do the right thing. As > > > for out-of-tree patches, broken things don't get fixed until > > > out-of-tree patches are developed and upstreamed, and I know Saravana > > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > > the module loading is not just a matter of luck. > > > > Btw, the only downstream fw_devlink change is setting itto =on (vs > > =permissive in upstream). > > I thought there was the clk_sync_state stuff as well? That's not needed to solve the module load ordering issues and deferred probe issues. That's only needed to keep clocks on till some of the modules are loaded and it depends on fw_devlink, but not really a part of fw_devlink IMHO. And yes, that's on my list of things to upstream. > > > Also I think Thierry's comments in the other thread today are also > > > good ideas for ways to better handle the optional dt link handling > > > (rather than using a timeout). > > > > Could you please give me a lore link to this thread? Just curious. > > Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ Thanks. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 3:12 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 3:12 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 8:09 PM John Stultz <john.stultz@linaro.org> wrote: > > On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@google.com> wrote: > > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@linaro.org> wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > > > I agree that would be preferred. But kernel parameters are often there > > > for these sorts of cases where we can't always do the right thing. As > > > for out-of-tree patches, broken things don't get fixed until > > > out-of-tree patches are developed and upstreamed, and I know Saravana > > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > > the module loading is not just a matter of luck. > > > > Btw, the only downstream fw_devlink change is setting itto =on (vs > > =permissive in upstream). > > I thought there was the clk_sync_state stuff as well? That's not needed to solve the module load ordering issues and deferred probe issues. That's only needed to keep clocks on till some of the modules are loaded and it depends on fw_devlink, but not really a part of fw_devlink IMHO. And yes, that's on my list of things to upstream. > > > Also I think Thierry's comments in the other thread today are also > > > good ideas for ways to better handle the optional dt link handling > > > (rather than using a timeout). > > > > Could you please give me a lore link to this thread? Just curious. > > Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/ Thanks. -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 2:48 ` John Stultz (?) @ 2020-08-07 5:58 ` Bjorn Andersson -1 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 5:58 UTC (permalink / raw) To: John Stultz Cc: Steev Klimaszewski, Saravana Kannan, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). I did object when this was proposed and I've objected for the last two years, because we keep adding more and more subsystems to follow this broken behavior. > Only later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > I can't argue with that and I'm at loss on how to turn this around. > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. > As for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. > I don't agree with this, upstream should be functional in its default configuration. Out-of-tree patches might be necessary to enable features or get the most out of the hardware, but what we have upstream should work. And no, this is not always the case, but we should at least aim for this. > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). > I'll take a look at that, but to repeat what I've said many times before, for Qualcomm platforms there's pretty much no such thing as optional links. Regards, Bjorn ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 5:58 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 5:58 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). I did object when this was proposed and I've objected for the last two years, because we keep adding more and more subsystems to follow this broken behavior. > Only later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > I can't argue with that and I'm at loss on how to turn this around. > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. > As for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. > I don't agree with this, upstream should be functional in its default configuration. Out-of-tree patches might be necessary to enable features or get the most out of the hardware, but what we have upstream should work. And no, this is not always the case, but we should at least aim for this. > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). > I'll take a look at that, but to repeat what I've said many times before, for Qualcomm platforms there's pretty much no such thing as optional links. Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 5:58 ` Bjorn Andersson 0 siblings, 0 replies; 93+ messages in thread From: Bjorn Andersson @ 2020-08-07 5:58 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thierry Reding, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > >>> <sigh> > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > >>> Saravana's macro magic. > > > > > > >>> > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > >>> building the driver in. > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > >> at the code delta. > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > allow me to boot again. > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > a module or built-in. > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > more grace time to load. > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > please don't upstream anything that depend this parameter to be > > > > increased. > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > pass additional kernel command line parameters in order to get their > > > > device to boot. > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > avoid it. But the reality is that it is already required (at least in > > > configurations heavily using modules) to give more time for modules > > > loaded to resolve missing dependencies after init begins (due to > > > changes in the driver core to fail loading after init so that optional > > > dt links aren't eternally looked for). This was seen when trying to > > > enable the qualcom clk drivers to modules. > > > > > > > So to clarify what you're saying, any system that boots successfully > > with the default options is a sign of pure luck - regardless of being > > builtin or modules. > > > > > > And there you have my exact argument against the deferred timeout magic > > going on in the driver core. But as you know people insist that it's > > more important to be able to boot some defunct system from NFS than a > > properly configured one reliably. > > I'd agree, but the NFS case was in use before, and when the original > deferred timeout/optional link handling stuff landed no one complained > they were broken by it (at least at the point where it landed). I did object when this was proposed and I've objected for the last two years, because we keep adding more and more subsystems to follow this broken behavior. > Only later when we started enabling more lower-level core drivers as > modules did the shortened dependency resolution time start to bite > folks. My attempt to set the default to be 30 seconds helped there, > but caused trouble and delays for the NFS case, and "don't break > existing users" seemed to rule, so I set the default timeout back to > 0. > I can't argue with that and I'm at loss on how to turn this around. > > > It doesn't seem necessary in this case, but I suggested it here as > > > I've got it enabled by default in my AOSP builds so that the > > > module-heavy configs for GKI boot properly (even if Saravana's > > > fw_devlink work is disabled). > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > should not rely on luck, out-of-tree patches or kernel parameters. > > I agree that would be preferred. But kernel parameters are often there > for these sorts of cases where we can't always do the right thing. > As for out-of-tree patches, broken things don't get fixed until > out-of-tree patches are developed and upstreamed, and I know Saravana > is doing exactly that, and I hope his fw_devlink work helps fix it so > the module loading is not just a matter of luck. > I don't agree with this, upstream should be functional in its default configuration. Out-of-tree patches might be necessary to enable features or get the most out of the hardware, but what we have upstream should work. And no, this is not always the case, but we should at least aim for this. > Also I think Thierry's comments in the other thread today are also > good ideas for ways to better handle the optional dt link handling > (rather than using a timeout). > I'll take a look at that, but to repeat what I've said many times before, for Qualcomm platforms there's pretty much no such thing as optional links. Regards, Bjorn _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-07 5:58 ` Bjorn Andersson (?) @ 2020-08-07 6:22 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 6:22 UTC (permalink / raw) To: Bjorn Andersson Cc: John Stultz, Steev Klimaszewski, Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Thierry Reding, Nicolas Saenz Julienne On Thu, Aug 6, 2020 at 10:58 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > > <bjorn.andersson@linaro.org> wrote: > > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > > >>> <sigh> > > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > > >>> Saravana's macro magic. > > > > > > > >>> > > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > > >>> building the driver in. > > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > > >> at the code delta. > > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > > allow me to boot again. > > > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > > a module or built-in. > > > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > > more grace time to load. > > > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > > please don't upstream anything that depend this parameter to be > > > > > increased. > > > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > > pass additional kernel command line parameters in order to get their > > > > > device to boot. > > > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > > avoid it. But the reality is that it is already required (at least in > > > > configurations heavily using modules) to give more time for modules > > > > loaded to resolve missing dependencies after init begins (due to > > > > changes in the driver core to fail loading after init so that optional > > > > dt links aren't eternally looked for). This was seen when trying to > > > > enable the qualcom clk drivers to modules. > > > > > > > > > > So to clarify what you're saying, any system that boots successfully > > > with the default options is a sign of pure luck - regardless of being > > > builtin or modules. > > > > > > > > > And there you have my exact argument against the deferred timeout magic > > > going on in the driver core. But as you know people insist that it's > > > more important to be able to boot some defunct system from NFS than a > > > properly configured one reliably. > > > > I'd agree, but the NFS case was in use before, and when the original > > deferred timeout/optional link handling stuff landed no one complained > > they were broken by it (at least at the point where it landed). > > I did object when this was proposed and I've objected for the last two > years, because we keep adding more and more subsystems to follow this > broken behavior. > > > Only later when we started enabling more lower-level core drivers as > > modules did the shortened dependency resolution time start to bite > > folks. My attempt to set the default to be 30 seconds helped there, > > but caused trouble and delays for the NFS case, and "don't break > > existing users" seemed to rule, so I set the default timeout back to > > 0. > > > > I can't argue with that and I'm at loss on how to turn this around. > > > > > It doesn't seem necessary in this case, but I suggested it here as > > > > I've got it enabled by default in my AOSP builds so that the > > > > module-heavy configs for GKI boot properly (even if Saravana's > > > > fw_devlink work is disabled). > > > > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. > > As for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > > > I don't agree with this, upstream should be functional in its default > configuration. Out-of-tree patches might be necessary to enable features > or get the most out of the hardware, but what we have upstream should > work. And no, this is not always the case, but we should at least aim > for this. > > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > > > I'll take a look at that, but to repeat what I've said many times > before, for Qualcomm platforms there's pretty much no such thing as > optional links. Nicolas had suggested earlier that we could have a way to enable fw_devlink=on in DT under the "chosen" node. I liked that idea, but wasn't sure how easy it would be to convince DT maintainers to allow it. If that happens, we could just set that and not have to worry about these timeouts for QC platforms. Not sure how easy it is to update DT in a DB 845c though. But for cases where DT can't be updated, we'd still have the crappy timeout to plaster over the issue. Something like this or whatever sensible name that suggests that the dependencies in DT are reliable enough to use for probe ordering, deferred probe, etc. Then once that's there, we can turn on fw_devlink=on and that'd completely skip this timeout code path (and has a bunch of other benefits). chosen { linux,reliable-dt-dependencies; } Just some food for thought. Also, Thierry's idea would work, but it'll need changes to multiple drivers. Also, I don't think it'll work for drivers that'll need to ignore vs not ignore dependencies based on what board they are used in. It's still better than the blind timeout though. -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 6:22 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 6:22 UTC (permalink / raw) To: Bjorn Andersson Cc: Thierry Reding, CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, John Stultz, Nicolas Saenz Julienne, linux-arm-msm, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 10:58 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > > <bjorn.andersson@linaro.org> wrote: > > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > > >>> <sigh> > > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > > >>> Saravana's macro magic. > > > > > > > >>> > > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > > >>> building the driver in. > > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > > >> at the code delta. > > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > > allow me to boot again. > > > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > > a module or built-in. > > > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > > more grace time to load. > > > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > > please don't upstream anything that depend this parameter to be > > > > > increased. > > > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > > pass additional kernel command line parameters in order to get their > > > > > device to boot. > > > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > > avoid it. But the reality is that it is already required (at least in > > > > configurations heavily using modules) to give more time for modules > > > > loaded to resolve missing dependencies after init begins (due to > > > > changes in the driver core to fail loading after init so that optional > > > > dt links aren't eternally looked for). This was seen when trying to > > > > enable the qualcom clk drivers to modules. > > > > > > > > > > So to clarify what you're saying, any system that boots successfully > > > with the default options is a sign of pure luck - regardless of being > > > builtin or modules. > > > > > > > > > And there you have my exact argument against the deferred timeout magic > > > going on in the driver core. But as you know people insist that it's > > > more important to be able to boot some defunct system from NFS than a > > > properly configured one reliably. > > > > I'd agree, but the NFS case was in use before, and when the original > > deferred timeout/optional link handling stuff landed no one complained > > they were broken by it (at least at the point where it landed). > > I did object when this was proposed and I've objected for the last two > years, because we keep adding more and more subsystems to follow this > broken behavior. > > > Only later when we started enabling more lower-level core drivers as > > modules did the shortened dependency resolution time start to bite > > folks. My attempt to set the default to be 30 seconds helped there, > > but caused trouble and delays for the NFS case, and "don't break > > existing users" seemed to rule, so I set the default timeout back to > > 0. > > > > I can't argue with that and I'm at loss on how to turn this around. > > > > > It doesn't seem necessary in this case, but I suggested it here as > > > > I've got it enabled by default in my AOSP builds so that the > > > > module-heavy configs for GKI boot properly (even if Saravana's > > > > fw_devlink work is disabled). > > > > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. > > As for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > > > I don't agree with this, upstream should be functional in its default > configuration. Out-of-tree patches might be necessary to enable features > or get the most out of the hardware, but what we have upstream should > work. And no, this is not always the case, but we should at least aim > for this. > > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > > > I'll take a look at that, but to repeat what I've said many times > before, for Qualcomm platforms there's pretty much no such thing as > optional links. Nicolas had suggested earlier that we could have a way to enable fw_devlink=on in DT under the "chosen" node. I liked that idea, but wasn't sure how easy it would be to convince DT maintainers to allow it. If that happens, we could just set that and not have to worry about these timeouts for QC platforms. Not sure how easy it is to update DT in a DB 845c though. But for cases where DT can't be updated, we'd still have the crappy timeout to plaster over the issue. Something like this or whatever sensible name that suggests that the dependencies in DT are reliable enough to use for probe ordering, deferred probe, etc. Then once that's there, we can turn on fw_devlink=on and that'd completely skip this timeout code path (and has a bunch of other benefits). chosen { linux,reliable-dt-dependencies; } Just some food for thought. Also, Thierry's idea would work, but it'll need changes to multiple drivers. Also, I don't think it'll work for drivers that'll need to ignore vs not ignore dependencies based on what board they are used in. It's still better than the blind timeout though. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-07 6:22 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-07 6:22 UTC (permalink / raw) To: Bjorn Andersson Cc: Thierry Reding, CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Andy Gross, John Stultz, Nicolas Saenz Julienne, linux-arm-msm, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Aug 6, 2020 at 10:58 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Thu 06 Aug 19:48 PDT 2020, John Stultz wrote: > > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > > > > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > > > > <bjorn.andersson@linaro.org> wrote: > > > > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@kali.org> wrote: > > > > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > > > > > > >>> <sigh> > > > > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > > > > >>> patch series out, as I had success with a much older version of > > > > > > > >>> Saravana's macro magic. > > > > > > > >>> > > > > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > > > > >>> building the driver in. > > > > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > > > > >> at the code delta. > > > > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > > > > to get debug output on the C630. > > > > > > > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > > > > allow me to boot again. > > > > > > > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > > > > a module or built-in. > > > > > > > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > > > > more grace time to load. > > > > > > > > > > With the risk of me reading more into this than what you're saying, > > > > > please don't upstream anything that depend this parameter to be > > > > > increased. > > > > > > > > > > Compiling any of these drivers as module should not require the user to > > > > > pass additional kernel command line parameters in order to get their > > > > > device to boot. > > > > > > > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > > > > avoid it. But the reality is that it is already required (at least in > > > > configurations heavily using modules) to give more time for modules > > > > loaded to resolve missing dependencies after init begins (due to > > > > changes in the driver core to fail loading after init so that optional > > > > dt links aren't eternally looked for). This was seen when trying to > > > > enable the qualcom clk drivers to modules. > > > > > > > > > > So to clarify what you're saying, any system that boots successfully > > > with the default options is a sign of pure luck - regardless of being > > > builtin or modules. > > > > > > > > > And there you have my exact argument against the deferred timeout magic > > > going on in the driver core. But as you know people insist that it's > > > more important to be able to boot some defunct system from NFS than a > > > properly configured one reliably. > > > > I'd agree, but the NFS case was in use before, and when the original > > deferred timeout/optional link handling stuff landed no one complained > > they were broken by it (at least at the point where it landed). > > I did object when this was proposed and I've objected for the last two > years, because we keep adding more and more subsystems to follow this > broken behavior. > > > Only later when we started enabling more lower-level core drivers as > > modules did the shortened dependency resolution time start to bite > > folks. My attempt to set the default to be 30 seconds helped there, > > but caused trouble and delays for the NFS case, and "don't break > > existing users" seemed to rule, so I set the default timeout back to > > 0. > > > > I can't argue with that and I'm at loss on how to turn this around. > > > > > It doesn't seem necessary in this case, but I suggested it here as > > > > I've got it enabled by default in my AOSP builds so that the > > > > module-heavy configs for GKI boot properly (even if Saravana's > > > > fw_devlink work is disabled). > > > > > > > > > > With all due respect, that's your downstream kernel, the upstream kernel > > > should not rely on luck, out-of-tree patches or kernel parameters. > > > > I agree that would be preferred. But kernel parameters are often there > > for these sorts of cases where we can't always do the right thing. > > As for out-of-tree patches, broken things don't get fixed until > > out-of-tree patches are developed and upstreamed, and I know Saravana > > is doing exactly that, and I hope his fw_devlink work helps fix it so > > the module loading is not just a matter of luck. > > > > I don't agree with this, upstream should be functional in its default > configuration. Out-of-tree patches might be necessary to enable features > or get the most out of the hardware, but what we have upstream should > work. And no, this is not always the case, but we should at least aim > for this. > > > Also I think Thierry's comments in the other thread today are also > > good ideas for ways to better handle the optional dt link handling > > (rather than using a timeout). > > > > I'll take a look at that, but to repeat what I've said many times > before, for Qualcomm platforms there's pretty much no such thing as > optional links. Nicolas had suggested earlier that we could have a way to enable fw_devlink=on in DT under the "chosen" node. I liked that idea, but wasn't sure how easy it would be to convince DT maintainers to allow it. If that happens, we could just set that and not have to worry about these timeouts for QC platforms. Not sure how easy it is to update DT in a DB 845c though. But for cases where DT can't be updated, we'd still have the crappy timeout to plaster over the issue. Something like this or whatever sensible name that suggests that the dependencies in DT are reliable enough to use for probe ordering, deferred probe, etc. Then once that's there, we can turn on fw_devlink=on and that'd completely skip this timeout code path (and has a bunch of other benefits). chosen { linux,reliable-dt-dependencies; } Just some food for thought. Also, Thierry's idea would work, but it'll need changes to multiple drivers. Also, I don't think it'll work for drivers that'll need to ignore vs not ignore dependencies based on what board they are used in. It's still better than the blind timeout though. -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-05 20:19 ` Saravana Kannan (?) @ 2020-08-06 1:24 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 1:24 UTC (permalink / raw) To: Saravana Kannan Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > > > Switch the driver to use the helper macros. In addition to reducing the > > > number of lines, this also adds module unload protection (if the driver > > > is compiled as a module) by switching from module_platform_driver to > > > builtin_platform_driver. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > --- > > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > > index 5b624e3295e4..c1c5dfad57cc 100644 > > > --- a/drivers/irqchip/qcom-pdc.c > > > +++ b/drivers/irqchip/qcom-pdc.c > > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > > return ret; > > > } > > > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > > -{ > > > - struct device_node *np = pdev->dev.of_node; > > > - struct device_node *parent = of_irq_find_parent(np); > > > - > > > - return qcom_pdc_init(np, parent); > > > -} > > > - > > > -static const struct of_device_id qcom_pdc_match_table[] = { > > > - { .compatible = "qcom,pdc" }, > > > - {} > > > -}; > > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > > - > > > -static struct platform_driver qcom_pdc_driver = { > > > - .probe = qcom_pdc_probe, > > > - .driver = { > > > - .name = "qcom-pdc", > > > - .of_match_table = qcom_pdc_match_table, > > > - .suppress_bind_attrs = true, > > > - }, > > > -}; > > > -module_platform_driver(qcom_pdc_driver); > > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > > MODULE_LICENSE("GPL v2"); > > > > <sigh> > > So this is where I bashfully admit I didn't get a chance to try this > > patch series out, as I had success with a much older version of > > Saravana's macro magic. > > > > But unfortunately, now that this has landed in mainline, I'm seeing > > boot regressions on db845c. :( This is in the non-modular case, > > building the driver in. > > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. I've not yet tested with modules with your patch. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; Yep. We're getting caught on the irq_find_matching_host() check. I'm a little lost as when I look at the qcom,pdc node in the dtsi its not under a parent controller (instead the soc node). Not sure if that's an issue in the dtsi or if par_np check needs to ignore the soc node and pass null? thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 1:24 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 1:24 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > > > Switch the driver to use the helper macros. In addition to reducing the > > > number of lines, this also adds module unload protection (if the driver > > > is compiled as a module) by switching from module_platform_driver to > > > builtin_platform_driver. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > --- > > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > > index 5b624e3295e4..c1c5dfad57cc 100644 > > > --- a/drivers/irqchip/qcom-pdc.c > > > +++ b/drivers/irqchip/qcom-pdc.c > > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > > return ret; > > > } > > > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > > -{ > > > - struct device_node *np = pdev->dev.of_node; > > > - struct device_node *parent = of_irq_find_parent(np); > > > - > > > - return qcom_pdc_init(np, parent); > > > -} > > > - > > > -static const struct of_device_id qcom_pdc_match_table[] = { > > > - { .compatible = "qcom,pdc" }, > > > - {} > > > -}; > > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > > - > > > -static struct platform_driver qcom_pdc_driver = { > > > - .probe = qcom_pdc_probe, > > > - .driver = { > > > - .name = "qcom-pdc", > > > - .of_match_table = qcom_pdc_match_table, > > > - .suppress_bind_attrs = true, > > > - }, > > > -}; > > > -module_platform_driver(qcom_pdc_driver); > > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > > MODULE_LICENSE("GPL v2"); > > > > <sigh> > > So this is where I bashfully admit I didn't get a chance to try this > > patch series out, as I had success with a much older version of > > Saravana's macro magic. > > > > But unfortunately, now that this has landed in mainline, I'm seeing > > boot regressions on db845c. :( This is in the non-modular case, > > building the driver in. > > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. I've not yet tested with modules with your patch. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; Yep. We're getting caught on the irq_find_matching_host() check. I'm a little lost as when I look at the qcom,pdc node in the dtsi its not under a parent controller (instead the soc node). Not sure if that's an issue in the dtsi or if par_np check needs to ignore the soc node and pass null? thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 1:24 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 1:24 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Hanks Chen, Loda Chou, lkml, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > > > > > > Switch the driver to use the helper macros. In addition to reducing the > > > number of lines, this also adds module unload protection (if the driver > > > is compiled as a module) by switching from module_platform_driver to > > > builtin_platform_driver. > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > --- > > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > > > 1 file changed, 3 insertions(+), 23 deletions(-) > > > > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > > index 5b624e3295e4..c1c5dfad57cc 100644 > > > --- a/drivers/irqchip/qcom-pdc.c > > > +++ b/drivers/irqchip/qcom-pdc.c > > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > > > return ret; > > > } > > > > > > -static int qcom_pdc_probe(struct platform_device *pdev) > > > -{ > > > - struct device_node *np = pdev->dev.of_node; > > > - struct device_node *parent = of_irq_find_parent(np); > > > - > > > - return qcom_pdc_init(np, parent); > > > -} > > > - > > > -static const struct of_device_id qcom_pdc_match_table[] = { > > > - { .compatible = "qcom,pdc" }, > > > - {} > > > -}; > > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > > > - > > > -static struct platform_driver qcom_pdc_driver = { > > > - .probe = qcom_pdc_probe, > > > - .driver = { > > > - .name = "qcom-pdc", > > > - .of_match_table = qcom_pdc_match_table, > > > - .suppress_bind_attrs = true, > > > - }, > > > -}; > > > -module_platform_driver(qcom_pdc_driver); > > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > > > MODULE_LICENSE("GPL v2"); > > > > <sigh> > > So this is where I bashfully admit I didn't get a chance to try this > > patch series out, as I had success with a much older version of > > Saravana's macro magic. > > > > But unfortunately, now that this has landed in mainline, I'm seeing > > boot regressions on db845c. :( This is in the non-modular case, > > building the driver in. > > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. I've not yet tested with modules with your patch. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; Yep. We're getting caught on the irq_find_matching_host() check. I'm a little lost as when I look at the qcom,pdc node in the dtsi its not under a parent controller (instead the soc node). Not sure if that's an issue in the dtsi or if par_np check needs to ignore the soc node and pass null? thanks -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 1:24 ` John Stultz (?) @ 2020-08-06 8:49 ` Marc Zyngier -1 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 8:49 UTC (permalink / raw) To: John Stultz Cc: Saravana Kannan, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, steev On 2020-08-06 02:24, John Stultz wrote: > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> >> wrote: >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: >> > > >> > > Switch the driver to use the helper macros. In addition to reducing the >> > > number of lines, this also adds module unload protection (if the driver >> > > is compiled as a module) by switching from module_platform_driver to >> > > builtin_platform_driver. >> > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> >> > > --- >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- >> > > 1 file changed, 3 insertions(+), 23 deletions(-) >> > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c >> > > index 5b624e3295e4..c1c5dfad57cc 100644 >> > > --- a/drivers/irqchip/qcom-pdc.c >> > > +++ b/drivers/irqchip/qcom-pdc.c >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) >> > > return ret; >> > > } >> > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) >> > > -{ >> > > - struct device_node *np = pdev->dev.of_node; >> > > - struct device_node *parent = of_irq_find_parent(np); >> > > - >> > > - return qcom_pdc_init(np, parent); >> > > -} >> > > - >> > > -static const struct of_device_id qcom_pdc_match_table[] = { >> > > - { .compatible = "qcom,pdc" }, >> > > - {} >> > > -}; >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); >> > > - >> > > -static struct platform_driver qcom_pdc_driver = { >> > > - .probe = qcom_pdc_probe, >> > > - .driver = { >> > > - .name = "qcom-pdc", >> > > - .of_match_table = qcom_pdc_match_table, >> > > - .suppress_bind_attrs = true, >> > > - }, >> > > -}; >> > > -module_platform_driver(qcom_pdc_driver); >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); >> > > MODULE_LICENSE("GPL v2"); >> > >> > <sigh> >> > So this is where I bashfully admit I didn't get a chance to try this >> > patch series out, as I had success with a much older version of >> > Saravana's macro magic. >> > >> > But unfortunately, now that this has landed in mainline, I'm seeing >> > boot regressions on db845c. :( This is in the non-modular case, >> > building the driver in. >> >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > > I've not yet tested with modules with your patch. > >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent >> irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > little lost as when I look at the qcom,pdc node in the dtsi its not > under a parent controller (instead the soc node). > Not sure if that's an issue in the dtsi or if par_np check needs to > ignore the soc node and pass null? I think you have nailed it. This checks for a domain attached to the driver we are about to probe, and this domain cannot possibly exist. Instead, it is the *parent* this should check for, as we depend on it for successful probing. Can you please give this a go? Thanks, M. diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 1bb0e36c2bf3..d2341153e181 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -52,7 +52,7 @@ int platform_irqchip_probe(struct platform_device *pdev) * interrupt controller. The actual initialization callback of this * interrupt controller can check for specific domains as necessary. */ - if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + if (par_np && !irq_find_matching_host(par_np, DOMAIN_BUS_ANY)) return -EPROBE_DEFER; return irq_init_cb(np, par_np); -- Jazz is not dead. It just smells funny... ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 8:49 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 8:49 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 2020-08-06 02:24, John Stultz wrote: > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> >> wrote: >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: >> > > >> > > Switch the driver to use the helper macros. In addition to reducing the >> > > number of lines, this also adds module unload protection (if the driver >> > > is compiled as a module) by switching from module_platform_driver to >> > > builtin_platform_driver. >> > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> >> > > --- >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- >> > > 1 file changed, 3 insertions(+), 23 deletions(-) >> > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c >> > > index 5b624e3295e4..c1c5dfad57cc 100644 >> > > --- a/drivers/irqchip/qcom-pdc.c >> > > +++ b/drivers/irqchip/qcom-pdc.c >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) >> > > return ret; >> > > } >> > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) >> > > -{ >> > > - struct device_node *np = pdev->dev.of_node; >> > > - struct device_node *parent = of_irq_find_parent(np); >> > > - >> > > - return qcom_pdc_init(np, parent); >> > > -} >> > > - >> > > -static const struct of_device_id qcom_pdc_match_table[] = { >> > > - { .compatible = "qcom,pdc" }, >> > > - {} >> > > -}; >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); >> > > - >> > > -static struct platform_driver qcom_pdc_driver = { >> > > - .probe = qcom_pdc_probe, >> > > - .driver = { >> > > - .name = "qcom-pdc", >> > > - .of_match_table = qcom_pdc_match_table, >> > > - .suppress_bind_attrs = true, >> > > - }, >> > > -}; >> > > -module_platform_driver(qcom_pdc_driver); >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); >> > > MODULE_LICENSE("GPL v2"); >> > >> > <sigh> >> > So this is where I bashfully admit I didn't get a chance to try this >> > patch series out, as I had success with a much older version of >> > Saravana's macro magic. >> > >> > But unfortunately, now that this has landed in mainline, I'm seeing >> > boot regressions on db845c. :( This is in the non-modular case, >> > building the driver in. >> >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > > I've not yet tested with modules with your patch. > >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent >> irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > little lost as when I look at the qcom,pdc node in the dtsi its not > under a parent controller (instead the soc node). > Not sure if that's an issue in the dtsi or if par_np check needs to > ignore the soc node and pass null? I think you have nailed it. This checks for a domain attached to the driver we are about to probe, and this domain cannot possibly exist. Instead, it is the *parent* this should check for, as we depend on it for successful probing. Can you please give this a go? Thanks, M. diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 1bb0e36c2bf3..d2341153e181 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -52,7 +52,7 @@ int platform_irqchip_probe(struct platform_device *pdev) * interrupt controller. The actual initialization callback of this * interrupt controller can check for specific domains as necessary. */ - if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + if (par_np && !irq_find_matching_host(par_np, DOMAIN_BUS_ANY)) return -EPROBE_DEFER; return irq_init_cb(np, par_np); -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 8:49 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 8:49 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On 2020-08-06 02:24, John Stultz wrote: > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> >> wrote: >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: >> > > >> > > Switch the driver to use the helper macros. In addition to reducing the >> > > number of lines, this also adds module unload protection (if the driver >> > > is compiled as a module) by switching from module_platform_driver to >> > > builtin_platform_driver. >> > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> >> > > --- >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- >> > > 1 file changed, 3 insertions(+), 23 deletions(-) >> > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c >> > > index 5b624e3295e4..c1c5dfad57cc 100644 >> > > --- a/drivers/irqchip/qcom-pdc.c >> > > +++ b/drivers/irqchip/qcom-pdc.c >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) >> > > return ret; >> > > } >> > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) >> > > -{ >> > > - struct device_node *np = pdev->dev.of_node; >> > > - struct device_node *parent = of_irq_find_parent(np); >> > > - >> > > - return qcom_pdc_init(np, parent); >> > > -} >> > > - >> > > -static const struct of_device_id qcom_pdc_match_table[] = { >> > > - { .compatible = "qcom,pdc" }, >> > > - {} >> > > -}; >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); >> > > - >> > > -static struct platform_driver qcom_pdc_driver = { >> > > - .probe = qcom_pdc_probe, >> > > - .driver = { >> > > - .name = "qcom-pdc", >> > > - .of_match_table = qcom_pdc_match_table, >> > > - .suppress_bind_attrs = true, >> > > - }, >> > > -}; >> > > -module_platform_driver(qcom_pdc_driver); >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); >> > > MODULE_LICENSE("GPL v2"); >> > >> > <sigh> >> > So this is where I bashfully admit I didn't get a chance to try this >> > patch series out, as I had success with a much older version of >> > Saravana's macro magic. >> > >> > But unfortunately, now that this has landed in mainline, I'm seeing >> > boot regressions on db845c. :( This is in the non-modular case, >> > building the driver in. >> >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > > I've not yet tested with modules with your patch. > >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent >> irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > little lost as when I look at the qcom,pdc node in the dtsi its not > under a parent controller (instead the soc node). > Not sure if that's an issue in the dtsi or if par_np check needs to > ignore the soc node and pass null? I think you have nailed it. This checks for a domain attached to the driver we are about to probe, and this domain cannot possibly exist. Instead, it is the *parent* this should check for, as we depend on it for successful probing. Can you please give this a go? Thanks, M. diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c index 1bb0e36c2bf3..d2341153e181 100644 --- a/drivers/irqchip/irqchip.c +++ b/drivers/irqchip/irqchip.c @@ -52,7 +52,7 @@ int platform_irqchip_probe(struct platform_device *pdev) * interrupt controller. The actual initialization callback of this * interrupt controller can check for specific domains as necessary. */ - if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) + if (par_np && !irq_find_matching_host(par_np, DOMAIN_BUS_ANY)) return -EPROBE_DEFER; return irq_init_cb(np, par_np); -- Jazz is not dead. It just smells funny... _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 8:49 ` Marc Zyngier (?) @ 2020-08-06 18:05 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 18:05 UTC (permalink / raw) To: Marc Zyngier Cc: John Stultz, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, steev, Nial Peters On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 02:24, John Stultz wrote: > > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > > wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> > >> wrote: > >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > >> > > > >> > > Switch the driver to use the helper macros. In addition to reducing the > >> > > number of lines, this also adds module unload protection (if the driver > >> > > is compiled as a module) by switching from module_platform_driver to > >> > > builtin_platform_driver. > >> > > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> > >> > > --- > >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > >> > > 1 file changed, 3 insertions(+), 23 deletions(-) > >> > > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > >> > > index 5b624e3295e4..c1c5dfad57cc 100644 > >> > > --- a/drivers/irqchip/qcom-pdc.c > >> > > +++ b/drivers/irqchip/qcom-pdc.c > >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > >> > > return ret; > >> > > } > >> > > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) > >> > > -{ > >> > > - struct device_node *np = pdev->dev.of_node; > >> > > - struct device_node *parent = of_irq_find_parent(np); > >> > > - > >> > > - return qcom_pdc_init(np, parent); > >> > > -} > >> > > - > >> > > -static const struct of_device_id qcom_pdc_match_table[] = { > >> > > - { .compatible = "qcom,pdc" }, > >> > > - {} > >> > > -}; > >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > >> > > - > >> > > -static struct platform_driver qcom_pdc_driver = { > >> > > - .probe = qcom_pdc_probe, > >> > > - .driver = { > >> > > - .name = "qcom-pdc", > >> > > - .of_match_table = qcom_pdc_match_table, > >> > > - .suppress_bind_attrs = true, > >> > > - }, > >> > > -}; > >> > > -module_platform_driver(qcom_pdc_driver); > >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > >> > > MODULE_LICENSE("GPL v2"); > >> > > >> > <sigh> > >> > So this is where I bashfully admit I didn't get a chance to try this > >> > patch series out, as I had success with a much older version of > >> > Saravana's macro magic. > >> > > >> > But unfortunately, now that this has landed in mainline, I'm seeing > >> > boot regressions on db845c. :( This is in the non-modular case, > >> > building the driver in. > >> > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > > > I've not yet tested with modules with your patch. > > > >> The only significant change from what your probe function is doing is > >> this snippet. But it'd be surprising if this only affects the builtin > >> case. > >> > >> + if (par_np == np) > >> + par_np = NULL; > >> + > >> + /* > >> + * If there's a parent interrupt controller and none of the parent > >> irq > >> + * domains have been registered, that means the parent interrupt > >> + * controller has not been initialized yet. it's not time for this > >> + * interrupt controller to initialize. So, defer probe of this > >> + * interrupt controller. The actual initialization callback of this > >> + * interrupt controller can check for specific domains as necessary. > >> + */ > >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > >> + return -EPROBE_DEFER; > > > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > > little lost as when I look at the qcom,pdc node in the dtsi its not > > under a parent controller (instead the soc node). > > Not sure if that's an issue in the dtsi or if par_np check needs to > > ignore the soc node and pass null? > > I think you have nailed it. This checks for a domain attached to > the driver we are about to probe, and this domain cannot possibly > exist. Instead, it is the *parent* this should check for, as we > depend on it for successful probing. Duh! Looks like I made a copy-paste/typo error. The comment clearly says I'm trying to check the parent and then I end up checking the node getting registered. I'm sure this will fix it. Actually Nial sent an email a few hours after your and he had found the same issue. He even tested the fix with an irqchip driver and it fixed the probe issue. I'm assuming you'll put up the patch yourself. Please let me know if you need me to send one. Thanks, Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 18:05 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 18:05 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 02:24, John Stultz wrote: > > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > > wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> > >> wrote: > >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > >> > > > >> > > Switch the driver to use the helper macros. In addition to reducing the > >> > > number of lines, this also adds module unload protection (if the driver > >> > > is compiled as a module) by switching from module_platform_driver to > >> > > builtin_platform_driver. > >> > > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> > >> > > --- > >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > >> > > 1 file changed, 3 insertions(+), 23 deletions(-) > >> > > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > >> > > index 5b624e3295e4..c1c5dfad57cc 100644 > >> > > --- a/drivers/irqchip/qcom-pdc.c > >> > > +++ b/drivers/irqchip/qcom-pdc.c > >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > >> > > return ret; > >> > > } > >> > > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) > >> > > -{ > >> > > - struct device_node *np = pdev->dev.of_node; > >> > > - struct device_node *parent = of_irq_find_parent(np); > >> > > - > >> > > - return qcom_pdc_init(np, parent); > >> > > -} > >> > > - > >> > > -static const struct of_device_id qcom_pdc_match_table[] = { > >> > > - { .compatible = "qcom,pdc" }, > >> > > - {} > >> > > -}; > >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > >> > > - > >> > > -static struct platform_driver qcom_pdc_driver = { > >> > > - .probe = qcom_pdc_probe, > >> > > - .driver = { > >> > > - .name = "qcom-pdc", > >> > > - .of_match_table = qcom_pdc_match_table, > >> > > - .suppress_bind_attrs = true, > >> > > - }, > >> > > -}; > >> > > -module_platform_driver(qcom_pdc_driver); > >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > >> > > MODULE_LICENSE("GPL v2"); > >> > > >> > <sigh> > >> > So this is where I bashfully admit I didn't get a chance to try this > >> > patch series out, as I had success with a much older version of > >> > Saravana's macro magic. > >> > > >> > But unfortunately, now that this has landed in mainline, I'm seeing > >> > boot regressions on db845c. :( This is in the non-modular case, > >> > building the driver in. > >> > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > > > I've not yet tested with modules with your patch. > > > >> The only significant change from what your probe function is doing is > >> this snippet. But it'd be surprising if this only affects the builtin > >> case. > >> > >> + if (par_np == np) > >> + par_np = NULL; > >> + > >> + /* > >> + * If there's a parent interrupt controller and none of the parent > >> irq > >> + * domains have been registered, that means the parent interrupt > >> + * controller has not been initialized yet. it's not time for this > >> + * interrupt controller to initialize. So, defer probe of this > >> + * interrupt controller. The actual initialization callback of this > >> + * interrupt controller can check for specific domains as necessary. > >> + */ > >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > >> + return -EPROBE_DEFER; > > > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > > little lost as when I look at the qcom,pdc node in the dtsi its not > > under a parent controller (instead the soc node). > > Not sure if that's an issue in the dtsi or if par_np check needs to > > ignore the soc node and pass null? > > I think you have nailed it. This checks for a domain attached to > the driver we are about to probe, and this domain cannot possibly > exist. Instead, it is the *parent* this should check for, as we > depend on it for successful probing. Duh! Looks like I made a copy-paste/typo error. The comment clearly says I'm trying to check the parent and then I end up checking the node getting registered. I'm sure this will fix it. Actually Nial sent an email a few hours after your and he had found the same issue. He even tested the fix with an irqchip driver and it fixed the probe issue. I'm assuming you'll put up the patch yourself. Please let me know if you need me to send one. Thanks, Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 18:05 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 18:05 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 02:24, John Stultz wrote: > > On Wed, Aug 5, 2020 at 1:19 PM Saravana Kannan <saravanak@google.com> > > wrote: > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@linaro.org> > >> wrote: > >> > On Fri, Jul 17, 2020 at 5:06 PM Saravana Kannan <saravanak@google.com> wrote: > >> > > > >> > > Switch the driver to use the helper macros. In addition to reducing the > >> > > number of lines, this also adds module unload protection (if the driver > >> > > is compiled as a module) by switching from module_platform_driver to > >> > > builtin_platform_driver. > >> > > > >> > > Signed-off-by: Saravana Kannan <saravanak@google.com> > >> > > --- > >> > > drivers/irqchip/qcom-pdc.c | 26 +++----------------------- > >> > > 1 file changed, 3 insertions(+), 23 deletions(-) > >> > > > >> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > >> > > index 5b624e3295e4..c1c5dfad57cc 100644 > >> > > --- a/drivers/irqchip/qcom-pdc.c > >> > > +++ b/drivers/irqchip/qcom-pdc.c > >> > > @@ -432,28 +432,8 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent) > >> > > return ret; > >> > > } > >> > > > >> > > -static int qcom_pdc_probe(struct platform_device *pdev) > >> > > -{ > >> > > - struct device_node *np = pdev->dev.of_node; > >> > > - struct device_node *parent = of_irq_find_parent(np); > >> > > - > >> > > - return qcom_pdc_init(np, parent); > >> > > -} > >> > > - > >> > > -static const struct of_device_id qcom_pdc_match_table[] = { > >> > > - { .compatible = "qcom,pdc" }, > >> > > - {} > >> > > -}; > >> > > -MODULE_DEVICE_TABLE(of, qcom_pdc_match_table); > >> > > - > >> > > -static struct platform_driver qcom_pdc_driver = { > >> > > - .probe = qcom_pdc_probe, > >> > > - .driver = { > >> > > - .name = "qcom-pdc", > >> > > - .of_match_table = qcom_pdc_match_table, > >> > > - .suppress_bind_attrs = true, > >> > > - }, > >> > > -}; > >> > > -module_platform_driver(qcom_pdc_driver); > >> > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(qcom_pdc) > >> > > +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init) > >> > > +IRQCHIP_PLATFORM_DRIVER_END(qcom_pdc) > >> > > MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Power Domain Controller"); > >> > > MODULE_LICENSE("GPL v2"); > >> > > >> > <sigh> > >> > So this is where I bashfully admit I didn't get a chance to try this > >> > patch series out, as I had success with a much older version of > >> > Saravana's macro magic. > >> > > >> > But unfortunately, now that this has landed in mainline, I'm seeing > >> > boot regressions on db845c. :( This is in the non-modular case, > >> > building the driver in. > >> > >> Does that mean the modular version is working? Or you haven't tried > >> that yet? I'll wait for your reply before I try to fix it. I don't > >> have the hardware, but it should be easy to guess this issue looking > >> at the code delta. > > > > I've not yet tested with modules with your patch. > > > >> The only significant change from what your probe function is doing is > >> this snippet. But it'd be surprising if this only affects the builtin > >> case. > >> > >> + if (par_np == np) > >> + par_np = NULL; > >> + > >> + /* > >> + * If there's a parent interrupt controller and none of the parent > >> irq > >> + * domains have been registered, that means the parent interrupt > >> + * controller has not been initialized yet. it's not time for this > >> + * interrupt controller to initialize. So, defer probe of this > >> + * interrupt controller. The actual initialization callback of this > >> + * interrupt controller can check for specific domains as necessary. > >> + */ > >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > >> + return -EPROBE_DEFER; > > > > Yep. We're getting caught on the irq_find_matching_host() check. I'm a > > little lost as when I look at the qcom,pdc node in the dtsi its not > > under a parent controller (instead the soc node). > > Not sure if that's an issue in the dtsi or if par_np check needs to > > ignore the soc node and pass null? > > I think you have nailed it. This checks for a domain attached to > the driver we are about to probe, and this domain cannot possibly > exist. Instead, it is the *parent* this should check for, as we > depend on it for successful probing. Duh! Looks like I made a copy-paste/typo error. The comment clearly says I'm trying to check the parent and then I end up checking the node getting registered. I'm sure this will fix it. Actually Nial sent an email a few hours after your and he had found the same issue. He even tested the fix with an irqchip driver and it fixed the probe issue. I'm assuming you'll put up the patch yourself. Please let me know if you need me to send one. Thanks, Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 18:05 ` Saravana Kannan (?) @ 2020-08-06 19:59 ` Marc Zyngier -1 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 19:59 UTC (permalink / raw) To: Saravana Kannan Cc: John Stultz, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, steev, Nial Peters On 2020-08-06 19:05, Saravana Kannan wrote: > On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: >> >> On 2020-08-06 02:24, John Stultz wrote: [...] >> >> + if (par_np == np) >> >> + par_np = NULL; >> >> + >> >> + /* >> >> + * If there's a parent interrupt controller and none of the parent >> >> irq >> >> + * domains have been registered, that means the parent interrupt >> >> + * controller has not been initialized yet. it's not time for this >> >> + * interrupt controller to initialize. So, defer probe of this >> >> + * interrupt controller. The actual initialization callback of this >> >> + * interrupt controller can check for specific domains as necessary. >> >> + */ >> >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> >> + return -EPROBE_DEFER; >> > >> > Yep. We're getting caught on the irq_find_matching_host() check. I'm a >> > little lost as when I look at the qcom,pdc node in the dtsi its not >> > under a parent controller (instead the soc node). >> > Not sure if that's an issue in the dtsi or if par_np check needs to >> > ignore the soc node and pass null? >> >> I think you have nailed it. This checks for a domain attached to >> the driver we are about to probe, and this domain cannot possibly >> exist. Instead, it is the *parent* this should check for, as we >> depend on it for successful probing. > > Duh! Looks like I made a copy-paste/typo error. The comment clearly > says I'm trying to check the parent and then I end up checking the > node getting registered. I'm sure this will fix it. > > Actually Nial sent an email a few hours after your and he had found > the same issue. He even tested the fix with an irqchip driver and it > fixed the probe issue. OK, thanks for confirming. It would have been good if these patches had seen a bit more testing. > > I'm assuming you'll put up the patch yourself. Please let me know if > you need me to send one. I have queued this [1] in -next. It'd be good if someone (John?) could give a Tested-by. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 19:59 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 19:59 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On 2020-08-06 19:05, Saravana Kannan wrote: > On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: >> >> On 2020-08-06 02:24, John Stultz wrote: [...] >> >> + if (par_np == np) >> >> + par_np = NULL; >> >> + >> >> + /* >> >> + * If there's a parent interrupt controller and none of the parent >> >> irq >> >> + * domains have been registered, that means the parent interrupt >> >> + * controller has not been initialized yet. it's not time for this >> >> + * interrupt controller to initialize. So, defer probe of this >> >> + * interrupt controller. The actual initialization callback of this >> >> + * interrupt controller can check for specific domains as necessary. >> >> + */ >> >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> >> + return -EPROBE_DEFER; >> > >> > Yep. We're getting caught on the irq_find_matching_host() check. I'm a >> > little lost as when I look at the qcom,pdc node in the dtsi its not >> > under a parent controller (instead the soc node). >> > Not sure if that's an issue in the dtsi or if par_np check needs to >> > ignore the soc node and pass null? >> >> I think you have nailed it. This checks for a domain attached to >> the driver we are about to probe, and this domain cannot possibly >> exist. Instead, it is the *parent* this should check for, as we >> depend on it for successful probing. > > Duh! Looks like I made a copy-paste/typo error. The comment clearly > says I'm trying to check the parent and then I end up checking the > node getting registered. I'm sure this will fix it. > > Actually Nial sent an email a few hours after your and he had found > the same issue. He even tested the fix with an irqchip driver and it > fixed the probe issue. OK, thanks for confirming. It would have been good if these patches had seen a bit more testing. > > I'm assuming you'll put up the patch yourself. Please let me know if > you need me to send one. I have queued this [1] in -next. It'd be good if someone (John?) could give a Tested-by. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 19:59 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 19:59 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, steev, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On 2020-08-06 19:05, Saravana Kannan wrote: > On Thu, Aug 6, 2020 at 5:12 AM Marc Zyngier <maz@kernel.org> wrote: >> >> On 2020-08-06 02:24, John Stultz wrote: [...] >> >> + if (par_np == np) >> >> + par_np = NULL; >> >> + >> >> + /* >> >> + * If there's a parent interrupt controller and none of the parent >> >> irq >> >> + * domains have been registered, that means the parent interrupt >> >> + * controller has not been initialized yet. it's not time for this >> >> + * interrupt controller to initialize. So, defer probe of this >> >> + * interrupt controller. The actual initialization callback of this >> >> + * interrupt controller can check for specific domains as necessary. >> >> + */ >> >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> >> + return -EPROBE_DEFER; >> > >> > Yep. We're getting caught on the irq_find_matching_host() check. I'm a >> > little lost as when I look at the qcom,pdc node in the dtsi its not >> > under a parent controller (instead the soc node). >> > Not sure if that's an issue in the dtsi or if par_np check needs to >> > ignore the soc node and pass null? >> >> I think you have nailed it. This checks for a domain attached to >> the driver we are about to probe, and this domain cannot possibly >> exist. Instead, it is the *parent* this should check for, as we >> depend on it for successful probing. > > Duh! Looks like I made a copy-paste/typo error. The comment clearly > says I'm trying to check the parent and then I end up checking the > node getting registered. I'm sure this will fix it. > > Actually Nial sent an email a few hours after your and he had found > the same issue. He even tested the fix with an irqchip driver and it > fixed the probe issue. OK, thanks for confirming. It would have been good if these patches had seen a bit more testing. > > I'm assuming you'll put up the patch yourself. Please let me know if > you need me to send one. I have queued this [1] in -next. It'd be good if someone (John?) could give a Tested-by. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next -- Jazz is not dead. It just smells funny... _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 19:59 ` Marc Zyngier (?) @ 2020-08-06 20:09 ` John Stultz -1 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 20:09 UTC (permalink / raw) To: Marc Zyngier Cc: Saravana Kannan, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Steev Klimaszewski, Nial Peters On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > OK, thanks for confirming. It would have been good if these patches > had seen a bit more testing. Yes, again, my apologies for that! > > I'm assuming you'll put up the patch yourself. Please let me know if > > you need me to send one. > > I have queued this [1] in -next. > > It'd be good if someone (John?) could give a Tested-by. Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks so much for the quick fix! -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 20:09 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 20:09 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > OK, thanks for confirming. It would have been good if these patches > had seen a bit more testing. Yes, again, my apologies for that! > > I'm assuming you'll put up the patch yourself. Please let me know if > > you need me to send one. > > I have queued this [1] in -next. > > It'd be good if someone (John?) could give a Tested-by. Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks so much for the quick fix! -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 20:09 ` John Stultz 0 siblings, 0 replies; 93+ messages in thread From: John Stultz @ 2020-08-06 20:09 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > OK, thanks for confirming. It would have been good if these patches > had seen a bit more testing. Yes, again, my apologies for that! > > I'm assuming you'll put up the patch yourself. Please let me know if > > you need me to send one. > > I have queued this [1] in -next. > > It'd be good if someone (John?) could give a Tested-by. Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks so much for the quick fix! -john _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 20:09 ` John Stultz (?) @ 2020-08-06 20:31 ` Marc Zyngier -1 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 20:31 UTC (permalink / raw) To: John Stultz Cc: Saravana Kannan, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Steev Klimaszewski, Nial Peters On 2020-08-06 21:09, John Stultz wrote: > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: >> OK, thanks for confirming. It would have been good if these patches >> had seen a bit more testing. > > Yes, again, my apologies for that! I would say this should be the job of the patch author, before anyone else. Yes, silly bugs happen. In this occurrence, it could have been avoided by just boot-testing it, though. Oh well. At least it was caught early. >> > I'm assuming you'll put up the patch yourself. Please let me know if >> > you need me to send one. >> >> I have queued this [1] in -next. >> >> It'd be good if someone (John?) could give a Tested-by. > > Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks for your patience, the reporting and testing. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 20:31 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 20:31 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On 2020-08-06 21:09, John Stultz wrote: > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: >> OK, thanks for confirming. It would have been good if these patches >> had seen a bit more testing. > > Yes, again, my apologies for that! I would say this should be the job of the patch author, before anyone else. Yes, silly bugs happen. In this occurrence, it could have been avoided by just boot-testing it, though. Oh well. At least it was caught early. >> > I'm assuming you'll put up the patch yourself. Please let me know if >> > you need me to send one. >> >> I have queued this [1] in -next. >> >> It'd be good if someone (John?) could give a Tested-by. > > Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks for your patience, the reporting and testing. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 20:31 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-08-06 20:31 UTC (permalink / raw) To: John Stultz Cc: CC Hwang, Jason Cooper, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On 2020-08-06 21:09, John Stultz wrote: > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: >> OK, thanks for confirming. It would have been good if these patches >> had seen a bit more testing. > > Yes, again, my apologies for that! I would say this should be the job of the patch author, before anyone else. Yes, silly bugs happen. In this occurrence, it could have been avoided by just boot-testing it, though. Oh well. At least it was caught early. >> > I'm assuming you'll put up the patch yourself. Please let me know if >> > you need me to send one. >> >> I have queued this [1] in -next. >> >> It'd be good if someone (John?) could give a Tested-by. > > Just validated. Tested-by: John Stultz <john.stultz@linaro.org> Thanks for your patience, the reporting and testing. M. -- Jazz is not dead. It just smells funny... _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros 2020-08-06 20:31 ` Marc Zyngier (?) @ 2020-08-06 21:16 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 21:16 UTC (permalink / raw) To: Marc Zyngier Cc: John Stultz, Thomas Gleixner, Jason Cooper, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, lkml, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Hanks Chen, CC Hwang, Loda Chou, Steev Klimaszewski, Nial Peters On Thu, Aug 6, 2020 at 1:31 PM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 21:09, John Stultz wrote: > > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > >> OK, thanks for confirming. It would have been good if these patches > >> had seen a bit more testing. > > > > Yes, again, my apologies for that! > > I would say this should be the job of the patch author, before > anyone else. Yes, silly bugs happen. In this occurrence, it > could have been avoided by just boot-testing it, though. Sorry about this. I don't have a DB 845c to test this one. I generally work with John or try and backport changes to devices I have that are running older 4.xx kernels. This one seemed harmless/simple enough that I didn't think I needed to go through all that. But obviously the few times you don't test is when things fail :-( -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 21:16 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 21:16 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 1:31 PM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 21:09, John Stultz wrote: > > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > >> OK, thanks for confirming. It would have been good if these patches > >> had seen a bit more testing. > > > > Yes, again, my apologies for that! > > I would say this should be the job of the patch author, before > anyone else. Yes, silly bugs happen. In this occurrence, it > could have been avoided by just boot-testing it, though. Sorry about this. I don't have a DB 845c to test this one. I generally work with John or try and backport changes to devices I have that are running older 4.xx kernels. This one seemed harmless/simple enough that I didn't think I needed to go through all that. But obviously the few times you don't test is when things fail :-( -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-08-06 21:16 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-08-06 21:16 UTC (permalink / raw) To: Marc Zyngier Cc: CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, lkml, Steev Klimaszewski, Bjorn Andersson, Andy Gross, John Stultz, Matthias Brugger, moderated list:ARM/Mediatek SoC support, Thomas Gleixner, Android Kernel Team, linux-arm-kernel, Nial Peters On Thu, Aug 6, 2020 at 1:31 PM Marc Zyngier <maz@kernel.org> wrote: > > On 2020-08-06 21:09, John Stultz wrote: > > On Thu, Aug 6, 2020 at 12:59 PM Marc Zyngier <maz@kernel.org> wrote: > >> OK, thanks for confirming. It would have been good if these patches > >> had seen a bit more testing. > > > > Yes, again, my apologies for that! > > I would say this should be the job of the patch author, before > anyone else. Yes, silly bugs happen. In this occurrence, it > could have been avoided by just boot-testing it, though. Sorry about this. I don't have a DB 845c to test this one. I generally work with John or try and backport changes to devices I have that are running older 4.xx kernels. This one seemed harmless/simple enough that I didn't think I needed to go through all that. But obviously the few times you don't test is when things fail :-( -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-18 0:06 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: Saravana Kannan, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, Hanks Chen, CC Hwang, Loda Chou This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c index 6ff98b87e5c0..7299c5ab4d10 100644 --- a/drivers/irqchip/irq-mtk-sysirq.c +++ b/drivers/irqchip/irq-mtk-sysirq.c @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, kfree(chip_data); return ret; } -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) -- 2.28.0.rc0.105.gf9edc3c819-goog ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c index 6ff98b87e5c0..7299c5ab4d10 100644 --- a/drivers/irqchip/irq-mtk-sysirq.c +++ b/drivers/irqchip/irq-mtk-sysirq.c @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, kfree(chip_data); return ret; } -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-sysirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c index 6ff98b87e5c0..7299c5ab4d10 100644 --- a/drivers/irqchip/irq-mtk-sysirq.c +++ b/drivers/irqchip/irq-mtk-sysirq.c @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, kfree(chip_data); return ret; } -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-23 11:42 ` Hanks Chen -1 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:42 UTC (permalink / raw) To: Saravana Kannan Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, CC Hwang, Loda Chou On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-sysirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c > index 6ff98b87e5c0..7299c5ab4d10 100644 > --- a/drivers/irqchip/irq-mtk-sysirq.c > +++ b/drivers/irqchip/irq-mtk-sysirq.c > @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, > kfree(chip_data); > return ret; > } > -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) > +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) Hi Saravana, Looks good for me to convert it to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver @ 2020-07-23 11:42 ` Hanks Chen 0 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:42 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, linux-kernel, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, kernel-team, linux-arm-kernel On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-sysirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c > index 6ff98b87e5c0..7299c5ab4d10 100644 > --- a/drivers/irqchip/irq-mtk-sysirq.c > +++ b/drivers/irqchip/irq-mtk-sysirq.c > @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, > kfree(chip_data); > return ret; > } > -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) > +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) Hi Saravana, Looks good for me to convert it to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver @ 2020-07-23 11:42 ` Hanks Chen 0 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:42 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, linux-kernel, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, kernel-team, linux-arm-kernel On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-sysirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c > index 6ff98b87e5c0..7299c5ab4d10 100644 > --- a/drivers/irqchip/irq-mtk-sysirq.c > +++ b/drivers/irqchip/irq-mtk-sysirq.c > @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node *node, > kfree(chip_data); > return ret; > } > -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq) > +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq) Hi Saravana, Looks good for me to convert it to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-18 0:06 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: Saravana Kannan, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, Hanks Chen, CC Hwang, Loda Chou This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-cirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c index 69ba8ce3c178..62a61275aaa3 100644 --- a/drivers/irqchip/irq-mtk-cirq.c +++ b/drivers/irqchip/irq-mtk-cirq.c @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, return ret; } -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) -- 2.28.0.rc0.105.gf9edc3c819-goog ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-cirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c index 69ba8ce3c178..62a61275aaa3 100644 --- a/drivers/irqchip/irq-mtk-cirq.c +++ b/drivers/irqchip/irq-mtk-cirq.c @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, return ret; } -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-18 0:06 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-18 0:06 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson Cc: CC Hwang, Saravana Kannan, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-mediatek, John Stultz, kernel-team, linux-arm-kernel This driver can work as a platform driver. So covert it to a platform driver. Signed-off-by: Saravana Kannan <saravanak@google.com> --- drivers/irqchip/irq-mtk-cirq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c index 69ba8ce3c178..62a61275aaa3 100644 --- a/drivers/irqchip/irq-mtk-cirq.c +++ b/drivers/irqchip/irq-mtk-cirq.c @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, return ret; } -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) -- 2.28.0.rc0.105.gf9edc3c819-goog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-23 11:46 ` Hanks Chen -1 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:46 UTC (permalink / raw) To: Saravana Kannan Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek, linux-arm-msm, John Stultz, CC Hwang, Loda Chou On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > index 69ba8ce3c178..62a61275aaa3 100644 > --- a/drivers/irqchip/irq-mtk-cirq.c > +++ b/drivers/irqchip/irq-mtk-cirq.c > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > return ret; > } > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) Hi Saravana, Looks good for me to convert cirq to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-23 11:46 ` Hanks Chen 0 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:46 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, linux-kernel, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, kernel-team, linux-arm-kernel On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > index 69ba8ce3c178..62a61275aaa3 100644 > --- a/drivers/irqchip/irq-mtk-cirq.c > +++ b/drivers/irqchip/irq-mtk-cirq.c > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > return ret; > } > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) Hi Saravana, Looks good for me to convert cirq to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-23 11:46 ` Hanks Chen 0 siblings, 0 replies; 93+ messages in thread From: Hanks Chen @ 2020-07-23 11:46 UTC (permalink / raw) To: Saravana Kannan Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, linux-kernel, Bjorn Andersson, Andy Gross, linux-mediatek, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, kernel-team, linux-arm-kernel On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > index 69ba8ce3c178..62a61275aaa3 100644 > --- a/drivers/irqchip/irq-mtk-cirq.c > +++ b/drivers/irqchip/irq-mtk-cirq.c > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > return ret; > } > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) Hi Saravana, Looks good for me to convert cirq to a platform. Thank you for your patch. Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hanks Chen _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver 2020-07-23 11:46 ` Hanks Chen (?) @ 2020-07-23 17:37 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-23 17:37 UTC (permalink / raw) To: Hanks Chen Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger, Andy Gross, Bjorn Andersson, Android Kernel Team, LKML, linux-arm-kernel, moderated list:ARM/Mediatek SoC support, linux-arm-msm, John Stultz, CC Hwang, Loda Chou On Thu, Jul 23, 2020 at 4:46 AM Hanks Chen <hanks.chen@mediatek.com> wrote: > > On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > > This driver can work as a platform driver. So covert it to a platform > > driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > > index 69ba8ce3c178..62a61275aaa3 100644 > > --- a/drivers/irqchip/irq-mtk-cirq.c > > +++ b/drivers/irqchip/irq-mtk-cirq.c > > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > > return ret; > > } > > > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) > > Hi Saravana, > > Looks good for me to convert cirq to a platform. > Thank you for your patch. > > Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hi Hanks, Thanks for the Reviewed-by on both patches. -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-23 17:37 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-23 17:37 UTC (permalink / raw) To: Hanks Chen Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, LKML, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Jul 23, 2020 at 4:46 AM Hanks Chen <hanks.chen@mediatek.com> wrote: > > On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > > This driver can work as a platform driver. So covert it to a platform > > driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > > index 69ba8ce3c178..62a61275aaa3 100644 > > --- a/drivers/irqchip/irq-mtk-cirq.c > > +++ b/drivers/irqchip/irq-mtk-cirq.c > > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > > return ret; > > } > > > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) > > Hi Saravana, > > Looks good for me to convert cirq to a platform. > Thank you for your patch. > > Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hi Hanks, Thanks for the Reviewed-by on both patches. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 4/4] irqchip/mtk-cirq: Convert to a platform driver @ 2020-07-23 17:37 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-23 17:37 UTC (permalink / raw) To: Hanks Chen Cc: CC Hwang, Jason Cooper, Marc Zyngier, Loda Chou, LKML, Bjorn Andersson, Andy Gross, moderated list:ARM/Mediatek SoC support, linux-arm-msm, Matthias Brugger, John Stultz, Thomas Gleixner, Android Kernel Team, linux-arm-kernel On Thu, Jul 23, 2020 at 4:46 AM Hanks Chen <hanks.chen@mediatek.com> wrote: > > On Fri, 2020-07-17 at 17:06 -0700, Saravana Kannan wrote: > > This driver can work as a platform driver. So covert it to a platform > > driver. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > drivers/irqchip/irq-mtk-cirq.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c > > index 69ba8ce3c178..62a61275aaa3 100644 > > --- a/drivers/irqchip/irq-mtk-cirq.c > > +++ b/drivers/irqchip/irq-mtk-cirq.c > > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node *node, > > return ret; > > } > > > > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init); > > +IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_cirq) > > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init) > > +IRQCHIP_PLATFORM_DRIVER_END(mtk_cirq) > > Hi Saravana, > > Looks good for me to convert cirq to a platform. > Thank you for your patch. > > Reviewed-by: Hanks Chen <hanks.chen@mediatek.com> Hi Hanks, Thanks for the Reviewed-by on both patches. -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros 2020-07-18 0:06 ` Saravana Kannan (?) @ 2020-07-25 14:23 ` Marc Zyngier -1 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-07-25 14:23 UTC (permalink / raw) To: Jason Cooper, Alexandre Torgue, Thomas Gleixner, Bjorn Andersson, Andy Gross, Saravana Kannan, Matthias Brugger Cc: linux-kernel, linux-gpio, marex, linux-stm32, linux-arm-kernel, linux-arm-msm, Loda Chou, kernel-team, linux-mediatek, CC Hwang, Hanks Chen, John Stultz On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > Made a series out of the previous v2 patch + some example uses of the > macros. > > Not sure if the MTK changes work (just compile tested), but saw that > Hanks was trying to make those drivers into tristate. So I assume > they'll work as platform drivers. Please wait for MTK Ack before picking > up patches 3 and 4. > > [...] Applied to irq/irqchip-5.9, thanks! [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros commit: 04741740254cd83fb4f2b7747aeb35202104f8fe [3/4] irqchip/mtk-sysirq: Convert to a platform driver commit: 3ae3022690e6787839dafa8ea3496450248b53e1 [4/4] irqchip/mtk-cirq: Convert to a platform driver commit: 538b63351607960ff2249460089daa31337ddeba Cheers, M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-25 14:23 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-07-25 14:23 UTC (permalink / raw) To: Jason Cooper, Alexandre Torgue, Thomas Gleixner, Bjorn Andersson, Andy Gross, Saravana Kannan, Matthias Brugger Cc: marex, CC Hwang, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-gpio, linux-mediatek, John Stultz, kernel-team, linux-stm32, linux-arm-kernel On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > Made a series out of the previous v2 patch + some example uses of the > macros. > > Not sure if the MTK changes work (just compile tested), but saw that > Hanks was trying to make those drivers into tristate. So I assume > they'll work as platform drivers. Please wait for MTK Ack before picking > up patches 3 and 4. > > [...] Applied to irq/irqchip-5.9, thanks! [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros commit: 04741740254cd83fb4f2b7747aeb35202104f8fe [3/4] irqchip/mtk-sysirq: Convert to a platform driver commit: 3ae3022690e6787839dafa8ea3496450248b53e1 [4/4] irqchip/mtk-cirq: Convert to a platform driver commit: 538b63351607960ff2249460089daa31337ddeba Cheers, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-25 14:23 ` Marc Zyngier 0 siblings, 0 replies; 93+ messages in thread From: Marc Zyngier @ 2020-07-25 14:23 UTC (permalink / raw) To: Jason Cooper, Alexandre Torgue, Thomas Gleixner, Bjorn Andersson, Andy Gross, Saravana Kannan, Matthias Brugger Cc: marex, CC Hwang, linux-arm-msm, Hanks Chen, Loda Chou, linux-kernel, linux-gpio, linux-mediatek, John Stultz, kernel-team, linux-stm32, linux-arm-kernel On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > Made a series out of the previous v2 patch + some example uses of the > macros. > > Not sure if the MTK changes work (just compile tested), but saw that > Hanks was trying to make those drivers into tristate. So I assume > they'll work as platform drivers. Please wait for MTK Ack before picking > up patches 3 and 4. > > [...] Applied to irq/irqchip-5.9, thanks! [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros commit: 04741740254cd83fb4f2b7747aeb35202104f8fe [3/4] irqchip/mtk-sysirq: Convert to a platform driver commit: 3ae3022690e6787839dafa8ea3496450248b53e1 [4/4] irqchip/mtk-cirq: Convert to a platform driver commit: 538b63351607960ff2249460089daa31337ddeba Cheers, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros 2020-07-25 14:23 ` Marc Zyngier (?) @ 2020-07-26 3:58 ` Saravana Kannan -1 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-26 3:58 UTC (permalink / raw) To: Marc Zyngier Cc: Jason Cooper, Alexandre Torgue, Thomas Gleixner, Bjorn Andersson, Andy Gross, Matthias Brugger, LKML, linux-gpio, marex, linux-stm32, linux-arm-kernel, linux-arm-msm, Loda Chou, Android Kernel Team, moderated list:ARM/Mediatek SoC support, CC Hwang, Hanks Chen, John Stultz On Sat, Jul 25, 2020 at 7:23 AM Marc Zyngier <maz@kernel.org> wrote: > > On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > > Made a series out of the previous v2 patch + some example uses of the > > macros. > > > > Not sure if the MTK changes work (just compile tested), but saw that > > Hanks was trying to make those drivers into tristate. So I assume > > they'll work as platform drivers. Please wait for MTK Ack before picking > > up patches 3 and 4. > > > > [...] > > Applied to irq/irqchip-5.9, thanks! > > [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros > commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 > [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros > commit: 04741740254cd83fb4f2b7747aeb35202104f8fe > [3/4] irqchip/mtk-sysirq: Convert to a platform driver > commit: 3ae3022690e6787839dafa8ea3496450248b53e1 > [4/4] irqchip/mtk-cirq: Convert to a platform driver > commit: 538b63351607960ff2249460089daa31337ddeba Thanks! -Saravana ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-26 3:58 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-26 3:58 UTC (permalink / raw) To: Marc Zyngier Cc: marex, CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, LKML, Bjorn Andersson, linux-gpio, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, John Stultz, Thomas Gleixner, Android Kernel Team, linux-stm32, linux-arm-kernel, Alexandre Torgue On Sat, Jul 25, 2020 at 7:23 AM Marc Zyngier <maz@kernel.org> wrote: > > On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > > Made a series out of the previous v2 patch + some example uses of the > > macros. > > > > Not sure if the MTK changes work (just compile tested), but saw that > > Hanks was trying to make those drivers into tristate. So I assume > > they'll work as platform drivers. Please wait for MTK Ack before picking > > up patches 3 and 4. > > > > [...] > > Applied to irq/irqchip-5.9, thanks! > > [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros > commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 > [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros > commit: 04741740254cd83fb4f2b7747aeb35202104f8fe > [3/4] irqchip/mtk-sysirq: Convert to a platform driver > commit: 3ae3022690e6787839dafa8ea3496450248b53e1 > [4/4] irqchip/mtk-cirq: Convert to a platform driver > commit: 538b63351607960ff2249460089daa31337ddeba Thanks! -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros @ 2020-07-26 3:58 ` Saravana Kannan 0 siblings, 0 replies; 93+ messages in thread From: Saravana Kannan @ 2020-07-26 3:58 UTC (permalink / raw) To: Marc Zyngier Cc: marex, CC Hwang, Jason Cooper, linux-arm-msm, Hanks Chen, Loda Chou, LKML, Bjorn Andersson, linux-gpio, Andy Gross, moderated list:ARM/Mediatek SoC support, Matthias Brugger, John Stultz, Thomas Gleixner, Android Kernel Team, linux-stm32, linux-arm-kernel, Alexandre Torgue On Sat, Jul 25, 2020 at 7:23 AM Marc Zyngier <maz@kernel.org> wrote: > > On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote: > > Made a series out of the previous v2 patch + some example uses of the > > macros. > > > > Not sure if the MTK changes work (just compile tested), but saw that > > Hanks was trying to make those drivers into tristate. So I assume > > they'll work as platform drivers. Please wait for MTK Ack before picking > > up patches 3 and 4. > > > > [...] > > Applied to irq/irqchip-5.9, thanks! > > [1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros > commit: f3b5e608ed6d17bdf04dacbf2374f10d51fe9b09 > [2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros > commit: 04741740254cd83fb4f2b7747aeb35202104f8fe > [3/4] irqchip/mtk-sysirq: Convert to a platform driver > commit: 3ae3022690e6787839dafa8ea3496450248b53e1 > [4/4] irqchip/mtk-cirq: Convert to a platform driver > commit: 538b63351607960ff2249460089daa31337ddeba Thanks! -Saravana _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~2020-08-07 6:25 UTC | newest] Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-18 0:06 [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` [PATCH v3 1/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH " Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER " Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-08-05 7:44 ` John Stultz 2020-08-05 7:44 ` John Stultz 2020-08-05 7:44 ` John Stultz 2020-08-05 20:19 ` Saravana Kannan 2020-08-05 20:19 ` Saravana Kannan 2020-08-05 20:19 ` Saravana Kannan 2020-08-05 21:16 ` Steev Klimaszewski 2020-08-05 21:16 ` Steev Klimaszewski 2020-08-05 21:16 ` Steev Klimaszewski 2020-08-05 21:47 ` Steev Klimaszewski 2020-08-05 21:47 ` Steev Klimaszewski 2020-08-05 21:47 ` Steev Klimaszewski 2020-08-05 21:57 ` John Stultz 2020-08-05 21:57 ` John Stultz 2020-08-05 21:57 ` John Stultz 2020-08-07 0:40 ` Bjorn Andersson 2020-08-07 0:40 ` Bjorn Andersson 2020-08-07 0:40 ` Bjorn Andersson 2020-08-07 1:22 ` John Stultz 2020-08-07 1:22 ` John Stultz 2020-08-07 1:22 ` John Stultz 2020-08-07 1:39 ` Bjorn Andersson 2020-08-07 1:39 ` Bjorn Andersson 2020-08-07 1:39 ` Bjorn Andersson 2020-08-07 2:48 ` John Stultz 2020-08-07 2:48 ` John Stultz 2020-08-07 2:48 ` John Stultz 2020-08-07 3:02 ` Saravana Kannan 2020-08-07 3:02 ` Saravana Kannan 2020-08-07 3:02 ` Saravana Kannan 2020-08-07 3:09 ` John Stultz 2020-08-07 3:09 ` John Stultz 2020-08-07 3:09 ` John Stultz 2020-08-07 3:12 ` Saravana Kannan 2020-08-07 3:12 ` Saravana Kannan 2020-08-07 3:12 ` Saravana Kannan 2020-08-07 5:58 ` Bjorn Andersson 2020-08-07 5:58 ` Bjorn Andersson 2020-08-07 5:58 ` Bjorn Andersson 2020-08-07 6:22 ` Saravana Kannan 2020-08-07 6:22 ` Saravana Kannan 2020-08-07 6:22 ` Saravana Kannan 2020-08-06 1:24 ` John Stultz 2020-08-06 1:24 ` John Stultz 2020-08-06 1:24 ` John Stultz 2020-08-06 8:49 ` Marc Zyngier 2020-08-06 8:49 ` Marc Zyngier 2020-08-06 8:49 ` Marc Zyngier 2020-08-06 18:05 ` Saravana Kannan 2020-08-06 18:05 ` Saravana Kannan 2020-08-06 18:05 ` Saravana Kannan 2020-08-06 19:59 ` Marc Zyngier 2020-08-06 19:59 ` Marc Zyngier 2020-08-06 19:59 ` Marc Zyngier 2020-08-06 20:09 ` John Stultz 2020-08-06 20:09 ` John Stultz 2020-08-06 20:09 ` John Stultz 2020-08-06 20:31 ` Marc Zyngier 2020-08-06 20:31 ` Marc Zyngier 2020-08-06 20:31 ` Marc Zyngier 2020-08-06 21:16 ` Saravana Kannan 2020-08-06 21:16 ` Saravana Kannan 2020-08-06 21:16 ` Saravana Kannan 2020-07-18 0:06 ` [PATCH v3 3/4] irqchip/mtk-sysirq: Convert to a platform driver Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-23 11:42 ` Hanks Chen 2020-07-23 11:42 ` Hanks Chen 2020-07-23 11:42 ` Hanks Chen 2020-07-18 0:06 ` [PATCH v3 4/4] irqchip/mtk-cirq: " Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-18 0:06 ` Saravana Kannan 2020-07-23 11:46 ` Hanks Chen 2020-07-23 11:46 ` Hanks Chen 2020-07-23 11:46 ` Hanks Chen 2020-07-23 17:37 ` Saravana Kannan 2020-07-23 17:37 ` Saravana Kannan 2020-07-23 17:37 ` Saravana Kannan 2020-07-25 14:23 ` [PATCH v3 0/4] irqchip: Add IRQCHIP_PLATFORM_DRIVER helper macros Marc Zyngier 2020-07-25 14:23 ` Marc Zyngier 2020-07-25 14:23 ` Marc Zyngier 2020-07-26 3:58 ` Saravana Kannan 2020-07-26 3:58 ` Saravana Kannan 2020-07-26 3:58 ` Saravana Kannan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.