On 23-08-24, 09:01, Biju Das wrote: > > >> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware > > limitation. > > >> As the register that need to be touched for this is in the address > > >> space of the USB PHY, and the UBS PHY need to be initialized before > > >> any other USB drivers handling data transfer, add support to initialize the USB BUS. > > >> > > >> As the USB PHY is probed before any other USB drivers that enables > > >> clocks and de-assert the reset signals and the BUS initialization is > > >> done in the probe phase, we need to add code to de-assert reset signal and runtime resume the > > device (which enables its clocks) before accessing the registers. > > >> > > >> As the reset signals are not required by the USB PHY driver for the > > >> other USB PHY hardware variants, the reset signals and runtime PM was handled only in the function > > that initialize the USB BUS. > > >> > > >> The PHY initialization was done right after runtime PM enable to have > > >> all in place when the PHYs are registered. > > > > > > There is no user for this patch. The first user is RZ/G3S and you > > > should merge this patch with next one. > > > > I think this is a matter of taste... This is how I usually format the patches (for scenarios like > > this) and got no request for squashing. > > That is strange for trivial patches like this. Splitting is better, this patch does one thing whereas the next one uses it adds in new device, i would say quite a clean approach NOTE: Don't quote the not required context while replying, it is good mail list hygiene -- ~Vinod
