[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221223134459.6bmiidn4mp6mnggx@skbuf>
Date: Fri, 23 Dec 2022 15:44:59 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Lee Jones <lee@...nel.org>,
Colin Foster <colin.foster@...advantage.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: Advice on MFD-style probing of DSA switch SoCs
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.
Powered by blists - more mailing lists