lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 8 Jan 2017 22:56:22 +0100
From:   Peter Rosin <>
To:     Wolfram Sang <>
Cc:, Rob Herring <>,
        Mark Rutland <>,
        Jonathan Cameron <>,
        Hartmut Knaack <>,
        Lars-Peter Clausen <>,
        Peter Meerwald-Stadler <>,
        Jonathan Corbet <>,
        Arnd Bergmann <>,
        Greg Kroah-Hartman <>,,,,
Subject: Re: [PATCH v7 00/12] mux controller abstraction and iio/i2c muxes

On 2017-01-08 11:51, Wolfram Sang wrote:
> 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?

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

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...

>> 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...

>> 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!


Powered by blists - more mailing lists