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: <CAFBinCALsnpbJGEb4LBLd_jy3E8fOZAQaacz-P7ijfkeyYg2dA@mail.gmail.com>
Date:   Fri, 18 Jun 2021 22:06:44 +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 Fri, Jun 18, 2021 at 5:33 PM Anand Moon <linux.amoon@...il.com> wrote:
[...]
> > For shared resets (like the one we have here) reset_control_reset will
> > only trigger the reset line once until all drivers using that reset
> > line are unloaded.
> > So effectively this new phy_ops.reset callback will be a no-op.
>
> I know his register is shared between two USB IPs,
> but I have not observed any issues.
have you checked at which point we're then actually triggering the reset?
I assume that you will find that the reset is only triggered for the
very first power_on/init call - which makes this patch effectively a
no-op (yes, we're calling reset_control_reset then, but that doesn't
mean that a reset is triggered on hardware level - see
drivers/reset/core.c at around line 346).

[...]
> > > -       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
> > > +       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, "phy");
> > I think this breaks compatibility with existing .dtbs and our
> > dt-bindings (as we're not documenting a "reset-names" property).
> > What is the goal of this one?
> >
>
> OK, If we pass NULL over here there is the possibility
> USB phy will not get registered.
I don't understand why - with NULL everything is working fine for me.
Also no matter which name you give to the reset line (in reset-names),
it will be the same reset line in all cases. If it's the same reset
line before and after: why is this needed?


Best regards,
Martin