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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 25 May 2020 17:36:30 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] dpaa_eth: fix usage as DSA master, try 3

On Mon, May 25, 2020 at 03:20:09PM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Vladimir Oltean <olteanv@...il.com>
> > Sent: Monday, May 25, 2020 12:23 AM
> > To: davem@...emloft.net
> > Cc: andrew@...n.ch; f.fainelli@...il.com; vivien.didelot@...il.com;
> > Madalin Bucur (OSS) <madalin.bucur@....nxp.com>; netdev@...r.kernel.org
> > Subject: [PATCH] dpaa_eth: fix usage as DSA master, try 3
> > 
> > From: Vladimir Oltean <vladimir.oltean@....com>
> > 
> > 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

Powered by blists - more mailing lists