* [PATCH 0/2] irqchip/mmp: A pair of robustness fixed @ 2020-02-19 8:00 Lubomir Rintel 2020-02-19 8:00 ` [PATCH 1/2] irqchip/mmp: Safeguard against multiple root intc initialization Lubomir Rintel ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Lubomir Rintel @ 2020-02-19 8:00 UTC (permalink / raw) To: Marc Zyngier; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel Hi, please consider applying these two patches. Thery are not strictly necessary, but improve diagnostics in case the DT is faulty. Thanks, Lubo ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] irqchip/mmp: Safeguard against multiple root intc initialization 2020-02-19 8:00 [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Lubomir Rintel @ 2020-02-19 8:00 ` Lubomir Rintel 2020-02-19 8:00 ` [PATCH 2/2] irqchip/mmp: Avoid overflowing icu_data[] Lubomir Rintel 2020-03-08 14:04 ` [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Marc Zyngier 2 siblings, 0 replies; 8+ messages in thread From: Lubomir Rintel @ 2020-02-19 8:00 UTC (permalink / raw) To: Marc Zyngier; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Lubomir Rintel We can only handle one root ICU. Let's warn if someone messes up and adds multiple in the devicetree. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> --- drivers/irqchip/irq-mmp.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c index 4a74ac7b7c42e..f597d96409a1f 100644 --- a/drivers/irqchip/irq-mmp.c +++ b/drivers/irqchip/irq-mmp.c @@ -250,6 +250,11 @@ void __init icu_init_irq(void) int irq; max_icu_nr = 1; + if (mmp_icu_base) { + pr_err("ICU already initialized\n"); + return; + } + mmp_icu_base = ioremap(0xd4282000, 0x1000); icu_data[0].conf_enable = mmp_conf.conf_enable; icu_data[0].conf_disable = mmp_conf.conf_disable; @@ -273,6 +278,11 @@ void __init mmp2_init_icu(void) int irq, end; max_icu_nr = 8; + if (mmp_icu_base) { + pr_err("ICU already initialized\n"); + return; + } + mmp_icu_base = ioremap(0xd4282000, 0x1000); icu_data[0].conf_enable = mmp2_conf.conf_enable; icu_data[0].conf_disable = mmp2_conf.conf_disable; @@ -380,6 +390,11 @@ static int __init mmp_init_bases(struct device_node *node) return ret; } + if (mmp_icu_base) { + pr_err("ICU already initialized\n"); + return -EEXIST; + } + mmp_icu_base = of_iomap(node, 0); if (!mmp_icu_base) { pr_err("Failed to get interrupt controller register\n"); -- 2.24.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/2] irqchip/mmp: Avoid overflowing icu_data[] 2020-02-19 8:00 [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Lubomir Rintel 2020-02-19 8:00 ` [PATCH 1/2] irqchip/mmp: Safeguard against multiple root intc initialization Lubomir Rintel @ 2020-02-19 8:00 ` Lubomir Rintel 2020-03-08 14:04 ` [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Marc Zyngier 2 siblings, 0 replies; 8+ messages in thread From: Lubomir Rintel @ 2020-02-19 8:00 UTC (permalink / raw) To: Marc Zyngier; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Lubomir Rintel In case someone messes up and adds too many interrupt muxes in the device tree, icu_data would overflow into things that follow it in bss, likely mmp_icu2_base and mmp_icu_base. Let's add a safeguard, so that we fail gracefully instead of panicking at some later point for reasons that are then not immediately clear. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> --- drivers/irqchip/irq-mmp.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c index f597d96409a1f..c7ef2cea1c020 100644 --- a/drivers/irqchip/irq-mmp.c +++ b/drivers/irqchip/irq-mmp.c @@ -505,6 +505,11 @@ static int __init mmp2_mux_of_init(struct device_node *node, return -ENODEV; i = max_icu_nr; + if (i >= MAX_ICU_NR) { + pr_err("Too many interrupt muxes\n"); + return -EINVAL; + } + ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs); if (ret) { -- 2.24.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed 2020-02-19 8:00 [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Lubomir Rintel 2020-02-19 8:00 ` [PATCH 1/2] irqchip/mmp: Safeguard against multiple root intc initialization Lubomir Rintel 2020-02-19 8:00 ` [PATCH 2/2] irqchip/mmp: Avoid overflowing icu_data[] Lubomir Rintel @ 2020-03-08 14:04 ` Marc Zyngier 2020-03-08 14:46 ` Lubomir Rintel 2020-03-09 16:13 ` Rob Herring 2 siblings, 2 replies; 8+ messages in thread From: Marc Zyngier @ 2020-03-08 14:04 UTC (permalink / raw) To: Lubomir Rintel; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Rob Herring On Wed, 19 Feb 2020 09:00:22 +0100 Lubomir Rintel <lkundrak@v3.sk> wrote: [+RobH] Lubomir, > Hi, > > please consider applying these two patches. Thery are not strictly > necessary, but improve diagnostics in case the DT is faulty. Can't we instead make sure our DT infrastructure checks for these? I'm very reluctant to add more "DT validation" to the kernel, as it feels like the wrong place to do this. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed 2020-03-08 14:04 ` [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Marc Zyngier @ 2020-03-08 14:46 ` Lubomir Rintel 2020-03-08 17:26 ` Marc Zyngier 2020-03-09 16:13 ` Rob Herring 1 sibling, 1 reply; 8+ messages in thread From: Lubomir Rintel @ 2020-03-08 14:46 UTC (permalink / raw) To: Marc Zyngier; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Rob Herring On Sun, Mar 08, 2020 at 02:04:34PM +0000, Marc Zyngier wrote: > On Wed, 19 Feb 2020 09:00:22 +0100 > Lubomir Rintel <lkundrak@v3.sk> wrote: > > [+RobH] > > Lubomir, > > > Hi, > > > > please consider applying these two patches. Thery are not strictly > > necessary, but improve diagnostics in case the DT is faulty. > > Can't we instead make sure our DT infrastructure checks for these? I'm > very reluctant to add more "DT validation" to the kernel, as it feels > like the wrong place to do this. These are not really problems of the DT infrastructure. It's that the driver has some constrains resulting from use of global data ([PATCH 1]) and statically sized arrays ([PATCH 2]) without enforcing them. It's probably easier to mess up DT than to mess up board files, but regardless of that, being a little defensive and checking the bounds of arrays is probably a good programming practice anyways. Thank you Lubo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed 2020-03-08 14:46 ` Lubomir Rintel @ 2020-03-08 17:26 ` Marc Zyngier 2020-03-09 10:10 ` Lubomir Rintel 0 siblings, 1 reply; 8+ messages in thread From: Marc Zyngier @ 2020-03-08 17:26 UTC (permalink / raw) To: Lubomir Rintel; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Rob Herring On Sun, 08 Mar 2020 14:46:04 +0000, Lubomir Rintel <lkundrak@v3.sk> wrote: > > On Sun, Mar 08, 2020 at 02:04:34PM +0000, Marc Zyngier wrote: > > On Wed, 19 Feb 2020 09:00:22 +0100 > > Lubomir Rintel <lkundrak@v3.sk> wrote: > > > > [+RobH] > > > > Lubomir, > > > > > Hi, > > > > > > please consider applying these two patches. Thery are not strictly > > > necessary, but improve diagnostics in case the DT is faulty. > > > > Can't we instead make sure our DT infrastructure checks for these? I'm > > very reluctant to add more "DT validation" to the kernel, as it feels > > like the wrong place to do this. > > These are not really problems of the DT infrastructure. They are. The DT bindings describes the constraints (or at least should), and the DT infrastructure could, at least in theory, check them at compile time. Adding the checks to the kernel defeats the single benefit of DT, which is independence from the kernel. > It's that the driver has some constrains resulting from use of > global data ([PATCH 1]) and statically sized arrays ([PATCH 2]) > without enforcing them. > > It's probably easier to mess up DT than to mess up board files, No, both models can be just as easily broken if people write them without thinking twice. > but regardless of that, being a little defensive and checking the > bounds of arrays is probably a good programming practice anyways. Is there even any example of such broken DT in the tree? M. -- Jazz is not dead, it just smells funny. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed 2020-03-08 17:26 ` Marc Zyngier @ 2020-03-09 10:10 ` Lubomir Rintel 0 siblings, 0 replies; 8+ messages in thread From: Lubomir Rintel @ 2020-03-09 10:10 UTC (permalink / raw) To: Marc Zyngier; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel, Rob Herring On Sun, Mar 08, 2020 at 05:26:35PM +0000, Marc Zyngier wrote: > On Sun, 08 Mar 2020 14:46:04 +0000, > Lubomir Rintel <lkundrak@v3.sk> wrote: > > > > On Sun, Mar 08, 2020 at 02:04:34PM +0000, Marc Zyngier wrote: > > > On Wed, 19 Feb 2020 09:00:22 +0100 > > > Lubomir Rintel <lkundrak@v3.sk> wrote: > > > > > > [+RobH] > > > > > > Lubomir, > > > > > > > Hi, > > > > > > > > please consider applying these two patches. Thery are not strictly > > > > necessary, but improve diagnostics in case the DT is faulty. > > > > > > Can't we instead make sure our DT infrastructure checks for these? I'm > > > very reluctant to add more "DT validation" to the kernel, as it feels > > > like the wrong place to do this. > > > > These are not really problems of the DT infrastructure. > > They are. The DT bindings describes the constraints (or at least > should), and the DT infrastructure could, at least in theory, check > them at compile time. Adding the checks to the kernel defeats the > single benefit of DT, which is independence from the kernel. > > > It's that the driver has some constrains resulting from use of > > global data ([PATCH 1]) and statically sized arrays ([PATCH 2]) > > without enforcing them. > > > > It's probably easier to mess up DT than to mess up board files, > > No, both models can be just as easily broken if people write them > without thinking twice. > > > but regardless of that, being a little defensive and checking the > > bounds of arrays is probably a good programming practice anyways. > > Is there even any example of such broken DT in the tree? No, this didn't occur with a FDT build from the kernel tree. The device tree from Open Firmware that is used on the OLPC XO-4 machine is broken in this way (but it also needs many more fixes in order to be able to run mainline kernels). Lubo > > M. > > -- > Jazz is not dead, it just smells funny. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed 2020-03-08 14:04 ` [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Marc Zyngier 2020-03-08 14:46 ` Lubomir Rintel @ 2020-03-09 16:13 ` Rob Herring 1 sibling, 0 replies; 8+ messages in thread From: Rob Herring @ 2020-03-09 16:13 UTC (permalink / raw) To: Marc Zyngier; +Cc: Lubomir Rintel, Thomas Gleixner, Jason Cooper, linux-kernel On Sun, Mar 8, 2020 at 9:04 AM Marc Zyngier <maz@kernel.org> wrote: > > On Wed, 19 Feb 2020 09:00:22 +0100 > Lubomir Rintel <lkundrak@v3.sk> wrote: > > [+RobH] > > Lubomir, > > > Hi, > > > > please consider applying these two patches. Thery are not strictly > > necessary, but improve diagnostics in case the DT is faulty. > > Can't we instead make sure our DT infrastructure checks for these? I'm > very reluctant to add more "DT validation" to the kernel, as it feels > like the wrong place to do this. We don't really have a way to say a binding can only occur once or N times in a DT. We'd have to have an SoC schema that listed out all the nodes in the DT and forbid any additional nodes. I don't think that's too useful as if there's only 1 instance for a given schema, then the schema is not too useful as the schema has a equal chance of being wrong. Is there something inherent about the h/w that prevents more than one instance? If support of more than one instance is a kernel limitation (because no current SoC needs more than 1), then shouldn't the kernel protect against this? Rob ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-03-09 16:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-19 8:00 [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Lubomir Rintel 2020-02-19 8:00 ` [PATCH 1/2] irqchip/mmp: Safeguard against multiple root intc initialization Lubomir Rintel 2020-02-19 8:00 ` [PATCH 2/2] irqchip/mmp: Avoid overflowing icu_data[] Lubomir Rintel 2020-03-08 14:04 ` [PATCH 0/2] irqchip/mmp: A pair of robustness fixed Marc Zyngier 2020-03-08 14:46 ` Lubomir Rintel 2020-03-08 17:26 ` Marc Zyngier 2020-03-09 10:10 ` Lubomir Rintel 2020-03-09 16:13 ` Rob Herring
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.