From: Peter Hurley <peter@hurleysoftware.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: stephan.gatzka@gmail.com, linux1394-devel@lists.sourceforge.net,
Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: function call fw_iso_resource_mange(..) (core-iso.c) does not return
Date: Wed, 22 May 2013 09:38:58 -0400 [thread overview]
Message-ID: <519CCA72.7000005@hurleysoftware.com> (raw)
In-Reply-To: <20130521231346.1fec9142@stein>
On 05/21/2013 05:13 PM, Stefan Richter wrote:
>> FWIW, I still believe that we should revert to the original bus reset
>> as tasklet and redo the TI workaround to use TI-workaround-specific versions
>> of non-sleeping PHY accesses.
>>
>> Regards,
>> Peter Hurley
>
> I am a friend of the self-ID-complete worklet, for two reasons:
> - Even if there was no need for the TI TSB41BA3D workaround (e.g. even
> if we simply stopped supporting TSB41BA3D), it would still be
> worthwhile to have at least the self-ID-complete IRQ BH performed in
> a non-atomic context. We should try to move as much of the
> firewire-core self-ID-complete handler as possible out of the currently
> spinlock protected section in order make more of this stuff
> preemptible and replace a few GFP_ATOMIC slab allocations by GFP_NOFS
> ones. (Could be GFP_KERNEL in absence of firewire-sbp2.)
> I would have liked to work on this already long ago, but such is life.
Sure. I understand reducing the card->lock critical section is desirable
(although even more care would be required when switching the work item).
> - How do you propose to access the PHY registers without sleeping?
> Or more to the point: How do you propose to mix sleeping and
> non-sleeping PHY register accesses? (Since we can't get rid of
> the sleeping ones.) If the accesses are not fully serialized, you will
> get corrupt PHY reg reads or writes. If they are fully serialized, the
> non-sleeping PHY reg accesses need to go a try-lock route and will be
> forced to error out during periods when a sleeping PHY reg access goes
> on, without even the ability to reschedule if it is done in a tasklet
> context.
Although this point is largely irrelevant now, I wasn't suggesting mixing
sleeping and non-sleeping PHY access -- simply that the TI quirk would
require non-sleeping PHY access and every other host controller would
use sleeping PHY access.
Regards,
Peter Hurley
next prev parent reply other threads:[~2013-05-22 13:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8ac7ca3200325ddf85ba57aa6d000f70@gatzka.org>
2013-05-21 20:28 ` function call fw_iso_resource_mange(..) (core-iso.c) does not return Stefan Richter
2013-05-22 9:08 ` Stephan Gatzka
2013-05-22 9:22 ` Tejun Heo
2013-05-22 13:11 ` Stefan Richter
[not found] ` <519BA6AC.1080600@hurleysoftware.com>
2013-05-21 21:13 ` Stefan Richter
2013-05-22 8:53 ` Stephan Gatzka
2013-05-22 13:38 ` Peter Hurley [this message]
[not found] ` <62922216e6007f9ef83956e0ca202644@gatzka.org>
2013-05-21 21:53 ` Stefan Richter
2013-05-21 22:10 ` Peter Hurley
2013-05-22 8:52 ` Stephan Gatzka
[not found] ` <20130521231847.GA6985@mtj.dyndns.org>
2013-05-22 7:48 ` Stefan Richter
2013-05-22 8:59 ` Stephan Gatzka
2013-05-22 12:58 ` Stefan Richter
2013-05-22 13:06 ` Stephan Gatzka
2013-05-22 13:21 ` Peter Hurley
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=519CCA72.7000005@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
--cc=stephan.gatzka@gmail.com \
--cc=tj@kernel.org \
/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.