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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx8De_qm9hVtK5CznfWke9nmOfV8OcvAW6kmwyeb7APr=g@mail.gmail.com>
Date:   Mon, 6 Feb 2023 22:49:03 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        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 5:44 AM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
> 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.

Hi Vladimir,

I stumbled onto this thread when searching for some old emails between
us to refresh my memory on fw_devlink + DSA issues.

>
> 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.

I'm glad you are looking into this and agree how IRQ controllers are
independent of the rest of the ethernet-switch, etc.

> 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/

It did land as FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD and it's used for
PHYs. But yeah, it's not a great long term solution.

> 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.

IMHO, the DSA is a logical device that's made up of many different
pieces of real hardware IP. IMHO an ideal solution would be something
like a dsa_bus type where we add a dsa_device. The dsa_device will
list all the necessary devices (IRQ, PHY, MDIO, etc -- they can be
wherever they want in DT) as its suppliers and when the dsa_device is
probed, it can assume all its suppliers are present and then do the
DSA initialization.

This would also solve the PHYs problem you stated earlier. So,
basically you'd move some of the dsa initialization code into the
dsa_probe() function of the dsa_bus.

Hope I'm making some sense. Let me know if you want to discuss this
further and I can try and provide more context and details.

Also, there's already a driver core feature that does just this --
component devices -- but the implementation is old and not so great
IMHO. Component device model can be done better using device links. I
want to refactor the component device framework to use device links,
but that's a problem for another time.

-Saravana