Hi peda, > One thing that I would like to do, but don't see a solution > for, is to move the mux control code that is present in > various drivers in drivers/i2c/muxes to this new minimalistic > muxing subsystem, thus converting all present i2c muxes (but > perhaps not gates and arbitrators) to be i2c-mux-simple muxes.
In a few lines, what is preventing that? > I'm using an rwsem to lock a mux, but that isn't really a > perfect fit. Is there a better locking primitive that I don't > know about that fits better? I had a mutex at one point, but > that didn't allow any concurrent accesses at all. At least > the rwsem allows concurrent access as long as all users > agree on the mux state, but I suspect that the rwsem will > degrade to the mutex situation pretty quickly if there is > any contention. Maybe ask this question in a seperate email thread on lkml cc-ing the locking gurus (with a pointer to this thread)? > Also, the "mux" name feels a bit ambitious, there are many muxes > in the world, and this tiny bit of code is probably not good > enough to be a nice fit for all... "... and it probably never will support anything other than AT-harddisks, as that's all I have..." ;)) Thanks for this work! Wolfram
signature.asc
Description: PGP signature
