Hi Vinod,

-----Original Message-----
From: Vinod Koul <vkoul@kernel.org>
Sent: Friday, August 30, 2024 9:03 AM
Subject: Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

On 23-08-24, 09:01, Biju Das wrote:

quoted

quoted

quoted

quoted

The Renesas RZ/G3S need to initialize the USB BUS before
transferring data due to hardware

limitation.

quoted

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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

Agreed. I was wrong then. To support a new device, bus initialization is required.
So I thought it should go together.

Cheers,
Biju