linux-kernel - Re: [PATCH] mux: Make it possible to select MULTIPLEXER if EXPERT

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] [day] [month] [year] [list]

Message-ID: <CAD_4BXgY0uJU1-TRdqOMXZGyEy_mx7LOui_y_+OFJm8OrOJytQ@mail.gmail.com>
Date:   Fri, 13 Oct 2023 04:52:54 -0400
From:   William Kennington <william@...nnington.com>
To:     Peter Rosin <peda@...ntia.se>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mux: Make it possible to select MULTIPLEXER if EXPERT

On Fri, Oct 13, 2023 at 4:36 AM Peter Rosin <peda@...ntia.se> wrote:
>
> Hi!
>
> 2023-10-12 at 23:52, William Kennington wrote:
> > On Wed, Sep 27, 2023 at 16:08 Peter Rosin <peda@...ntia.se <mailto:peda@...ntia.se>> wrote:
> >
> >     Hi!
> >
> >     2023-09-27 at 01:07, William A. Kennington III wrote:
> >     > Right now, there is no way to enable multiplexer support unless another
> >     > config option selects it. When using `allnoconfig` with CONFIG_EXPERT,
> >     > this is deselected with no way to enable it.
> >
> >     I fail to see how that would be useful? Why would you want the mux
> >     core if there are no users?
> >
> >
> > In this case the user is a custom configuration that is added per board following
> > Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
>
> (That binding has recently been moved:
> Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml)
>
> >
> > I suppose the problem is that ARCH_NPCM7XX doesn’t select MULTIPLEXER and MUX_MMIO. Maybe that’s the patch you are looking for? Nothing else that we use has a dt compatible string with mmio-mux or uses the functionality under the covers. This leads to our board config selecting it manually.
>
> Perhaps? I think that's one way to do it.
>
> I'm not sure about what exactly should select MULTIPLEXER in your case,
> but the thinking is that whatever driver wants to use a mux controller
> should be responsible for selecting the mux core.
>
> Maybe that thinking needs revisiting?

It looks like for many of our boards, we are basically relying on
mmio-mux to be able to set the initial state for some of the registers
in the SoC. In our usecase we want the serial port mux registers to be
set to an idle value that never gets updated by any driver, so we have
these dangling mmio-mux entries.

>
> When digging I'm finding nodes that wants to add mux controllers to the
> npcm "gcr" syscon node in:
>
> arch/arm/boot/dts/nuvoton/nuvoton-npcm730-gbs.dts
> arch/arm/boot/dts/nuvoton/nuvoton-npcm730-kudo.dts
> arch/arm/boot/dts/nuvoton/nuvoton-npcm750-runbmc-olympus.dts
>
> But I then find no mention of any nodes wanting make use of those mux
> controllers. My thinking is that whomever comes up with a dts that
> actually has such nodes will also want to select drivers for those nodes.
> And those drivers in turn should select MULTIPLEXER.

It seems like there are no consuming drivers, we just want a global
initial state set for SoC registers when the kernel starts. There is
probably a better way to do this. I think the intention was to be able
to expose the mmio-mux functionality to userspace but obvious the
mmio-mux in itself doesn't support that.

>
> (The above olympus case is a bit suspect since the mux controller has no
> label, and it is therefore needlessly difficult to reference the node
> from a node that needs a mux controller)
>
> Cheers,
> Peter