From: Rob Herring <robh@kernel.org> To: Sven Van Asbroeck <thesven73@gmail.com> Cc: "Sven Van Asbroeck" <svendev@arcx.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Lee Jones" <lee.jones@linaro.org>, "Mark Rutland" <mark.rutland@arm.com>, "Andreas Färber" <afaerber@suse.de>, "Thierry Reding" <treding@nvidia.com>, "David Lechner" <david@lechnology.com>, "Noralf Trønnes" <noralf@tronnes.org>, "Johan Hovold" <johan@kernel.org>, "Michal Simek" <monstr@monstr.eu>, "Michal Vokáč" <michal.vokac@ysoft.com>, "Arnd Bergmann" <arnd@arndb.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "John Garry" <john.garry@huawei.com>, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Robin Murphy" <robin.murphy@arm.com>, "Paul Gortmaker" <paul.gortmaker@windriver.com>, "Sebastien Bourdelin" <sebastien.bourdelin@savoirfairelinux.com>, "Icenowy Zheng" <icenowy@aosc.io>, "Stuart Yoder" <stuyoder@gmail.com>, "Maxime Ripard" <maxime.ripard@bootlin.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, devicetree@vger.kernel.org Subject: Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document devicetree binding Date: Wed, 28 Nov 2018 10:36:24 -0600 [thread overview] Message-ID: <CAL_JsqK--6UE9N2je3mkoxf_0+i5fTYqYpmTF2bpzFf-KRjhaQ@mail.gmail.com> (raw) In-Reply-To: <CAGngYiWBBe7P80ASQJnS8woe6SKLgNUmqKxOHMeyV1fGSCpY_w@mail.gmail.com> On Wed, Nov 28, 2018 at 9:38 AM Sven Van Asbroeck <thesven73@gmail.com> wrote: > > Rob, thank you so much for the review ! > > On Mon, Nov 26, 2018 at 5:08 PM Rob Herring <robh@kernel.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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Sven Van Asbroeck <thesven73@gmail.com> Cc: "Sven Van Asbroeck" <svendev@arcx.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Lee Jones" <lee.jones@linaro.org>, "Mark Rutland" <mark.rutland@arm.com>, "Andreas Färber" <afaerber@suse.de>, "Thierry Reding" <treding@nvidia.com>, "David Lechner" <david@lechnology.com>, "Noralf Trønnes" <noralf@tronnes.org>, "Johan Hovold" <johan@kernel.org>, "Michal Simek" <monstr@monstr.eu>, "Michal Vokáč" <michal.vokac@ysoft.com>, "Arnd Bergmann" <arnd@arndb.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "John Garry" <john.garry@huawei.com>, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Robin Murphy" <robin.murphy@arm.com>, "Paul Gortmaker" <paul.gortmaker@windriver.com>, "Sebastien Bourdelin" <sebastien.bourdelin@savoirfairelinux> Subject: Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document devicetree binding Date: Wed, 28 Nov 2018 10:36:24 -0600 [thread overview] Message-ID: <CAL_JsqK--6UE9N2je3mkoxf_0+i5fTYqYpmTF2bpzFf-KRjhaQ@mail.gmail.com> (raw) In-Reply-To: <CAGngYiWBBe7P80ASQJnS8woe6SKLgNUmqKxOHMeyV1fGSCpY_w@mail.gmail.com> On Wed, Nov 28, 2018 at 9:38 AM Sven Van Asbroeck <thesven73@gmail.com> wrote: > > Rob, thank you so much for the review ! > > On Mon, Nov 26, 2018 at 5:08 PM Rob Herring <robh@kernel.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
next prev parent reply other threads:[~2018-11-28 16:36 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-21 15:07 [PATCH anybus v4 0/7] Add Fieldbus subsystem + support HMS Profinet card thesven73 2018-11-21 15:07 ` [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem thesven73 2018-11-27 7:47 ` Greg KH 2018-11-27 7:47 ` Greg KH 2018-11-27 7:54 ` Greg KH 2018-11-28 15:39 ` Sven Van Asbroeck 2018-11-28 17:42 ` Greg KH 2018-11-28 18:19 ` Sven Van Asbroeck 2018-11-28 18:36 ` Greg KH 2018-11-28 19:39 ` Sven Van Asbroeck 2018-11-21 15:07 ` [PATCH anybus v4 2/7] fieldbus: support the Arcx anybus bridge thesven73 2018-11-21 15:07 ` [PATCH anybus v4 3/7] dt-bindings: Add vendor prefix for arcx / Archronix thesven73 2018-11-21 15:07 ` [PATCH anybus v4 4/7] dt-bindings: anybus-bridge: document devicetree binding thesven73 2018-11-21 15:07 ` [PATCH anybus v4 5/7] fieldbus: support HMS Anybus-S bus thesven73 2018-11-21 15:07 ` [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document devicetree binding thesven73 2018-11-26 22:08 ` Rob Herring 2018-11-28 15:38 ` Sven Van Asbroeck 2018-11-28 16:36 ` Rob Herring [this message] 2018-11-28 16:36 ` Rob Herring 2018-11-29 20:59 ` Sven Van Asbroeck 2018-11-30 1:39 ` Rob Herring 2018-11-30 1:39 ` Rob Herring 2018-11-21 15:07 ` [PATCH anybus v4 7/7] fieldbus_dev: support HMS Profinet IRT industrial controller thesven73
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqK--6UE9N2je3mkoxf_0+i5fTYqYpmTF2bpzFf-KRjhaQ@mail.gmail.com \ --to=robh@kernel.org \ --cc=afaerber@suse.de \ --cc=arnd@arndb.de \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=geert+renesas@glider.be \ --cc=gregkh@linuxfoundation.org \ --cc=icenowy@aosc.io \ --cc=johan@kernel.org \ --cc=john.garry@huawei.com \ --cc=lee.jones@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=michal.vokac@ysoft.com \ --cc=monstr@monstr.eu \ --cc=noralf@tronnes.org \ --cc=paul.gortmaker@windriver.com \ --cc=robin.murphy@arm.com \ --cc=sebastien.bourdelin@savoirfairelinux.com \ --cc=stuyoder@gmail.com \ --cc=svendev@arcx.com \ --cc=thesven73@gmail.com \ --cc=treding@nvidia.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.