linux-kernel - Re: [PATCH v3 0/9] Add the Renesas USBF controller support

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_JsqJiZU=sHVPc92nDNoqUjm7FUb=u0izGYa+irkUW1XmA_w@mail.gmail.com>
Date:   Wed, 7 Dec 2022 16:19:42 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Herve Codina <herve.codina@...tlin.com>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Magnus Damm <magnus.damm@...il.com>,
        Gareth Williams <gareth.williams.jx@...esas.com>,
        linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [PATCH v3 0/9] Add the Renesas USBF controller support

On Wed, Dec 7, 2022 at 10:24 AM Herve Codina <herve.codina@...tlin.com> wrote:
>
> Hi,
>
> This series add support for the Renesas USBF controller (USB Device
> Controller) available in the Renesas RZ/N1 SoC.
>
> Based on previous review:
>   https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
>
> A new strategy is proposed to handle the H2MODE bit from CFG_USB
> register compared to the previous versions on the series. As a
> reminder, H2MODE bit allows to configure the internal USB Port
> interface for two hosts or one host and one device.

Is this case any different from all the phandle properties we have in
bindings that point to some misc registers somewhere else you need to
poke? If so, I'm not really a fan of duplicating the information.

We also have cases of of_find_compatible_node(NULL, NULL,
"foo-bar-syscon") which is a dependency expressed in the driver, but
not DT. In either case, adding 'depends-on' would be an ABI break as
you are requiring a DT change.

> This new strategy is:
>   - Add the new generic 'depends-on' property in the device tree.
>
>     This generic property expresses an simple functionnal dependency
>     that does not rely on a specific topic. It is an 'order only'
>     dependency that can be used for dependencies between consumers
>     and producers that are not based on a specific infrastructure
>     and not need other relationship than this simple 'order only'
>     (ie no API is provided between the provider and the consumer)

Isn't getting a regmap an API?

Rob