ARM: shmobile: r8a7791: add for USB-DMAC

Hello Shimoda-san,

(Dropping the DT maintainers from CC and adding Linus Walleij, Kishon Vijay Abraham and Felipe Balbi)

I've successfully tested USB-DMAC integration (congratulations for the good work !), but ran into several issues that I wanted to discuss with you.

Both issues are I believe related to the fact that the HSUSB and EHCI/OHCI controllers share the same PHY and the same pins.

When both drivers are loaded, the following messages are printed to the kernel log.

[    8.917418] sh-pfc e6060000.pfc: pin GP_7_23 already requested by 
ee090000.pci; cannot claim for e6590000.usb
[    8.927594] sh-pfc e6060000.pfc: pin-247 (e6590000.usb) status -22
[    8.933913] sh-pfc e6060000.pfc: could not request pin 247 (GP_7_23) from 
group usb0  on device sh-pfc
[    8.943990] renesas_usbhs e6590000.usb: Error applying setting, reverse 

things back

This is caused by the pci0 and hsusb DT nodes referencing the same default pin configuration node. There should be no issue in practice as the pin configuration is already applied through the other device, but I'd still like to find a fix to avoid the error message.

The other issue is that the renesas_hsusb and ehci drivers compete to control the same PHY. The phy-rcar-gen2 driver creates two Linux PHYs for each physical PHY (called channel in the driver) to ensure that each driver can get its own PHY instance. Arbitration is then handled in the PHY .init() handler which returns -EBUSY if another driver already controls the channel. The error value is propagated up to usbhsc_power_ctrl() where it's then ignored. This doesn't look like a good way to handled the shared PHY, but I'm not familiar enough with the PHY subsystem to know how to fix it.

Regards,

Laurent Pinchart