Why is USB_DT_HUB not used?

2015-03-06 Thread Tal Shorer
As far as I can grep, the only hcd that uses the named constants USB_DT_HUB and USB_DT_SS_HUB is xhci. even dummy_hcd which uses USB_DT_SS_HUB to check that uscore asked for a superspeed hub descriptor still uses the numeric value when filling the buffer. Was this just overlooked? Will a patch

[PATCH v2] usb: gadget: f_mass_storage: use defined constant instead of numeric value

2015-03-06 Thread Tal Shorer
replace numeric value with TYPE_NO_LUN (defined in scsi/scsi.h) Signed-off-by: Tal Shorer tal.sho...@gmail.com Acked-by: Michal Nazarewicz min...@mina86.com --- drivers/usb/gadget/function/f_mass_storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget

Re: [PATCH] usb: musb: add softconnect for host mode

2015-03-24 Thread Tal Shorer
Mostly out of curiosity, why a debugfs interface and not an attribute in sysfs? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: f_mass_storage: use defined constant instead of numeric value

2015-02-26 Thread Tal Shorer
Signed-off-by: Tal Shorer tal.sho...@gmail.com --- drivers/usb/gadget/function/f_mass_storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c index 811929c..6d5ca2b 100644

Re: [PATCH v2] USB: don't build PCI quirks if USB support isn't configured

2015-04-22 Thread Tal Shorer
Why is drivers/usb/Makefile even read when CONFIG_USB is not set? Won't it make more sense to throw the line obj-$(CONFIG_PCI) += usb/ from drivers/Makfile? On Wed, Apr 22, 2015 at 7:11 PM, Alan Stern st...@rowland.harvard.edu wrote: The USB PCI quirks code gets built into the kernel whenever

Re: [PATCH v2 4/4] Documentation: ABI: Fix documentation for mass_storage function

2015-04-09 Thread Tal Shorer
On Wed, Apr 8, 2015 at 3:06 PM, Krzysztof Opasiak k.opas...@samsung.com wrote: Luns in mass storage function are identified using their id. While creating lun's directory user cannot choose any arbitrary name other than arabic numeral from 1 to FSG_MAX_LUNS. Signed-off-by: Krzysztof Opasiak

Re: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()

2015-04-07 Thread Tal Shorer
Wild guess, you don't see the same behavior on your desktop machine because it's a different hcd that sets the return value. What happens when you On Tue, Apr 7, 2015 at 9:57 PM, Mark Enstone mark.enst...@silabs.com wrote: linux-usb, Apologies if I've come at this the wrong way, I've read

Re: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()

2015-04-07 Thread Tal Shorer
Stupid mail client sent my message mid-writing. Sorry. What happens when you remove a last-non-CP210X device from the hub? On Tue, Apr 7, 2015 at 10:39 PM, Tal Shorer tal.sho...@gmail.com wrote: Wild guess, you don't see the same behavior on your desktop machine because it's a different hcd

Re: common code for CDC drivers

2015-06-26 Thread Tal Shorer
As someone who has cdc-acm enabled and usbnet disabled on my project, I'd rather you don't break my configuration : On Fri, Jun 26, 2015 at 4:40 PM, Oliver Neukum oneu...@suse.com wrote: Hi, I am looking at all the CDC drivers. They all have a parser for the extra CDC headers. If I unify this

Re: common code for CDC drivers

2015-06-26 Thread Tal Shorer
, the happier I am. On Fri, Jun 26, 2015 at 7:59 PM, Greg KH g...@kroah.com wrote: On Fri, Jun 26, 2015 at 07:47:47PM +0300, Tal Shorer wrote: As someone who has cdc-acm enabled and usbnet disabled on my project, I'd rather you don't break my configuration : configurations will not break

Re: [PATCH] usb: ulpi: don't register drivers if bus doesn't exist

2015-05-24 Thread Tal Shorer
Why do we even need that? If you take patch that makes ulpi_init a subsys_initcall you won't have this problem, and no additional weird hacks and errors will be needed On Sun, May 24, 2015 at 11:09 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: On Sun, May 24, 2015 at 12:19:48AM -0700,

Values for SetHubDepth and GetPortErrorCount

2015-08-07 Thread Tal Shorer
In include/linux/usb/hcd.h, we have /* class requests from USB 3.0 hub spec, table 10-5 */ #define SetHubDepth (0x3000 | HUB_SET_DEPTH) #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) However, from the usb 3.1 spec I downloaded at http://www.usb.org/developers/docs/, table 10-5

