On Mon, May 25, 2020 at 03:20:09PM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Vladimir Oltean <[email protected]>
> > Sent: Monday, May 25, 2020 12:23 AM
> > To: [email protected]
> > Cc: [email protected]; [email protected]; [email protected];
> > Madalin Bucur (OSS) <[email protected]>; [email protected]
> > Subject: [PATCH] dpaa_eth: fix usage as DSA master, try 3
> >
> > From: Vladimir Oltean <[email protected]>
> >
> > The dpaa-eth driver probes on compatible string for the MAC node, and
> > the fman/mac.c driver allocates a dpaa-ethernet platform device that
> > triggers the probing of the dpaa-eth net device driver.
> >
> > All of this is fine, but the problem is that the struct device of the
> > dpaa_eth net_device is 2 parents away from the MAC which can be
> > referenced via of_node. So of_find_net_device_by_node can't find it, and
> > DSA switches won't be able to probe on top of FMan ports.
> >
> > It would be a bit silly to modify a core function
> > (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> > just for one driver. We're just 1 step away from implementing full
> > recursion.
>
> Changing a netdevice parent to satisfy this DSA assumption can be regarded as
> being just as silly. How about changing the DSA assumption, not the generic
> of_find_net_device_by_node API?
>
> ACPI support is in the making for these platforms, is DSA going to work
> with that?
Hi Madalin
If you listen to what the ACPI people say, ACPI is never going to work
with DSA. ACPI is too primitive, you need to use an advanced
configuration system like DT.
Andrew