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:   Thu, 14 May 2020 10:31:02 -0700
From:   Florian Fainelli <>
To:     Bartosz Golaszewski <>
Cc:     Andrew Lunn <>,
        Heiner Kallweit <>,
        Russell King <>,
        "David S . Miller" <>,
        netdev <>,
        Linux Kernel Mailing List <>,
        Bartosz Golaszewski <>
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 <> napisaƂ(a):
>> On 5/14/2020 9:59 AM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <>
>>> mdio-moxart doesn't use regulators in the driver code. We can remove
>>> the regulator include.
>>> Signed-off-by: Bartosz Golaszewski <>
>> Reviewed-by: Florian Fainelli <>
>> --
>> 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.

Powered by blists - more mailing lists