linux-kernel - Re: [PATCH 4/4] ARM: dts: uniphier: change support card to simple-mfd from simple-bus

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]

Message-ID: <20200629073617.GF177734@dell>
Date:   Mon, 29 Jun 2020 08:36:17 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] ARM: dts: uniphier: change support card to
 simple-mfd from simple-bus

On Mon, 29 Jun 2020, Masahiro Yamada wrote:

> On Thu, Jun 25, 2020 at 11:57 PM Lee Jones <lee.jones@...aro.org> wrote:
> >
> > On Thu, 25 Jun 2020, Masahiro Yamada wrote:
> >
> > > On Thu, Jun 25, 2020 at 3:16 AM Lee Jones <lee.jones@...aro.org> wrote:
> > > >
> > > > On Thu, 25 Jun 2020, Masahiro Yamada wrote:
> > > >
> > > > > On Tue, Jun 23, 2020 at 9:24 PM Lee Jones <lee.jones@...aro.org> wrote:
> > > > > >
> > > > > > On Tue, 23 Jun 2020, Masahiro Yamada wrote:
> > > > > >
> > > > > > > 'make ARCH=arm dtbs_check' emits the following warning:
> > > > > > >
> > > > > > >   support-card@1,1f00000: $nodename:0: 'support-card@1,1f00000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
> > > > > > >
> > > > > > > Maybe, simple-mfd could be a better fit for this device.
> > > > > >
> > > > > > The two should be equivalent.
> > > > >
> > > > > Yes, I know.
> > > > > That's why I can change "simple-bus" to "simple-mfd"
> > > > > with no risk.
> > > > >
> > > > > The difference is schema-check.
> > > > >
> > > > > The node name for "simple-bus" is checked by 'make dtbs_check'.
> > > > >
> > > > > See this code:
> > > > > https://github.com/robherring/dt-schema/blob/v2020.05/schemas/simple-bus.yaml#L17
> > > > >
> > > > > Even if I rename the node, it does not accept the
> > > > > unit name '1,1f00000'
> > > > >
> > > > > > What do you mean by "maybe"?  Does this squash the warning?
> > > > >
> > > > > "maybe" means I am not quite sure
> > > > > which compatible is a better fit
> > > > > to describe this device.
> > > > >
> > > > > As mentioned above, simple-bus and simple-mfd
> > > > > are interchangeable from a driver point of view.
> > > > >
> > > > > This add-on board is integrated with various peripherals
> > > > > such as 16550a serial, smsc9115 ether etc.
> > > > > The address-decode is implemented in a CPLD device.
> > > > > It has chip selects and local addresses, which are mapped to
> > > > > the parent.
> > > > >
> > > > > It can be either simple-bus or simple-mfd, I think.
> > > > >
> > > > >
> > > > > dt-schema checks the node name of simple-bus.
> > > > > Currently, there is no check for simple-mfd.
> > > > >
> > > > > So, I think this patch is an easy solution
> > > > > to fix the warning.
> > > >
> > > > Yes, looking at the documentation it seems as though 'simple-mfd'
> > > > would be a better fit.  Is the device a single IP with various
> > > > different functions?
> > >
> > > Not an IP.
> > >
> > > This is a small board that consists of
> > > a CPLD + ethernet controller + serial controller + LED, etc.
> >
> > Then simple MFD does not seem like a good fit.
> >
> > Neither does 'simple-bus'.
> 
> Then, I do not know what to do.
> 
> 
> This board connection is so simple
> that no hardware initialization needed to get access
> to peripherals.
> 
> So, 'simple-bus' or 'simple-mfd' is preferred.
> 
> If this is not either simple-bus or simple-mfd,
> I need a special driver to probe the
> child devices such as ethernet, serial etc.
> 
> 
> 
> > What is it you're trying to describe in the device hierarchy?
> 
> 
> The connection is as follows:
> 
> 
> |-Main board -|      |----- add-on board ----|
> |             |      |     (this board)      |
> |             |      |                       |
> |    (SoC) ---|------|--- CPLD --- ethernet  |
> |             |      |          |- serial    |
> |-------------|      |          |- LED       |
>                      |                       |
>                      |-----------------------|
> 
> 
> 
> uniphier-support-card.dtsi describes the
> "add-on board" part.
> Address-decode is implemented in CPLD.
> 
> 
> So, the criteria to become MFD is
> whether it is an IP integrated into SoC.
> 
> 
> - implemented in an SoC  --> MFD

If

 s/in an SoC/in a single piece of silicon/

... then yes.

> - implemented in a board + CPLD  --> not MFD
> 
> Right?

Right.  Unless all H/W is represented inside the CPLD, in which case
the CPLD is, in theory, the MFD.  Although, due to the nature of
CPLDs, this is a slippery slope.

You may want something like:

  arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezzanine.dts

... where the add-on board is represented separately (not in the
same hierarchical structure as the main board.  The main board is then
included as a DTSI from the add-on board.

It might also be worth looking at how consumer boards such as the
RaspberryPi, BeagleBoard and the like handle their add-on boards,
mezzanines, capes, hats, etc.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog