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
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
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
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
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
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
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
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
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
, 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
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,
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
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
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
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
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
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
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
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
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
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(+)
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 +++
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
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
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
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
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
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
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
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
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/
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
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.
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
.
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
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.
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
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
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
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,
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
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,
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
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.
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
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
, 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
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/
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
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
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
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
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
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
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).
>
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
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
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:
>>
>>>
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
>>
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
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
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
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
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/
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
, 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
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.
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
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
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
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
85 matches
Mail list logo