Re: ftdi_sio BUG: NULL pointer dereference
On Wed, Jun 04, 2014 at 01:05:03PM -0400, Mike Remski wrote: On 06/04/2014 12:00 PM, Johan Hovold wrote: On Wed, Jun 04, 2014 at 11:41:47AM -0400, Mike Remski wrote: Ok, had a chance to try the cdc-acm; yes it's the ancient one that is in the base install of CentOS 6.4 (2.6.32-71.29.1 centos patched). I'm hitting something similar; I noticed there where a few commits for NULL pointer dereferences in cdc-acm.c. I'll poke into this a bit (yes, I know try a newer kernel, etc) and let you know what I find (or perhaps this looks similar to something already seen?). This device is the same as the original ftdi crash, 1.2 is the same interface with bNumEndpoints == 0. Jun 4 11:35:20 nicA91A84 kernel: cdc_acm 5-2:1.2: This device cannot do calls on its own. It is not a modem. Jun 4 11:35:20 nicA91A84 kernel: BUG: unable to handle kernel NULL pointer dereference at 0004 Jun 4 11:35:20 nicA91A84 kernel: IP: [f84f9c9e] acm_probe+0x44e/0x127c [cdc_acm] Jun 4 11:35:20 nicA91A84 kernel: *pdpt = 354eb001 *pde = 7f003067 Jun 4 11:35:20 nicA91A84 kernel: Oops: [#1] SMP Jun 4 11:35:20 nicA91A84 kernel: last sysfs file: /sys/devices/pci:00/:00:1d.0/usb5/5-2/product Yeah, you really need to update your kernel. You'll definitely need at least commit 99f347caa456 (USB: CDC ACM: Fix NULL pointer dereference). No more reports until you've tried a recent kernel, ok? ;) Johan Device in question does not cause kernel crash when using the cdc-acm driver on a Fedora 19 system running Fedora kernel 3.9.5-301. Thanks for all the help, I'll take care of my ancient kernels. That's good to hear. Good luck with the backporting. Johan -- 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 2/2] tools: ffs-test: convert to new descriptor format fixing compilation error
Commit [ac8dde11: “usb: gadget: f_fs: Add flags to descriptors block”]
which introduced a new descriptor format for FunctionFS removed the
usb_functionfs_descs_head structure, which is still used by ffs-test.
tool.
Convert ffs-test by converting it to use the new header format. For
testing kernels prior to 3.14 (when the new format was introduced) and
parsing of the legacy headers in the new kernels, provide a compilation
flag to make the tool use the old format.
Finally, include information as to when the legacy FunctionFS headers
format has been deprecated (which is also when the new one has been
introduced).
Reported-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Reported-by: Krzysztof Opasiak k.opas...@samsung.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/uapi/linux/usb/functionfs.h | 2 +-
tools/usb/Makefile | 6 +-
tools/usb/ffs-test.c| 20 ++--
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 92c94e8..d54ba5d 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -60,7 +60,7 @@ struct usb_functionfs_descs_head {
* structure. Any flags that are not recognised cause the whole block to be
* rejected with -ENOSYS.
*
- * Legacy descriptors format:
+ * Legacy descriptors format (deprecated as of 3.14):
*
* | off | name | type | description |
* |-+---+--+--|
diff --git a/tools/usb/Makefile b/tools/usb/Makefile
index acf2165..d576b3b 100644
--- a/tools/usb/Makefile
+++ b/tools/usb/Makefile
@@ -6,7 +6,11 @@ WARNINGS = -Wall -Wextra
CFLAGS = $(WARNINGS) -g -I../include
LDFLAGS = $(PTHREAD_LIBS)
-all: testusb ffs-test
+all: testusb ffs-test ffs-test-legacy
+
+ffs-test-legacy: ffs-test.c
+ $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) -DUSE_LEGACY_DESC_HEAD
+
%: %.c
$(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index fe1e66b..74b353d 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -1,5 +1,5 @@
/*
- * ffs-test.c.c -- user mode filesystem api for usb composite function
+ * ffs-test.c -- user mode filesystem api for usb composite function
*
* Copyright (C) 2010 Samsung Electronics
*Author: Michal Nazarewicz min...@mina86.com
@@ -21,6 +21,8 @@
/* $(CROSS_COMPILE)cc -Wall -Wextra -g -o ffs-test ffs-test.c -lpthread */
+/* Uncomment to make the tool use legacy FFS descriptor headers. */
+/* #define USE_LEGACY_DESC_HEAD */
#define _BSD_SOURCE /* for endian.h */
@@ -106,7 +108,15 @@ static void _msg(unsigned level, const char *fmt, ...)
/ Descriptors and Strings ***/
static const struct {
- struct usb_functionfs_descs_head header;
+ struct {
+ __le32 magic;
+ __le32 length;
+#ifndef USE_LEGACY_DESC_HEAD
+ __le32 flags;
+#endif
+ __le32 fs_count;
+ __le32 hs_count;
+ } __attribute__((packed)) header;
struct {
struct usb_interface_descriptor intf;
struct usb_endpoint_descriptor_no_audio sink;
@@ -114,7 +124,13 @@ static const struct {
} __attribute__((packed)) fs_descs, hs_descs;
} __attribute__((packed)) descriptors = {
.header = {
+#ifdef USE_LEGACY_DESC_HEAD
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
+#else
+ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
+ .flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
+FUNCTIONFS_HAS_HS_DESC),
+#endif
.length = cpu_to_le32(sizeof descriptors),
.fs_count = 3,
.hs_count = 3,
--
2.0.0.526.g5318336
--
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 1/2] usb: gadget: f_fs: resurect usb_functionfs_descs_head structure
Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools. It's removel in commit
[ac8dde1: Add flags to descriptors block] was an oversight leading
to build breakage for such tools.
Bring it back so that old user space tools can still be build
without problems on newer kernel versions.
Cc: sta...@vger.kernel.org # 3.14
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/uapi/linux/usb/functionfs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 2a4b4a7..92c94e8 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +33,13 @@ struct usb_endpoint_descriptor_no_audio {
__u8 bInterval;
} __attribute__((packed));
+/* Legacy format, deprecated as of 3.14. */
+struct usb_functionfs_descs_head {
+ __le32 magic;
+ __le32 length;
+ __le32 fs_count;
+ __le32 hs_count;
+} __attribute__((packed));
/*
* Descriptors format:
--
2.0.0.526.g5318336
--
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
Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
W dniu 04.06.2014 17:26, Alan Stern pisze: On Wed, 4 Jun 2014, Andrzej Pietrasiewicz wrote: snip What is the difference in purpose between usb_function and usb_function_instance? I can't tell just by reading the header file. Does one of them get created dynamically when the host sets the appropriate config? Please see below. snip Among traditional gadgets there is no gadget which uses mass storage function more than once. On the other hand, when gadgets are created with configfs it is forbidden to link a given function more than once into a given config, What is the reason for this restriction? Please see below. that is a struct usb_function_instance can be referenced by more than one config, but can be referenced only once in a given config; each symbolic link corresponds to an instance of struct usb_function (don't confuse with struct usb_function_instance). It's extremely easy to confuse them, since I don't understand the differences between them. It even seems like you confused them in this description: You mentioned link a given function, link corresponds to an instance of struct usb_function, and struct usb_function_instance can be referenced by more than one config. What's the difference between linking a usb_function and referencing a usb_function_instance? Normally linking and referencing mean more or less the same thing. As I said, I didn't like the naming here. I got used to it, though, but understand (and agree) that it is confusing. As far as explaining the difference is concerned, being a non-native speaker of English has its influence, too, so let me do it again. I think it is easier to tell the purpose of the two structures taking gadgets composed with configfs as example. In each gadget there is functions directory. Function directories are created there: $ cd $CONFIGFS_ROOT/usb_gadget/our_gadget $ mkdir functions/mass_storage.0 mass_storage.0 is internally represented as an instance of struct usb_function_instance, which has its associated struct fsg_common (the fsg_common is a member of container_of(struct usb_function_instance)). It can be referenced from multiple configurations. $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.0 configs/config.2 Each reference (symbolic link) is internally represented as an instance of struct usb_function. The struct usb_function here has its associated struct fsg_dev (the fsg_dev is a container_of(struct usb_function)). By the very nature of any file system one cannot do: $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.0 configs/config.1 = -EEXIST By design of how configfs is applied to any usb gadget on cannot even do: $ ln -s functions/mass_storage.0 configs/config.1/my_mass_storage.0 $ ln -s functions/mass_storage.0 configs/config.1/the_same_mass_storage.0 = -EEXIST However, there should be no problem with this: $ mkdir functions/mass_storage.0 $ mkdir functions/mass_storage.1 $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.1 configs/config.1 Legacy gadgets (g_mass_storage, g_acm_ms, g_multi) in fact operate in a somewhat similar manner, the difference is that instead of creating directories and making symbolic links, usb_get_function_instance() and usb_get_function() are called, respectively, and composing a gadget happens from beginning to end at module init. I hope this clarifies things a bit. AP -- 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
Re: [PATCH] leds: USB: Add support for MSI GT683R led panels
[ +CC: linux-usb ]
On Sat, May 31, 2014 at 06:46:44PM +0300, Janne Kanniainen wrote:
This driver adds support for USB controlled led panels that exist in MSI
GT683R laptop.
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-gt683r.c | 241
+
3 files changed, 248 insertions(+)
create mode 100644 drivers/leds/leds-gt683r.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6de9dfb..2cffa0c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -487,6 +487,12 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_GT683R
+ tristate LED support for the MSI GT683R
+ depends on LEDS_CLASS USB
+ help
+ This option enables support for the MSI GT683R LEDS
+
comment LED Triggers
source drivers/leds/trigger/Kconfig
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3cd76db..af5fb4e 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_LEDS_ASIC3)+= leds-asic3.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x)+= leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM)+= leds-blinkm.o
+obj-$(CONFIG_LEDS_GT683R)+= leds-gt683r.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085)+= leds-dac124s085.o
diff --git a/drivers/leds/leds-gt683r.c b/drivers/leds/leds-gt683r.c
new file mode 100644
index 000..d67709c
--- /dev/null
+++ b/drivers/leds/leds-gt683r.c
@@ -0,0 +1,241 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/usb.h
+#include linux/slab.h
+#include linux/leds.h
+
+#define USB_DEVICE_ID_MSI_GT683R_LED_PANEL 0xff00
+#define USB_VENDOR_ID_MSI 0x1770
+
+#define GT683R_LED_MSG_TYPE_CTRL 0
+#define GT683R_LED_MSG_TYPE_INT 1
These two are never used.
+
+#define GT683R_LED_FRONT 4
+#define GT683R_LED_SIDE 2
+#define GT683R_LED_BACK 1
Sort and use BIT(n) for these?
+#define GT683R_LED_NORMAL 5
+#define GT683R_LED_BREATHING 3
+#define GT683R_LED_AUDIO 2
+#define GT683R_LED_OFF 0
Sort these numerically as well?
Please use tabs to align the values above as well.
+
+struct gt683r_led {
+ struct usb_device *usb_dev;
+
+ struct usb_endpoint_descriptor *ctrl_out_ep;
+ int ctrl_out_buffer_size;
+ char *ctrl_out_buffer;
+ struct usb_ctrlrequest *ctrl_out_request;
+ struct urb *ctrl_out_urb;
You don't need to track ctrl_out_urb, which you allocate dynamically for
every message (more below).
+
+ struct led_classdev led_dev;
+ struct mutex lock;
+ struct work_struct work;
+
+ enum led_brightness brightness;
+};
+
+static const struct usb_device_id gt683r_led_id[] = {
+ { USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL) },
+ { }
+};
+
+static char gt683r_led_select_leds[8] = {0x01, 0x02, 0x30, 0x00,
+ 0x00, 0x00, 0x00, 0x00};
+static char gt683r_led_select_type[8] = {0x01, 0x02, 0x20, 0x00,
+ 0x01, 0x00, 0x00, 0x00};
It would be better to make these const (or remove altogether) and only
modify the fourth byte of the copy (more below).
+
+static void gt683r_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct gt683r_led *led =
+ container_of(led_cdev, struct gt683r_led, led_dev);
+
+ led-brightness = brightness;
Missing locking?
+
+ schedule_work(led-work);
+}
+
+static void gt683r_led_msg_snd_complete(struct urb *urb)
+{
+ usb_free_urb(urb);
+}
+
+static int gt683r_led_snd_msg(struct gt683r_led *led, char *msg)
+{
+ int result;
+
+ if (strlen(msg) led-ctrl_out_buffer_size) {
This is bogus. You can't use strlen on your byte arrays that contains
NULL-bytes.
If at all needed you could verify wMaxPacketSize once at probe.
+ dev_err(led-usb_dev-dev, Message to be send to device is
too long\n);
+ return -EMSGSIZE;
+ }
+
+
RE: [PATCH 2/2] tools: ffs-test: convert to new descriptor format fixing compilation error
Hi,
-Original Message-
From: Michal Nazarewicz [mailto:min...@mina86.com]
Sent: Thursday, June 05, 2014 9:43 AM
To: Felipe Balbi
Cc: Krzysztof Opasiak; linux-usb@vger.kernel.org; linux-
ker...@vger.kernel.org; Michal Nazarewicz
Subject: [PATCH 2/2] tools: ffs-test: convert to new descriptor
format fixing compilation error
Commit [ac8dde11: “usb: gadget: f_fs: Add flags to descriptors
block”]
which introduced a new descriptor format for FunctionFS removed the
usb_functionfs_descs_head structure, which is still used by ffs-
test.
tool.
Convert ffs-test by converting it to use the new header format.
For
testing kernels prior to 3.14 (when the new format was introduced)
and
parsing of the legacy headers in the new kernels, provide a
compilation
flag to make the tool use the old format.
Finally, include information as to when the legacy FunctionFS
headers
format has been deprecated (which is also when the new one has been
introduced).
Reported-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Reported-by: Krzysztof Opasiak k.opas...@samsung.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
(...)
static const struct {
- struct usb_functionfs_descs_head header;
+ struct {
+ __le32 magic;
+ __le32 length;
+#ifndef USE_LEGACY_DESC_HEAD
+ __le32 flags;
+#endif
+ __le32 fs_count;
+ __le32 hs_count;
+ } __attribute__((packed)) header;
I would suggest adding a suitable structure as you described in previous
discussion[1]. Writing first 3 fields in each userspace program doesn't look
quite good. Using:
#ifndef USE_LEGACY_DESC_HEAD
struct {
struct usb_functionfs_desc_head2 header;
__le32 fs_count
(... and rest according to flags ...)
} __attribute__((packed)) header;
#else ...
Would be shorter, more flexible and user friendly. Moreover it gives less
places for mistake (writing fields in wrong order).
Footnotes:
1 - http://marc.info/?l=linux-usbm=140190878901586w=2
--
BR's
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
k.opas...@samsung.com
--
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
RE: [PATCHv2] usb: gadget: f_fs: Add flags to descriptors block
Hi,
-Original Message-
From: Michal Nazarewicz [mailto:m...@google.com] On Behalf Of Michal
Nazarewicz
Sent: Wednesday, June 04, 2014 9:06 PM
To: Krzysztof Opasiak; 'Manu Gautam'
Cc: ba...@ti.com; ja...@codeaurora.org; pheat...@codeaurora.org;
linux-usb@vger.kernel.org; linux-arm-...@vger.kernel.org;
ben...@android.com; Andrzej Pietrasiewicz;
gre...@linuxfoundation.org; 'Manu Gautam'; Karol Lewandowski; Marek
Szyprowski
Subject: Re: [PATCHv2] usb: gadget: f_fs: Add flags to descriptors
block
-struct usb_functionfs_descs_head {
- __le32 magic;
- __le32 length;
- __le32 fs_count;
- __le32 hs_count;
-} __attribute__((packed));
On Wed, Jun 04 2014, Krzysztof Opasiak k.opas...@samsung.com
wrote:
I have tried to compile FFS examples with v3.15-rc8 but I have
faced an
issue that they are unable to build due to missing definition of
this
structure.
https://lkml.org/lkml/2014/5/21/522
Thank you for this link, I have missed that patch.
I don't care either way to be honest. I guess if there's non-
negligible
number of usb_functionfs_descs_head structure users out there, I
can
prepare a CL adding the structure back.
The number of FFS users which I know is limited to 3 maybe 4, so it's not too
much. I can port all of them to new API but I'm not sure if we would like to do
this?
There is also no structure definition for new API, maybe suitable
structure should be defined (struct usb_functionfs_descs_head2
for
example) to make userspace life easier?
That structure would not have many fields though, since what
exactly the
header contains depends on the flags. Whether fs_count, hs_count
and
ss_count fields are present depends on which bits in the flags are
set.
So the usb_functionfs_descs_head2 structure could only contain:
struct usb_functionfs_descs_head2 {
__le32 magic;
__le32 length;
__le32 flags;
};
I'm not sure if that would be particularly helpful.
I think that this structure is much more user friendly than copy-paste of those
3 fields in each ffs program.
--
BR's
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
k.opas...@samsung.com
--
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
Re: [PATCH 2/2] tools: ffs-test: convert to new descriptor format fixing compilation error
On Thu, Jun 05 2014, Krzysztof Opasiak k.opas...@samsung.com wrote:
I would suggest adding a suitable structure as you described in
previous discussion[1]. Writing first 3 fields in each userspace
program doesn't look quite good. Using:
#ifndef USE_LEGACY_DESC_HEAD
struct {
struct usb_functionfs_desc_head2 header;
__le32 fs_count
(... and rest according to flags ...)
} __attribute__((packed)) header;
#else ...
Would be shorter, more flexible and user friendly. Moreover it gives
less places for mistake (writing fields in wrong order).
For ffs-test with USE_LEGACY_DESC_HEAD support it would be longer.
Compare:
--- 8 -
static const struct {
struct {
__le32 magic;
__le32 length;
#ifndef USE_LEGACY_DESC_HEAD
__le32 flags;
#endif
__le32 fs_count;
__le32 hs_count;
} __attribute__((packed)) header;
/* … */
} __attribute__((packed)) descriptors = {
.header = {
#ifdef USE_LEGACY_DESC_HEAD
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
#else
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC),
#endif
.length = cpu_to_le32(sizeof descriptors),
.fs_count = 3,
.hs_count = 3,
},
/* … */
};
--- 8 -
with
--- 8 -
static const struct {
#ifdef USE_LEGACY_DESC_HEAD
struct usb_functionfs_descs_head header;
#else
struct usb_functionfs_descs_head2 header;
__le32 fs_count;
__le32 hs_count;
#endif
/* … */
} __attribute__((packed)) descriptors = {
#ifndef USE_LEGACY_DESC_HEAD
.fs_count = 3,
.hs_count = 3,
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC),
#else
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
.fs_count = 3,
.hs_count = 3,
#endif
.length = cpu_to_le32(sizeof descriptors),
},
/* … */
};
--- 8 -
or with
--- 8 -
static const struct {
#ifdef USE_LEGACY_DESC_HEAD
struct usb_functionfs_descs_head header;
#else
struct {
struct usb_functionfs_descs_head2 header;
__le32 fs_count;
__le32 hs_count;
} header;
#endif
/* … */
} __attribute__((packed)) descriptors = {
.header = {
#ifdef USE_LEGACY_DESC_HEAD
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
.length = cpu_to_le32(sizeof descriptors),
#else
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC),
.length = cpu_to_le32(sizeof descriptors),
},
#endif
.fs_count = 3,
.hs_count = 3,
},
/* … */
};
--- 8 -
The second one uses an unreadable hack to match length of the first one
and the third one is two lines longer. On top of that, the second and
third produce different structures, use more complicated preprocessing
directives, and repeat value of fs_count and hs_count twice.
Without legacy support, it would indeed be shorter (by two lines), but
would lead to awkward structures:
--- 8 -
struct {
struct usb_functionfs_descs_head2 header;
/* Why aren't the two below fields inside of a header? */
__le32 fs_count;
__le32 hs_count;
};
struct {
struct {
/* Why is there a header.header field? */
struct usb_functionfs_descs_head2 header;
__le32 fs_count;
__le32 hs_count;
};
};
--- 8 -
And I don't see how it would be more flexible. If anything, it would be
less.
I understand, and share, your sentiment, but I don't think adding
usb_functionfs_descs_head2 structure with magic, flags and length would
improve the situation.
Something I thought about shortly was:
--- 8 -
#define USB_FFS_DESCS_HEAD(_flags) struct {
[PATCHv2 5/6] base: platform: name the device already during allocation
This allows resources such as GPIOs and clocks, which can be
matched based on the device name when requested, to be
assigned even when PLATFORM_DEVID_AUTO is used.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 77 ++---
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9e9227e..e856bc4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -177,11 +177,45 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -214,6 +248,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -294,28 +332,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -358,7 +374,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -378,11 +393,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -400,8 +410,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.0.0.rc4
--
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
[PATCHv2 6/6] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 32db328..8387564 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -27,8 +27,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -46,22 +45,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.0.0.rc4
--
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
[PATCHv2 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-core.c | 45 +++--
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c| 3 +--
drivers/phy/phy-exynos5250-sata.c | 2 +-
drivers/phy/phy-mvebu-sata.c| 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +---
drivers/phy/phy-xgene.c | 2 +-
include/linux/phy/phy.h | 37 --
14 files changed, 19 insertions(+), 90 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index e94f5a6..47d810f 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, ops, NULL);
+ gphy = devm_phy_create(dev, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 38034fd..74d4346 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -54,36 +54,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -209,10 +179,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -696,12 +662,10 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
-struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data)
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops)
{
int ret;
int id;
@@ -729,7 +693,6 @@ struct phy *phy_create(struct device *dev, const struct
phy_ops *ops,
phy-dev.of_node = dev-of_node;
phy-id = id;
phy-ops = ops;
- phy-init_data = init_data;
ret = dev_set_name(phy-dev, phy-%s.%d, dev_name(dev), id);
if (ret)
@@ -759,15 +722,13 @@ EXPORT_SYMBOL_GPL(phy_create);
* devm_phy_create() - create a new phy
* @dev: device that is creating the new phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Creates a new PHY device adding it to the PHY class.
* While at that, it also associates the device with the phy using devres.
* On driver detach, release function is invoked on the devres data,
* then, devres data is freed.
*/
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data)
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops)
{
struct phy **ptr, *phy;
@@ -775,7 +736,7 @@ struct phy *devm_phy_create(struct device *dev, const
struct phy_ops *ops,
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_create(dev, ops, init_data);
+ phy = phy_create(dev, ops);
if (!IS_ERR(phy)) {
*ptr = phy;
devres_add(dev, ptr);
diff --git a/drivers/phy/phy-exynos-dp-video.c
[PATCHv2 3/6] arm: omap3: twl: use the new lookup method with usb phy
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/twl-common.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..b78383c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,14 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup twl4030_usb_lookup = {
+ .phy_name = phy-twl4030_usb.0,
+ .dev_id = musb-hdrc.0,
+ .con_id = usb,
};
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
@@ -225,8 +221,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_register_lookup(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
2.0.0.rc4
--
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
[PATCHv2 0/6] phy: simplified phy lookup
Hi, So the idea with these is that they should help to make it possible to request phys without caring about how they are mapped to the consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping phys to consumers can be now done with lookups similarly how clocks can be mapped in clkdev.c. Vivek needs to handle the phys of dwc3 also in xhci driver on Exynos5420 SoC, so I'm resending these now. Heikki Krogerus (6): phy: safer to_phy() macro phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method base: platform: name the device already during allocation usb: dwc3: host: convey the PHYs to xhci Documentation/phy.txt | 66 +-- arch/arm/mach-omap2/twl-common.c| 18 ++--- drivers/base/platform.c | 77 +++--- drivers/phy/phy-bcm-kona-usb2.c | 2 +- drivers/phy/phy-core.c | 156 +--- drivers/phy/phy-exynos-dp-video.c | 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-exynos5-usbdrd.c| 3 +- drivers/phy/phy-exynos5250-sata.c | 2 +- drivers/phy/phy-mvebu-sata.c| 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-samsung-usb2.c | 2 +- drivers/phy/phy-sun4i-usb.c | 2 +- drivers/phy/phy-ti-pipe3.c | 2 +- drivers/phy/phy-twl4030-usb.c | 4 +- drivers/phy/phy-xgene.c | 2 +- drivers/usb/dwc3/host.c | 22 +++-- include/linux/phy/phy.h | 60 +++--- 18 files changed, 259 insertions(+), 167 deletions(-) -- 2.0.0.rc4 -- 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
[PATCHv2 1/6] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..10d9714 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -108,7 +108,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.0.0.rc4
--
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
[PATCHv2 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index ebff6ee..441dc10 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -53,17 +53,13 @@ unregister the PHY.
The PHY driver should create the PHY in order for other peripheral controllers
to make use of it. The PHY framework provides 2 APIs to create the PHY.
-struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
-struct phy_init_data *init_data);
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data);
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
@@ -135,42 +131,24 @@ There are exported APIs like phy_pm_runtime_get,
phy_pm_runtime_get_sync,
phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
phy_pm_runtime_forbid for performing PM operations.
-8. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index c64a2f3..38034fd 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -25,6 +25,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -83,6 +84,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+ mutex_unlock(phy_provider_mutex);
+}
+
+/**
+ * phy_unregister_lookup() - remove PHY/device association
+ * @pl: association to be removed
+ */
+void
Re: [PATCHv2 0/6] phy: simplified phy lookup
Hi Heikki, On Thu, Jun 5, 2014 at 6:22 PM, Heikki Krogerus heikki.kroge...@linux.intel.com wrote: Hi, So the idea with these is that they should help to make it possible to request phys without caring about how they are mapped to the consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping phys to consumers can be now done with lookups similarly how clocks can be mapped in clkdev.c. Vivek needs to handle the phys of dwc3 also in xhci driver on Exynos5420 SoC, so I'm resending these now. Thank you so much for your efforts. This will greatly help me in preparing the patches for PHY tuning. Heikki Krogerus (6): phy: safer to_phy() macro phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method base: platform: name the device already during allocation usb: dwc3: host: convey the PHYs to xhci Documentation/phy.txt | 66 +-- arch/arm/mach-omap2/twl-common.c| 18 ++--- drivers/base/platform.c | 77 +++--- drivers/phy/phy-bcm-kona-usb2.c | 2 +- drivers/phy/phy-core.c | 156 +--- drivers/phy/phy-exynos-dp-video.c | 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-exynos5-usbdrd.c| 3 +- drivers/phy/phy-exynos5250-sata.c | 2 +- drivers/phy/phy-mvebu-sata.c| 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-samsung-usb2.c | 2 +- drivers/phy/phy-sun4i-usb.c | 2 +- drivers/phy/phy-ti-pipe3.c | 2 +- drivers/phy/phy-twl4030-usb.c | 4 +- drivers/phy/phy-xgene.c | 2 +- drivers/usb/dwc3/host.c | 22 +++-- include/linux/phy/phy.h | 60 +++--- 18 files changed, 259 insertions(+), 167 deletions(-) -- 2.0.0.rc4 -- 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 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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: gadgetfs: correct dev state
Commit 1826e9b1 fixes the use after free of dev. However if this is not the final call to dev_release() and the state is not reset to STATE_DEV_DISABLED and hence all further open() calls to the gadgetfs ep0 device will fail with EBUSY. So this commit reverts 1826e9b1 and places the call put_dev() after setting the state. Signed-off-by: Marcus Nutzinger marcus.nutzin...@theobroma-systems.com Reviewed-by: Christoph Muellner christoph.muell...@theobroma-systems.com --- drivers/usb/gadget/inode.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index a925d0c..6330528 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -1264,8 +1264,13 @@ dev_release (struct inode *inode, struct file *fd) kfree (dev-buf); dev-buf = NULL; - put_dev (dev); + /* other endpoints were all decoupled from this device */ + spin_lock_irq(dev-lock); + dev-state = STATE_DEV_DISABLED; + spin_unlock_irq(dev-lock); + + put_dev (dev); return 0; } -- 1.9.0 -- 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
RE: [PATCH 2/2] tools: ffs-test: convert to new descriptor format fixing compilation error
Hi,
-Original Message-
From: Michal Nazarewicz [mailto:m...@google.com] On Behalf Of Michal
Nazarewicz
Sent: Thursday, June 05, 2014 1:56 PM
To: Krzysztof Opasiak; 'Felipe Balbi'
Cc: Krzysztof Opasiak; linux-usb@vger.kernel.org; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH 2/2] tools: ffs-test: convert to new descriptor
format fixing compilation error
On Thu, Jun 05 2014, Krzysztof Opasiak k.opas...@samsung.com
wrote:
I would suggest adding a suitable structure as you described in
previous discussion[1]. Writing first 3 fields in each userspace
program doesn't look quite good. Using:
#ifndef USE_LEGACY_DESC_HEAD
struct {
struct usb_functionfs_desc_head2 header;
__le32 fs_count
(... and rest according to flags ...)
} __attribute__((packed)) header;
#else ...
Would be shorter, more flexible and user friendly. Moreover it
gives
less places for mistake (writing fields in wrong order).
For ffs-test with USE_LEGACY_DESC_HEAD support it would be longer.
Compare:
(... snip ...)
The second one uses an unreadable hack to match length of the first
one
and the third one is two lines longer. On top of that, the second
and
third produce different structures, use more complicated
preprocessing
directives, and repeat value of fs_count and hs_count twice.
Without legacy support, it would indeed be shorter (by two lines),
Yes and I was talking about apps which use only new API without compatibility
layer.
I agree that when providing compatibility layer it is more complicated but as
always this is a cost of compatibility layer.
but
would lead to awkward structures:
--- 8
-
struct {
struct usb_functionfs_descs_head2 header;
/* Why aren't the two below fields inside of a header? */
__le32 fs_count;
__le32 hs_count;
};
struct {
struct {
/* Why is there a header.header field? */
struct usb_functionfs_descs_head2 header;
__le32 fs_count;
__le32 hs_count;
};
};
--- 8
-
Please consider this:
struct {
struct usb_functionfs_descs_head2 header;
__le32 fs_count;
__le32 hs_count;
struct {
(...)
} fs_desc;
struct {
(...) /* Other than previous */
} hs_desc;
} = {
.header = (...),
.fs_count = X,
.fs_desc = {
(...)
},
.hs_count = Y,
.hs_desc = {
(...)
},
}
This approach looks quite reasonable for me and don't cause any confusion.
Numbers of fs and hs descriptors don't go to headers because they are more
connected with fs_desc and hs_desc than with header. Using this allows you to
initialize them as close to fs_desc and hs_desc as possible. BTW yes I see that
when we would like to have backward compatibility this will be few lines longer.
And I don't see how it would be more flexible. If anything, it
would be
less.
When I was writing about flexibility I was talking about use case described
above.
I understand, and share, your sentiment, but I don't think adding
usb_functionfs_descs_head2 structure with magic, flags and length
would
improve the situation.
Something I thought about shortly was:
--- 8
-
#define USB_FFS_DESCS_HEAD(_flags) struct { \
__le32 magic, length, flags;\
__le32 data[!!(_flags FUNCTIONFS_HAS_FS_DESC) + \
!!(_flags FUNCTIONFS_HAS_HS_DESC) + \
!!(_flags FUNCTIONFS_HAS_SS_DESC)]; \
} __attribute__((packed))
#define USB_FFS_DESCS_HEAD_INIT(_flags, length, ...) {
\
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
\
.flags = cpu_to_le32(flags),\
.langth = cpu_to_le32(length), \
.data = { __VA_ARGS__ } \
}
static const struct {
USB_FFS_DESCS_HEAD(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC),
/* … */
} __attribute__((packed)) descriptors = {
USB_FFS_DESCS_HEAD_INIT(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC,
sizeof(descriptors), 3, 3),
/* … */
};
--- 8
-
But whether this is nicer is arguable as well.
In my opinion those macros are quite nice and should appear in functionfs.h.
Maybe it would be suitable to provide ifdef __USB_FFS_USE_LEGACY_API and two
versions of those macros? This will make backward compatibility to be handled
by one switch
[PATCH 4/5] USB: ftdi_sio: clean up ftdi_set_max_packet_size()
Code and comment style clean ups of ftdi_set_max_packet_size().
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ftdi_sio.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 19f1114d36c7..5fdc30c58e61 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1554,16 +1554,16 @@ static void ftdi_determine_type(struct usb_serial_port
*port)
}
-/* Determine the maximum packet size for the device. This depends on the chip
- * type and the USB host capabilities. The value should be obtained from the
- * device descriptor as the chip will use the appropriate values for the
host.*/
+/*
+ * Determine the maximum packet size for the device. This depends on the chip
+ * type and the USB host capabilities. The value should be obtained from the
+ * device descriptor as the chip will use the appropriate values for the host.
+ */
static void ftdi_set_max_packet_size(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
- struct usb_serial *serial = port-serial;
- struct usb_interface *interface = serial-interface;
+ struct usb_interface *interface = port-serial-interface;
struct usb_endpoint_descriptor *ep_desc;
-
unsigned num_endpoints;
unsigned i;
@@ -1571,20 +1571,22 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
if (!num_endpoints)
return;
- /* NOTE: some customers have programmed FT232R/FT245R devices
-* with an endpoint size of 0 - not good. In this case, we
+ /*
+* NOTE: Some customers have programmed FT232R/FT245R devices
+* with an endpoint size of 0 - not good. In this case, we
* want to override the endpoint descriptor setting and use a
-* value of 64 for wMaxPacketSize */
+* value of 64 for wMaxPacketSize.
+*/
for (i = 0; i num_endpoints; i++) {
ep_desc = interface-cur_altsetting-endpoint[i].desc;
- if (ep_desc-wMaxPacketSize == 0) {
+ if (!ep_desc-wMaxPacketSize) {
ep_desc-wMaxPacketSize = cpu_to_le16(0x40);
dev_warn(port-dev, Overriding wMaxPacketSize on
endpoint %d\n,
usb_endpoint_num(ep_desc));
}
}
- /* set max packet size based on descriptor */
+ /* Set max packet size based on last descriptor. */
priv-max_packet_size = usb_endpoint_maxp(ep_desc);
}
--
1.8.5.5
--
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 0/5] USB: ftdi_sio: wMaxPacketSize patches
Some FTDI devices have broken endpoint descriptors that needs to be fixed up during probe. Mike Remski discovered that the current implementation is broken as it crashes the kernel if an interface without endpoints is probed. These patches fix this bug, while cleaning up the max-packet-size handling and removing a redundant probe quirk that fixes up mtxorb devices. Johan Johan Hovold (5): USB: ftdi_sio: fix null deref at port probe USB: ftdi_sio: make port probe less verbose USB: ftdi_sio: fix max-packet-size warning USB: ftdi_sio: clean up ftdi_set_max_packet_size() USB: ftdi_sio: remove redundant mtxorb quirk drivers/usb/serial/ftdi_sio.c | 87 ++- 1 file changed, 27 insertions(+), 60 deletions(-) -- 1.8.5.5 -- 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 5/5] USB: ftdi_sio: remove redundant mtxorb quirk
Remove redundant mtxorb quirk used to fix up incorrect wMaxPacketSize,
which was added before 895f28badce9 (USB: ftdi_sio: fix hi-speed device
packet size calculation) which does the same thing for all devices.
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ftdi_sio.c | 47 ---
1 file changed, 8 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 5fdc30c58e61..d9adc33d927a 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -87,7 +87,6 @@ struct ftdi_sio_quirk {
};
static int ftdi_jtag_probe(struct usb_serial *serial);
-static int ftdi_mtxorb_hack_setup(struct usb_serial *serial);
static int ftdi_NDI_device_setup(struct usb_serial *serial);
static int ftdi_stmclite_probe(struct usb_serial *serial);
static int ftdi_8u2232c_probe(struct usb_serial *serial);
@@ -98,10 +97,6 @@ static struct ftdi_sio_quirk ftdi_jtag_quirk = {
.probe = ftdi_jtag_probe,
};
-static struct ftdi_sio_quirk ftdi_mtxorb_hack_quirk = {
- .probe = ftdi_mtxorb_hack_setup,
-};
-
static struct ftdi_sio_quirk ftdi_NDI_device_quirk = {
.probe = ftdi_NDI_device_setup,
};
@@ -256,14 +251,12 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0124_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0125_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0126_PID) },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0127_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0127_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0128_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0129_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012A_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012B_PID) },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012C_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012C_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012D_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012E_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_012F_PID) },
@@ -302,18 +295,12 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0150_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0151_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0152_PID) },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0153_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0154_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0155_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0156_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0157_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
- { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0158_PID),
- .driver_info = (kernel_ulong_t)ftdi_mtxorb_hack_quirk },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0153_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0154_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0155_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0156_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0157_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0158_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0159_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_015A_PID) },
{ USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_015B_PID) },
@@ -1856,24 +1843,6 @@ static int ftdi_stmclite_probe(struct usb_serial *serial)
return 0;
}
-/*
- * The Matrix Orbital VK204-25-USB has an invalid IN endpoint.
- * We have to correct it if we want to read from it.
- */
-static int ftdi_mtxorb_hack_setup(struct usb_serial *serial)
-{
- struct usb_host_endpoint *ep = serial-dev-ep_in[1];
- struct usb_endpoint_descriptor *ep_desc = ep-desc;
-
- if (ep-enabled ep_desc-wMaxPacketSize == 0) {
- ep_desc-wMaxPacketSize = cpu_to_le16(0x40);
- dev_info(serial-dev-dev,
-Fixing invalid wMaxPacketSize on read pipe\n);
- }
-
- return 0;
-}
-
static int ftdi_sio_port_remove(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
--
1.8.5.5
--
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
[PATCH 1/5] USB: ftdi_sio: fix null deref at port probe
Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28badce9 (USB: ftdi_sio: fix hi-speed device packet size calculation) Reported-by: Mike Remski mrem...@mutualink.net Tested-by: Mike Remski mrem...@mutualink.net Cc: sta...@vger.kernel.org# 2.3.61 Signed-off-by: Johan Hovold jo...@kernel.org --- drivers/usb/serial/ftdi_sio.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 7c6e1dedeb06..3019141397eb 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1564,14 +1564,17 @@ static void ftdi_set_max_packet_size(struct usb_serial_port *port) struct usb_device *udev = serial-dev; struct usb_interface *interface = serial-interface; - struct usb_endpoint_descriptor *ep_desc = interface-cur_altsetting-endpoint[1].desc; + struct usb_endpoint_descriptor *ep_desc; unsigned num_endpoints; - int i; + unsigned i; num_endpoints = interface-cur_altsetting-desc.bNumEndpoints; dev_info(udev-dev, Number of endpoints %d\n, num_endpoints); + if (!num_endpoints) + return; + /* NOTE: some customers have programmed FT232R/FT245R devices * with an endpoint size of 0 - not good. In this case, we * want to override the endpoint descriptor setting and use a -- 1.8.5.5 -- 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 2/5] USB: ftdi_sio: make port probe less verbose
There's no need to print the number of endpoints per interface or
endpoint wMaxPacketSize during port probe. This information is readily
available using lsusb should it ever be needed.
Note that this also fixes the wMaxPacketSize being incorrectly reported
on big-endian systems due to a missing le16_to_cpu().
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ftdi_sio.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 3019141397eb..a988a3b86ee1 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1570,8 +1570,6 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
unsigned i;
num_endpoints = interface-cur_altsetting-desc.bNumEndpoints;
- dev_info(udev-dev, Number of endpoints %d\n, num_endpoints);
-
if (!num_endpoints)
return;
@@ -1580,8 +1578,6 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
* want to override the endpoint descriptor setting and use a
* value of 64 for wMaxPacketSize */
for (i = 0; i num_endpoints; i++) {
- dev_info(udev-dev, Endpoint %d MaxPacketSize %d\n, i+1,
-
interface-cur_altsetting-endpoint[i].desc.wMaxPacketSize);
ep_desc = interface-cur_altsetting-endpoint[i].desc;
if (ep_desc-wMaxPacketSize == 0) {
ep_desc-wMaxPacketSize = cpu_to_le16(0x40);
@@ -1591,8 +1587,6 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
/* set max packet size based on descriptor */
priv-max_packet_size = usb_endpoint_maxp(ep_desc);
-
- dev_info(udev-dev, Setting MaxPacketSize %d\n,
priv-max_packet_size);
}
--
1.8.5.5
--
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 3/5] USB: ftdi_sio: fix max-packet-size warning
Promote max-packet-size-override message to warning level and use the
port device for logging, while using actual endpoint numbers in the
message itself.
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ftdi_sio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index a988a3b86ee1..19f1114d36c7 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1561,8 +1561,6 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
struct usb_serial *serial = port-serial;
- struct usb_device *udev = serial-dev;
-
struct usb_interface *interface = serial-interface;
struct usb_endpoint_descriptor *ep_desc;
@@ -1581,7 +1579,8 @@ static void ftdi_set_max_packet_size(struct
usb_serial_port *port)
ep_desc = interface-cur_altsetting-endpoint[i].desc;
if (ep_desc-wMaxPacketSize == 0) {
ep_desc-wMaxPacketSize = cpu_to_le16(0x40);
- dev_info(udev-dev, Overriding wMaxPacketSize on
endpoint %d\n, i);
+ dev_warn(port-dev, Overriding wMaxPacketSize on
endpoint %d\n,
+ usb_endpoint_num(ep_desc));
}
}
--
1.8.5.5
--
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
Re: [PATCH 1/2] usb: gadget: f_fs: resurect usb_functionfs_descs_head structure
Hello. On 06/05/2014 11:43 AM, Michal Nazarewicz wrote: Even though usb_functionfs_descs_head structure is now deprecated, it has been used by some user space tools. It's removel in commit s/It's removel/Its removal/. [ac8dde1: Add flags to descriptors block] was an oversight leading to build breakage for such tools. Bring it back so that old user space tools can still be build without problems on newer kernel versions. Cc: sta...@vger.kernel.org # 3.14 Signed-off-by: Michal Nazarewicz min...@mina86.com WBR, Sergei -- 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
Re: [PATCH] usb: gadget: gadgetfs: correct dev state
Hello. On 06/05/2014 05:08 PM, Marcus Nutzinger wrote: Commit 1826e9b1 fixes the use after free of dev. Please also specify that commit's summary line in parens. However if this is not the final call to dev_release() and the state is not reset to STATE_DEV_DISABLED and hence all further open() calls to the gadgetfs ep0 device will fail with EBUSY. So this commit reverts 1826e9b1 and places the call put_dev() after setting the state. Signed-off-by: Marcus Nutzinger marcus.nutzin...@theobroma-systems.com Reviewed-by: Christoph Muellner christoph.muell...@theobroma-systems.com --- drivers/usb/gadget/inode.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index a925d0c..6330528 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -1264,8 +1264,13 @@ dev_release (struct inode *inode, struct file *fd) kfree (dev-buf); dev-buf = NULL; - put_dev (dev); + /* other endpoints were all decoupled from this device */ + spin_lock_irq(dev-lock); + dev-state = STATE_DEV_DISABLED; + spin_unlock_irq(dev-lock); Not sure I understand why you need spinlock here... isn't the assignment atomic already? + + put_dev (dev); return 0; } WBR, Sergei -- 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
Re: [PATCH] leds: USB: Add support for MSI GT683R led panels
2014-06-05 13:06 GMT+02:00: + dev_err(led-usb_dev-dev, Message to be send to device is too long\n); there's a typo: s/send/sent/ -- Daniele Forsi -- 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
RE: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
On Thu, 5 Jun 2014, Peter Chen wrote: It is a little strange we call gadget's disconnect at SET_ADDRESS? How the udc calls gadget driver the disconnection has happened when the usb cable is disconnected from the host? Usually, we call gadget's disconnect at two situations - udc's reset handler if udc's speed is not UNKNOWN, it is usually happened when the host sends reset after enumeration. - udc's disconnect handler, it is usually happened when the usb cable is disconnected from host. Hmm, usually the two situations, but according to the commit log, s3c hsotg does not support Disconnected interrupt for device mode, so the second situation does not happen for s3c hsotg, therefore, he has to disconnect the connection before it is connected again. Why does he need to do that? Why not just skip the disconnect notification if the hardware can't detect a disconnect? We must call gadget driver's disconnect, otherwise, there at least has a warning when unload module, please refer to __composite_unbind at drivers/usb/gadget/composite.c The disconnect callback can run just before unbind. That's not a valid reason for doing a disconnect notification as part of SET_ADDRESS. Alan Stern -- 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 v2] usb: gadget: gadgetfs: correct dev state
This reverts commit 1826e9b1 (usb: gadget: gadgetfs: use after free in dev_release()) and places the call to put_dev() after setting the state. If this is not the final call to dev_release() and the state is not reset to STATE_DEV_DISABLED and hence all further open() calls to the gadgetfs ep0 device will fail with EBUSY. Signed-off-by: Marcus Nutzinger marcus.nutzin...@theobroma-systems.com Reviewed-by: Christoph Muellner christoph.muell...@theobroma-systems.com --- drivers/usb/gadget/inode.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index a925d0c..6330528 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -1264,8 +1264,13 @@ dev_release (struct inode *inode, struct file *fd) kfree (dev-buf); dev-buf = NULL; - put_dev (dev); + /* other endpoints were all decoupled from this device */ + spin_lock_irq(dev-lock); + dev-state = STATE_DEV_DISABLED; + spin_unlock_irq(dev-lock); + + put_dev (dev); return 0; } -- 1.9.0 -- 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
Re: [PATCH 0/5] USB: ftdi_sio: wMaxPacketSize patches
On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote: Some FTDI devices have broken endpoint descriptors that needs to be fixed up during probe. Mike Remski discovered that the current implementation is broken as it crashes the kernel if an interface without endpoints is probed. These patches fix this bug, while cleaning up the max-packet-size handling and removing a redundant probe quirk that fixes up mtxorb devices. Looks good, but did you forget to cc: me as well so that I know to pick these up? Or are you going to send a pull request later on with them? thanks, greg k-h -- 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
linux-next crash in xhci_add_ep_to_interval
Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval when it's docked in a newer dock that has USB3. It's very possible that the BIOS is buggy - it isn't like I haven't found BIOS bugs in every single Dell laptop I've had. :) But that shouldn't make the kernel crash lsusb reports: Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 413c:5534 Dell Computer Corp. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter Bus 003 Device 002: ID 413c:2134 Dell Computer Corp. Bus 003 Device 004: ID 045e:0023 Microsoft Corp. Trackball Optical Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Git bisect comes down to this: commit d8521afe35862f4fbe3ccd6ca37897c0a304edf3 Author: Dan Williams dan.j.willi...@intel.com Date: Tue May 20 18:08:28 2014 -0700 usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. Thanks to pstore, we have the explosion: [3.974159] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020 [3.974173] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.974247] usb 3-4.1: Product: PS2toUSB Adapter [3.974259] usb 3-4.1: Manufacturer: GASIA [3.975475] BUG: unable to handle kernel NULL pointer dereference at 0080 [3.975643] IP: [8139abd4] xhci_add_ep_to_interval_table+0xc8/0x172 [3.975795] PGD 0 [3.975849] Oops: 0002 [#1] PREEMPT SMP [3.975954] Modules linked in: [3.976029] CPU: 0 PID: 37 Comm: khubd Not tainted 3.15.0-rc5-00299-g7e73be2 #234 [3.976169] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013 [3.976304] task: 880128e809d0 ti: 880128e84000 task.ti: 880128e84000 [3.976441] RIP: 0010:[8139abd4] [8139abd4] xhci_add_ep_to_interval_table+0xc8/0x172 [3.976631] RSP: 0018:880128e85608 EFLAGS: 00010006 [3.976732] RAX: 0003 RBX: RCX: 8800c5861800 [3.976863] RDX: 0001 RSI: 0078 RDI: 0005 [3.976997] RBP: 880128e85640 R08: 8801288f2228 R09: [3.977125] R10: 880128e85968 R11: 0004 R12: 8801288f22fc [3.977255] R13: 8800c5861800 R14: 88003f878000 R15: 0007 [3.977353] FS: () GS:88012dc0() knlGS: [3.977440] CS: 0010 DS: ES: CR0: 80050033 [3.977503] CR2: 0080 CR3: c5eb4000 CR4: 001407f0 [3.977578] Stack: [3.977606] 8801288f2228 8801288f2000 8801288f22fc [3.977708] 88003f878000 8800c5d8b000 0003 880128e85990 [3.977808] 8139c76d 880128e85700 880128e85680 00010007 [3.977910] Call Trace: [3.977948] [8139c76d] xhci_reserve_bandwidth+0x158/0x534 [3.978022] [8107d810] ? mark_held_locks+0x5d/0x74 [3.978086] [8107d5da] ? mark_lock+0x2a/0x203 [3.978148] [8107e313] ? __lock_acquire+0x696/0xedf [3.978215] [8112256b] ? dma_pool_alloc+0x188/0x225 [3.978281] [8107d5da] ? mark_lock+0x2a/0x203 [3.980065] [8107d5da] ? mark_lock+0x2a/0x203 [3.981976] [8107d810] ? mark_held_locks+0x5d/0x74 [3.984302] [8107d5da] ? mark_lock+0x2a/0x203 [3.986919] [8107e313] ? __lock_acquire+0x696/0xedf [3.989317] [8139cb84] ? xhci_configure_endpoint+0x3b/0x4b0 [3.991817] [8107d5da] ? mark_lock+0x2a/0x203 [3.994396] [8107d810] ? mark_held_locks+0x5d/0x74 [3.996896] [8107eebf] ? lock_acquire+0xc1/0x14e [3.998795] [8139cb84] ? xhci_configure_endpoint+0x3b/0x4b0 [4.000407] [813a84b0] ? xhci_dbg_trace+0x3f/0x47 [4.002724] [8139cc88] xhci_configure_endpoint+0x13f/0x4b0 [4.005076] [8139d706] xhci_check_bandwidth+0x11e/0x231 [4.007457] [813791ce] usb_hcd_alloc_bandwidth+0x21d/0x2bd [4.009787] [8137be1b] usb_set_configuration+0x282/0x6f9 [4.012008]
Re: [PATCH] usb: gadget: gadgetfs: correct dev state
Hi Sergei, On Jun 5, 2014, at 4:18 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Please also specify that commit's summary line in parens. I'll resubmit the updated patch in a minute! +/* other endpoints were all decoupled from this device */ +spin_lock_irq(dev-lock); +dev-state = STATE_DEV_DISABLED; +spin_unlock_irq(dev-lock); Not sure I understand why you need spinlock here... isn't the assignment atomic already? Sure, an assignment might be atomic. However, following the policy of commit 7489d149 (USB: gadgetfs cleanups) all ep0 state changes shall be protected by spinlocks. Thanks, Marcus -- 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
Re: ASMedia AS2105 interface on USB 3.0 corrupts data
On 05/26/2014 08:19 PM, Heinz Diehl wrote: On 26.05.2014, Mathias Nyman wrote: This would be helpful, I've got a LeCroy protocol analyzer in Finland. Heinz, if you're willing to send it to Europe Finland I'll gladly take it, (I'll send the address details in a separate personal mail) Of course! Send me your adress, and I'll send you the controller. I've purchased it here in Norway, it's exactly this one: Hi I got the device, tried it out with a vfat formatted 120G SSD drive, and everything works for me? Running on a Haswell (Lynxpoint) machine with only initrd image. [root@hsw06 /]# uname -r 3.14.4 [root@hsw06 /]# lsusb Bus 001 Device 002: ID 8564:1000 Bus 002 Device 002: ID 174c:5136 ASMedia Technology Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub [root@hsw06 /]# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M |__ Port 5: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M [root@hsw06 /]# fdisk -l Disk /dev/sdb: 8103 MB, 8103395328 bytes 1 heads, 32 sectors/track, 494592 cylinders, total 15826944 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000d9ec3 Device Boot Start End Blocks Id System /dev/sdb1 * 32 48799 24384c W95 FAT32 (LBA) Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xb099e729 Device Boot Start End Blocks Id System /dev/sda1 63 234441647 117220792+ c W95 FAT32 (LBA) [root@hsw06 /]# mount /dev/sda1 /mnt [ 256.752077] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [root@hsw06 /]# dd if=/dev/zero of=/mnt/zeroes bs=1M count=1000 1000+0 records in 1000+0 records out [root@hsw06 /]# sync [root@hsw06 /]# ls -lh /mnt total 1126400 -rwxr-xr-x1 root root 100.0M Aug 26 06:28 100Mzeroes* -rwxr-xr-x1 root root 1000.0M Aug 26 06:38 zeroes* [root@hsw06 /]# I tried several times, always works, dmesg is clean. Haswell has Lynxpoint PCH, I can try to find a PantherPoint based system a try it out with that as well. What kind of a hard drive did you have connected? and with what filsystem? Just in case if that somehow affects the USB traffic. -Mathias -- 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: dummy_hcd: remove superfluous setting HC_STATE_RUNNING in dummy_start()
After commit 4814030ce11f08350b7, the core now sets hcd-state = HC_STATE_RUNNING in usb_add_hcd() before the driver's start() method is called. So, we can safely remove this line from dummy_start() since it is now superfluous. Signed-off-by: Pantelis Koukousoulas pkt...@gmail.com --- drivers/usb/gadget/dummy_hcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c index ffd5af0..3a2e649 100644 --- a/drivers/usb/gadget/dummy_hcd.c +++ b/drivers/usb/gadget/dummy_hcd.c @@ -2345,7 +2345,6 @@ static int dummy_start(struct usb_hcd *hcd) INIT_LIST_HEAD(dum_hcd-urbp_list); hcd-power_budget = POWER_BUDGET; - hcd-state = HC_STATE_RUNNING; hcd-uses_new_polling = 1; #ifdef CONFIG_USB_OTG -- 1.9.1 -- 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 9/9] ARM: dts: Berlin: enable USB on the BG2Q DMP
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 2da9c41e29d8..4195874b9bed 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -7,6 +7,8 @@
*/
/dts-v1/;
+
+#include dt-bindings/gpio/gpio.h
#include berlin2q.dtsi
/ {
@@ -26,3 +28,21 @@
uart0 {
status = okay;
};
+
+usb_phy0 {
+ power-gpio = portb 8 GPIO_ACTIVE_HIGH;
+ status = okay;
+};
+
+usb_phy2 {
+ power-gpio = portb 12 GPIO_ACTIVE_HIGH;
+ status = okay;
+};
+
+usb0 {
+ status = okay;
+};
+
+usb2 {
+ status = okay;
+};
--
1.9.1
--
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 8/9] ARM: dts: berlin: add BG2Q nodes for USB support
Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
SoC has 3 USB host controller, compatible with ChipIdea.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q.dtsi | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index b74e5ec66354..a6902ea5580c 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -87,6 +87,39 @@
#interrupt-cells = 3;
};
+ usb_phy2: usbphy@a2f400 {
+ compatible = marvell,berlin-usbphy;
+ reg = 0xa2f400 0x128;
+ #phy-cells = 0;
+ resets = chip 14;
+ status = disabled;
+ };
+
+ usb2: usb@a3 {
+ compatible = marvell,berlin-usb;
+ reg = 0xa3 0x1;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB2;
+ marvell,usbphy = usb_phy2;
+ status = disabled;
+ };
+
+ usb_phy0: usbphy@b74000 {
+ compatible = marvell,berlin-usbphy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 12;
+ status = disabled;
+ };
+
+ usb_phy1: usbphy@b78000 {
+ compatible = marvell,berlin-usbphy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 13;
+ status = disabled;
+ };
+
apb@e8 {
compatible = simple-bus;
#address-cells = 1;
@@ -280,6 +313,24 @@
clock-names = refclk;
};
+ usb0: usb@ed {
+ compatible = marvell,berlin-usb;
+ reg = 0xed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ marvell,usbphy = usb_phy0;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = marvell,berlin-usb;
+ reg = 0xee 0x1;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ marvell,usbphy = usb_phy1;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 1;
--
1.9.1
--
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 6/9] usb: chipidea: add Berlin USB support
The Marvell Berlin USB controllers are compatible with ChipIdea. Add a
driver using the ChipIdea common functions to support them.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/Makefile | 1 +
drivers/usb/chipidea/ci_hdrc_berlin.c | 108 ++
2 files changed, 109 insertions(+)
create mode 100644 drivers/usb/chipidea/ci_hdrc_berlin.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 480bd4d5710a..b3a1b0b3b7a9 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -19,4 +19,5 @@ endif
ifneq ($(CONFIG_OF),)
obj-$(CONFIG_USB_CHIPIDEA) += usbmisc_imx.o ci_hdrc_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_berlin.o
endif
diff --git a/drivers/usb/chipidea/ci_hdrc_berlin.c
b/drivers/usb/chipidea/ci_hdrc_berlin.c
new file mode 100644
index ..567d83039e3e
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_berlin.c
@@ -0,0 +1,108 @@
+/*
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart antoine.ten...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/usb/chipidea.h
+#include linux/usb/hcd.h
+#include linux/usb/ulpi.h
+
+#include ci.h
+
+struct ci_hdrc_berlin_priv {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static int ci_hdrc_berlin_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct ci_hdrc_berlin_priv *priv;
+ struct ci_hdrc_platform_data ci_pdata = {
+ .name = ci_hdrc_berlin,
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER |
+ CI_HDRC_DISABLE_STREAMING,
+ };
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv-clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev, failed to get clock: %ld\n, PTR_ERR(priv-clk));
+ return PTR_ERR(priv-clk);
+ }
+
+ ret = clk_prepare_enable(priv-clk);
+ if (ret)
+ return ret;
+
+ ci_pdata.phy = devm_usb_get_phy_by_phandle(dev, marvell,usbphy, 0);
+ if (IS_ERR(ci_pdata.phy)) {
+ ret = PTR_ERR(ci_pdata.phy);
+ goto clk_err;
+ }
+
+ priv-ci_pdev = ci_hdrc_add_device(dev, pdev-resource,
+pdev-num_resources, ci_pdata);
+ if (IS_ERR(priv-ci_pdev)) {
+ ret = PTR_ERR(priv-ci_pdev);
+ dev_err(dev,
+ failed to register ci_hdrc platform device: %d\n,
+ ret);
+ goto clk_err;
+ }
+
+ platform_set_drvdata(pdev, priv);
+
+ pm_runtime_no_callbacks(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+
+clk_err:
+ clk_disable_unprepare(priv-clk);
+ return ret;
+}
+
+static int ci_hdrc_berlin_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_berlin_priv *priv = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(priv-ci_pdev);
+ clk_disable_unprepare(priv-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_berlin_of_match[] = {
+ { .compatible = marvell,berlin-usb },
+ { }
+};
+
+static struct platform_driver ci_hdrc_berlin_driver = {
+ .probe = ci_hdrc_berlin_probe,
+ .remove = ci_hdrc_berlin_remove,
+ .driver = {
+ .name = berlin-usb,
+ .owner = THIS_MODULE,
+ .of_match_table = ci_hdrc_berlin_of_match,
+ },
+};
+module_platform_driver(ci_hdrc_berlin_driver);
+
+MODULE_DESCRIPTION(ChipIdea HDRC Berlin USB binding);
+MODULE_AUTHOR(Antoine Ténart antoine.ten...@free-electrons.com);
+MODULE_LICENSE(GPL);
--
1.9.1
--
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 5/9] Documentation: bindings: add doc for the Berlin USB PHY
Document the bindings of the Marvell Berlin USB PHY driver.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
.../devicetree/bindings/usb/berlin-usbphy.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/berlin-usbphy.txt
diff --git a/Documentation/devicetree/bindings/usb/berlin-usbphy.txt
b/Documentation/devicetree/bindings/usb/berlin-usbphy.txt
new file mode 100644
index ..d97eb1f9d53f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/berlin-usbphy.txt
@@ -0,0 +1,18 @@
+* Marvell Berlin USB PHY
+
+Required properties:
+- compatible: should be marvell,berlin-usbphy
+- reg: base address and length of the registers
+- #phys-cells: should be 0
+- reset: reference to the reset controller
+- power-gpio: reference the GPIO pin to power the PHY
+
+Example:
+
+ usbphy@f774000 {
+ compatible = marvell,berlin-usbphy;
+ reg = 0xf774000 0x128;
+ #phy-cells = 0;
+ resets = chip 14;
+ power-gpio = portb 8 GPIO_ACTIVE_HIGH;
+ };
--
1.9.1
--
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 7/9] Documentation: bindings: add doc for the Berlin ChipIdea USB driver
Document the Marvell Berlin USB driver bindings.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
.../devicetree/bindings/usb/ci-hdrc-berlin.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt
new file mode 100644
index ..a3fc9054b830
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt
@@ -0,0 +1,18 @@
+* Marvell Berlin usb controllers
+
+Required properties:
+- compatible: should be marvell,berlin-usb
+- reg: base address and length of the registers
+- interrupts: interrupt for the USB controller
+- clocks: reference to the USB clock
+- marvell,usbphy: reference to the USB PHY
+
+Example:
+
+ usb@f7ed {
+ compatible = marvell,berlin-usb;
+ reg = 0xf7ed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ marvell,usbphy = usb_phy0;
+ };
--
1.9.1
--
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 4/9] usb: phy: add the Berlin USB PHY driver
Add the driver driving the Marvell Berlin USB PHY. This allows to initialize the PHY and to use it from the USB driver later. Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com --- drivers/usb/phy/Kconfig | 9 ++ drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-berlin-usb.c | 223 +++ 3 files changed, 233 insertions(+) create mode 100644 drivers/usb/phy/phy-berlin-usb.c diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 416e0c8cf6ff..8be8d4afc428 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -27,6 +27,15 @@ config AB8500_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config BERLIN_USBPHY + tristate Marvell Berlin USB Transceiver Driver + depends on ARCH_BERLIN + select USB_PHY + help + Enable this to support the USB tranceiver on Marvell Berlin + SoCs. + + config FSL_USB2_OTG bool Freescale USB OTG Transceiver Driver depends on USB_EHCI_FSL USB_FSL_USB2 USB_OTG_FSM PM_RUNTIME diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index f8fa719a31b9..9253f59cf82a 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_USB_OTG_FSM) += phy-fsm-usb.o # transceiver drivers, keep the list sorted obj-$(CONFIG_AB8500_USB) += phy-ab8500-usb.o +obj-$(CONFIG_BERLIN_USBPHY)+= phy-berlin-usb.o obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb.o obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301-omap.o obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o diff --git a/drivers/usb/phy/phy-berlin-usb.c b/drivers/usb/phy/phy-berlin-usb.c new file mode 100644 index ..79416668a71b --- /dev/null +++ b/drivers/usb/phy/phy-berlin-usb.c @@ -0,0 +1,223 @@ +/* + * Copyright (C) 2014 Marvell Technology Group Ltd. + * + * Antoine Ténart antoine.ten...@free-electrons.com + * Jisheng Zhang jszh...@marvell.com + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed as is without any + * warranty of any kind, whether express or implied. + */ + +#include linux/gpio.h +#include linux/io.h +#include linux/module.h +#include linux/of_gpio.h +#include linux/usb/phy.h +#include linux/platform_device.h +#include linux/reset.h + +#define USB_PHY_PLL0x04 +#define USB_PHY_PLL_CONTROL0x08 +#define USB_PHY_TX_CTRL0 0x10 +#define USB_PHY_TX_CTRL1 0x14 +#define USB_PHY_TX_CTRL2 0x18 +#define USB_PHY_RX_CTRL0x20 +#define USB_PHY_ANALOG 0x34 + +/* USB_PHY_PLL */ +#define CLK_REF_DIV(x) ((x) 4) +#define FEEDBACK_CLK_DIV(x)((x) 8) + +/* USB_PHY_PLL_CONTROL */ +#define CLK_STABLE (0x1 0) +#define PLL_CTRL_PIN (0x1 1) +#define PLL_CTRL_REG (0x1 2) +#define PLL_ON (0x1 3) +#define PHASE_OFF_TOL_125 (0x0 5) +#define PHASE_OFF_TOL_250 (0x1 5) +#define KVC0_CALIB (0x0 9) +#define KVC0_REG_CTRL (0x1 9) +#define KVC0_HIGH (0x0 10) +#define KVC0_LOW (0x3 10) +#define CLK_BLK_EN (0x1 13) + +/* USB_PHY_TX_CTRL0 */ +#define EXT_HS_RCAL_EN (0x1 3) +#define EXT_FS_RCAL_EN (0x1 4) +#define IMPCAL_VTH_DIV(x) ((x) 5) +#define EXT_RS_RCAL_DIV(x) ((x) 8) +#define EXT_FS_RCAL_DIV(x) ((x) 12) + +/* USB_PHY_TX_CTRL1 */ +#define TX_VDD15_14(0x0 4) +#define TX_VDD15_15(0x1 4) +#define TX_VDD15_16(0x2 4) +#define TX_VDD15_17(0x3 4) +#define TX_VDD12_VDD (0x0 6) +#define TX_VDD12_11(0x1 6) +#define TX_VDD12_12(0x2 6) +#define TX_VDD12_13(0x3 6) +#define LOW_VDD_EN (0x1 8) +#define TX_OUT_AMP(x) ((x) 9) + +/* USB_PHY_TX_CTRL2 */ +#define TX_CHAN_CTRL_REG(x)((x) 0) +#define DRV_SLEWRATE(x)((x) 4) +#define IMP_CAL_FS_HS_DLY_0(0x0 6) +#define IMP_CAL_FS_HS_DLY_1(0x1 6) +#define IMP_CAL_FS_HS_DLY_2(0x2 6) +#define IMP_CAL_FS_HS_DLY_3(0x3 6) +#define FS_DRV_EN_MASK(x) ((x) 8) +#define HS_DRV_EN_MASK(x) ((x) 12) + +/* USB_PHY_RX_CTRL */ +#define PHASE_FREEZE_DLY_2_CL (0x0 0) +#define PHASE_FREEZE_DLY_4_CL (0x1 0) +#define ACK_LENGTH_8_CL(0x0 2) +#define ACK_LENGTH_12_CL (0x1 2) +#define ACK_LENGTH_16_CL (0x2 2) +#define ACK_LENGTH_20_CL (0x3 2) +#define SQ_LENGTH_3(0x0 4) +#define SQ_LENGTH_6(0x1 4) +#define SQ_LENGTH_9(0x2 4) +#define SQ_LENGTH_12 (0x3 4) +#define DISCON_THRESHOLD_260 (0x0 6) +#define DISCON_THRESHOLD_270 (0x1 6) +#define DISCON_THRESHOLD_280 (0x2 6) +#define DISCON_THRESHOLD_290 (0x3 6) +#define SQ_THRESHOLD(x)((x) 8)
[PATCH 0/9] ARM: Berlin: USB support
This series adds the support for the Marvell Berlin USB controllers, the USB PHYs and also adds a reset controller. The reset controller is used by the USB PHY driver and shares the existing chip controller node with the clocks and one pin controller. The Marvell Berlin USB controllers are host only on the BG2Q and are compatible with USB ChipIdea. We here add a glue to use the available common functions for this kind of controllers. A USB PHY driver is also added to control the PHY. Antoine Ténart (9): reset: add the Berlin reset controller driver ARM: Berlin: select the reset controller ARM: dts: berlin: add a required reset property in the chip controller node usb: phy: add the Berlin USB PHY driver Documentation: bindings: add doc for the Berlin USB PHY usb: chipidea: add Berlin USB support Documentation: bindings: add doc for the Berlin ChipIdea USB driver ARM: dts: berlin: add BG2Q nodes for USB support ARM: dts: Berlin: enable USB on the BG2Q DMP .../devicetree/bindings/usb/berlin-usbphy.txt | 18 ++ .../devicetree/bindings/usb/ci-hdrc-berlin.txt | 18 ++ arch/arm/boot/dts/berlin2.dtsi | 1 + arch/arm/boot/dts/berlin2cd.dtsi | 1 + arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 20 ++ arch/arm/boot/dts/berlin2q.dtsi| 52 + arch/arm/mach-berlin/Kconfig | 2 + drivers/reset/Makefile | 1 + drivers/reset/reset-berlin.c | 113 +++ drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_berlin.c | 108 ++ drivers/usb/phy/Kconfig| 9 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-berlin-usb.c | 223 + 14 files changed, 568 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/berlin-usbphy.txt create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt create mode 100644 drivers/reset/reset-berlin.c create mode 100644 drivers/usb/chipidea/ci_hdrc_berlin.c create mode 100644 drivers/usb/phy/phy-berlin-usb.c -- 1.9.1 -- 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
Re: linux-next crash in xhci_add_ep_to_interval
[ adding Mathias ] On Thu, Jun 5, 2014 at 8:22 AM, Valdis Kletnieks valdis.kletni...@vt.edu wrote: Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval when it's docked in a newer dock that has USB3. It's very possible that the BIOS is buggy - it isn't like I haven't found BIOS bugs in every single Dell laptop I've had. :) But that shouldn't make the kernel crash lsusb reports: Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 413c:5534 Dell Computer Corp. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter Bus 003 Device 002: ID 413c:2134 Dell Computer Corp. Bus 003 Device 004: ID 045e:0023 Microsoft Corp. Trackball Optical Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Git bisect comes down to this: commit d8521afe35862f4fbe3ccd6ca37897c0a304edf3 Author: Dan Williams dan.j.willi...@intel.com Date: Tue May 20 18:08:28 2014 -0700 usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. Thanks to pstore, we have the explosion: [3.974159] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020 [3.974173] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.974247] usb 3-4.1: Product: PS2toUSB Adapter [3.974259] usb 3-4.1: Manufacturer: GASIA [3.975475] BUG: unable to handle kernel NULL pointer dereference at 0080 [3.975643] IP: [8139abd4] xhci_add_ep_to_interval_table+0xc8/0x172 [3.975795] PGD 0 [3.975849] Oops: 0002 [#1] PREEMPT SMP [3.975954] Modules linked in: [3.976029] CPU: 0 PID: 37 Comm: khubd Not tainted 3.15.0-rc5-00299-g7e73be2 #234 [3.976169] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013 [3.976304] task: 880128e809d0 ti: 880128e84000 task.ti: 880128e84000 [3.976441] RIP: 0010:[8139abd4] [8139abd4] xhci_add_ep_to_interval_table+0xc8/0x172 [3.976631] RSP: 0018:880128e85608 EFLAGS: 00010006 [3.976732] RAX: 0003 RBX: RCX: 8800c5861800 [3.976863] RDX: 0001 RSI: 0078 RDI: 0005 [3.976997] RBP: 880128e85640 R08: 8801288f2228 R09: [3.977125] R10: 880128e85968 R11: 0004 R12: 8801288f22fc [3.977255] R13: 8800c5861800 R14: 88003f878000 R15: 0007 [3.977353] FS: () GS:88012dc0() knlGS: [3.977440] CS: 0010 DS: ES: CR0: 80050033 [3.977503] CR2: 0080 CR3: c5eb4000 CR4: 001407f0 [3.977578] Stack: [3.977606] 8801288f2228 8801288f2000 8801288f22fc [3.977708] 88003f878000 8800c5d8b000 0003 880128e85990 [3.977808] 8139c76d 880128e85700 880128e85680 00010007 [3.977910] Call Trace: [3.977948] [8139c76d] xhci_reserve_bandwidth+0x158/0x534 [3.978022] [8107d810] ? mark_held_locks+0x5d/0x74 [3.978086] [8107d5da] ? mark_lock+0x2a/0x203 [3.978148] [8107e313] ? __lock_acquire+0x696/0xedf [3.978215] [8112256b] ? dma_pool_alloc+0x188/0x225 [3.978281] [8107d5da] ? mark_lock+0x2a/0x203 [3.980065] [8107d5da] ? mark_lock+0x2a/0x203 [3.981976] [8107d810] ? mark_held_locks+0x5d/0x74 [3.984302] [8107d5da] ? mark_lock+0x2a/0x203 [3.986919] [8107e313] ? __lock_acquire+0x696/0xedf [3.989317] [8139cb84] ? xhci_configure_endpoint+0x3b/0x4b0 [3.991817] [8107d5da] ? mark_lock+0x2a/0x203 [3.994396] [8107d810] ? mark_held_locks+0x5d/0x74 [3.996896] [8107eebf] ? lock_acquire+0xc1/0x14e [3.998795] [8139cb84] ? xhci_configure_endpoint+0x3b/0x4b0 [4.000407] [813a84b0] ? xhci_dbg_trace+0x3f/0x47 [4.002724] [8139cc88] xhci_configure_endpoint+0x13f/0x4b0 [4.005076]
Re: [PATCH] usb: gadget: gadgetfs: correct dev state
On Thu, 5 Jun 2014, Marcus Nutzinger wrote: Hi Sergei, On Jun 5, 2014, at 4:18 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Please also specify that commit's summary line in parens. I'll resubmit the updated patch in a minute! + /* other endpoints were all decoupled from this device */ + spin_lock_irq(dev-lock); + dev-state = STATE_DEV_DISABLED; + spin_unlock_irq(dev-lock); Not sure I understand why you need spinlock here... isn't the assignment atomic already? Sure, an assignment might be atomic. However, following the policy of commit 7489d149 (USB: gadgetfs cleanups) all ep0 state changes shall be protected by spinlocks. Sometimes an assignment needs to be protected by a lock, even though the assignment itself is atomic. This happens, for example, when some other code executes a lock-protected region that expects the variable not to change. I don't know if that's the case here. But this example shows that in general, one sometimes needs locks in places where you wouldn't expect them. In fact, it may even be necessary to take and release a lock, without doing anything in between! Alan Stern -- 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
Re: [PATCH 0/5] USB: ftdi_sio: wMaxPacketSize patches
On Thu, Jun 05, 2014 at 08:30:42AM -0700, Greg KH wrote: On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote: Some FTDI devices have broken endpoint descriptors that needs to be fixed up during probe. Mike Remski discovered that the current implementation is broken as it crashes the kernel if an interface without endpoints is probed. These patches fix this bug, while cleaning up the max-packet-size handling and removing a redundant probe quirk that fixes up mtxorb devices. Looks good, but did you forget to cc: me as well so that I know to pick these up? Or are you going to send a pull request later on with them? Yes, that was my intention. None of these are really critical and could wait for v3.17-rc1, although I'll probably send you the first for v3.16-rc2. As we discussed briefly off-list, I intend to maintain a usb-next and usb-linus branch in my USB-serial tree on kernel.org, while posting my own patches to linux-usb for review before applying them (I can still CC you as well of course). Perhaps I should start using a usb-serial: prefix to make it easier to discern what I intend to apply myself from any non-USB-serial patches I might be sending you? Or the diff-stat would be sufficient (drivers/usb/serial/*) for that? Thanks, Johan -- 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
Re: [PATCH 1/5] USB: ftdi_sio: fix null deref at port probe
On Thu, 2014-06-05 at 16:05 +0200, Johan Hovold wrote: Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28badce9 (USB: ftdi_sio: fix hi-speed device packet size calculation) Reported-by: Mike Remski mrem...@mutualink.net Tested-by: Mike Remski mrem...@mutualink.net Cc: sta...@vger.kernel.org # 2.3.61 [...] Or maybe 2.6.31? Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/5] USB: ftdi_sio: fix null deref at port probe
On Thu, Jun 05, 2014 at 05:13:49PM +0100, Ben Hutchings wrote: On Thu, 2014-06-05 at 16:05 +0200, Johan Hovold wrote: Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28badce9 (USB: ftdi_sio: fix hi-speed device packet size calculation) Reported-by: Mike Remski mrem...@mutualink.net Tested-by: Mike Remski mrem...@mutualink.net Cc: sta...@vger.kernel.org# 2.3.61 [...] Or maybe 2.6.31? Thanks, I'll fix that up before applying. :) Johan -- 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
Re: [PATCH 0/5] USB: ftdi_sio: wMaxPacketSize patches
On Thu, Jun 05, 2014 at 06:04:32PM +0200, Johan Hovold wrote: On Thu, Jun 05, 2014 at 08:30:42AM -0700, Greg KH wrote: On Thu, Jun 05, 2014 at 04:05:51PM +0200, Johan Hovold wrote: Some FTDI devices have broken endpoint descriptors that needs to be fixed up during probe. Mike Remski discovered that the current implementation is broken as it crashes the kernel if an interface without endpoints is probed. These patches fix this bug, while cleaning up the max-packet-size handling and removing a redundant probe quirk that fixes up mtxorb devices. Looks good, but did you forget to cc: me as well so that I know to pick these up? Or are you going to send a pull request later on with them? Yes, that was my intention. None of these are really critical and could wait for v3.17-rc1, although I'll probably send you the first for v3.16-rc2. As we discussed briefly off-list, I intend to maintain a usb-next and usb-linus branch in my USB-serial tree on kernel.org, while posting my own patches to linux-usb for review before applying them (I can still CC you as well of course). Perhaps I should start using a usb-serial: prefix to make it easier to discern what I intend to apply myself from any non-USB-serial patches I might be sending you? Or the diff-stat would be sufficient (drivers/usb/serial/*) for that? No need, I'll just know now that if I see you send patches out, and don't cc: me, I'll assume you will later be sending them to me through a git tree or somewhere else. Same as I currently do for Peter and Felipe, no problem. thanks, greg k-h -- 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
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, Jun 5, 2014 at 9:24 AM, valdis.kletni...@vt.edu wrote:
On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
On a working boot, it progresses:
Is a working boot after reverting that change, or it intermittently
works? If it's the latter I'm not sure I trust the bisect result,
yet.
Oh, it's a 100% guaranteed crash. The following is from a good kernel:
[3.823139] usb 3-4.1: New USB device found, idVendor=0e8f,
idProduct=0020
[3.823160] usb 3-4.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[3.823174] usb 3-4.1: Product: PS2toUSB Adapter
[3.823187] usb 3-4.1: Manufacturer: GASIA
[3.842836] input: GASIA PS2toUSB Adapter as
/devices/pci:00/:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:0E8F:0020.0001/input/input14
[3.848598] hid-generic 0003:0E8F:0020.0001: input,hidraw0: USB HID
v1.10 Keyboard [GASIA PS2toUSB Adapter] on usb-:00:14.0-4.1/input0
[3.863592] input: GASIA PS2toUSB Adapter as
/devices/pci:00/:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:0E8F:0020.0002/input/input15
[3.878608] hid-generic 0003:0E8F:0020.0002: input,hidraw1: USB HID
v1.10 Mouse [GASIA PS2toUSB Adapter] on usb-:00:14.0-4.1/input1
I'm booted on next-20140519
It's a really odd place to crash relative to the peer port changes
since those do not affect any xhci internals. At first glance this
also does not look related to the command queue changes. Mathias, any
ideas?
Valdis, can you get me the output of:
$ gdb drivers/usb/host/xhci-hcd.ko
(gdb) li *(xhci_add_ep_to_interval_table+0xc8)
(gdb) li *(xhci_add_ep_to_interval_table+0xc8)
0x10c9 is in xhci_add_ep_to_interval_table (drivers/usb/host/xhci.c:2446).
2441normalized_interval = ep_bw-ep_interval - 3;
2442
2443if (normalized_interval == 0)
2444bw_table-interval0_esit_payload +=
ep_bw-max_esit_payload;
2445interval_bw = bw_table-interval_bw[normalized_interval];
2446interval_bw-num_packets += ep_bw-num_packets;
2447switch (udev-speed) {
2448case USB_SPEED_LOW:
2449interval_bw-overhead[LS_OVERHEAD_TYPE] += 1;
2450break;
Note that's as of the end of the git bisect. Looks like it picked up
a duff value for interval_bw somehow, but I have no idea why.
Yeah, you're right, the bisected commit doesn't seem to have anything
to do with it. Weird. ;)
Actually, on second look I bet xhci_alloc_tt_info() is being called
while hdev-maxchild is not set. Let me throw together a debug
patch...
--
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
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said: Actually, on second look I bet xhci_alloc_tt_info() is being called while hdev-maxchild is not set. Let me throw together a debug patch... Sure, no problem - just let me know what variant of linux-next you want it applied against. :) pgp9PIoAPZAjs.pgp Description: PGP signature
Re: [PATCH v2] USB:gadget: Fix a warning while loading g_mass_storage
On Wed, 4 Jun 2014 wei.y...@windriver.com wrote: From: Yang Wei wei.y...@windriver.com While loading g_mass_storage module, the following warning is triggered. WARNING: at drivers/usb/gadget/composite.c: usb_composite_setup_continue: Unexpected call Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage [800179cc] (unwind_backtrace+0x0/0x104) from [80619608] (dump_stack+0x20/0x24) [80619608] (dump_stack+0x20/0x24) from [80025100] (warn_slowpath_common+0x64/0x74) [80025100] (warn_slowpath_common+0x64/0x74) from [800251cc] (warn_slowpath_fmt+0x40/0x48) [800251cc] (warn_slowpath_fmt+0x40/0x48) from [7f047774] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) [7f047774] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from [7f047ad4] (handle_exception+0x358/0x3e4 [g_mass_storage]) [7f047ad4] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [7f048080] (fsg_main_thread+0x520/0x157c [g_mass_storage]) [7f048080] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [8004bc90] (kthread+0x98/0x9c) [8004bc90] (kthread+0x98/0x9c) from [8000faec] (kernel_thread_exit+0x0/0x8) The root cause is that Robert once introduced the following patch to fix disconnect handling of s3c-hsotg. [ commit d18f7116a5ddb8263fe62b05ad63e5ceb5875791 Author: Robert Baldyga r.bald...@samsung.com Date: Thu Nov 21 13:49:18 2013 +0100 usb: gadget: s3c-hsotg: fix disconnect handling This patch moves s3c_hsotg_disconnect function call from USBSusp interrupt handler to SET_ADDRESS request handler. It's because disconnected state can't be detected directly, because this hardware doesn't support Disconnected interrupt for device mode. For both Suspend and Disconnect events there is one interrupt USBSusp, but calling s3c_hsotg_disconnect from this interrupt handler causes config reset in composite layer, which is not undesirable for Suspended state. For this reason s3c_hsotg_disconnect is called from SET_ADDRESS request handler, which occurs always after disconnection, so we do disconnect immediately before we are connected again. It's probably only way we can do handle disconnection correctly. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com ] So it also means that s3c_hsotg_disconnect is called from SET_ADDRESS request handler, ultimately reset_config would finally be called, it raises a FSG_STATE_CONFIG_CHANGE exception, and set common-new_fsg to NULL, and then wakes up fsg_main_thread to handle this exception. After handling SET_ADDRESS, subsequently the irq hanler of s3c-hsotg would also invokes composite_setup() function to handle USB_REQ_SET_CONFIGURATION request, set_config would be invoked, it not only raises a FSG_STATE_CONFIG_CHANGE and set common-new_fsg to new_fsg but also makes cdev-delayed_status plus one. If the execution ordering just likes the following scenario, the warning would be triggered. irq handler | |- s3c_hsotg_disconnect() | |- common-new_fsg = NULL |- common-state = FSG_STATE_CONFIG |- wakes up fsg_main_thread. |-set USB device address. fsg_main_thread | |- handle_exception | |- common-state = FSG_STATE_IDLE |- do_set_interface() irq happens -- irq handler needs to handle USB_REQ_SET_CONFIGURATION request | |- set_config() | |- common-new_fsg = new_fsg; |- common-state = FSG_STATE_CONFIG |- cdev-delayed_status++ |- wakes up fsg_main_thread fsg_main_thread | |- Now the common-state = FSG_STATE_CONFIG and common-new_fsg is not equal to NULL |- if(common-new_fsg) |- usb_composite_setup_continue() |- cdev-delayed_status-- |- fsg_main_thread still finds the common-state is equal to FSG_STATE_IDLE |- so it invokes handle_exception again, subsequently the usb_composite_setup_continue |- is executed again. It would fininally results in the warning. So we also need to define a variable(struct fsg_dev *new) and then save common-new_fsg to it with the common-lock protection. Signed-off-by: Yang Wei wei.y...@windriver.com --- drivers/usb/gadget/f_mass_storage.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Changes in v2: Only rephrase the commit log to make sense this issue. Wei diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
On Thu, 5 Jun 2014, Andrzej Pietrasiewicz wrote: I think it is easier to tell the purpose of the two structures taking gadgets composed with configfs as example. In each gadget there is functions directory. Function directories are created there: $ cd $CONFIGFS_ROOT/usb_gadget/our_gadget $ mkdir functions/mass_storage.0 mass_storage.0 is internally represented as an instance of struct usb_function_instance, which has its associated struct fsg_common (the fsg_common is a member of container_of(struct usb_function_instance)). Okay. It can be referenced from multiple configurations. $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.0 configs/config.2 Each reference (symbolic link) is internally represented as an instance of struct usb_function. The struct usb_function here has its associated struct fsg_dev (the fsg_dev is a container_of(struct usb_function)). So in essence, a usb_function connects a particular function to a particular config. By the very nature of any file system one cannot do: $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.0 configs/config.1 = -EEXIST By design of how configfs is applied to any usb gadget on cannot even do: $ ln -s functions/mass_storage.0 configs/config.1/my_mass_storage.0 $ ln -s functions/mass_storage.0 configs/config.1/the_same_mass_storage.0 = -EEXIST So for any given usb_function_instance, only one usb_function will be active at any time: the one connecting the function to the current config. And presumably the reasons why struct fsg_dev contains interface_number, bulk_in, and bulk_out members are because these values are determined when the config is originally set up, and they can vary from one config to another. Right? Whereas the items in struct fsg_common don't depend on the config. However, there should be no problem with this: $ mkdir functions/mass_storage.0 $ mkdir functions/mass_storage.1 $ ln -s functions/mass_storage.0 configs/config.1 $ ln -s functions/mass_storage.1 configs/config.1 That makes sense now. Legacy gadgets (g_mass_storage, g_acm_ms, g_multi) in fact operate in a somewhat similar manner, the difference is that instead of creating directories and making symbolic links, usb_get_function_instance() and usb_get_function() are called, respectively, and composing a gadget happens from beginning to end at module init. I hope this clarifies things a bit. Yes, it helps a lot. Thank you. Alan Stern -- 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
Re: [PATCH] usb: gadget: dummy_hcd: remove superfluous setting HC_STATE_RUNNING in dummy_start()
Hello. On 06/05/2014 07:44 PM, Pantelis Koukousoulas wrote: After commit 4814030ce11f08350b7, the core now sets Please also specify that commit's summary line in parens. hcd-state = HC_STATE_RUNNING in usb_add_hcd() before the driver's start() method is called. So, we can safely remove this line from dummy_start() since it is now superfluous. Signed-off-by: Pantelis Koukousoulas pkt...@gmail.com WBR, Sergei -- 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
Re: [PATCH] usb: gadget: dummy_hcd: remove superfluous setting HC_STATE_RUNNING in dummy_start()
On Thu, Jun 5, 2014 at 9:13 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: After commit 4814030ce11f08350b7, the core now sets Please also specify that commit's summary line in parens. Is this in order to be able to grep it more easily? I 'm asking because that summary (Initialize hcd-state roothubs) doesn't seem to add much to the rationale otherwise. I have no problem to do this of course, just asking for future reference. Cheers, Pantelis -- 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
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 2014-06-05 at 13:29 -0400, valdis.kletni...@vt.edu wrote:
On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:
Actually, on second look I bet xhci_alloc_tt_info() is being called
while hdev-maxchild is not set. Let me throw together a debug
patch...
Sure, no problem - just let me know what variant of linux-next you
want it applied against. :)
This should apply to -next. Use git am -c, but I have attached it for
convenience as well. Boots for me, but more importantly does it boot
for you :-).
8--
Subject: usb: fix -update_hub_device() vs hdev-maxchild
From: Dan Williams dan.j.willi...@intel.com
Commit d8521afe3586 usb: assign default peer ports for root hubs
delayed marking a hub valid (set hdev-maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.
However, xhci_update_hub_device() in some cases depends on
hdev-maxchild already being set. Do the minimal fix and move it after
the setting of hdev-maxchild.
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Reported-by: Valdis Kletnieks valdis.kletni...@vt.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
drivers/usb/core/hub.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..971d95745e2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1526,18 +1526,6 @@ static int hub_configure(struct usb_hub *hub,
dev_dbg(hub_dev, %umA bus power budget for each child\n,
hub-mA_per_port);
- /* Update the HCD's internal representation of this hub before khubd
-* starts getting port status changes for devices under the hub.
-*/
- if (hcd-driver-update_hub_device) {
- ret = hcd-driver-update_hub_device(hcd, hdev,
- hub-tt, GFP_KERNEL);
- if (ret 0) {
- message = can't update HCD hub info;
- goto fail;
- }
- }
-
ret = hub_hub_status(hub, hubstatus, hubchange);
if (ret 0) {
message = can't get hub status;
@@ -1593,6 +1581,18 @@ static int hub_configure(struct usb_hub *hub,
if (ret 0)
goto fail;
+ /* Update the HCD's internal representation of this hub before khubd
+* starts getting port status changes for devices under the hub.
+*/
+ if (hcd-driver-update_hub_device) {
+ ret = hcd-driver-update_hub_device(hcd, hdev,
+ hub-tt, GFP_KERNEL);
+ if (ret 0) {
+ message = can't update HCD hub info;
+ goto fail;
+ }
+ }
+
usb_hub_adjust_deviceremovable(hdev, hub-descriptor);
hub_activate(hub, HUB_INIT);
usb: fix -update_hub_device() vs hdev-maxchild
From: Dan Williams dan.j.willi...@intel.com
Commit d8521afe3586 usb: assign default peer ports for root hubs
delayed marking a hub valid (set hdev-maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.
However, xhci_update_hub_device() in some cases depends on
hdev-maxchild already being set. Do the minimal fix and move it after
the setting of hdev-maxchild.
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Reported-by: Valdis Kletnieks valdis.kletni...@vt.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
drivers/usb/core/hub.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..971d95745e2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1526,18 +1526,6 @@ static int hub_configure(struct usb_hub *hub,
dev_dbg(hub_dev, %umA bus power budget for each child\n,
hub-mA_per_port);
- /* Update the HCD's internal representation of this hub before khubd
- * starts getting port status changes for devices under the hub.
- */
- if (hcd-driver-update_hub_device) {
- ret = hcd-driver-update_hub_device(hcd, hdev,
-hub-tt, GFP_KERNEL);
- if (ret 0) {
- message = can't update HCD hub info;
- goto fail;
- }
- }
-
ret = hub_hub_status(hub, hubstatus, hubchange);
if (ret 0) {
message = can't get hub status;
@@ -1593,6 +1581,18 @@ static int hub_configure(struct usb_hub *hub,
if (ret 0)
goto fail;
+ /* Update the HCD's internal representation of this hub before khubd
+ * starts getting port status changes for devices under the hub.
+ */
+ if (hcd-driver-update_hub_device) {
+ ret = hcd-driver-update_hub_device(hcd, hdev,
+hub-tt, GFP_KERNEL);
+ if (ret 0) {
+ message = can't update HCD hub info;
+ goto fail;
+ }
+ }
+
usb_hub_adjust_deviceremovable(hdev, hub-descriptor);
hub_activate(hub, HUB_INIT);
[PATCH] HID: usbhid: remove unneeded initialization of quirks_param[]
The quirks_param array is located in the BSS, no need to explicitly
initialize it with NULL.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
drivers/hid/usbhid/hid-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 7b88f4cb99..37d2a95c5a 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -58,7 +58,7 @@ module_param_named(ignoreled, ignoreled, uint, 0644);
MODULE_PARM_DESC(ignoreled, Autosuspend with active leds);
/* Quirks specified at module load time */
-static char *quirks_param[MAX_USBHID_BOOT_QUIRKS] = { [ 0 ...
(MAX_USBHID_BOOT_QUIRKS - 1) ] = NULL };
+static char *quirks_param[MAX_USBHID_BOOT_QUIRKS];
module_param_array_named(quirks, quirks_param, charp, NULL, 0444);
MODULE_PARM_DESC(quirks, Add/modify USB HID quirks by specifying
quirks=vendorID:productID:quirks
--
1.7.10.4
--
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
Re: [PATCH] usb: gadget: dummy_hcd: remove superfluous setting HC_STATE_RUNNING in dummy_start()
Hello. On 06/05/2014 10:55 PM, Pantelis Koukousoulas wrote: After commit 4814030ce11f08350b7, the core now sets Please also specify that commit's summary line in parens. Is this in order to be able to grep it more easily? I 'm asking because It's actually the only way to uniquely identify the commit as the SHA1 IDs can coincide for the different commits. that summary (Initialize hcd-state roothubs) doesn't seem to add much to the rationale otherwise. It's anyway a lot more info about the commit's nature than just a bare SHA1 ID. Unfortunately with switching from gitweb to cgit you can't jump to a commit clicking on its SHA1 ID anymore when browsing a git repo... Cheers, Pantelis WBR, Sergei -- 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: dummy_hcd: remove superfluous setting HC_STATE_RUNNING in dummy_start()
After commit 4814030ce11f08350b7, (usb: initialize hcd-state roothubs) the core now sets hcd-state = HC_STATE_RUNNING in usb_add_hcd() before the driver's start() method is called. So, we can safely remove this line from dummy_start() since it is now superfluous. Signed-off-by: Pantelis Koukousoulas pkt...@gmail.com --- drivers/usb/gadget/dummy_hcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c index ffd5af0..3a2e649 100644 --- a/drivers/usb/gadget/dummy_hcd.c +++ b/drivers/usb/gadget/dummy_hcd.c @@ -2345,7 +2345,6 @@ static int dummy_start(struct usb_hcd *hcd) INIT_LIST_HEAD(dum_hcd-urbp_list); hcd-power_budget = POWER_BUDGET; - hcd-state = HC_STATE_RUNNING; hcd-uses_new_polling = 1; #ifdef CONFIG_USB_OTG -- 1.9.1 -- 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 0/5] randconfig build fixes for staging
Hi Greg, Here are a couple of simple fixes from my backlog of ARM randconfig bugs. Nothing urgent, they can probably all go into next for 3.17 after the merge window, but see for yourself. Arnd Arnd Bergmann (5): staging: lirc: remove sa1100 support staging/iio: IIO_SIMPLE_DUMMY_BUFFER neds IIO_BUFFER staging: sn9c102 depends on USB staging: wlags49_h2: avoid PROFILE_ALL_BRANCHES warnings staging: rtl8712, rtl8712: avoid lots of build warnings drivers/staging/iio/Kconfig| 9 +- drivers/staging/media/lirc/lirc_sir.c | 301 + drivers/staging/media/sn9c102/Kconfig | 2 +- drivers/staging/rtl8192u/ieee80211/ieee80211.h | 10 +- drivers/staging/rtl8712/ieee80211.h| 4 +- drivers/staging/wlags49_h2/wl_internal.h | 4 +- 6 files changed, 17 insertions(+), 313 deletions(-) -- 1.8.3.2 Cc: Florian Schilhabel florian.c.schilha...@googlemail.com Cc: Henk de Groot pe1...@amsat.org Cc: Jarod Wilson ja...@wilsonet.com Cc: Jonathan Cameron ji...@kernel.org Cc: Larry Finger larry.fin...@lwfinger.net Cc: Luca Risolia luca.riso...@studio.unibo.it Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: Tuomas Tynkkynen tuomas.tynkky...@iki.fi Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linux-usb@vger.kernel.org -- 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 3/5] staging: sn9c102 depends on USB
If the USB code is a loadable module, this driver cannot be built-in. This adds an explicit dependency on CONFIG_USB so that Kconfig can force sn9c102 to be a module in this case. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Luca Risolia luca.riso...@studio.unibo.it Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-me...@vger.kernel.org Cc: linux-usb@vger.kernel.org --- drivers/staging/media/sn9c102/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/sn9c102/Kconfig b/drivers/staging/media/sn9c102/Kconfig index c9aba59..10f586b 100644 --- a/drivers/staging/media/sn9c102/Kconfig +++ b/drivers/staging/media/sn9c102/Kconfig @@ -1,6 +1,6 @@ config USB_SN9C102 tristate USB SN9C1xx PC Camera Controller support (DEPRECATED) - depends on VIDEO_V4L2 MEDIA_USB_SUPPORT + depends on VIDEO_V4L2 MEDIA_USB_SUPPORT USB ---help--- This driver is DEPRECATED, please use the gspca sonixb and sonixj modules instead. -- 1.8.3.2 -- 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
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 05 Jun 2014 12:05:56 -0700, Dan Williams said: Subject: usb: fix -update_hub_device() vs hdev-maxchild From: Dan Williams dan.j.willi...@intel.com Commit d8521afe3586 usb: assign default peer ports for root hubs delayed marking a hub valid (set hdev-maxchild) until it had been fully configured and to enable the publishing of valid hubs to be serialized by usb_port_peer_mutex. However, xhci_update_hub_device() in some cases depends on hdev-maxchild already being set. Do the minimal fix and move it after the setting of hdev-maxchild. Cc: Mathias Nyman mathias.ny...@linux.intel.com Reported-by: Valdis Kletnieks valdis.kletni...@vt.edu Signed-off-by: Dan Williams dan.j.willi...@intel.com Applied cleanly, booted without complaint, the keyboard that's behind the PS2-USB converter works. uname -r reports 3.15.0-rc8-next-20140605-dirty as expected. So feel free to stick a Tested-By: on there. :) pgpHluJIkfaj6.pgp Description: PGP signature
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, Jun 5, 2014 at 2:10 PM, valdis.kletni...@vt.edu wrote: On Thu, 05 Jun 2014 12:05:56 -0700, Dan Williams said: Subject: usb: fix -update_hub_device() vs hdev-maxchild From: Dan Williams dan.j.willi...@intel.com Commit d8521afe3586 usb: assign default peer ports for root hubs delayed marking a hub valid (set hdev-maxchild) until it had been fully configured and to enable the publishing of valid hubs to be serialized by usb_port_peer_mutex. However, xhci_update_hub_device() in some cases depends on hdev-maxchild already being set. Do the minimal fix and move it after the setting of hdev-maxchild. Cc: Mathias Nyman mathias.ny...@linux.intel.com Reported-by: Valdis Kletnieks valdis.kletni...@vt.edu Signed-off-by: Dan Williams dan.j.willi...@intel.com Applied cleanly, booted without complaint, the keyboard that's behind the PS2-USB converter works. uname -r reports 3.15.0-rc8-next-20140605-dirty as expected. So feel free to stick a Tested-By: on there. :) Thank you, much appreciated! -- 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
[boot regression PATCH] usb: fix -update_hub_device() vs hdev-maxchild
Commit d8521afe3586 usb: assign default peer ports for root hubs
delayed marking a hub valid (set hdev-maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.
However, xhci_update_hub_device() in some cases depends on
hdev-maxchild already being set. Do the minimal fix and move it after
the setting of hdev-maxchild.
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Reported-by: Valdis Kletnieks valdis.kletni...@vt.edu
Tested-by: Valdis Kletnieks valdis.kletni...@vt.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
For 3.16-rc1
drivers/usb/core/hub.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..971d95745e2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1526,18 +1526,6 @@ static int hub_configure(struct usb_hub *hub,
dev_dbg(hub_dev, %umA bus power budget for each child\n,
hub-mA_per_port);
- /* Update the HCD's internal representation of this hub before khubd
-* starts getting port status changes for devices under the hub.
-*/
- if (hcd-driver-update_hub_device) {
- ret = hcd-driver-update_hub_device(hcd, hdev,
- hub-tt, GFP_KERNEL);
- if (ret 0) {
- message = can't update HCD hub info;
- goto fail;
- }
- }
-
ret = hub_hub_status(hub, hubstatus, hubchange);
if (ret 0) {
message = can't get hub status;
@@ -1593,6 +1581,18 @@ static int hub_configure(struct usb_hub *hub,
if (ret 0)
goto fail;
+ /* Update the HCD's internal representation of this hub before khubd
+* starts getting port status changes for devices under the hub.
+*/
+ if (hcd-driver-update_hub_device) {
+ ret = hcd-driver-update_hub_device(hcd, hdev,
+ hub-tt, GFP_KERNEL);
+ if (ret 0) {
+ message = can't update HCD hub info;
+ goto fail;
+ }
+ }
+
usb_hub_adjust_deviceremovable(hdev, hub-descriptor);
hub_activate(hub, HUB_INIT);
--
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
Re: [PATCH 07/10] xhci: Use command structures when queuing commands on the command ring
Hi Mathias, hit a small issue playing with -next:
On Thu, May 8, 2014 at 9:26 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
To create a global command queue we require that each command put on the
command ring is submitted with a command structure.
Functions that queue commands and wait for completion need to allocate a
command
before submitting it, and free it once completed. The following command
queuing
functions need to be modified.
xhci_configure_endpoint()
xhci_address_device()
xhci_queue_slot_control()
xhci_queue_stop_endpoint()
xhci_queue_new_dequeue_state()
xhci_queue_reset_ep()
xhci_configure_endpoint()
xhci_configure_endpoint() could already be called with a command structure,
and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These
are changed and a command structure is now required. This change also
simplifies
the configure endpoint command completion handling and the goto
bandwidth_change
handling code can be removed.
In some cases the command queuing function is called in interrupt context.
These commands needs to be allocated atomically, and they can't wait for
completion. These commands will in this patch be freed directly after queuing,
but freeing will be moved to the command completion event handler in a later
patch once we get the global command queue up.(Just so that we won't leak
memory in the middle of the patch set)
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 21 +++--
drivers/usb/host/xhci-ring.c | 107 +---
drivers/usb/host/xhci.c | 194
---
drivers/usb/host/xhci.h | 31 +++
4 files changed, 216 insertions(+), 137 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1ad6bc1..3ce9c0a 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,7 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/gfp.h
+
+#include linux/slab.h
#include asm/unaligned.h
#include xhci.h
@@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_lock_irqsave(xhci-lock, flags);
for (i = LAST_EP_INDEX; i 0; i--) {
- if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue)
- xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
+ if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue) {
+ struct xhci_command *command;
+ command = xhci_alloc_command(xhci, false, false,
+GFP_NOIO);
...this needs to be GFP_NOWAIT, or move it outside the lock.
--
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
