kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/usb/misc/ehset.c

190 lines
5.6 KiB
Raw Normal View History

USB: add SPDX identifiers to all remaining files in drivers/usb/ It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-03 11:28:30 +01:00
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: fix wrong if condition A negative number from ret means the host controller had failed to send usb message and 0 means succeed. Therefore, the if logic is wrong here and this patch will fix it. Fixes: f2b42379c576 ("usb: misc: ehset: Rework test mode entry") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20230705095231.457860-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05 17:52:31 +08:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: fix wrong if condition A negative number from ret means the host controller had failed to send usb message and 0 means succeed. Therefore, the if logic is wrong here and this patch will fix it. Fixes: f2b42379c576 ("usb: misc: ehset: Rework test mode entry") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20230705095231.457860-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05 17:52:31 +08:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: fix wrong if condition A negative number from ret means the host controller had failed to send usb message and 0 means succeed. Therefore, the if logic is wrong here and this patch will fix it. Fixes: f2b42379c576 ("usb: misc: ehset: Rework test mode entry") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20230705095231.457860-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05 17:52:31 +08:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: fix wrong if condition A negative number from ret means the host controller had failed to send usb message and 0 means succeed. Therefore, the if logic is wrong here and this patch will fix it. Fixes: f2b42379c576 ("usb: misc: ehset: Rework test mode entry") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20230705095231.457860-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05 17:52:31 +08:00
usb: misc: ehset: Rework test mode entry The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. We should follow the specification and put the USB port in suspend before sending the test command. Also there are some "special" hubs, which requires to disable the USB port power instead of putting it in suspend. I found out only three hubs which requires this step, but if more are found, they can be added to the list. Since this changes the default implementation, it raises the posibility of finding other broken hubs which are not compliant with the spec and the test command might not work is the port is suspended. If such hubs are found, a similar workaround like the disable part can be implemented to skip putting the port in suspend. Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com> Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-13 20:36:15 +02:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET The USB Embedded High-speed Host Electrical Test (EHSET) defines the SINGLE_STEP_SET_FEATURE test as follows: 1) The host enumerates the test device with VID:0x1A0A, PID:0x0108 2) The host sends the SETUP stage of a GetDescriptor(Device) 3) The device ACKs the request 4) The host issues SOFs for 15 seconds allowing the test operator to raise the scope trigger just above the SOF voltage level 5) The host sends the IN packet 6) The device sends data in response, triggering the scope 7) The host sends an ACK in response to the data This patch adds additional handling to the EHCI hub driver and allows the EHSET driver to initiate this test mode by issuing a a SetFeature request to the root hub with a Test Selector value of 0x06. From there it mimics ehci_urb_enqueue() but separately submits QTDs for the SETUP and DATA/STATUS stages in order to insert a delay in between. Signed-off-by: Manu Gautam <mgautam@codeaurora.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> [jackp@codeaurora.org: imported from commit c2084930 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-08 16:49:24 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET The USB Embedded High-speed Host Electrical Test (EHSET) defines the SINGLE_STEP_SET_FEATURE test as follows: 1) The host enumerates the test device with VID:0x1A0A, PID:0x0108 2) The host sends the SETUP stage of a GetDescriptor(Device) 3) The device ACKs the request 4) The host issues SOFs for 15 seconds allowing the test operator to raise the scope trigger just above the SOF voltage level 5) The host sends the IN packet 6) The device sends data in response, triggering the scope 7) The host sends an ACK in response to the data This patch adds additional handling to the EHCI hub driver and allows the EHSET driver to initiate this test mode by issuing a a SetFeature request to the root hub with a Test Selector value of 0x06. From there it mimics ehci_urb_enqueue() but separately submits QTDs for the SETUP and DATA/STATUS stages in order to insert a delay in between. Signed-off-by: Manu Gautam <mgautam@codeaurora.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> [jackp@codeaurora.org: imported from commit c2084930 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-08 16:49:24 -07:00
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API The newer usb_control_msg_{send|recv}() API ensures that a short read is treated as an error, data can be used off the stack, and raw usb pipes need not be created in the calling functions. For this reason, instances of usb_control_msg() have been replaced with usb_control_msg_{recv|send}() appropriately. Now, we also test for a short device descriptor (which USB core should already have fetched if you get to probe this driver), but which wasn't verified again here before. Reviewed-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-27 04:02:49 +05:30
usb: misc: EHSET Test Fixture device driver for host compliance An Embedded Host High-Speed Electrical Test (EHSET) test fixture is used to initiate test modes on a host controller in order to perform the high speed electrical testing procedure for USB-IF compliance. When this test fixture is connected to a host, it can enumerate as one of several selectable VID/PID pairs, each corresponding to one of the following test modes: * TEST_SE0_NAK * TEST_J * TEST_K * TEST_PACKET * HS_HOST_PORT_SUSPEND_RESUME * SINGLE_STEP_GET_DEV_DESC * SINGLE_STEP_SET_FEATURE The USB EHSET procedure can be found here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf Signed-off-by: Manu Gautam <mgautam@codeaurora.org> [jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 20:13:51 -07:00