netdev - Re: [PATCH RFC leds + net-next 7/7] net: phy: marvell: support LEDs connected on Marvell PHYs

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:   Wed, 25 Nov 2020 13:38:17 +0100
From:   Pavel Machek <pavel@....cz>
To:     Marek Behún <kabel@...nel.org>
Cc:     netdev@...r.kernel.org, linux-leds@...r.kernel.org,
        Dan Murphy <dmurphy@...com>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Ben Whitten <ben.whitten@...il.com>
Subject: Re: [PATCH RFC leds + net-next 7/7] net: phy: marvell: support LEDs
 connected on Marvell PHYs


> +/* FIXME: Blinking rate is shared by all LEDs on a PHY. Should we check whether
> + * another LED is currently blinking with incompatible rate? It would be cleaner
> + * if we in this case failed to offload blinking this LED.
> + * But consider this situation:
> + *   1. user sets LED[1] to blink with period 500ms for some reason. This would
> + *      start blinking LED[1] with perion 670ms here

period.

> + *   2. user sets netdev trigger to LED[0] to blink on activity, default there
> + *      is 100ms period, which would translate here to 84ms. This is
> + *      incompatible with the already blinking LED, so we fail to offload to HW,
> + *      and netdev trigger does software offloading instead.
> + *   3. user unsets blinking od LED[1], so now we theoretically can offload
> + *      netdev trigger to LED[0], but we don't know about it, and so it is left
> + *      in SW triggering until user writes the settings again
> + * This could be solved by the netdev trigger periodically trying to offload to
> + * HW if we reported that it is theoretically possible (by returning -EAGAIN
> + * instead of -EOPNOTSUPP, for example). Do we want to do this?
> + */

I believe we should check & fallback to software if there's already
incompatible rate in use. No need to periodically re-try to activate
the offload.

Best regards,
								Pavel

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

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