From: Marek Behun <marek.behun@nic.cz>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, linux-leds@vger.kernel.org,
"Pavel Machek" <pavel@ucw.cz>,
jacek.anaszewski@gmail.com, "Dan Murphy" <dmurphy@ti.com>,
"Ondřej Jirman" <megous@megous.com>,
"Russell King" <linux@armlinux.org.uk>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Gregory Clement" <gregory.clement@bootlin.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW
Date: Tue, 28 Jul 2020 19:27:13 +0200 [thread overview]
Message-ID: <20200728192713.01153e43@nic.cz> (raw)
In-Reply-To: <20200728162816.GK1705504@lunn.ch>
On Tue, 28 Jul 2020 18:28:16 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> > > @@ -736,6 +777,16 @@ struct phy_driver {
> > > int (*set_loopback)(struct phy_device *dev, bool enable);
> > > int (*get_sqi)(struct phy_device *dev);
> > > int (*get_sqi_max)(struct phy_device *dev);
> > > +
> > > + /* PHY LED support */
> > > + int (*led_init)(struct phy_device *dev, struct
> > > phy_device_led *led);
> > > + int (*led_brightness_set)(struct phy_device *dev, struct
> > > phy_device_led *led,
> > > + enum led_brightness brightness);
> > > + const char *(*led_iter_hw_mode)(struct phy_device *dev,
> > > struct phy_device_led *led,
> > > + void ** iter);
> > > + int (*led_set_hw_mode)(struct phy_device *dev, struct
> > > phy_device_led *led,
> > > + const char *mode);
> > > + const char *(*led_get_hw_mode)(struct phy_device *dev,
> > > struct phy_device_led *led); };
> > > #define to_phy_driver(d)
> > > container_of(to_mdio_common_driver(d), \ struct
> > > phy_driver, mdiodrv)
> >
> > The problem here is that the same code will have to be added to DSA
> > switch ops structure, which is not OK.
>
> Not necessarily. DSA drivers do have access to the phydev structure.
>
> I think putting these members into a structure is a good idea. That
> structure can be part of phy_driver and initialised just like other
> members. But on probing the phy, it can be copied over to the
> phy_device structure. And we can provide an API which DSA drivers can
> use to register there own structure of ops to be placed into
> phy_device, which would call into the DSA driver.
>
> Andrew
On Marvell switches there are LEDs that do not necesarrily blink on
events on a specific port, but instead on the whole switch. Ie a LED
can be put into a mode "act on any port". Vendors may create devices
with this as intender mode for a LED, and such a LED may be on the
other side of the device from where the ports are, or something. Such a
LED should be described in the device tree not as a child of any PHY or
port, but instead as a child of the switch itself. And since all the
LEDs on Marvell switches are technically controlled by the switch, not
it's internal PHYs, I think all of them should be children of the
switch node (or a "leds" node which is a child of the switch node),
instead of being descended from the internal PHYs.
Marek
next prev parent reply other threads:[~2020-07-28 17:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 15:05 [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs Marek Behún
2020-07-28 15:05 ` [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW Marek Behún
2020-07-28 15:11 ` Marek Behún
2020-07-28 16:28 ` Andrew Lunn
2020-07-28 17:27 ` Marek Behun [this message]
2020-07-28 16:18 ` Andrew Lunn
2020-07-28 17:28 ` Marek Behun
2020-07-28 18:47 ` kernel test robot
2020-07-28 19:13 ` kernel test robot
2020-07-28 15:05 ` [PATCH RFC leds + net-next v4 2/2] net: phy: marvell: add support for PHY LEDs via LED class Marek Behún
2020-07-28 15:52 ` [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs Jakub Kicinski
2020-08-07 9:06 ` Pavel Machek
2020-08-07 13:29 ` Andrew Lunn
2020-08-29 22:43 ` Pavel Machek
2020-08-29 23:36 ` Andrew Lunn
2020-08-30 1:50 ` Andrew Lunn
2020-08-30 9:22 ` Pavel Machek
2020-08-25 8:13 ` Matthias Schiffer
2020-08-30 22:56 ` Marek Behun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200728192713.01153e43@nic.cz \
--to=marek.behun@nic.cz \
--cc=andrew@lunn.ch \
--cc=dmurphy@ti.com \
--cc=gregory.clement@bootlin.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=megous@megous.com \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.