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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
