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: <CAGngYiXczK6dsfyDGxe1ym-vQQfH5XS0jeEkuWW_og23JmTAZg@mail.gmail.com>
Date:   Tue, 6 Nov 2018 09:45:55 -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 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?

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.

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:

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.

Suggestions are very welcome :)

Sven