Messages in this thread | | | From | Martin Blumenstingl <> | Date | Fri, 18 Jun 2021 22:06:44 +0200 | 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@gmail.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
| |