netdev - Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool 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]

Message-ID: <20110406173308.4737e9d4@nehalam>
Date:	Wed, 6 Apr 2011 17:33:08 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Casey Leedom <leedom@...lsio.com>
Cc:	Dimitris Michailidis <dm@...lsio.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id

On Wed, 6 Apr 2011 17:20:29 -0700
Casey Leedom <leedom@...lsio.com> wrote:

> | From: Stephen Hemminger <shemminger@...ux-foundation.org>
> | Date: Wednesday, April 06, 2011 05:09 pm
> | 
> | The Chelsio cxgb4 drivers implement blinking in a unique way by
> | waiting on the mailbox. This patch cleans it up slightly by no longer
> | holding the system wide network configuration lock during the process.
> | 
> | The patch also uses correct semantics for the time argument
> | which is supposed to be in seconds; and zero is supposed
> | to signify infinite blinking.
> | 
> | This is still a bad firmware interface design for this
> | since it means the board is basically hung while doing the blink.
> | But fixing it correctly would require hardware and firmware
> | documentation. With that information the device could be converted
> | to the new set_phys_id.
> | 
> | Compile tested only.
> | 
> | Signed-off-by: Stephen Hemminger <shemminger@...tta.com>
> 
>   Are you assuming that the firmware won't respond with a command completion 
> until the LED blinking is complete?  If so, that's a bad assumption.  The 
> firmware runs as an asynchronous real-time OS.  The LED blinking simply becomes 
> a thread of activity within the OS and the command completes immediately.
> 
> Casey

Then how is LED blinking stopped?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html