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

Message-ID: <ba8d31bf-28f5-d8a1-adff-1b9ea7c3a578@axentia.se>
Date:   Fri, 13 Oct 2023 10:36:19 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     William Kennington <william@...nnington.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mux: Make it possible to select MULTIPLEXER if EXPERT

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?

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.

(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