On 3/31/21 5:23 AM, Muhammad Usama Anjum wrote:
On Fri, 2021-03-26 at 14:24 -0600, Shuah Khan wrote:
On 3/25/21 5:46 AM, Muhammad Usama Anjum wrote:
The driver was assuming that all the parameters would be valid. But it
is possible that parameters are sent from userspace. For those cases,
appropriate error checks have been added.
Are you sure this change is necessary for vhci_hcd? Is there a
scenario where vhci_hcd will receive these values from userspace?
I'm not sure if these changes are necessary for vhci_hcd. I'd sent
this patch following the motivation of a patch (c318840fb2) from
dummy_hcd to handle some cases. Yeah, there is scenario where vhci_hcd
will receive these values from userspace. For example, typReq =
SetPortFeature and wValue = USB_PORT_FEAT_C_CONNECTION can be received
from userspace. As USB_PORT_FEAT_C_CONNECTION case isn't being
handled, default case will is executed for it. So I'm assuming
USB_PORT_FEAT_C_CONNECTION isn't supported and default case shouldn't
be executed.
The way dummy_hcd handles USB_PORT_FEAT_C_CONNECTION isn't applicable
to vhci_hcd.
rh_port_connect() and rh_port_disconnect() set the
USB_PORT_FEAT_C_CONNECTION this flag to initiate port status polling.
This flag is set by the driver as a result of attach/deatch request
from the user-space. Current handling of this flag is correct.
Is there a way to reproduce the problem?
I'm not able to reproduce any problem. But typReq = SetPortFeature and
wValue = USB_PORT_FEAT_C_CONNECTION may trigger some behavior which
isn't intended as USB_PORT_FEAT_C_CONNECTION may not be supported for
vhci_hcd.
If you reproduce the problem and it impacts attach/detach and device
remote device access, we can to look into this further.
thanks,
-- Shuah
