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.
Signed-off-by: William A. Kennington III <[email protected]>
---
drivers/mux/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 80f015cf6e54..5d585d778312 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -4,7 +4,7 @@
#
config MULTIPLEXER
- tristate
+ tristate "Multiplexer"
menu "Multiplexer drivers"
depends on MULTIPLEXER
--
2.42.0.582.g8ccd20d70d-goog
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?
Cheers,
Peter
> Signed-off-by: William A. Kennington III <[email protected]>
> ---
> drivers/mux/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index 80f015cf6e54..5d585d778312 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -4,7 +4,7 @@
> #
>
> config MULTIPLEXER
> - tristate
> + tristate "Multiplexer"
>
> menu "Multiplexer drivers"
> depends on MULTIPLEXER
Hi!
2023-10-12 at 23:52, William Kennington wrote:
> On Wed, Sep 27, 2023 at 16:08 Peter Rosin <[email protected] <mailto:[email protected]>> 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
On Fri, Oct 13, 2023 at 4:36 AM Peter Rosin <[email protected]> wrote:
>
> Hi!
>
> 2023-10-12 at 23:52, William Kennington wrote:
> > On Wed, Sep 27, 2023 at 16:08 Peter Rosin <[email protected] <mailto:[email protected]>> 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