netdev - Re: [PATCH net-next 0/2] net: phy: add generic ndo_do_ioctl handler phy_do

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <97389eb0-fc7f-793b-6f84-730e583c00e9@googlemail.com>
Date:   Sun, 19 Jan 2020 18:18:03 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: phy: add generic ndo_do_ioctl handler
 phy_do_ioctl

On 19.01.2020 17:12, Andrew Lunn wrote:
> On Sun, Jan 19, 2020 at 02:31:06PM +0100, Heiner Kallweit wrote:
>> A number of network drivers has the same glue code to use phy_mii_ioctl
>> as ndo_do_ioctl handler. So let's add such a generic ndo_do_ioctl
>> handler to phylib. As first user convert r8169.
> 
> Hi Heiner
> 
Hi Andrew,

> Looks sensible. 
> 
> Two questions:
> 
> Did you look at how many drivers don't make the running check? I know
> there are some MAC drivers which allow PHY ioctls when the interface
> is down.  So maybe we want to put _running_ into this helper name, and
> add anther helper which does not check for running?
> 
Almost all drivers have the running check. I found five that don't:

*ag71xx, fec_mpc52xx*
They don't have the running check but should, because the PHY is
attached in ndo_open only.

*agere, faraday, rdc*
They don't have the running check and attach the PHY in probe.

So yes, we could add a second helper w/o the running check, even if
it's just for three drivers. There may be more in the future.

> Do you plan to convert any more MAC drivers?
> 
Not yet ;) Question would be whether one patch would be sufficient
or whether we need one patch per driver that needs to be ACKed by
the respective maintainer.

>    Andrew
> 
Heiner