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: <CAL_Jsq+YeW+BtVh=L8PBjXYLj9sp91BcUQrJJrwnmChRnXoK_w@mail.gmail.com>
Date:   Tue, 6 Nov 2018 12:30:55 -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 v3 1/6] misc: support the Arcx anybus bridge

On Tue, Nov 6, 2018 at 8:46 AM Sven Van Asbroeck <thesven73@...il.com> wrote:
>
> On Tue, Nov 6, 2018 at 8:58 AM Rob Herring <robh@...nel.org> wrote:
>
> > It doesn't really sound like the host should be in DT. The bridge
> > should register itself as an anybus provider and that should in turn
> > enable the anybus host protocol.
>
> Very good point. Just to make sure we're on the same page, could you point
> me to a relevant example where something registers as a provider?

Not sure exactly. Perhaps I2C SMBus functions that implement the
register access protocol on top of I2C bus.

> v1 of this patch did not have the host in DT. The host just required platform
> data with a regmap and a reset (the interrupt was passed via resources):
>
> struct anybuss_host_pdata {
>     struct regmap *regmap;
>     void (*reset)(struct device *dev, bool reset);
> };
>
> But there were problems with this approach.

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

> The review feedback told me that my self-rolled reset callback should really
> be a reset controller. I looked for ways to pass a handle to a reset controller
> via platform data. This has recently been introduced via:

Maybe an overkill for 1 reset.

>
> reset_controller_add_lookup()
>
> This binds a client device to a reset controller, without using the devicetree,
> so the device can grab its controller via (devm_)reset_control_get*. Great!
> But... to make the binding, you have to specify the full device names of the
> controllers and client devices. See this example from psc-da850.c:
>
> static struct reset_control_lookup da850_psc0_reset_lookup_table[] = {
>     RESET_LOOKUP("da850-psc0", 15, "davinci-rproc.0", NULL),
> };
>
> I very quickly found myself in ida_simple_get() hell, trying to second-guess
> what the devices I was creating, would be called !
>
> So instead I put the host in DT, then I could easily connect the reset
> controller. This also greatly simplified the bridge driver, a lot of boilerplate
> would simply disappear.

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.

What are the resets connected to? The slots? Maybe you should model
the slots in DT.

Rob