On 11/21/24 6:08 AM, Abbarapu, Venkatesh wrote:
[...]
As this delay might be specific to the boards which we tested.
There won't be any issue if we can add the default
"reset_delay"(5us) and
"power_on_delay" (1ms) from the USB5744 datasheet, as other boards
will be working without any board specific delay?
Right, the driver has to be generic , that means it should contain
delays specified in the datasheet. Board specific delays have to be
configured in
board specific DTs.
Thanks. I have updated the delays based on usb5744 specification in
the [PATCH v13 3/7] usb: onboard-hub: add support for Microchip
USB5744 Please review.
V13 also enables the hub driver for Xilinx hardware, does it not ?
If so, won't doing so lead to incorrect behavior due to -- now -- too
short delay ? I suspect you will need V14 which adds those board
specific delays via DT for the Xilinx hardware.
There are many customers who use their own boards and they might not see the
issue what we observe on Xilinx/AMD boards. Don't you think we are blocking them
because of our board issues? What you think?
Sure, drop 6 and 7 and the current state of 1..5 can go in I think.
Rather than dropping these patches...
To not block others, update the default reset delays mentioned in the USB5744
datasheet.
This way the customers can use these patch series and don’t wait for the
Xilinx/AMD board issues to be fixed.
We can fix Xilinx/AMD board issues with the reset delays(via DT property) for
USB5744 by introducing/ discussing with Linux community.
I think this way...you don't see any issue right?
Sure, simply send the first five hub patches separately as v14, without
the DT patches, and I'll most likely pick them up. The DT patches have
to go in via Xilinx tree anyway, the USB patches go through USB tree.
