linux-kernel - Re: [PATCH anybus v3 1/6] misc: support the Arcx anybus bridge

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: <CAK8P3a3uS5wbNwmGGdYqEFdVi0ErzG7_6yaMheAACh6Tta+DZQ@mail.gmail.com>
Date:   Thu, 8 Nov 2018 14:40:00 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     thesven73@...il.com
Cc:     Rob Herring <robh@...nel.org>, 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@...nnes.org,
        Johan Hovold <johan@...nel.org>,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        gregkh <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 Mailing List <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v3 1/6] misc: support the Arcx anybus bridge

On Tue, Nov 6, 2018 at 9:05 PM Sven Van Asbroeck <thesven73@...il.com> wrote:
> On Tue, Nov 6, 2018 at 1:31 PM Rob Herring <robh@...nel.org> wrote:
>
> > If the host is not a h/w component, but just a s/w protocol then it
> > doesn't belong in DT. Perhaps it could be a library which the bridge
> > driver can call into.
>
> Anybus cards have an id register, which identifies what they are, so
> that the appropriate client driver may be instantiated.
> In that sense anybus is very suited to the bus/client abstraction of
> pci/usb/etc.
>
> > What are the resets connected to? The slots? Maybe you should model
> > the slots in DT.
> >
>
> Yes, the resets are ultimately connected to the slots.
> I'm happy to model the slots in DT. It makes sense, they are physical,
> hardware components.

It may also be necessary to have a way to add more DT properties to
a device in the slot that can not be probed by looking at the ID
register. Ideally it should not be needed, but we have added this
to most buses anyway: USB, PCI, MMC and others can all be
probed automatically for many devices, but there are some devices
that need a place where extra information can be stored, e.g.
an ethernet MAC address (in the absence of a PROM), an
external clock or reset line that is not part of the normal protocol,
or a more specific identification when two devices accidentally
have the same ID.

       Arnd