From: Dimitris Michailidis <dm@chelsio•com>
To: Stephen Hemminger <shemminger@linux-foundation•org>
Cc: Casey Leedom <leedom@chelsio•com>,
Ben Hutchings <bhutchings@solarflare•com>,
David Miller <davem@davemloft•net>,
netdev@vger•kernel.org
Subject: Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id
Date: Thu, 07 Apr 2011 01:18:51 -0700 [thread overview]
Message-ID: <4D9D736B.3050106@chelsio.com> (raw)
In-Reply-To: <20110406173308.4737e9d4@nehalam>
Stephen Hemminger wrote:
> On Wed, 6 Apr 2011 17:20:29 -0700
> Casey Leedom <leedom@chelsio•com> wrote:
>
>> | From: Stephen Hemminger <shemminger@linux-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@vyatta•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?
You can pass 0 as blinks to cancel your request, which may or may not cancel
the LED blinking depending on what other drivers have concurrent blinking
requests in progress. But you can't pass UINT_MAX as the patch does. I'll
fix it up to use the new ethtool interface this week.
next prev parent reply other threads:[~2011-04-07 8:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-07 0:09 [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id Stephen Hemminger
2011-04-07 0:20 ` Casey Leedom
2011-04-07 0:33 ` Stephen Hemminger
2011-04-07 8:18 ` Dimitris Michailidis [this message]
2011-04-07 0:35 ` Ben Hutchings
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=4D9D736B.3050106@chelsio.com \
--to=dm@chelsio$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=leedom@chelsio$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox