linux-kernel - Re: [PATCH] net: phy: mdio-moxart: remove unneeded include

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:   Thu, 14 May 2020 10:31:02 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH] net: phy: mdio-moxart: remove unneeded include



On 5/14/2020 10:20 AM, Bartosz Golaszewski wrote:
> czw., 14 maj 2020 o 19:13 Florian Fainelli <f.fainelli@...il.com> napisał(a):
>>
>>
>>
>> On 5/14/2020 9:59 AM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>>
>>> mdio-moxart doesn't use regulators in the driver code. We can remove
>>> the regulator include.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>
>> Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
>> --
>> Florian
> 
> Hi Andrew, Florian,
> 
> I noticed this by accident when I was looking at the PHY drivers to
> see how they handle regulators supplying PHYs. In the case of the
> MediaTek Pumpkin board I'm working on - the PHY is a Realtek RTL8201F
> and it's supplied by a regulator that's enabled on boot by the
> relevant PMIC driver. I'd like to model it in the device-tree but I'm
> not sure what the correct approach is. Some ethernet drivers have a
> phy-supply property but it looks wrong to me - IMO this should be
> handled at the PHY driver level. Is it fine if I add a probe()
> callback to the realtek driver and retrieve the "phy-supply" there?

Don't you need to do this earlier than probe() though? If the PHY device
is powered down, then surely get_phy_id() won't be able to read its
registers and bind the device to the driver.

This should be dealt the same way that resets are being dealt with,
which is prior to the MDIO bus scan.
-- 
Florian