linux-kernel - Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document devicetree binding

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: <CAL_JsqK--6UE9N2je3mkoxf_0+i5fTYqYpmTF2bpzFf-KRjhaQ@mail.gmail.com>
Date:   Wed, 28 Nov 2018 10:36:24 -0600
From:   Rob Herring <robh@...nel.org>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Sven Van Asbroeck <svendev@...x.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andreas Färber <afaerber@...e.de>,
        Thierry Reding <treding@...dia.com>,
        David Lechner <david@...hnology.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Johan Hovold <johan@...nel.org>,
        Michal Simek <monstr@...str.eu>,
        Michal Vokáč <michal.vokac@...ft.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Garry <john.garry@...wei.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Robin Murphy <robin.murphy@....com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Sebastien Bourdelin <sebastien.bourdelin@...oirfairelinux.com>,
        Icenowy Zheng <icenowy@...c.io>,
        Stuart Yoder <stuyoder@...il.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document
 devicetree binding

On Wed, Nov 28, 2018 at 9:38 AM Sven Van Asbroeck <thesven73@...il.com> wrote:
>
> Rob, thank you so much for the review !
>
> On Mon, Nov 26, 2018 at 5:08 PM Rob Herring <robh@...nel.org> wrote:
>
> > Unit-addresses are based on 'reg'. So this should either be '89' or
> > based on a definition for the bus (e.g. PCI uses dev and func).
> >
> >> +                     reg = <0x0089>;
> >
> > Is fieldbus type how one addresses a device on the bus?
>
> I'm afraid not. Anybus cards don't have an address, because only a single card
> can be connected to an anybus at a time.

Then you don't need reg as you should only have 1 child node.

> Fieldbus type defines the type/functionality of the connected card. Like pci
> device ids.

Which for PCI can be overridden in DT, but is part of reg.

> The current patchset allows devicetree nodes to be provided depending on
> the type of card connected to the bus. It identifies the card by type,
> not location.
>
> Is this not desired / allowed ?

No, 'reg' is how you address a device. You could use 'type' in the
compatible string if type implies some sort of standard class
interface.

> > I'm still not clear what a bridge vs. host is. Both examples are on WEIM
> > bus CS0?
>
> I agree that the terminology is too confusing. I'm looking to change it.
>
> Let's compare current anybus with a well-established bus architecture like pci:
>
>                                 pci                     anybus
> --------------------------------------------------------------------------------
> Common bus code (spec),         pci/pci_driver.c        fieldbus/anybuss-host.c
>   calls bus_register()                                  must be parallel bus
>                                                         subnode
>                                 no of compatible        has of compatible
> --------------------------------------------------------------------------------
> Device on bus, calls
>   XXX_client_driver_register()  hwmon/k8temp.c          fieldbus/hms-profinet.c
> --------------------------------------------------------------------------------
> Controller, silicon driver      pci/pcie-tango.c        fieldbus/anybus-bridge.c
>                                 platform_driver calls   platform_driver does not
>                                 pci_host_probe()        register with anybus
>
> I should probably rework this so it conforms more closely to the way it's done
> on pci. Would the following look any better?

Yes, this looks better.

>                                 pci                     anybus
> --------------------------------------------------------------------------------
> Common bus code (spec),         pci/pci_driver.c        anybus/anybus_driver.c

Maybe just anybus/core.c or anybus/bus.c. I'm guessing your
implementation will be *much* more simple than PCI.

>   calls bus_register()          no of compatible        no of compatible
> --------------------------------------------------------------------------------
> Device on bus, calls
>   XXX_client_driver_register()  hwmon/k8temp.c          fieldbus/hms-profinet.c
> --------------------------------------------------------------------------------
> Controller, silicon driver      pci/pcie-tango.c        anybus/arcx-controller.c
>                                 platform_driver calls   platform_driver calls
>                                 pci_host_probe()        anybus_host_probe()
>
> Of course, the analogy is not perfect, as there can only be a single card
> (device) connected to an anybus at a time.

Right, that should simplify the bus code a lot.

Rob