netdev - RE: FEC unbind/bind feature

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 29 Mar 2021 09:12:18 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Florian Fainelli <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: FEC unbind/bind feature


> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: 2021年3月26日 20:34
> To: Joakim Zhang <qiangqing.zhang@....com>
> Cc: Florian Fainelli <f.fainelli@...il.com>; hkallweit1@...il.com;
> netdev@...r.kernel.org
> Subject: Re: FEC unbind/bind feature
> 
> > One more add, yes, I am looking the drivers/net/mdio, it is better to
> implement standalone MDIO driver when writing the MAC driver at the
> beginning.
> > Now if I abstract MDIO driver from FEC driver, dt bindings would change, it
> will break all existing implementations in the kernel based on FEC driver, let
> them can't work.
> > How to compatible the legacy dt bindings? I have no idea now. At the same
> time, I also feel that it seems not necessary to rewrite it.
> 
> I have a reasonable understanding of the FEC MDIO driver. I have broken it a
> few times :-)
> 
> It is going to be hard to make it an independent driver, because it needs access
> to the interrupt flags and the clocks for power saving. From a hardware
> perspective, it is not an independent hardware block, it is integrated into the
> MAC.

Agree 😊

For another curiosity, dual FEC instances share one MDIO bus, we can successfully unbind them one by one. But if users first unbind FEC which attached MDIO bus, kernel would have a dump or crash, it seems not good.
So I look at the code, want to find a way to reject unbind this FEC first, then print a log, something like "other FEC instances depend on MDIO bus of this FEC, so can't unbind it now". It seems no way to do this at FEC driver remove path (fec_drv_remove). If you have some idea, happy share with me. Thanks.

Best Regards,
Joakim Zhang
> XDP probably is your easier path.
> 
>     Andrew