Re: Values for SetHubDepth and GetPortErrorCount

2015-08-07 Thread Tal Shorer
On Fri, Aug 7, 2015 at 8:31 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 07:56:37PM +0300, Tal Shorer wrote: On Fri, Aug 7, 2015 at 7:37 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote: In include/linux/usb

[Patch v2] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux

Re: Values for SetHubDepth and GetPortErrorCount

2015-08-07 Thread Tal Shorer
On Fri, Aug 7, 2015 at 7:37 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote: In include/linux/usb/hcd.h, we have /* class requests from USB 3.0 hub spec, table 10-5 */ #define SetHubDepth (0x3000 | HUB_SET_DEPTH) #define

[PATCH] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux

Re: [Patch v2] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
Please ignore v2, I missed that you On Fri, Aug 7, 2015 at 9:13 PM, Tal Shorer tal.sho...@gmail.com wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request

[Patch v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h

Re: [Patch v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
On Fri, Aug 7, 2015 at 9:40 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth

[Patch v4] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

2015-08-07 Thread Tal Shorer
0010B SET_HUB_DEPTH Hub Depth ZeroZeroNone GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero PortTwo Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com

[PATCH 0/1] usb: musb: nuke endpoint before setting its descriptor to NULL

2016-04-14 Thread Tal Shorer
This patch fixes this problem by moving the clearing of ep->desc to occur after calling the complete() callbacks for all requests. Tal Shorer (1): usb: musb: gadget: nuke endpoint before setting its descriptor to NULL drivers/usb/musb/musb_gadget.c | 6 +++--- 1 file changed, 3 insertions(+)

[PATCH 1/1] usb: musb: gadget: nuke endpoint before setting its descriptor to NULL

2016-04-14 Thread Tal Shorer
Some functions, such as f_sourcesink, rely on an endpoint's desc field during their requests' complete() callback, so clear it only _after_ nuking all requests to avoid NULL pointer dereference. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/musb/musb_gadget.c | 6 +++

Possible design problem with struct ulpi_ops's dev field

2016-07-30 Thread Tal Shorer
hes that make such a series. Do I change the api and all users in one patch? one patch for api and one for each user? Any comments and guidelines are welcome :) Respectfully, Tal Shorer -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a mess

[PATCH 2/5] usb: ulpi: change operations api to pass parent device directly

2016-07-30 Thread Tal Shorer
ead() and ulpi_write() instead of via the ops argument Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 4 ++-- drivers/usb/dwc3/ulpi.c| 8 include/linux/ulpi/interface.h | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) d

[PATCH 3/5] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-07-30 Thread Tal Shorer
Operations now use ulpi->dev.parent directly instead of via the ulpi_ops struct, making this field unused. Remove it. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 1 - include/linux/ulpi/interface.h | 2 +- 2 files changed, 1 insertion(+), 2

[PATCH 4/5] usb: ulpi: make ops struct constant

2016-07-30 Thread Tal Shorer
None of the core ulpi functions perform any changes to the operations struct, and logically as a struct that contains function pointers there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- include/linu

[PATCH 0/5] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-07-30 Thread Tal Shorer
son to modify it. Tal Shorer (5): usb: ulpi: move setting of ulpi->dev parent up in ulpi_register() usb: ulpi: change operations api to pass parent device directly usb: ulpi: remove "dev" field from struct ulpi_ops usb: ulpi: make ops struct constant usb: dwc3: ulpi: make dwc3_u

[PATCH 5/5] usb: dwc3: ulpi: make dwc3_ulpi_ops constant

2016-07-30 Thread Tal Shorer
ulpi_register_interface() accepts a const struct ulpi_ops and dwc3 doesn't perform any changes to this struct at runtime, so there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/dwc3/ulpi.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH 1/5] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()

2016-07-30 Thread Tal Shorer
Once ulpi operations use the parent device directly, this will be needed during the operations used in ulpi_register() itself, so set the parent field before calling any ulpi operations. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- 1 file chan

[PATCH v2 01/10] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()

2016-08-01 Thread Tal Shorer
Once ulpi operations use the parent device directly, this will be needed during the operations used in ulpi_register() itself, so set the parent field before calling any ulpi operations. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- 1 file chan

[PATCH v2 03/10] usb: ulpi: use new api functions if available

