When a sdmmc device driver currently calls sdmmc_io_function_enable()
in its attach routine it will cause a 'locking against myself' panic
since the lock already has been set in the sdmmc attach path.
Therefore just check if the lock already has been set in
sdmmc_io_function_enable() fixes this.
On Sat, Aug 21, 2010 at 05:21:20PM -0700, Matthew Dempsky wrote:
> On Sat, Aug 21, 2010 at 10:04 AM, Bret S. Lambert
> wrote:
> > This diff changes the locking in sbt and sdmmc from the old-and-busted
> > lockmgr locks to the new-hotness rwlock locks. I don't have the
> > hardware to test this on
> Why not simply change the SDMMC_LOCK/SDMMC_UNLOCK/SDMMC_ASSERT_LOCKED
> macros and leave the .c files untouched (other than the lock init)?
Because it obscures things.
Eventually we all have to learn the native locking API's. If they
are throughout our tree wrapped up into 50-60 variations, wh
On Sat, Aug 21, 2010 at 10:04 AM, Bret S. Lambert wrote:
> This diff changes the locking in sbt and sdmmc from the old-and-busted
> lockmgr locks to the new-hotness rwlock locks. I don't have the
> hardware to test this on, so anybody with sbt/sdmmc is encouraged
> to give it a spin.
Why not simp
This diff changes the locking in sbt and sdmmc from the old-and-busted
lockmgr locks to the new-hotness rwlock locks. I don't have the
hardware to test this on, so anybody with sbt/sdmmc is encouraged
to give it a spin.
-Bert
-- all is achievable through the power of Robocop
Index: sbt.c
===
