Re: [PATCH v3 2/4] misc: hisi_hikey_usb: change the DT schema

[Matthias Kaehlcke <mka@chromium.org>]

On Thu, Sep 02, 2021 at 04:35:29PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 2 Sep 2021 15:56:36 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> 
> > On Thu, Sep 02, 2021 at 03:38:20PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 2 Sep 2021 15:10:53 +0200
> > > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> > >   
> > > > Em Thu, 2 Sep 2021 13:40:28 +0200
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> > > >   
> > > > > On Thu, Sep 02, 2021 at 01:28:35PM +0200, Mauro Carvalho Chehab wrote:    
> > > > > > As there's no upstream DT bindings for this driver, let's
> > > > > > update its DT schema, while it is not too late.      
> > > > > 
> > > > > So this is for 5.15-final?    
> > > > 
> > > > It can either be for 5.15 or 5.16, as there aren't any compatible
> > > > under arch/ which uses the DT schema there. All patches adding
> > > > such compatible are on this series. So, whatever version this
> > > > is applied should be OK.  
> > > 
> > > On a separate note, despite having "hisi_" on this driver's name, there's
> > > nothing there that is really HiSilicon specific. What this driver does is
> > > to control an USB HUB integrated inside a DT-based board, doing those 
> > > functions:
> > > 
> > > 	- Power on/off the chip;
> > > 	- reset the HUB;
> > > 	- control its OTG switch;
> > > 	- control power on/off for an USB type-C connector;
> > > 	- set USB role as host or device.
> > > 
> > > This is used on both HiKey 960 and HiKey 970 with the following
> > > topology:
> > > 
> > >   +-----+      +--------+       +---------+
> > >   | SoC | ---> | USB PHY|  ---> | USB HUB | ---> USB 3.0
> > >   +-----+      +--------+       +---------+      and type-C ports 
> > > 
> > > Both Kirin 960 and 970 SoCs have a Synapsys IP (DWC 3). 
> > > 
> > > Both HiKey 960 and 970 cards use Richtek RT1711H Type-C Chip Driver
> > > as part of the USB PHY logic, but they use different USB HUBs:
> > > 
> > > 	- HiKey 960 use a Microchip USB5734 HUB
> > > 	- HiKey 970 use a TI TUSB8041 HUB
> > > 
> > > While I'm not sure how generic this driver can be, I'm thinking that
> > > maybe a future patch could rename it to 'generic-usb-hub' or 
> > > something similar - finding a good name is always the hardest 
> > > part :-)  
> > 
> > Try looking at:
> > 	https://lore.kernel.org/r/20210813195228.2003500-1-mka@chromium.org
> > for another example of this.
> 
> (C/C Matthias here).
> 
> Interesting to know that someone else is also needing to add support
> for USB chips.

Yeah, there were several attempts over the years, but so far none of
them landed upstream ...

> Yet, the approach took there won't work with HiKey 960/970, as
> it needs to control not only the regulator, but it should also
> work as as usb-role-switch. 
> 
> So, besides controlling the regulator, which seems to be basically what
> the onboard_usb_hub_driver does, but it should also be able to:
> 
>  	- (optionally) reset the HUB;
> 	- control its OTG switch;
>  	- control power on/off for an USB type-C connector;
>  	- set USB role as host or device.

> Perhaps it would be possible to merge both approaches by modifying
> hisi_hikey_usb in order to add the extra bits required by the boards that
> Matthias is currently working, and requiring the GPIOs for OTG and
> type-C connectors only if DT contains usb-role-switch.

I'm not convinced that a hub driver should be in charge of role switching.
I wonder if the hub part could remain separate, and the role switching be
done by a dedicated driver that interacts with the hub driver through
some interface. From the above list the hub driver could still be in charge
of:

- (optionally) reset the HUB;
- control power on/off for an USB type-C connector;

Maybe the hub driver could implement a reset controller to allow the role
switching driver to switch it on and off (including type-C power).

The role switch driver (a leaner version of hisi_hikey_usb) could model
the mux and switch the hub on and off, without being concerned about all
the details.

I fear if we go the route of completely merging the two drivers it might
end up in a hodgepodge of vaguely related things, and it would probably
re-open the can of worms of the DT binding, which took a long time to
settle, even with a more limited functionality.