Re: Advice on MFD-style probing of DSA switch SoCs

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Fri, Dec 23, 2022 at 09:44:14AM +0100, Krzysztof Kozlowski wrote:
> just trim the code... we do not need to scroll over unrelated pieces.

ok

> > However, the irq_domain/irqchip handling code in this case will go to
> > drivers/net/dsa/, and it won't really be a "driver" (there is no struct
> 
> Why? Devicetree hierarchy has nothing to do with Linux driver hierarchy
> and nothing stops you from putting irqchip code in respective directory
> for such DT. Your parent device can be MFD, can be same old DSA switch
> driver etc. Several options.

True, in fact I've already migrated in my tree the drivers for
nxp,sja1110-base-tx-mdio and nxp,sja1110-base-t1-mdio (which in the
current bindings, are under ethernet-switch/mdios/mdio@N) to dedicated
platform drivers under drivers/net/mdio/. The sja1105 driver will have
to support old bindings as well, so code in sja1105_mdio.c which
registers platform devices for MDIO nodes for compatibility will have to
stay.

But I don't want to keep doing that for other peripherals. The irqchip
is not a child of the ethernet-switch, not in any sense at all. The
ethernet-switch even has 2 IRQ lines which need to be provided by the
irqchip, so there would be a circular dependency in the device tree
description if the ethernet-switch was the parent.

fw_devlink doesn't really like that, and has been causing problems for
similar topologies with other DSA switches. There have been discussions
with Saravana Kannan, and he proposed introducing a FWNODE_FLAG_BROKEN_PARENT
flag, that says "don't create device links between a consumer and a
supplier, if the consumer needs a resource from the supplier to probe,
and the supplier needs to manually probe the consumer to finish its own
probing".
https://patchwork.kernel.org/project/netdevbpf/cover/20210826074526.825517-1-saravanak@google.com/

That patch didn't really go anywhere to my knowledge, but I'd prefer to
sidestep all that discussion about what constitutes a broken parent and
what doesn't, and here, introducing an irqchip driver which is a fwnode
child of the ethernet-switch driver seems like a big mistake, given past
experience.

I omitted this because I wanted to give you a bit of context, but I felt
like some of it was outside the scope of my real question, which is
mostly about how to deal with IORESOURCE_REG resources through generic
OF address code.