Thread (28 messages) 28 messages, 3 authors, 2017-01-10

Re: [PATCH v7 00/12] mux controller abstraction and iio/i2c muxes

From: Wolfram Sang <hidden>
Date: 2017-01-08 10:52:34
Also in: linux-i2c, linux-iio, lkml

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help