[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZwFwXBbMFeIZNntQ@makrotopia.org>
Date: Sat, 5 Oct 2024 17:59:08 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Christian Marangi <ansuelsmth@...il.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next] net: phy: always set polarity_modes if op
is supported
On Sat, Oct 05, 2024 at 06:35:58PM +0200, Andrew Lunn wrote:
> On Sat, Oct 05, 2024 at 04:51:30PM +0100, Daniel Golle wrote:
> > On Sat, Oct 05, 2024 at 04:17:56PM +0200, Andrew Lunn wrote:
> > > > I'll add "active-high" as an additional property then, as I found out
> > > > that both, Aquantia and Intel/MaxLinear are technically speaking
> > > > active-low by default (ie. after reset) and what we need to set is a
> > > > property setting the LED to be driven active-high (ie. driving VDD
> > > > rather than GND) instead. I hope it's not too late to make this change
> > > > also for the Aquantia driver.
> > >
> > > Adding a new property should not affect backwards compatibility, so it
> > > should be safe to merge at any time.
> >
> > Ok, I will proceed in that direction then and post a patch shortly.
> > My intial assumption that absence of 'active-low' would always imply
> > the LED being driven active-high was due to the commit description of
> > the introduction of the active-low property:
> >
> > commit c94d1783136eb66f2a464a6891a32eeb55eaeacc
> > Author: Christian Marangi <ansuelsmth@...il.com>
> > Date: Thu Jan 25 21:36:57 2024 +0100
> >
> > dt-bindings: net: phy: Make LED active-low property common
> >
> > Move LED active-low property to common.yaml. This property is currently
> > defined multiple times by bcm LEDs. This property will now be supported
> > in a generic way for PHY LEDs with the use of a generic function.
> >
> > With active-low bool property not defined, active-high is always
> > assumed.
>
> So we have a difference between the commit message and what the
> binding actually says. I would go by what the binding says.
+1
>
> However, what about the actual implementations? Do any do what the
> commit message says?
The current implementation for PHY LEDs:
- 'active-low' property is present: Change LED polarity (in many cases
wrongly from initially being active-low to active-high).
- 'active-low' property is not set: Don't touch polarity settings.
See drivers/net/phy/phy_device.c, from line 3360:
if (of_property_read_bool(led, "active-low"))
set_bit(PHY_LED_ACTIVE_LOW, &modes);
if (of_property_read_bool(led, "inactive-high-impedance"))
set_bit(PHY_LED_INACTIVE_HIGH_IMPEDANCE, &modes);
if (modes) {
/* Return error if asked to set polarity modes but not supported */
if (!phydev->drv->led_polarity_set)
return -EINVAL;
err = phydev->drv->led_polarity_set(phydev, index, modes);
if (err)
return err;
}
led_polarity_set() is not called if neither 'active-low' nor
'inactive-high-impedance' are set.
Powered by blists - more mailing lists