linux-kernel - Re: [RFC 2/2] mux: mmio-based syscon mux controller

lists.openwall.net		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 linux-cve-announce 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:   Wed, 19 Apr 2017 18:42:10 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Philipp Zabel <p.zabel@...gutronix.de>,
        Steve Longerbeam <slongerbeam@...il.com>
CC:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Sakari Ailus <sakari.ailus@....fi>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...gutronix.de>
Subject: Re: [RFC 2/2] mux: mmio-based syscon mux controller

On 2017-04-19 18:32, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 09:23 -0700, Steve Longerbeam wrote:
>>
>> On 04/19/2017 08:27 AM, Philipp Zabel wrote:
>>> On Wed, 2017-04-19 at 13:58 +0200, Peter Rosin wrote:
>>>> On 2017-04-19 13:50, Philipp Zabel wrote:
>>>>> On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>>>>>>
>>>>>> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
>>>>>>> This adds a driver for mmio-based syscon multiplexers controlled by a
>>>>>>> single bitfield in a syscon register range.
>>>>>>>
>>>>>>> Signed-off-by: Philipp Zabel <p.zabel@...gutronix.de>
>>>>>>> ---
>>>>>>>   drivers/mux/Kconfig      |  13 +++++
>>>>>>>   drivers/mux/Makefile     |   1 +
>>>>>>>   drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>   3 files changed, 144 insertions(+)
>>>>>>>   create mode 100644 drivers/mux/mux-syscon.c
>>>>>>>
>>>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>>>> index 86668b4d2fc52..a5e6a3b01ac24 100644
>>>>>>> --- a/drivers/mux/Kconfig
>>>>>>> +++ b/drivers/mux/Kconfig
>>>>>>> @@ -43,4 +43,17 @@ config MUX_GPIO
>>>>>>>   	  To compile the driver as a module, choose M here: the module will
>>>>>>>   	  be called mux-gpio.
>>>>>>>
>>>>>>> +config MUX_SYSCON
>>>>>>
>>>>>> my preference would be CONFIG_MUX_MMIO.
>>>>>>
>>>>>>> +	tristate "MMIO bitfield-controlled Multiplexer"
>>>>>>
>>>>>> "MMIO register bitfield-controlled Multiplexer"
>>>>>>
>>>>>> The rest looks good to me.
>>>>>
>>>>> I'll change those. mux-syscon.c should probably be renamed to
>>>>> mux-mmio.c, too.
>>>>
>>>> I think I disagree. But I'm not familiar with syscon so I don't know.
>>>> IIUC, syscon uses regmap to do mmio and this driver requires syscon
>>>> to get at the regmap, and in the end this driver doesn't know anything
>>>> about mmio. All it knows is syscon/regmap.
>>>
>>> That is a good point. Right now there is nothing MMIO about the driver
>>> except for the hardware that I want it to handle.
>>>
>>>>  If some warped syscon
>>>> thing shows up that wraps something other than mmio in its regmap,
>>>> this driver wouldn't care about it. And syscon is something that
>>>> is also known in the DT world. Given that, I think everything in this
>>>> driver should be named syscon and not mmio.
>>>>
>>
>> My argument against using the name "syscon" in the device tree is that
>> it is referring to a subsystem in the Linux kernel. Besides the fact
>> that "syscon" does not clearly describe, at least to me, what sort of
>> device this mux is.
> 
> If I'm not mistaken, this point was not about the DT compatible
> property, just about the driver name.
> 
> I'm also in favor of keeping the "syscon" name out of the device tree as
> far as it is still possible, for the same reasons. The i.MX6 muxes are
> MMIO register bitfield muxes, but not "syscon muxes".

The corresponding mux in the i2c-mux "sub-sub-system" is named i2c-mux-reg.
It is about "raw" mmio, i.e. w/o syscon and regmap. Just for the record...

Cheers,
peda