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: <CANAwSgRABOyWYJPrrw64Wa6j2D94T4tybn7MHGCTbBowt7UncA@mail.gmail.com>
Date:   Mon, 21 Jun 2021 12:45:51 +0530
From:   Anand Moon <linux.amoon@...il.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.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 Martin

Thanks for your review comments.

On Sat, 19 Jun 2021 at 01:36, Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
>
> 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).
>
Ok Thanks for the inputs. got your point.

I was also looking into Amlogic source code for reset. (aml_cbus_update_bits)
[0] https://github.com/khadas/linux/blob/khadas-vims-4.9.y/drivers/amlogic/usb/phy/phy-aml-new-usb.c
is there some feature to iomap the USB with cbus?

> [...]
> > > > -       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?
>
I need to investigate this reset feature. With my setup with current changes
after I update the below.
-       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, "phy");
+       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
        if (PTR_ERR(priv->reset) == -EPROBE_DEFER)
                return PTR_ERR(priv->reset);

Reset will break the USB initialization, see below output.

[    1.265403] dwc2 c9040000.usb: mapped PA c9040000 to VA (ptrval)
[    1.265540] dwc2 c9040000.usb: Looking up vusb_d-supply from device tree
[    1.265554] dwc2 c9040000.usb: Looking up vusb_d-supply property in
node /soc/usb@...40000 failed
[    1.265585] dwc2 c9040000.usb: supply vusb_d not found, using dummy regulator
[    1.265717] dwc2 c9040000.usb: Looking up vusb_a-supply from device tree
[    1.265730] dwc2 c9040000.usb: Looking up vusb_a-supply property in
node /soc/usb@...40000 failed
[    1.265752] dwc2 c9040000.usb: supply vusb_a not found, using dummy regulator
[    1.265812] dwc2 c9040000.usb: registering common handler for irq35
[    1.265867] dwc2 c9040000.usb: Looking up vbus-supply from device tree
[    1.265880] dwc2 c9040000.usb: Looking up vbus-supply property in
node /soc/usb@...40000 failed
[    1.267066] dwc2 c9040000.usb: Core Release: 3.10a (snpsid=4f54310a)
[    1.270983] dwc2 c9040000.usb: dwc2_core_reset: HANG! Soft Reset
timeout GRSTCTL_CSFTRST
[    1.271319] dwc2: probe of c9040000.usb failed with error -16
[    1.273296] dwc2 c90c0000.usb: mapped PA c90c0000 to VA (ptrval)
[    1.273426] dwc2 c90c0000.usb: Looking up vusb_d-supply from device tree
[    1.273440] dwc2 c90c0000.usb: Looking up vusb_d-supply property in
node /soc/usb@...c0000 failed
[    1.273471] dwc2 c90c0000.usb: supply vusb_d not found, using dummy regulator
[    1.273607] dwc2 c90c0000.usb: Looking up vusb_a-supply from device tree
[    1.273621] dwc2 c90c0000.usb: Looking up vusb_a-supply property in
node /soc/usb@...c0000 failed
[    1.273641] dwc2 c90c0000.usb: supply vusb_a not found, using dummy regulator
[    1.273700] dwc2 c90c0000.usb: registering common handler for irq36
[    1.273750] dwc2 c90c0000.usb: Looking up vbus-supply from device tree
[    1.273762] dwc2 c90c0000.usb: Looking up vbus-supply property in
node /soc/usb@...c0000 failed
[    1.274966] dwc2 c90c0000.usb: Core Release: 3.10a (snpsid=4f54310a)
[    1.278888] dwc2 c90c0000.usb: dwc2_core_reset: HANG! Soft Reset
timeout GRSTCTL_CSFTRST
[    1.279224] dwc2: probe of c90c0000.usb failed with error -16



>
> Best regards,
> Martin

Thanks
-Anand