2016-08-01 Thread Tal Shorer
If the registered has the new api callbacks {read|write}_dev, call these instead of the deprecated read, write functions. If the registered does not support the new callbacks, revert to calling the old ones as before. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/

[PATCH v2 06/10] usb: ulpi: remove old api callbacks from struct ulpi_ops

2016-08-01 Thread Tal Shorer
The old api callbacks, read() and write(), are not referenced anywhere. Remove them. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- include/linux/ulpi/interface.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h

[PATCH v2 04/10] usb: dwc3: ulpi: use new api

2016-08-01 Thread Tal Shorer
The old read, write callbacks in struct ulpi_ops have been deprecated in favor of new callbacks that pass the parent device directly. Replace the used callbacks in dwc3's ulpi component with the new api. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/dwc3/ulpi.

[PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-08-01 Thread Tal Shorer
son to modify it. Changes from v1: * Split the actual api change into multiple patch as per Felipe Balbi's suggestion. The series now first adds the new api, then migrates everything to use and only then removes the old api. Tal Shorer (10): usb: ulpi: move setting of ulpi->dev par

[PATCH v2 02/10] usb: ulpi: add new api functions, {read|write}_dev()

2016-08-01 Thread Tal Shorer
Add these two new api callbacks to struct ulpi_ops. These are different than read, write in that they pass the parent device directly instead of via the ops argument. They are intended to replace the old api functions. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- include/linu

[PATCH v2 09/10] usb: ulpi: make ops struct constant

2016-08-01 Thread Tal Shorer
None of the core ulpi functions perform any changes to the operations struct, and logically as a struct that contains function pointers there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- include/linu

[PATCH v2 07/10] usb: ulpi: rename operations {read|write}_dev to simply {read|write}

2016-08-01 Thread Tal Shorer
With the removal of the old {read|write} operations, we can now safely rename the new api operations {read|write}_dev to use the shorter and clearer names {read|write}, respectively. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 4 ++-- drivers/us

[PATCH v2 05/10] usb: ulpi: remove calls to old api callbacks

2016-08-01 Thread Tal Shorer
Now that all users use the new api callbacks, remove the calls to the old api functions and force new interface drivers to use the new api. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/

[PATCH v2 08/10] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-08-01 Thread Tal Shorer
Operations now use ulpi->dev.parent directly instead of via the ulpi_ops struct, making this field unused. Remove it. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 1 - include/linux/ulpi/interface.h | 2 +- 2 files changed, 1 insertion(+), 2

[PATCH v2 10/10] usb: dwc3: ulpi: make dwc3_ulpi_ops constant

2016-08-01 Thread Tal Shorer
ulpi_register_interface() accepts a const struct ulpi_ops and dwc3 doesn't perform any changes to this struct at runtime, so there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/dwc3/ulpi.c | 2 +- 1 file changed, 1 insertion(+), 1 de

Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-08-09 Thread Tal Shorer
On Tue, Aug 9, 2016 at 5:04 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Aug 01, 2016 at 09:15:48PM +0300, Tal Shorer wrote: >> struct ulpi_ops is defined as follows: >> >> struct ulpi_ops { >> struct device *dev; >> in

[PATCH v3 6/8] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-08-16 Thread Tal Shorer
Operations now use ulpi->dev.parent directly instead of via the ulpi_ops struct, making this field unused. Remove it. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 1 - include/linux/ulpi/interface.h | 3 +-- 2 files changed, 1 insertion(+), 3

[PATCH v3 7/8] usb: ulpi: make ops struct constant

2016-08-16 Thread Tal Shorer
None of the core ulpi functions perform any changes to the operations struct, and logically as a struct that contains function pointers there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- include/linu

[PATCH v3 5/8] usb: ulpi: rename operations {read|write}_dev to simply {read|write}

2016-08-16 Thread Tal Shorer
With the removal of the old {read|write} operations, we can now safely rename the new api operations {read|write}_dev to use the shorter and clearer names {read|write}, respectively. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 4 ++-- drivers/us

[PATCH v3 4/8] usb: ulpi: remove calls to old api callbacks

2016-08-16 Thread Tal Shorer
Now that all users use the new api callbacks, remove the old api callbacks and force new interface drivers to use the new api. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 4 include/linux/ulpi/interface.h | 2 -- 2 files changed, 6 del

[PATCH v3 8/8] usb: dwc3: ulpi: make dwc3_ulpi_ops constant

2016-08-16 Thread Tal Shorer
ulpi_register_interface() accepts a const struct ulpi_ops and dwc3 doesn't perform any changes to this struct at runtime, so there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/dwc3/ulpi.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH v3 1/8] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()

2016-08-16 Thread Tal Shorer
Once ulpi operations use the parent device directly, this will be needed during the operations used in ulpi_register() itself, so set the parent field before calling any ulpi operations. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 3 ++- 1 file chan

[PATCH v3 0/8] usb: ulpi: remove "dev" field from struct ulpi_ops

2016-08-16 Thread Tal Shorer
s 5 and 6 (now patch 4) * Remove comment documenting the removed dev field in struct ulpi_ops Tal Shorer (8): usb: ulpi: move setting of ulpi->dev parent up in ulpi_register() usb: ulpi: add new api functions, {read|write}_dev() usb: dwc3: ulpi: use new api usb: ulpi: remove calls to o

[PATCH v3 2/8] usb: ulpi: add new api functions, {read|write}_dev()

2016-08-16 Thread Tal Shorer
. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/common/ulpi.c | 8 ++-- include/linux/ulpi/interface.h | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c index c6ce92b..15e4a14

[PATCH v3 3/8] usb: dwc3: ulpi: use new api

2016-08-16 Thread Tal Shorer
The old read, write callbacks in struct ulpi_ops have been deprecated in favor of new callbacks that pass the parent device directly. Replace the used callbacks in dwc3's ulpi component with the new api. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/dwc3/ulpi.

[PATCH v2] usb: hcd.h: construct hub class request conastants from simpler constants

2016-11-18 Thread Tal Shorer
TYPE_CLASS | USB_RECIP_OTHER). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- include/linux/usb/hcd.h | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index 66fc137..76159fb 100644 --- a/include/linux/usb/hcd

[PATCH v3] usb: hcd.h: construct hub class request constants from simpler constants

2016-11-18 Thread Tal Shorer
CIP_DEVICE) and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- include/linux/usb/hcd.h | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux

