[PATCH] sunxi: usb: convert PHY GPIO functions to DM

[Andre Przywara]

On Wed, 8 Jun 2022 08:14:27 -0500
Samuel Holland <samuel at sholland.org> wrote:

Hi,

> On 6/8/22 4:46 AM, Andre Przywara wrote:
> > On Tue, 7 Jun 2022 21:07:59 -0500
> > Samuel Holland <samuel at sholland.org> wrote:
> > 
> > Hi,
> >   
> >> On 6/7/22 7:06 PM, Andre Przywara wrote:  
> >>> The Allwinner USB PHY driver is still using the legacy GPIO interface,
> >>> which is now implemented by the DM_GPIO compat functions.
> >>> Those seem to have some design flaws, as setting the direction, then
> >>> later setting the value will not work, if the DM_GPIO driver is
> >>> implementing set_flags.
> >>>
> >>> Fix this by using the dm_ version of the direct GPIO interface, which
> >>> uses struct gpio_desc structs to handle requested GPIOs, and actually
> >>> keeps the flags we set earlier.
> >>>
> >>> This fixes USB operation on boards which need to toggle the VBUS supply
> >>> via a GPIO, like the Teres-I laptop or the BananaPi M2 Berry board.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >>> Reported-by: Milan P. Stanić <mps at arvanta.net>    
> >>
> >> Reviewed-by: Samuel Holland <samuel at sholland.org>  
> > 
> > Thanks!
> >   
> >>
> >> It looks like the other users of sunxi_name_to_gpio are unaffected because they
> >> call only gpio_direction_output (sometimes repeatedly), never gpio_set_value.  
> > 
> > Yeah, that's right, I was concerned about SATAPWR and MACPWR too, but they
> > work, for the very reason you mentioned.
> > But we should eventually eliminate their usage, together with
> > CONFIG_USB?_VBUS_PIN, as they are only used in U-Boot proper, where we can
> > rely on proper DT information now.  
> 
> I have a series for converting the USB PHY driver to devicetree already, but it

So I remembered correctly ...

> has been blocked on the devicetree update renaming "usb0_*_det-gpio" to
> "usb0_*_det-gpios". In fact it is still blocked on that, because the sun4i
> devicetree patch was only partially applied.

Yeah, I saw that, sorry for the mixup. That patch didn't make it to
patchwork, so I applied it manually on one tree, but fixed it up wrongly on
the other machine. It is in my (mental) fixes queue, together with that
H616 FEL issue (once I find the actual culprit), and that NAND environment
fix.
Once that's in, I will try to update the -next branch with stuff for the
next merge window (in July), so you can then work on that branch.

> I will rebase the series on top of your patch and send it soon.

Cool, many thanks. And no rush, I just wanted to check to avoid double
work.
I think I figured nice and easy solutions for SATAPWR and MACPWR, will
test them later tonight.

Cheers,
Andre