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]

Date:   Tue, 6 Nov 2018 15:05:24 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Sven Van Asbroeck <svendev@...x.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>, mark.rutland@....com,
        Andreas Färber <afaerber@...e.de>,
        treding@...dia.com, David Lechner <david@...hnology.com>,
        noralf@...nnes.org, johan@...nel.org,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        Arnd Bergmann <arnd@...db.de>, gregkh@...uxfoundation.org,
        john.garry@...wei.com, geert+renesas@...der.be,
        robin.murphy@....com, paul.gortmaker@...driver.com,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        Stuart Yoder <stuyoder@...il.com>, maxime.ripard@...tlin.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v3 1/6] misc: support the Arcx anybus bridge

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.

>
> A block diagram would help. Something that shows the host SoC, your
> CPLD, reset, irq, etc.
>

  +------------------------------------------------------------------------+
  |                                  SOC (i.MX6)                           |
  |------------------------------------------------------------------------|
  |     i.MX WEIM bus                                   | i.MX GPIO        |
  +------------------------------------------------------------------------+
                ^                                              ^ ^
                | parallel bus                                 | | irq x2
                v                                              | |
  +------------------------------------------------------------------------+
  |                                     CPLD                               |
  |------------------------------------------------------------------------|
  |             anybus slot 1             ||            anybus slot 2      |
  |------------------------------------------------------------------------|
  | memory bus               | irq| reset || memory bus       | irq| reset |
  +------------------------------------------------------------------------+
                ^                                               ^
                |                                               |
                v                                               v
  +--------------------------------------+ +-------------------------------+
  |          anybus card                 | |           anybus card         |
  +--------------------------------------+ +-------------------------------+