[PATCH] usb: hcd.h: construct hub class request conastants from simpler constants

2016-11-18 Thread Tal Shorer
TYPE_CLASS | USB_RECIP_OTHER). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- include/linux/usb/hcd.h | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index 66fc137..2405853 100644 --- a/include

Re: [PATCH v3] usb: hcd.h: construct hub class request constants from simpler constants

2016-12-03 Thread Tal Shorer
On Fri, Nov 18, 2016 at 2:17 PM, Tal Shorer <tal.sho...@gmail.com> wrote: > Currently, each hub class request constant is defined by a line like: > #define ClearHubFeature (0x2000 | USB_REQ_CLEAR_FEATURE) > > The "magic" number for the high byte is one of 0x20,

possible circular locking dependency detected in musb_dsps in gadget mode

2017-06-29 Thread Tal Shorer
when unregistering the configfs driver on my beaglebone black (running linux-4.12-rc6), this happens: root@beaglebone:/sys/kernel/config/usb_gadget/g_ecm|0 # echo > UDC [ 39.074784] [ 39.076361] == [ 39.082815] WARNING: possible circular

Re: Piping f_acm to real hardware

2017-06-12 Thread Tal Shorer
On Mon, Jun 12, 2017 at 4:34 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Jun 12, 2017 at 04:00:56PM +0300, Tal Shorer wrote: >> On Mon, Jun 12, 2017 at 2:42 PM, Greg KH <gre...@linuxfoundation.org> wrote: >> > On Mon, Jun 12, 2017 at 01:17:18PM +0300,

Re: Piping f_acm to real hardware

2017-06-12 Thread Tal Shorer
On Mon, Jun 12, 2017 at 2:42 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote: >> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH <gre...@linuxfoundation.org> wrote: >> > On Sun, Jun 11, 2017 at 11:41:02PM +030

[PATCH 2/8] usb: gadget: u_serial: propagate poll() to the next layer

2017-06-12 Thread Tal Shorer
In order for a serial function to add flags to the poll() mask of their tty files, propagate the poll() callback to the next layer so it can return a mask if it sees fit to do so. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.

[PATCH 1/8] tty: add a poll() callback in struct tty_operations

2017-06-12 Thread Tal Shorer
will be called in n_tty_poll(). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/tty/n_tty.c| 2 ++ include/linux/tty_driver.h | 3 +++ 2 files changed, 5 insertions(+) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index bdf0e6e..7af8c29 100644 --- a/drivers/tty/n

