On 2017-01-08 11:51, Wolfram Sang wrote:

Hi peda,

quoted

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?

i2c-mux-gpio has the auto-detect for mux-/parent-locked and (old
style?) support for specifying what gpios to use with platform data
from code (i.e. not from dt/acpi). All of that gets messier if
someone else (the mux) owns the gpios.

i2c-mux-pinctrl has similar issues.

i2c-mux-reg has the platform data from code issue, plus a read-write
mode (mux is write only, at least as-is).

i2c-mux-pca954x has things going on like irqs (not applied yet) and
a reset gpio that makes it a poor candidate for something generic.

i2c-mux-mlxcplc could probably be converted (I don't think it existed
when I wrote the quoted paragraph).

So, since there are issues with just about all of the i2c muxes, the
only way forward that I see would be to instantiate the mux locally
and feed it to the generic i2c-mux-simple, but what would be the point
of that? There would still be a handful of i2c-mux drivers under
drivers/i2c/muxes.

Maybe some of the above are non-issues and maybe I have failed to see
some issue? I didn't think too hard about it...

quoted

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)?

I don't think there is a suitable primitive. In order to get
something that really matches, I think the users need to hint
how long they (think they) are going to lock the mux. And
then it no longer a primitive, methinks. It something that is
much heavier...

quoted

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!

And thanks for looking!

Cheers,
peda