Searched hist:53642399 (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/include/uapi/linux/usb/ |
H A D | functionfs.h | 1f7da4f8 Fri Feb 17 05:20:38 CST 2017 Vincent Pelletier <plr.vincent@gmail.com> usb: gadget: f_fs: Fix ExtCompat documentation in uapi header
The code was fixed in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof OS_DESC_EXT_COMPAT") but the in-header documentation kept referencing 0 as the expected value. Reference 1 instead as per original commit message.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 1f7da4f8 Fri Feb 17 05:20:38 CST 2017 Vincent Pelletier <plr.vincent@gmail.com> usb: gadget: f_fs: Fix ExtCompat documentation in uapi header The code was fixed in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof OS_DESC_EXT_COMPAT") but the in-header documentation kept referencing 0 as the expected value. Reference 1 instead as per original commit message. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
/openbmc/linux/drivers/usb/gadget/function/ |
H A D | f_fs.c | a3acc696 Mon Nov 27 12:15:40 CST 2017 John Keeping <john@metanate.com> usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT
The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values.
This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded!
If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves.
Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Cc: <stable@vger.kernel.org> Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> a3acc696 Mon Nov 27 12:15:40 CST 2017 John Keeping <john@metanate.com> usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT
The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values.
This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded!
If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves.
Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Cc: <stable@vger.kernel.org> Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 3ba534df Thu Feb 16 07:54:12 CST 2017 Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation"
This reverts commit ac670a3a650b899fc020b81f63e810d06015b865.
This introduce bug we already fixed in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof OS_DESC_EXT_COMPAT")
Next FFS (adb) SS enumeration fail with Windows OS.
Signed-off-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 53642399 Fri May 20 05:13:19 CDT 2016 Jim Lin <jilin@nvidia.com> usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT
Current __ffs_data_do_os_desc() of f_fs.c will check reserved1 field of OS_DESC_EXT_COMPAT and return -EINVAL if it's 1. But MS OS 1.0 Descriptors http://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx defines that field to be 1.
Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> a3acc696 Mon Nov 27 12:15:40 CST 2017 John Keeping <john@metanate.com> usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values. This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded! If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves. Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Cc: <stable@vger.kernel.org> Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> a3acc696 Mon Nov 27 12:15:40 CST 2017 John Keeping <john@metanate.com> usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values. This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded! If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves. Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Cc: <stable@vger.kernel.org> Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 3ba534df Thu Feb 16 07:54:12 CST 2017 Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation" This reverts commit ac670a3a650b899fc020b81f63e810d06015b865. This introduce bug we already fixed in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof OS_DESC_EXT_COMPAT") Next FFS (adb) SS enumeration fail with Windows OS. Signed-off-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 53642399 Fri May 20 05:13:19 CDT 2016 Jim Lin <jilin@nvidia.com> usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT Current __ffs_data_do_os_desc() of f_fs.c will check reserved1 field of OS_DESC_EXT_COMPAT and return -EINVAL if it's 1. But MS OS 1.0 Descriptors http://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx defines that field to be 1. Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|