linux-kernel - Re: [RFCv1 6/8] phy: amlogic: meson8b-usb2: Use phy reset callback function

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: <CAFBinCD+seUuYUrObiqJNgEi_DaULB3nU+QQFHz9d85dAU06ZA@mail.gmail.com>
Date:   Sun, 27 Jun 2021 22:25:33 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Anand Moon <linux.amoon@...il.com>
Cc:     Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        linux-phy@...ts.infradead.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-amlogic@...ts.infradead.org,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFCv1 6/8] phy: amlogic: meson8b-usb2: Use phy reset callback function

Hi Anand,

On Sun, Jun 27, 2021 at 10:07 PM Anand Moon <linux.amoon@...il.com> wrote:
[...]
> Sorry for the delay.
> We could switch the reset logic to
> *devm_reset_control_get_optional_exclusive* as below
> to fix the reset line, since both the dwc2 c90c0000.usb and c9040000.usb
> will have their own context to reset control register, it means the
> reset line is not share
> between two USB PHY nodes.
This is something I don't understand.
As discussed in our previous mails reset_control_reset in case of the
USB PHY driver (which uses the RESET_USB_OTG reset line for *both*
PHYs) is equivalent to the following code in the vendor kernel:
  aml_cbus_update_bits(0x1102, 0x1<<2, 0x1<<2)

We have two PHYs but only one reset line. So in my own words I
describe the reset line as being shared.

>
> -       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
> +       priv->reset = devm_reset_control_get_optional_exclusive(&pdev->dev,
> +                                                               "reset");
Have you boot-tested this?
Without any .dts changes this will return NULL because there's no
reset-names = "reset"; in the .dts(i).
If you replace "reset" with NULL then I assume that the second PHY
will fail to obtain the reset line because it's shared between two
devices but we're trying to obtain it exclusively for both (PHYs).


Best regards,
Martin