Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
MIME-Version: 1.0
References: <20230926230712.516709-1-william@wkennington.com>
 <aa4591dd-b558-3401-4a19-362780ec321f@axentia.se> <CAD_4BXhWbUxuidM47poTKFYYruL5jdJyPUfoZvXnqwDNNLd98w@mail.gmail.com>
 <ba8d31bf-28f5-d8a1-adff-1b9ea7c3a578@axentia.se>
In-Reply-To: <ba8d31bf-28f5-d8a1-adff-1b9ea7c3a578@axentia.se>
From:   William Kennington <william@wkennington.com>
Date:   Fri, 13 Oct 2023 04:52:54 -0400
Message-ID: <CAD_4BXgY0uJU1-TRdqOMXZGyEy_mx7LOui_y_+OFJm8OrOJytQ@mail.gmail.com>
Subject: Re: [PATCH] mux: Make it possible to select MULTIPLEXER if EXPERT
To:     Peter Rosin <peda@axentia.se>
Cc:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Oct 13, 2023 at 4:36=E2=80=AFAM Peter Rosin <peda@axentia.se> wrote=
:
>
> Hi!
>
> 2023-10-12 at 23:52, William Kennington wrote:
> > On Wed, Sep 27, 2023 at 16:08 Peter Rosin <peda@axentia.se <mailto:peda=
@axentia.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 a=
nother
> >     > config option selects it. When using `allnoconfig` with CONFIG_EX=
PERT,
> >     > 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=E2=80=99t select MULTI=
PLEXER and MUX_MMIO. Maybe that=E2=80=99s the patch you are looking for? No=
thing 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 i=
t 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