On Sat, 16 Jul 2022 16:21:48 +0100, <Lewis.Hanly@xxxxxxxxxxxxx> wrote: > > Thanks Marc, > > On Sat, 2022-07-16 at 11:33 +0100, Marc Zyngier wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you > > know the content is safe > > > > On Sat, 16 Jul 2022 08:11:13 +0100, > > <lewis.hanly@xxxxxxxxxxxxx> wrote: > > > From: Lewis Hanly <lewis.hanly@xxxxxxxxxxxxx> > > > > > > Add a driver to support the Polarfire SoC gpio controller. > > > > > > Signed-off-by: Lewis Hanly <lewis.hanly@xxxxxxxxxxxxx> > > > > [...] > > > > > +static int mpfs_gpio_child_to_parent_hwirq(struct gpio_chip *gc, > > > + unsigned int child, > > > + unsigned int child_type, > > > + unsigned int *parent, > > > + unsigned int *parent_type) > > > +{ > > > + struct mpfs_gpio_chip *mpfs_gpio = gpiochip_get_data(gc); > > > + struct irq_data *d = irq_get_irq_data(mpfs_gpio- > > > >irq_number[child]); > > > > This looks totally wrong. It means that you have already instantiated > > part of the hierarchy, and it is likely that you will get multiple > > hierarchy sharing some levels, which isn't intended. > > Some background why I use the above. > We need to support both direct and non-direct IRQ connections to the > PLIC. > In direct mode the GPIO IRQ's are connected directly to the PLIC and > certainly no need for the above. GPIO's can also be configured in non- > direct, which means they use a shared IRQ, hence the above. That's unfortunately not acceptable. You need to distinguish which one is which, and separate them. Your non-direct mode certainly requires special handling, and is not fit for a hierarchical mode. M. -- Without deviation from the norm, progress is not possible.