Dear Alan Dear Greg Thank you for your feedback. I really appreciate your concrete proposal. > So let's change the code to do 3 tries with each scheme. I understood. I will try to modify it so that the number of attempts will decrease. It is 6 attempts in total both old and new schemes, but msleep is executed at various places in hub_port_connect and hub_port_init. apart from a timeout. For example, msleep(100) is executed every time in the loop of GET_DESCRIPTOR_TRIES[8] of new scheme. and In the old scheme, msleep(200) is executed in the loop of SET_ADDRESS_TRIES[10]. >From my measurement, it does not subside within 30 seconds, but it is around 32 seconds. >From these things, I would like you to reconsider the number of attempts. Is it OK to set the new scheme to 3 times and the old scheme to 2 times(no change as it is)? In other words [plan 1] 3 * new scheme, then 2 * old scheme, or else 2 * old scheme, then 3 * new_scheme, depending on the old_scheme_first parameter. Also, although it is a "better plan", the original processing is in the following. 6 * new scheme, then 6 * new scheme, then 2 * old scheme, then 2 * old scheme if it will be modified from above to below, It seems that the structure of the loop has to be greatly revised. I think. 2 * new scheme, then 2 * old scheme, then 1 * new scheme, then 1 * old scheme The fix is likely to be large, so Can I proceed with a patch in plan 1? I will post the patch after confirming the behavior of the patch with the customer board with the PET tool. please give me a little time. Best Regards Yasushi Asano On Thu, Jul 30, 2020 at 07:42:26PM +0900, Yasushi Asano wrote: > From: Yasushi Asano <yasano@xxxxxxxxxxxxxx> > > Dear Alan > Dear Greg > > I would like to have a consultation with you. The customer's product > board needs to get a USB certification and compliance, but it can not > pass the test using the current USB hub driver. According to the USB > compliance plan[1], the“6.7.22 Device No Response” test requires the > detection of device enumeration failure within 30 seconds. The > kernel(USB hub driver) must notify userspace of the enumeration failure > within 30 seconds. > > In the current hub driver, the place to detect device enumeration > failure is [2]. I have modified the hub driver to issue a uevent here, > but the procedure of device enumeration (new_scheme+old_scheme) takes > too long to execute, it couldn't reach [2] within 30 seconds after > starting the test. According to the result of PETtool [3], the state of > "Device No response" is that usb_control_msg(USB_REQ_GET_DESCRIPTOR) [4] > in hub_port_initn times out. That means r == -ETIMEDOUT. because of the > default setting of initial_descriptor_timeout is 5000 msec[5], > usb_control_msg() took 5000msec until -ETIMEDOUT. > > I will try to describe the flow of device enumeration processing > below[6]. If my understanding is correct, the enumeration failure [2] > will be reached after performing all the loops of [7][8][9]+[7][10]. In > the new scheme, 12 times check will be performed ([7]/2*[8]*[9] => 2*2*3 > => 12). In the old scheme , 4 times check will be performed ([7]/2*[10] > => 2*2 => 4). In total, it checks 16 times, and it took 5000msec to > ETIMEDOUT every time. Therefore, It takes about 80 seconds(16*5000msec) > to reach [2]. This does not pass the "Device No response" test. I agree with Greg, we don't want to add module parameters. The problem is that we make up to 16 attempts, and each attempt can take 5 seconds. We need to decrease the number of attempts to 6; then the total time will be 30 seconds. We also need to keep both the old and new schemes. So let's change the code to do 3 tries with each scheme. For example, 3 * new scheme, then 3 * old scheme, or else 3 * old scheme, then 3 * new_scheme, depending on the old_scheme_first parameter. Change the loops in [7], [8], [9], and [10] so that each iteration does the next item on this list instead of starting back at the beginning. (Or maybe it would work better with 2 * scheme, then 2 * old scheme, then 1 * new scheme, then 1 * old scheme with old and new swapped if old_scheme_first is set. I don't know.) Anyway, can you write a patch to do this? Alan Stern
