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]

Date:   Sun, 19 Jan 2020 21:50:59 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
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

> Speaking for r8169:
> If interface is up and cable detached, then it runtime-suspends
> and goes into PCI D3 (chip and MDIO bus not accessible).
> But ndev is "running" and PHY is attached.

Hi Heiner

And how does it get out of this state? I assume the PHY interrupts
when the link is established. Is phylib handling this interrupt? If
so, when phylib accesses the MDIO bus, the bus needs to be runtime PM
aware. And if the bus is runtime PM aware, the IOCTL handler should
work, when the device is runtime suspended.  If the MAC is handling
this interrupt, and it is the MAC interrupt handler which is run-time
unsuspending, then the ioctl handler is not going to work unless it
also runtime unsuspends.

	Andrew