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.