[PATCH v3 00/12] fw_devlink improvements
saravanak at google.com
Fri Feb 10 11:27:11 PST 2023
On Fri, Feb 10, 2023 at 2:13 AM Vladimir Oltean <vladimir.oltean at nxp.com> wrote:
> Hi Saravana,
> On Mon, Feb 06, 2023 at 05:41:52PM -0800, Saravana Kannan wrote:
> > Vladimir,
> > Ccing you because DSA's and fw_devlink have known/existing problems
> > (still in my TODOs to fix). But I want to make sure this series doesn't
> > cause additional problems for DSA.
> > All,
> > This patch series improves fw_devlink in the following ways:
> > 1. It no longer cares about a fwnode having a "compatible" property. It
> > figures this out more dynamically. The only expectation is that
> > fwnodes that are converted to devices actually get probed by a driver
> > for the dependencies to be enforced correctly.
> > 2. Finer grained dependency tracking. fw_devlink will now create device
> > links from the consumer to the actual resource's device (if it has one,
> > Eg: gpio_device) instead of the parent supplier device. This improves
> > things like async suspend/resume ordering, potentially remove the need
> > for frameworks to create device links, more parallelized async probing,
> > and better sync_state() tracking.
> > 3. Handle hardware/software quirks where a child firmware node gets
> > populated as a device before its parent firmware node AND actually
> > supplies a non-optional resource to the parent firmware node's
> > device.
> > 4. Way more robust at cycle handling (see patch for the insane cases).
> > 5. Stops depending on OF_POPULATED to figure out some corner cases.
> > 6. Simplifies the work that needs to be done by the firmware specific
> > code.
> > The v3 series has gone through my usual testing on my end and looks good
> > to me.
> Booted on an NXP LS1028A (arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts)
> and a Turris MOX (arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts)
> with no observed regressions.
Thanks for testing Vladimir!
> Is there something specific you would like
> me to test?
Not really, I just want to make sure the common DSA architectures
don't hit any regression. In the hardware you tested, are there cases
of PHYs where the supplier is the parent MDIO? I remember that being
the only case where I needed special casing
(FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD) in fw_devlink -- so it'll be
good to make sure I didn't accidentally break anything there.
More information about the linux-mtd