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@xxxxxxxxxx/ 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.