[PATCH 0/8] Allow f_acm gadgets to notify the user about SetLineCoding requests

2017-06-12 Thread Tal Shorer
comment at every turn), it was never used and it was initialized with invalid values. Tal Shorer (8): tty: add a poll() callback in struct tty_operations usb: gadget: u_serial: propagate poll() to the next layer usb: gadget: f_acm: validate set_line_coding requests usb: gadget: u_serial

[PATCH 8/8] usb: gadget: u_serial: remove port_line_config from struct gserial

2017-06-12 Thread Tal Shorer
, the initialized never-used values were invalid, with bDataBits and bCharFormat having each other's value. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.c | 22 ++ drivers/usb/gadget/function/u_serial.h | 3 --- 2 files changed, 2 inse

[PATCH 4/8] usb: gadget: u_serial: propagate ioctl() to the next layer

2017-06-12 Thread Tal Shorer
In order for a serial function to implement its own ioctl() calls, propagate the ioctl() callback to the next layer so it can handle it if it sees fit to do so. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.c | 15 +++ drivers/usb/

[PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

2017-06-12 Thread Tal Shorer
The user can issue USB_F_GET_LINE_CODING to get the current line coding as set by the host (or the default if unset yet). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- Documentation/ioctl/ioctl-number.txt | 1 + drivers/usb/gadget/function/f_acm.c

[PATCH 5/8] usb: gadget: f_acm: initialize port_line_coding when creating an instance

2017-06-12 Thread Tal Shorer
Initialize acm->port_line_coding with something that makes sense so that we can return a valid line coding if the host requests GetLineCoding before requesting SetLineCoding Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/f_acm.c | 6 ++ 1 file c

[PATCH 7/8] usb: gadget: f_acm: notify the user on SetLineCoding

2017-06-12 Thread Tal Shorer
Notify the user with a POLLPRI event when the host issues a SetLineCoding request so that they can act upon it, for example by configuring the line coding on a real serial port. The event is cleared when the user reads the line coding using USB_F_ACM_GET_LINE_CODING ioctl() Signed-off-by: Tal

[PATCH 3/8] usb: gadget: f_acm: validate set_line_coding requests

2017-06-12 Thread Tal Shorer
We shouldn't accept malformed set_line_coding requests. All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec available at http://www.usb.org/developers/docs/devclass_docs/ The table is in the file PTSN120.pdf. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drive

Re: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

2017-06-12 Thread Tal Shorer
On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer <tal.sho...@gmail.com> wrote: > The user can issue USB_F_GET_LINE_CODING to get the current line coding > as set by the host (or the default if unset yet). > > Signed-off-by: Tal Shorer <tal.sho...@gmail.com> > --- > @@ -7

Re: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

2017-06-12 Thread Tal Shorer
On Mon, Jun 12, 2017 at 9:02 PM, Tal Shorer <tal.sho...@gmail.com> wrote: > On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer <tal.sho...@gmail.com> wrote: >> The user can issue USB_F_GET_LINE_CODING to get the current line coding >> as set by the host (or the default if u

Re: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

2017-06-13 Thread Tal Shorer
On Tue, Jun 13, 2017 at 12:19 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, Jun 13, 2017 at 09:52:12AM +0300, Tal Shorer wrote: >> The user can issue USB_F_GET_LINE_CODING to get the current line coding >> as set by the host (or the default if unset yet). >

Piping f_acm to real hardware

2017-06-11 Thread Tal Shorer
I'm currently working on a project where I'd like to have an omap board running linux be a usb-to-uart converter (using f_acm). I have an application that holds both the ttyGS* and the ttyO* port (the physical uart port) open, polls for readable data, and writes any incoming data to the other

Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

2017-06-14 Thread Tal Shorer
On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > On Tue, 13 Jun 2017 09:52:07 +0300 > Tal Shorer <tal.sho...@gmail.com> wrote: > >> If a tty driver wants to notify the user of some exceptional event, >> such as a usb cdc acm devic

Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

2017-06-14 Thread Tal Shorer
On Wed, Jun 14, 2017 at 11:20 AM, Tal Shorer <tal.sho...@gmail.com> wrote: > On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: >> On Tue, 13 Jun 2017 09:52:07 +0300 >> Tal Shorer <tal.sho...@gmail.com> wrote: >> >>>

Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

2017-06-15 Thread Tal Shorer
On Wed, Jun 14, 2017 at 4:33 PM, Alan Cox wrote: >> That would cut it, but TIOCPKT is too coupled with having a linked tty. >> I could make acm behave like a pty (accept TIOCPKT and issue the >> ctrl_status bits), but for that I need n_tty to know that packet does >>

Re: gadgetfs: how to wait for USB device initialization?

2017-06-13 Thread Tal Shorer
On Tue, Jun 13, 2017 at 3:21 PM, Andrey Konovalov wrote: > Hi! > > I'm trying to use gadgetfs to fuzz USB device drivers by simply > connecting random devices for now. > > What I want to achieve right now is the following: > > 1. mount gadgetfs > 2. emulate connection of a

[PATCH v2 0/8] Allow f_acm gadgets to notify the user about SetLineCoding requests

2017-06-13 Thread Tal Shorer
comment at every turn), it was never used and it was initialized with invalid values. Changes from v1: - patch 5 was messed up, which made patch 6 also messed up. fixed both of these. Tal Shorer (8): tty: add a poll() callback in struct tty_operations usb: gadget: u_serial: propagate poll

[PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

2017-06-13 Thread Tal Shorer
The user can issue USB_F_GET_LINE_CODING to get the current line coding as set by the host (or the default if unset yet). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- Documentation/ioctl/ioctl-number.txt | 1 + drivers/usb/gadget/function/f_acm.c | 19 +++ includ

[PATCH v2 5/8] usb: gadget: f_acm: initialize port_line_coding when creating an instance

2017-06-13 Thread Tal Shorer
Initialize acm->port_line_coding with something that makes sense so that we can return a valid line coding if the host requests GetLineCoding before requesting SetLineCoding Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/f_acm.c | 6 ++ 1 file c

[PATCH v2 4/8] usb: gadget: u_serial: propagate ioctl() to the next layer

2017-06-13 Thread Tal Shorer
In order for a serial function to implement its own ioctl() calls, propagate the ioctl() callback to the next layer so it can handle it if it sees fit to do so. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.c | 15 +++ drivers/usb/

[PATCH v2 7/8] usb: gadget: f_acm: notify the user on SetLineCoding

2017-06-13 Thread Tal Shorer
Notify the user with a POLLPRI event when the host issues a SetLineCoding request so that they can act upon it, for example by configuring the line coding on a real serial port. The event is cleared when the user reads the line coding using USB_F_ACM_GET_LINE_CODING ioctl() Signed-off-by: Tal

[PATCH v2 8/8] usb: gadget: u_serial: remove port_line_config from struct gserial

2017-06-13 Thread Tal Shorer
, the initialized never-used values were invalid, with bDataBits and bCharFormat having each other's value. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.c | 22 ++ drivers/usb/gadget/function/u_serial.h | 3 --- 2 files changed, 2 inse

[PATCH v2 2/8] usb: gadget: u_serial: propagate poll() to the next layer

2017-06-13 Thread Tal Shorer
In order for a serial function to add flags to the poll() mask of their tty files, propagate the poll() callback to the next layer so it can return a mask if it sees fit to do so. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/usb/gadget/function/u_serial.

[PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

2017-06-13 Thread Tal Shorer
will be called in n_tty_poll(). Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drivers/tty/n_tty.c| 2 ++ include/linux/tty_driver.h | 3 +++ 2 files changed, 5 insertions(+) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index bdf0e6e..7af8c29 100644 --- a/drivers/tty/n

[PATCH v2 3/8] usb: gadget: f_acm: validate set_line_coding requests

2017-06-13 Thread Tal Shorer
We shouldn't accept malformed set_line_coding requests. All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec available at http://www.usb.org/developers/docs/devclass_docs/ The table is in the file PTSN120.pdf. Signed-off-by: Tal Shorer <tal.sho...@gmail.com> --- drive

Re: Piping f_acm to real hardware

2017-06-12 Thread Tal Shorer
On Mon, Jun 12, 2017 at 9:48 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote: >> I'm currently working on a project where I'd like to have an omap board >> running linux be a usb-to-uart converter (using f_acm). I h

Re: gadgetfs: how to wait for USB device initialization?

2017-06-13 Thread Tal Shorer
On Tue, Jun 13, 2017 at 7:02 PM, Tal Shorer <tal.sho...@gmail.com> wrote: > On Tue, Jun 13, 2017 at 3:21 PM, Andrey Konovalov <andreyk...@google.com> > wrote: >> Hi! >> >> I'm trying to use gadgetfs to fuzz USB device drivers by simply >> connecting