netdev - Re: [PATCH net-next 5/5] igc: Export LEDs

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] [day] [month] [year] [list]

Date:   Thu, 26 Aug 2021 14:45:11 +0200
From:   Pavel Machek <pavel@....cz>
To:     Marek Behún <kabel@...nel.org>
Cc:     andrew@...n.ch, Heiner Kallweit <hkallweit1@...il.com>,
        Michael Walle <michael@...le.cc>, anthony.l.nguyen@...el.com,
        bigeasy@...utronix.de, davem@...emloft.net,
        dvorax.fuxbrumer@...ux.intel.com, f.fainelli@...il.com,
        jacek.anaszewski@...il.com, kuba@...nel.org, kurt@...utronix.de,
        linux-leds@...r.kernel.org, netdev@...r.kernel.org,
        sasha.neftin@...el.com, vinicius.gomes@...el.com,
        vitaly.lifshits@...el.com
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

Hi!

> > > > > Pavel, one point of the discussion is that in this case the LED
> > > > > is controlled by MAC, not PHY. So the question is whether we
> > > > > want to do "ethmacN" (in addition to "ethphyN").    
> > > > 
> > > > Sorry, I missed that. I guess that yes, ethmacX is okay, too.
> > > > 
> > > > Even better would be to find common term that could be used for
> > > > both ethmacN and ethphyN and just use that. (Except that we want
> > > > to avoid ethX). Maybe "ethportX" would be suitable?  
> > > 
> > > See
> > >   https://lore.kernel.org/linux-leds/YQAlPrF2uu3Gr+0d@lunn.ch/
> > > and
> > >   https://lore.kernel.org/linux-leds/20210727172828.1529c764@thinkpad/
> > >  
> > 
> > Ok, I guess I'd preffer all LEDs corresponding to one port to be
> > grouped, but that may be hard to do.
> 
> Hi Pavel (and Andrew),
> 
> The thing is that normally we are creating LED classdevs when the
> parent device is probed. In this case when the PHY is probed. But we
> will know the corresponding MAC only once the PHY is attached to it's
> network interface.
> 
> Also, a PHY may be theoretically attached to multiple different
> interfaces during it's lifetime. I guess there isn't many boards
> currently that have such a configuration wired (maybe none), but
> kernel's API is prepared for this.
> 
> So we really can't group them under one parent device, unless:

Ok, I guess my proposal is just too complex to implement. Let's go
with "ethmacN" + "ethphyN".

Best regards,

								Pavel
-- 
http://www.livejournal.com/~pavelmachek

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)