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 loc
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
>> not always mean a linked tty i
On Wed, Jun 14, 2017 at 11:20 AM, Tal Shorer wrote:
> On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox wrote:
>> On Tue, 13 Jun 2017 09:52:07 +0300
>> Tal Shorer wrote:
>>
>>> If a tty driver wants to notify the user of some exceptional event,
>>> such as a usb c
On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox wrote:
> On Tue, 13 Jun 2017 09:52:07 +0300
> Tal Shorer wrote:
>
>> If a tty driver wants to notify the user of some exceptional event,
>> such as a usb cdc acm device set_line_coding event, it needs a way to
>> modify the
On Tue, Jun 13, 2017 at 7:02 PM, Tal Shorer wrote:
> 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
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 new USB device
> 3. wait
On Tue, Jun 13, 2017 at 12:19 PM, Greg KH 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).
>>
>> Signed-off-by: Tal Shore
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
---
drivers/usb/gadget/function/u_serial.c | 16
drivers/usb/gadget
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
---
drivers/usb/gadget/function/f_
will be called in n_tty_poll().
Signed-off-by: Tal Shorer
---
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_tty.c
+++ b/drivers/tty
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
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/usb/gadget/function/f_acm.c | 19 +++
include/uapi/linux/usb/f_acm.h
, the initialized never-used values were invalid, with bDataBits
and bCharFormat having each other's value.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 22 ++
drivers/usb/gadget/function/u_serial.h | 3 ---
2 files changed, 2 insertions(+), 23
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
---
drivers/usb/gadget/function/f_acm.c | 6 ++
1 file changed, 6 insertions(+)
diff --
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
---
drivers/usb/gadget/function/u_serial.c | 15 +++
drivers/usb/gadget/function/u_serial.h | 1
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
se to have there (and had a REVISIT
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: ga
On Mon, Jun 12, 2017 at 9:02 PM, Tal Shorer wrote:
> On Mon, Jun 12, 2017 at 8:26 PM, 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).
>>
>> Signed-off-by: Tal Sho
On Mon, Jun 12, 2017 at 8:26 PM, 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).
>
> Signed-off-by: Tal Shorer
> ---
> @@ -764,10 +783,10 @@ static struct usb_function *acm
will be called in n_tty_poll().
Signed-off-by: Tal Shorer
---
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_tty.c
+++ b/drivers/tty
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
---
drivers/usb/gadget/function/u_serial.c | 16
drivers/usb/gadget
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
---
drivers/usb/gadget/function/f_acm.c | 6 ++
1 file changed, 6 insertions(+)
diff --
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
---
drivers/usb/gadget/function/f_
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
---
drivers/usb/gadget/function/u_serial.c | 15 +++
drivers/usb/gadget/function/u_serial.h | 1
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
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/usb/gadget/function/f_acm.c | 27 +++
include/uapi/linux/usb
, the initialized never-used values were invalid, with bDataBits
and bCharFormat having each other's value.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 22 ++
drivers/usb/gadget/function/u_serial.h | 3 ---
2 files changed, 2 insertions(+), 23
se to have there (and had a REVISIT
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_codi
On Mon, Jun 12, 2017 at 4:34 PM, Greg KH 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 wrote:
>> > On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote:
>> >> On Mon, Jun 12, 2017 at
On Mon, Jun 12, 2017 at 2:42 PM, Greg KH 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 wrote:
>> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
>> >> I'm currently working on
On Mon, Jun 12, 2017 at 9:48 AM, Greg KH 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 have an
>> applic
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 side.
On Fri, Nov 18, 2016 at 2:17 PM, Tal Shorer 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, 0xa0, 0x23, 0xa3.
>
CIP_DEVICE)
and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER).
Signed-off-by: Tal Shorer
---
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..40ed
TYPE_CLASS | USB_RECIP_OTHER).
Signed-off-by: Tal Shorer
---
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.h
+++ b/include/linux
TYPE_CLASS | USB_RECIP_OTHER).
Signed-off-by: Tal Shorer
---
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/linux/usb/hcd.h
+++ b/include
.
Signed-off-by: Tal Shorer
---
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 100644
--- a/drivers/usb/common/ulpi.c
* Merge patches 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: re
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
---
drivers/usb/common/ulpi.c | 3 ++-
include/linux/ulpi/drive
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
---
drivers/usb/common/ulpi.c | 4 ++--
drivers/usb/dwc3/ulpi.c| 4
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
---
drivers/usb/common/ulpi.c | 4
include/linux/ulpi/interface.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/usb
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
---
drivers/usb/dwc3/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
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
---
drivers/usb/dwc3/ulpi.c | 12 ++--
1 file chang
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
---
drivers/usb/common/ulpi.c | 1 -
include/linux/ulpi/interface.h | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/driv
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
---
drivers/usb/common/ulpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
On Tue, Aug 9, 2016 at 5:04 PM, Greg KH 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;
>> int (*read)(struct ulpi_ops *ops, u8 addr
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
---
drivers/usb/common/ulpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
The old api callbacks, read() and write(), are not referenced anywhere.
Remove them.
Signed-off-by: Tal Shorer
---
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
index d8189d0..71f3c99 100644
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
---
drivers/usb/dwc3/ulpi.c | 12 ++--
1 file chang
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
---
drivers/usb/common/ulpi.c | 8 ++--
1 file
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
---
include/linux/ulpi/interface.h | 2 ++
1 file
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
---
drivers/usb/common/ulpi.c | 3 ++-
include/linux/ulpi/drive
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
---
drivers/usb/common/ulpi.c | 4 ++--
drivers/usb/dwc3/ulpi.c| 4
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
---
drivers/usb/common/ulpi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/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
---
drivers/usb/common/ulpi.c | 1 -
include/linux/ulpi/interface.h | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/driv
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
---
drivers/usb/dwc3/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
s a reason 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
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
---
drivers/usb/common/ulpi.c | 3 ++-
include/linux/ulpi/drive
s a reason 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: m
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
---
drivers/usb/dwc3/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
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
---
drivers/usb/common/ulpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
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
---
drivers/usb/common/ulpi.c | 1 -
include/linux/ulpi/interface.h | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/driv
lpi_read() and ulpi_write() instead
of via the ops argument
Signed-off-by: Tal Shorer
---
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(-)
diff --git a/drivers/usb/commo
f the patches 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
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
---
drivers/usb/musb/musb_gadget.c | 6 +++---
1 file
b_gadget.c
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 ins
pth 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
---
include/linux/
On Fri, Aug 7, 2015 at 9:40 PM, Greg KH 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 and
>&
Please ignore v2, I missed that you
On Fri, Aug 7, 2015 at 9:13 PM, 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 and
> GetPortErrorCount as:
>
> Request bmReque
one
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
---
include/linux/usb/hcd.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/usb/hcd.h b/include/li
one
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
---
include/linux/usb/hcd.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/usb/hcd.h b/incl
one
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
---
include/linux/usb/hcd.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/usb/hcd.h b/incl
On Fri, Aug 7, 2015 at 8:31 PM, Greg KH 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 wrote:
>> > On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
>> >> In include/linux/usb/hcd.h, we have
On Fri, Aug 7, 2015 at 7:37 PM, Greg KH 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)
>>
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 appear
but never runs, the happier I am.
On Fri, Jun 26, 2015 at 7:59 PM, Greg KH 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 >:
&
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 wrote:
> Hi,
>
> I am looking at all the CDC drivers. They all have a parser for
> the extra CDC headers. If I unify this would it be
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
wrote:
> On Sun, May 24, 2015 at 12:19:48AM -0700, Greg KH wrote:
>> On Wed, Ma
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 wrote:
> The USB PCI quirks code gets built into the kernel whenever CONFIG_PCI
> is enabled, e
On Wed, Apr 8, 2015 at 3:06 PM, Krzysztof Opasiak 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
> ---
> .../ABI/
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 wrote:
> Wild guess, you don't see the same behavior on your desktop machine
> because it's a different hcd that
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 wrote:
> linux-usb,
>
> Apologies if I've come at this the wrong way, I've read MAINTAINERS and
> usb-se
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
replace numeric value with TYPE_NO_LUN (defined in )
Signed-off-by: Tal Shorer
Acked-by: Michal Nazarewicz
---
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
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 seri
Signed-off-by: Tal Shorer
---
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
--- a/drivers/usb/gadget
85 matches
Mail list logo
