On 19/09/2020 16.54, M. Vefa Bicakci wrote:
On 18/09/2020 18.49, Shuah Khan wrote:
On 9/18/20 8:31 AM, M. Vefa Bicakci wrote:
Hello Shuah,
I have just cleaned up the patches and run usbip_test.sh with a kernel without the patches in this series and with a kernel in this series.
I noticed that there is a change in behaviour due to the fact that the new match function (usbip_match) does not always return true. This causes the stub device driver's probe() function to not get called at all, as the new more selective match function will prevent the stub device driver from being considered as a potential driver for the device under consideration.
Yes. This is the behavior I am concerned about and hence the reason to use the usbip test to verify this doesn't happen.
With the patch you have the usbip match behavior becomes restrictive which isn't desirable.
All of this results in the following difference in the logs of the usbip_test.sh, where the expected kernel log message "usbip-host 2-6: 2-6 is not in match_busid table... skip!" is not printed by a kernel that includes the patches in this series.
--- unpatched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 +++ patched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 @@ -213,70 +213,69 @@ |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M ============================================================== modprobe usbip_host - does it work? Should see -busid- is not in match_busid table... skip! dmesg ============================================================== -usbip-host 2-6: 2-6 is not in match_busid table... skip! ==============================================================
Do you find this change in behaviour unacceptable?
Yeah. This behavior isn't acceptable.
If no, I can remove this
test case from usbip_test.sh with the same patch. If yes, then there is a need for a different solution to resolve the unexpected negative interaction between Bastien's work on generic/specific USB device driver selection and usbip functionality.
I would recommend finding a different solution. Now that you have the usbip test handy, you can verify and test for regressions.
thanks, -- Shuah
Thanks for the feedback, Shuah. I spent some time looking at and instrumenting the code in an attempt to find another solution, but have not found one.
If the generic/specific USB driver selection functionality that Bastien Nocera introduced is desired to stay in the kernel, then making usbip_match more specific appears to be the only option for usbip to be functional without negatively affecting other device drivers.
Should Bastien's work be reverted until a solution to this issue is found? Would you (or anyone) have any suggestions? I would be happy to work further on resolving this issue.
Hello again,
Status update: I found a solution that should be more acceptable. It involves some changes to the generic/specialized driver selection code and the removal of usbip_match altogether, while preserving proper behaviour of the usbip driver, apple-mfi-fastcharge and dummy_hcd. I intend to publish a new patch set by tomorrow.
Vefa