Re: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
Hi, On Wed, Jan 14, 2015 at 11:04:27PM +, Paul Zimmerman wrote: > > > > > > > > > > This is really, really odd. Register accesses are atomic, > > > > > > > > > > so the lock > > > > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so > > > > > > > > > > IRQs are > > > > > > > > > > already disabled. > > > > > > > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, > > > > > > > > > here the > > > > > > > > > lock prevents the register access from happening while some > > > > > > > > > other CPU > > > > > > > > > is holding the lock. If a silicon quirk causes the register > > > > > > > > > access to > > > > > > > > > interfere with other activities, this could be important. > > > > > > > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a > > > > > > > > memory > > > > > > > > barrier to the register accesses, that should force all register > > > > > > > > accesses the be correctly ordered. > > > > > > > > > > > > > > Memory barriers will order accesses that are all made on the same > > > > > > > CPU > > > > > > > with respect to each other. They do not order these accesses > > > > > > > against > > > > > > > accesses made from another CPU -- that's why we have spinlocks. > > > > > > > :-) > > > > > > > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > > > > matter either :-) > > > > > > > > > > > > > > I fail to see how a silicon quirk > > > > > > > > could cause this and if, indeed, it does, I'd be more > > > > > > > > comfortable with a > > > > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > > > > > > > Maybe accessing this register somehow resets something else. I > > > > > > > don't > > > > > > > know. It seems unlikely, but at least it explains how adding a > > > > > > > spinlock could fix the problem. > > > > > > > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > > > > somehow. Maybe it has something to do with how the register is > > > > > > implemented, dunno. > > > > > > > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > > > > some weird state if we read GSNPSID at random locations or when > > > > > > data is > > > > > > being transferred, or anything like that ? > > > > > > > > > > Only thing I can think of is that there is some silicon bug in > > > > > Robert's > > > > > platform. But I am not aware of any STARs that mention accesses to the > > > > > GSNPSID register as being problematic. > > > > > > > > > > Funny thing is, this code has been basically the same since at least > > > > > November 2013. So I think some other recent change must have modified > > > > > the timing of the register accesses, or something like that. But > > > > > that's > > > > > just handwaving, really. > > > > > > > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > > > > already sent my last pull request to Greg. Unless someone has a really > > > > big complaint about doing things as such. > > > > > > It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform > > > is broken without it, IIUC. > > > > It can also be categorized as "has-never-worked-before" before the code > > has been like this forever. Since we don't really have a git bisect > > result pointing to a commit that went in v3.19 merge window, I'm not > > sure how I can convince myself that this absolutely needs to be in > > v3.19. > > > > At a minimum, I need a proper bisection with a proper commit being > > blamed (even if it's a commit from months ago). From my point of view, > > debugging of this "regression" has not been finalized and we're just > > "assuming" it's caused by GSNPSID because moving that inside the > > spin_lock seems to fix the problem. > > On further investigation, I was wrong about "this code has been > basically the same since at least November 2013". Prior to commit > db8178c33db "usb: dwc2: Update common interrupt handler to call gadget > interrupt handler" from November 2014, the gadget interrupt handler > did not read from the GSNPSID register. right, but the common IRQ always did. So unless Robert's SoC has always been used only for peripheral, then I agree with you that behavior did, in fact, change. > So likely the bug in Robert's hardware has been there all along, and > that commit just caused it to manifest itself. Robert, out of curiosity, which SoC are you using ? Is it UP or SMP ? I guess we need a mention on commit log that at least SoC XYZ is known to break unless the register access is done with locks held. -- balbi signature.asc Description: Digital signature
Re: [PATCH] uwb: Fix for coding style errors in address.c
On Thu, Jan 15, 2015 at 09:30:32AM +0530, Asheesh Ranjan wrote: > Fixes for many warnings and errors as reported by checkpatch.pl what warnings and errors? If there are different types of things being fixed, then they need to be in different patches, one per thing you are doing. Please fix up and resend. 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
[PATCH] uwb: Fix for coding style errors in address.c
Fixes for many warnings and errors as reported by checkpatch.pl
Signed-off-by: Asheesh Ranjan
---
drivers/uwb/address.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/uwb/address.c b/drivers/uwb/address.c
index 8739c4f..9a45ffd 100644
--- a/drivers/uwb/address.c
+++ b/drivers/uwb/address.c
@@ -46,7 +46,7 @@ struct uwb_rc_cmd_dev_addr_mgmt {
*
* @hwarc: HWA Radio Control interface instance
* @bmOperationType:
- * Set/get, MAC/DEV (see WUSB1.0[8.6.2.2])
+ * Set/get, MAC/DEV (see WUSB1.0[8.6.2.2])
* @baAddr:address buffer--assumed to have enough data to hold
* the address type requested.
* @reply: Pointer to reply buffer (can be stack allocated)
@@ -72,10 +72,16 @@ int uwb_rc_dev_addr_mgmt(struct uwb_rc *rc,
cmd->bmOperationType = bmOperationType;
if (baAddr) {
size_t size = 0;
+
switch (bmOperationType >> 1) {
- case 0: size = 2; break;
- case 1: size = 6; break;
- default: BUG();
+ case 0:
+ size = 2;
+ break;
+ case 1:
+ size = 6;
+ break;
+ default:
+ BUG();
}
memcpy(cmd->baAddr, baAddr, size);
}
@@ -125,7 +131,7 @@ static int uwb_rc_addr_set(struct uwb_rc *rc,
const void *_addr, enum uwb_addr_type type)
{
int result;
- u8 bmOperationType = 0x1; /* Set address */
+ u8 bmOperationType = 0x1; /* Set address */
const struct uwb_dev_addr *dev_addr = _addr;
const struct uwb_mac_addr *mac_addr = _addr;
struct uwb_rc_evt_dev_addr_mgmt reply;
@@ -163,7 +169,7 @@ static int uwb_rc_addr_get(struct uwb_rc *rc,
void *_addr, enum uwb_addr_type type)
{
int result;
- u8 bmOperationType = 0x0; /* Get address */
+ u8 bmOperationType = 0x0; /* Get address */
struct uwb_rc_evt_dev_addr_mgmt evt;
struct uwb_dev_addr *dev_addr = _addr;
struct uwb_mac_addr *mac_addr = _addr;
@@ -220,6 +226,7 @@ int uwb_rc_mac_addr_set(struct uwb_rc *rc,
const struct uwb_mac_addr *addr)
{
int result = -EINVAL;
+
mutex_lock(&rc->uwb_dev.mutex);
result = uwb_rc_addr_set(rc, addr, UWB_ADDR_MAC);
mutex_unlock(&rc->uwb_dev.mutex);
@@ -232,6 +239,7 @@ int uwb_rc_dev_addr_set(struct uwb_rc *rc,
const struct uwb_dev_addr *addr)
{
int result = -EINVAL;
+
mutex_lock(&rc->uwb_dev.mutex);
result = uwb_rc_addr_set(rc, addr, UWB_ADDR_DEV);
rc->uwb_dev.dev_addr = *addr;
@@ -255,6 +263,7 @@ int __uwb_dev_addr_assigned_check(struct device *dev, void
*_addr)
{
struct uwb_dev *uwb_dev = to_uwb_dev(dev);
struct uwb_dev_addr *addr = _addr;
+
if (!uwb_dev_addr_cmp(addr, &uwb_dev->dev_addr))
return !0;
return 0;
@@ -362,6 +371,7 @@ size_t __uwb_addr_print(char *buf, size_t buf_size, const
unsigned char *addr,
int type)
{
size_t result;
+
if (type)
result = scnprintf(buf, buf_size, "%pM", addr);
else
--
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
[PATCH] usb: Fix typo in `struct usb_host_interface' comment
The descriptor member `bNumEndpoints' is plural.
Signed-off-by: Chris Rorvick
---
include/linux/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index f89c24a..4add566 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -82,7 +82,7 @@ struct usb_host_interface {
int extralen;
unsigned char *extra; /* Extra descriptors */
- /* array of desc.bNumEndpoint endpoints associated with this
+ /* array of desc.bNumEndpoints endpoints associated with this
* interface setting. these will be in no particular order.
*/
struct usb_host_endpoint *endpoint;
--
2.1.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
[PATCH] usb: phy: make GPIOs optional for the generic phy
>From 47bd18e210fecf701d493c27884e13c69bc449ea Mon Sep 17 00:00:00 2001
From: Paul Zimmerman
Date: Wed, 14 Jan 2015 18:15:58 -0800
Subject: [PATCH] usb: phy: make GPIOs optional for the generic phy
The use of GPIOs should be optional for the generic phy, otherwise
the Altera SOCFPGA platform at least is broken.
Fixes breakage caused by a combination of e9f2cefb0cd "usb: phy:
generic: migrate to gpio_desc" and 135b3c4304d "usb: dwc2: platform:
add generic PHY framework support".
Signed-off-by: Paul Zimmerman
---
Based on top of testing/next.
drivers/usb/phy/phy-generic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index dd05254..9a826ff 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -218,10 +218,10 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
+ nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset-gpios");
err = PTR_ERR(nop->gpiod_reset);
if (!err) {
- nop->gpiod_vbus = devm_gpiod_get(dev,
+ nop->gpiod_vbus = devm_gpiod_get_optional(dev,
"vbus-detect-gpio");
err = PTR_ERR(nop->gpiod_vbus);
}
--
1.7.6.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 6/6] usb: gadget: uvc: cleanup UVCG_FRAME_ATTR macro
1) Change "conv" an "vnoc" to "to_cpu_endian" to "to_little_endian".
2) No need to check the "limit" because that is already handled in
kstrtoXX so delete that parameter along with the check.
3) By using a "bits" parameter, we can combine the "uxx" parameter and
the "str2u" parameters.
4) The kstrtou##bits() conversion does not need to be done under the
mutex so move it to the start of the function.
5) Change the name of "identity_conv" to "noop_conversion".
Signed-off-by: Dan Carpenter
---
This file has a couple pages of Sparse endian warnings.
http://lwn.net/Articles/205624/
It's hard to review the static checker warnings when there are so many.
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index a0443a2..87beb8c 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -1032,7 +1032,7 @@ static struct configfs_item_operations
uvcg_frame_item_ops = {
.store_attribute= uvcg_frame_attr_store,
};
-#define UVCG_FRAME_ATTR(cname, aname, conv, str2u, uxx, vnoc, limit) \
+#define UVCG_FRAME_ATTR(cname, aname, to_cpu_endian, to_little_endian, bits) \
static ssize_t uvcg_frame_##cname##_show(struct uvcg_frame *f, char *page)\
{ \
struct f_uvc_opts *opts;\
@@ -1046,7 +1046,7 @@ static ssize_t uvcg_frame_##cname##_show(struct
uvcg_frame *f, char *page)\
opts = to_f_uvc_opts(opts_item);\
\
mutex_lock(&opts->lock);\
- result = sprintf(page, "%d\n", conv(f->frame.cname)); \
+ result = sprintf(page, "%d\n", to_cpu_endian(f->frame.cname)); \
mutex_unlock(&opts->lock); \
\
mutex_unlock(su_mutex); \
@@ -1061,7 +1061,11 @@ static ssize_t uvcg_frame_##cname##_store(struct
uvcg_frame *f, \
struct uvcg_format *fmt;\
struct mutex *su_mutex = &f->item.ci_group->cg_subsys->su_mutex;\
int ret;\
- uxx num;\
+ u##bits num;\
+ \
+ ret = kstrtou##bits(page, 0, &num); \
+ if (ret)\
+ return ret; \
\
mutex_lock(su_mutex); /* for navigating configfs hierarchy */ \
\
@@ -1075,15 +1079,7 @@ static ssize_t uvcg_frame_##cname##_store(struct
uvcg_frame *f, \
goto end; \
} \
\
- ret = str2u(page, 0, &num); \
- if (ret)\
- goto end; \
- \
- if (num > limit) { \
- ret = -EINVAL; \
- goto end; \
- } \
- f->frame.cname = vnoc(num); \
+ f->frame.cname = to_little_endian(num); \
ret = len; \
end: \
mutex_unlock(&opts->lock); \
@@ -1097,24 +1093,20 @@ static struct uvcg_frame_attribute
\
uvcg_frame_##cname##_show, \
uvcg_frame_##cname##_store)
-#define identity_conv(x) (x)
+#define noop_conversion(x) (x)
-UVCG_FRAME_ATTR(bm_capabilities, bmCapabilities, identity_conv, kstrtou8, u8,
- identity_conv, 0xFF);
-UVCG_FRAME_ATTR(w_width, wWidth, le16_to_cpu, kstrtou16, u16, cpu_to_le16,
- 0x);
-UVCG_FRAME_ATTR(w_height, wHeight, le16_to_cpu, kstrtou16, u16, cpu_to_le16,
- 0x);
-UVCG_FRAME_ATTR
Re: [PATCH v2 2/3] usb: phy: add lubbock phy driver
Hello, 2015-01-13 9:10 GMT+03:00 Kishon Vijay Abraham I : > Hi, > > On Tuesday 13 January 2015 03:21 AM, Felipe Balbi wrote: >> On Sun, Jan 11, 2015 at 10:44:59PM +0400, Dmitry Eremin-Solenikov wrote: >>> Hello, >>> >>> 2015-01-08 19:58 GMT+03:00 Felipe Balbi : On Sun, Nov 30, 2014 at 01:02:04AM +0300, Dmitry Eremin-Solenikov wrote: > Extract lubbock-specific code from pxa25x_udc driver. As a bonus, phy > driver determines connector/VBUS status by reading CPLD register. Also > it uses a work to call into udc stack, instead of pinging vbus session > right from irq handler. > > Signed-off-by: Dmitry Eremin-Solenikov > --- > drivers/usb/phy/Kconfig | 10 ++ > drivers/usb/phy/Makefile | 1 + new phy drivers under drivers/phy only, sorry. >>> >>> Hmm. How do drivers/phy drivers coordinate with usb gadget subsystem? >>> I see none of them calling usb_gadget_vbus_connect/disconnect(). >> >> I'll leave that to Kishon, since he wrote drivers/phy. Kishon, any >> hints? > > Extcon framework can be used to detect the connector status. So the PHY driver > should register with the extcon framework if it has the capability to > determine > the connector status and the gadget driver should register with the extcon > framework if it has to receive the connector status. If I understand correctly, this means the whole usb gadget/otg subsystem needs to be redesigned/refactored to support extconn drivers. Is it planned already? Can we still submit drivers to an old usb-phy subsystem as 'new phy' subsystem does not provide us necessary integration with usb-gadget subsystem? > > I'm not sure if we should be adding these extcon APIs inside the PHY framework > itself as all PHYs might not have the capability to detect the connector > status. In fact I have several devices for which I had to implement a simple usb-phy that is able to control D+ pullup, but isn't able to detect VBUS presense and thus has to assume that the device is always connected. -- With best wishes Dmitry -- 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: BUG: xhci_queue_new_dequeue_state dereference a NULL pointer
Thanks Mathias. I read the patch, it fixes my problem. 2015-01-14 19:19 GMT+08:00 Mathias Nyman : > Hi > > On 14.01.2015 08:04, c-aries wrote: >> I have an x86 PC, it oops, and I took a screenshot: >> http://babyaries.org/mirror/picture/2015-01-13-165845_1600x900_scrot.png >> >> >> Then I browsed the xhci source code, compared with the oops machine code: >> http://babyaries.org/mirror/picture/2015-01-14-113248_1600x900_scrot.png >> >> I found that it's because deq_state->new_deq_seg is an invalid pointer >> that makes my PC oops. >> -- > > From the logs it looks like you're using a 3.13 kernel. > There were some major changes in 3.17 regarding finding the new dequeue > pointer > (e.g. new_deq_seg and new_deq_ptr) in: > > commit 365038d83313951d6ace15342eb24624bbef1666 > xhci: rework cycle bit checking for new dequeue pointers > > It sets the new deq_seg and deq_ptr to NULL if the new state can't be found, > also > adds checks for those pointers before calling xhci_queue_new_dequeue_state() > > Have you seen this with a 3.17 or later kernel? > > -Mathias > > -- Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. = = I'm a GNU C Programmer, Happy Hacking! -- 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: [GIT PULL] USB patches
On Wed, Jan 14, 2015 at 11:48:39AM -0600, Felipe Balbi wrote: > Hi Greg, > > Alright, 3 more fixes for v3.19-rc and my queue is finally clean. > > All three fixes are rather obvious, two of them just took longer > to sort out all the stable rules details and I ended up having > to fix all that, otherwise we would miss the time frame. > > Please condiser merging to your greg/usb-linus branch. > > cheers > > The following changes since commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5: > > usb: gadget: udc: atmel: fix possible oops when unloading module > (2015-01-09 18:15:11 -0600) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v3.19-rc6 Pulled and pushed out, 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: USB-serial fixes for v3.19-rc5
On Wed, Jan 14, 2015 at 09:49:56AM +0100, Johan Hovold wrote: > Hi Greg, > > Here's my first set of fixes for 3.19, somewhat late partially due to the > holidays. > > Please pull. > > Thanks, > Johan > > > The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6: > > Linux 3.19-rc2 (2014-12-28 16:49:37 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-3.19-rc5 Pulled and pushed out, you aren't going to get the automated emails due to you basing your tree on -rc2, but my tree on -rc1, not a big deal at all. 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: Fatal Exception on device when Hotsyncing Palm in linux
On Thu, Jan 15, 2015 at 12:00:28AM +0100, Henri Manson wrote: > I own a Palm m505 and a while ago a developed programs using SuperWaba > and uploaded them using pilot-xfer. Using Ubuntu 14.04 I tried > Hotsyncing on the device but now the devices shows a dialog box > containing 'Fatal Exception' and then hangs. > I figured out using VirtualBox and old Ubuntu ISO images that > hotsyncing goes well in Ubuntu 9.04 and fatal exceptions start > occurring as early as Ubuntu 10.04. > > Being a developer myself, what can I do to resolve this bug, e.g. how > do I turn on usb_serial_debug_data? That really sounds like a userspace application is crashing, is there any kernel log message when this happens? As for turning on debugging, take a look at the file in the kernel: Documentation/dynamic-debug-howto.txt for how to turn on debugging on the fly, when the module is loaded. Hope this helps, 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: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
> From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, January 14, 2015 2:50 PM > > On Wed, Jan 14, 2015 at 10:45:26PM +, Paul Zimmerman wrote: > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Wednesday, January 14, 2015 2:40 PM > > > > > > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote: > > > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > > > Sent: Wednesday, January 14, 2015 1:46 PM > > > > > > > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > > > > > This is really, really odd. Register accesses are atomic, so > > > > > > > > > the lock > > > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so > > > > > > > > > IRQs are > > > > > > > > > already disabled. > > > > > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, here > > > > > > > > the > > > > > > > > lock prevents the register access from happening while some > > > > > > > > other CPU > > > > > > > > is holding the lock. If a silicon quirk causes the register > > > > > > > > access to > > > > > > > > interfere with other activities, this could be important. > > > > > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a > > > > > > > memory > > > > > > > barrier to the register accesses, that should force all register > > > > > > > accesses the be correctly ordered. > > > > > > > > > > > > Memory barriers will order accesses that are all made on the same > > > > > > CPU > > > > > > with respect to each other. They do not order these accesses > > > > > > against > > > > > > accesses made from another CPU -- that's why we have spinlocks. :-) > > > > > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > > > matter either :-) > > > > > > > > > > > > I fail to see how a silicon quirk > > > > > > > could cause this and if, indeed, it does, I'd be more comfortable > > > > > > > with a > > > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > > > > > Maybe accessing this register somehow resets something else. I > > > > > > don't > > > > > > know. It seems unlikely, but at least it explains how adding a > > > > > > spinlock could fix the problem. > > > > > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > > > somehow. Maybe it has something to do with how the register is > > > > > implemented, dunno. > > > > > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > > > some weird state if we read GSNPSID at random locations or when data > > > > > is > > > > > being transferred, or anything like that ? > > > > > > > > Only thing I can think of is that there is some silicon bug in Robert's > > > > platform. But I am not aware of any STARs that mention accesses to the > > > > GSNPSID register as being problematic. > > > > > > > > Funny thing is, this code has been basically the same since at least > > > > November 2013. So I think some other recent change must have modified > > > > the timing of the register accesses, or something like that. But that's > > > > just handwaving, really. > > > > > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > > > already sent my last pull request to Greg. Unless someone has a really > > > big complaint about doing things as such. > > > > It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform > > is broken without it, IIUC. > > It can also be categorized as "has-never-worked-before" before the code > has been like this forever. Since we don't really have a git bisect > result pointing to a commit that went in v3.19 merge window, I'm not > sure how I can convince myself that this absolutely needs to be in > v3.19. > > At a minimum, I need a proper bisection with a proper commit being > blamed (even if it's a commit from months ago). From my point of view, > debugging of this "regression" has not been finalized and we're just > "assuming" it's caused by GSNPSID because moving that inside the > spin_lock seems to fix the problem. On further investigation, I was wrong about "this code has been basically the same since at least November 2013". Prior to commit db8178c33db "usb: dwc2: Update common interrupt handler to call gadget interrupt handler" from November 2014, the gadget interrupt handler did not read from the GSNPSID register. So likely the bug in Robert's hardware has been there all along, and that commit just caused it to manifest itself. -- Paul -- 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
Fatal Exception on device when Hotsyncing Palm in linux
I own a Palm m505 and a while ago a developed programs using SuperWaba and uploaded them using pilot-xfer. Using Ubuntu 14.04 I tried Hotsyncing on the device but now the devices shows a dialog box containing 'Fatal Exception' and then hangs. I figured out using VirtualBox and old Ubuntu ISO images that hotsyncing goes well in Ubuntu 9.04 and fatal exceptions start occurring as early as Ubuntu 10.04. Being a developer myself, what can I do to resolve this bug, e.g. how do I turn on usb_serial_debug_data? Hope to hear from you, Henri Manson -- 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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
Hi, On Wed, Jan 14, 2015 at 10:45:26PM +, Paul Zimmerman wrote: > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Wednesday, January 14, 2015 2:40 PM > > > > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote: > > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > > Sent: Wednesday, January 14, 2015 1:46 PM > > > > > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > > > > This is really, really odd. Register accesses are atomic, so > > > > > > > > the lock > > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs > > > > > > > > are > > > > > > > > already disabled. > > > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, here > > > > > > > the > > > > > > > lock prevents the register access from happening while some other > > > > > > > CPU > > > > > > > is holding the lock. If a silicon quirk causes the register > > > > > > > access to > > > > > > > interfere with other activities, this could be important. > > > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > > > > > barrier to the register accesses, that should force all register > > > > > > accesses the be correctly ordered. > > > > > > > > > > Memory barriers will order accesses that are all made on the same CPU > > > > > with respect to each other. They do not order these accesses against > > > > > accesses made from another CPU -- that's why we have spinlocks. :-) > > > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > > matter either :-) > > > > > > > > > > I fail to see how a silicon quirk > > > > > > could cause this and if, indeed, it does, I'd be more comfortable > > > > > > with a > > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > > > Maybe accessing this register somehow resets something else. I don't > > > > > know. It seems unlikely, but at least it explains how adding a > > > > > spinlock could fix the problem. > > > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > > somehow. Maybe it has something to do with how the register is > > > > implemented, dunno. > > > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > > some weird state if we read GSNPSID at random locations or when data is > > > > being transferred, or anything like that ? > > > > > > Only thing I can think of is that there is some silicon bug in Robert's > > > platform. But I am not aware of any STARs that mention accesses to the > > > GSNPSID register as being problematic. > > > > > > Funny thing is, this code has been basically the same since at least > > > November 2013. So I think some other recent change must have modified > > > the timing of the register accesses, or something like that. But that's > > > just handwaving, really. > > > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > > already sent my last pull request to Greg. Unless someone has a really > > big complaint about doing things as such. > > It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform > is broken without it, IIUC. It can also be categorized as "has-never-worked-before" before the code has been like this forever. Since we don't really have a git bisect result pointing to a commit that went in v3.19 merge window, I'm not sure how I can convince myself that this absolutely needs to be in v3.19. At a minimum, I need a proper bisection with a proper commit being blamed (even if it's a commit from months ago). From my point of view, debugging of this "regression" has not been finalized and we're just "assuming" it's caused by GSNPSID because moving that inside the spin_lock seems to fix the problem. -- balbi signature.asc Description: Digital signature
RE: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
> From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, January 14, 2015 2:40 PM > > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote: > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Wednesday, January 14, 2015 1:46 PM > > > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > > > This is really, really odd. Register accesses are atomic, so the > > > > > > > lock > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs > > > > > > > are > > > > > > > already disabled. > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, here the > > > > > > lock prevents the register access from happening while some other > > > > > > CPU > > > > > > is holding the lock. If a silicon quirk causes the register access > > > > > > to > > > > > > interfere with other activities, this could be important. > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > > > > barrier to the register accesses, that should force all register > > > > > accesses the be correctly ordered. > > > > > > > > Memory barriers will order accesses that are all made on the same CPU > > > > with respect to each other. They do not order these accesses against > > > > accesses made from another CPU -- that's why we have spinlocks. :-) > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > matter either :-) > > > > > > > > I fail to see how a silicon quirk > > > > > could cause this and if, indeed, it does, I'd be more comfortable > > > > > with a > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > Maybe accessing this register somehow resets something else. I don't > > > > know. It seems unlikely, but at least it explains how adding a > > > > spinlock could fix the problem. > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > somehow. Maybe it has something to do with how the register is > > > implemented, dunno. > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > some weird state if we read GSNPSID at random locations or when data is > > > being transferred, or anything like that ? > > > > Only thing I can think of is that there is some silicon bug in Robert's > > platform. But I am not aware of any STARs that mention accesses to the > > GSNPSID register as being problematic. > > > > Funny thing is, this code has been basically the same since at least > > November 2013. So I think some other recent change must have modified > > the timing of the register accesses, or something like that. But that's > > just handwaving, really. > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > already sent my last pull request to Greg. Unless someone has a really > big complaint about doing things as such. It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform is broken without it, IIUC. -- Paul -- 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 5/6] usb: gadget: uvc: make a bunch of stuff static
On Thu, Jan 15, 2015 at 12:03:52AM +0300, Dan Carpenter wrote: > Sparse rightly complains that these things should be static since they > are only used in the one .c file. > > Signed-off-by: Dan Carpenter fails to apply on top of my testing/next checking file drivers/usb/gadget/function/uvc_configfs.c Hunk #1 FAILED at 43. Hunk #2 FAILED at 135. Hunk #3 FAILED at 161. Hunk #4 FAILED at 718. Hunk #5 FAILED at 795. Hunk #6 FAILED at 947. Hunk #7 FAILED at 973. Hunk #8 FAILED at 1017. Hunk #9 FAILED at 1260. Hunk #10 FAILED at 1311. Hunk #11 FAILED at 1334. Hunk #12 FAILED at 1544. Hunk #13 FAILED at 1582. Hunk #14 FAILED at 1606. Hunk #15 FAILED at 1757. Hunk #16 FAILED at 1789. 16 out of 16 hunks FAILED please rebase on that branch. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
On Wed, Jan 14, 2015 at 04:39:41PM -0600, Felipe Balbi wrote: > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote: > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Wednesday, January 14, 2015 1:46 PM > > > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > > > This is really, really odd. Register accesses are atomic, so the > > > > > > > lock > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs > > > > > > > are > > > > > > > already disabled. > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, here the > > > > > > lock prevents the register access from happening while some other > > > > > > CPU > > > > > > is holding the lock. If a silicon quirk causes the register access > > > > > > to > > > > > > interfere with other activities, this could be important. > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > > > > barrier to the register accesses, that should force all register > > > > > accesses the be correctly ordered. > > > > > > > > Memory barriers will order accesses that are all made on the same CPU > > > > with respect to each other. They do not order these accesses against > > > > accesses made from another CPU -- that's why we have spinlocks. :-) > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > matter either :-) > > > > > > > > I fail to see how a silicon quirk > > > > > could cause this and if, indeed, it does, I'd be more comfortable > > > > > with a > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > Maybe accessing this register somehow resets something else. I don't > > > > know. It seems unlikely, but at least it explains how adding a > > > > spinlock could fix the problem. > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > somehow. Maybe it has something to do with how the register is > > > implemented, dunno. > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > some weird state if we read GSNPSID at random locations or when data is > > > being transferred, or anything like that ? > > > > Only thing I can think of is that there is some silicon bug in Robert's > > platform. But I am not aware of any STARs that mention accesses to the > > GSNPSID register as being problematic. > > > > Funny thing is, this code has been basically the same since at least > > November 2013. So I think some other recent change must have modified > > the timing of the register accesses, or something like that. But that's > > just handwaving, really. > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > already sent my last pull request to Greg. Unless someone has a really > big complaint about doing things as such. But of course, I need a better changelog :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote: > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Wednesday, January 14, 2015 1:46 PM > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > > This is really, really odd. Register accesses are atomic, so the > > > > > > lock > > > > > > isn't really doing anything. Besides, you're calling > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are > > > > > > already disabled. > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, here the > > > > > lock prevents the register access from happening while some other CPU > > > > > is holding the lock. If a silicon quirk causes the register access to > > > > > interfere with other activities, this could be important. > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > > > barrier to the register accesses, that should force all register > > > > accesses the be correctly ordered. > > > > > > Memory barriers will order accesses that are all made on the same CPU > > > with respect to each other. They do not order these accesses against > > > accesses made from another CPU -- that's why we have spinlocks. :-) > > > > a fair point :-) The register is still read-only, so that shouldn't > > matter either :-) > > > > > > I fail to see how a silicon quirk > > > > could cause this and if, indeed, it does, I'd be more comfortable with a > > > > proper STARS tickect number from synopsys :-s > > > > > > Maybe accessing this register somehow resets something else. I don't > > > know. It seems unlikely, but at least it explains how adding a > > > spinlock could fix the problem. > > > > I would really need Paul (or someone at Synopsys) to confirm this > > somehow. Maybe it has something to do with how the register is > > implemented, dunno. > > > > Paul, do you have any idea what could cause this ? Could the HW into > > some weird state if we read GSNPSID at random locations or when data is > > being transferred, or anything like that ? > > Only thing I can think of is that there is some silicon bug in Robert's > platform. But I am not aware of any STARs that mention accesses to the > GSNPSID register as being problematic. > > Funny thing is, this code has been basically the same since at least > November 2013. So I think some other recent change must have modified > the timing of the register accesses, or something like that. But that's > just handwaving, really. Alright, I'll apply this patch but for 3.20 with a stable tag as I have already sent my last pull request to Greg. Unless someone has a really big complaint about doing things as such. -- balbi signature.asc Description: Digital signature
RE: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
> From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, January 14, 2015 1:46 PM > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > > This is really, really odd. Register accesses are atomic, so the lock > > > > > isn't really doing anything. Besides, you're calling > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are > > > > > already disabled. > > > > > > > > Spinlocks sometimes do more than you think. For instance, here the > > > > lock prevents the register access from happening while some other CPU > > > > is holding the lock. If a silicon quirk causes the register access to > > > > interfere with other activities, this could be important. > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > > barrier to the register accesses, that should force all register > > > accesses the be correctly ordered. > > > > Memory barriers will order accesses that are all made on the same CPU > > with respect to each other. They do not order these accesses against > > accesses made from another CPU -- that's why we have spinlocks. :-) > > a fair point :-) The register is still read-only, so that shouldn't > matter either :-) > > > > I fail to see how a silicon quirk > > > could cause this and if, indeed, it does, I'd be more comfortable with a > > > proper STARS tickect number from synopsys :-s > > > > Maybe accessing this register somehow resets something else. I don't > > know. It seems unlikely, but at least it explains how adding a > > spinlock could fix the problem. > > I would really need Paul (or someone at Synopsys) to confirm this > somehow. Maybe it has something to do with how the register is > implemented, dunno. > > Paul, do you have any idea what could cause this ? Could the HW into > some weird state if we read GSNPSID at random locations or when data is > being transferred, or anything like that ? Only thing I can think of is that there is some silicon bug in Robert's platform. But I am not aware of any STARs that mention accesses to the GSNPSID register as being problematic. Funny thing is, this code has been basically the same since at least November 2013. So I think some other recent change must have modified the timing of the register accesses, or something like that. But that's just handwaving, really. -- Paul -- 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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
Hi, On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote: > > > > This is really, really odd. Register accesses are atomic, so the lock > > > > isn't really doing anything. Besides, you're calling > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are > > > > already disabled. > > > > > > Spinlocks sometimes do more than you think. For instance, here the > > > lock prevents the register access from happening while some other CPU > > > is holding the lock. If a silicon quirk causes the register access to > > > interfere with other activities, this could be important. > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > > barrier to the register accesses, that should force all register > > accesses the be correctly ordered. > > Memory barriers will order accesses that are all made on the same CPU > with respect to each other. They do not order these accesses against > accesses made from another CPU -- that's why we have spinlocks. :-) a fair point :-) The register is still read-only, so that shouldn't matter either :-) > > I fail to see how a silicon quirk > > could cause this and if, indeed, it does, I'd be more comfortable with a > > proper STARS tickect number from synopsys :-s > > Maybe accessing this register somehow resets something else. I don't > know. It seems unlikely, but at least it explains how adding a > spinlock could fix the problem. I would really need Paul (or someone at Synopsys) to confirm this somehow. Maybe it has something to do with how the register is implemented, dunno. Paul, do you have any idea what could cause this ? Could the HW into some weird state if we read GSNPSID at random locations or when data is being transferred, or anything like that ? -- balbi signature.asc Description: Digital signature
Re: Looking for hire a developer to resolve en issue with xHCI and Lego robotic kit.
Hi Greg, m, I'm sure that yes, I sent a response on Jan 7 to the list. I'll forward the e-mail stored on my sent try. Gustavo. On Wed, Jan 14, 2015 at 6:31 PM, Greg KH wrote: > On Wed, Jan 14, 2015 at 03:17:28PM -0200, Gustavo Duarte wrote: >> Hi guys, first I apologize if the topic of this email isn't proper for >> this list. >> >> First a short background. >> >> I work for an Uruguayan governmental organization called Plan Ceibal, >> http://en.wikipedia.org/wiki/Ceibal_project. >> >> Since the last two years Ceibal have been adding a new Robotic area >> to the educational >> platform. It has delivered to schools of the whole >> country thousands of robotic kits, >> http://www.lego.com/en-us/mindstorms. >> >> Until now these kits are working pretty well with all the laptop >> models, provided by Ceibal. >> >> However for 2015, Ceibal acquired one new laptop model, with USB >> 3.0 and robotic kits aren't working with it, as I tried to explain on >> my previous email sent to the list. (linux-usb@vger.kernel.org), >> http://marc.info/?t=14186840597&r=1&w=2 > > You never responded to the requests for you to try in that email thread, > so we really don't even know what the problem is, or if it's not already > fixed in the latest version of the kernel. > > 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: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
On Wed, 14 Jan 2015, Felipe Balbi wrote: > > > This is really, really odd. Register accesses are atomic, so the lock > > > isn't really doing anything. Besides, you're calling > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are > > > already disabled. > > > > Spinlocks sometimes do more than you think. For instance, here the > > lock prevents the register access from happening while some other CPU > > is holding the lock. If a silicon quirk causes the register access to > > interfere with other activities, this could be important. > > readl() (which is used by dwc2_is_controller_alive()) adds a memory > barrier to the register accesses, that should force all register > accesses the be correctly ordered. Memory barriers will order accesses that are all made on the same CPU with respect to each other. They do not order these accesses against accesses made from another CPU -- that's why we have spinlocks. :-) > I fail to see how a silicon quirk > could cause this and if, indeed, it does, I'd be more comfortable with a > proper STARS tickect number from synopsys :-s Maybe accessing this register somehow resets something else. I don't know. It seems unlikely, but at least it explains how adding a spinlock could fix the problem. > Then again, I don't even have a device with this controller and it seems > to only be a problem with Robert's setup, so maybe it's a silicon bug > caused by whoever integrated dwc2 in his silicon. 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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
Hi,
On Wed, Jan 14, 2015 at 03:06:39PM -0500, Alan Stern wrote:
> > > This patch fixes bug described here:
> > > https://lkml.org/lkml/2014/12/22/185
> > >
> > > Signed-off-by: Robert Baldyga
> > > ---
> > >
> > > Changelog:
> > >
> > > v2:
> > > - fixed comment from Paul Zimmerman
> > >
> > > v1: https://lkml.org/lkml/2015/1/13/186
> > >
> > > drivers/usb/dwc2/core_intr.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> > > index ad43c5b..02e3e2d 100644
> > > --- a/drivers/usb/dwc2/core_intr.c
> > > +++ b/drivers/usb/dwc2/core_intr.c
> > > @@ -476,13 +476,13 @@ irqreturn_t dwc2_handle_common_intr(int irq, void
> > > *dev)
> > > u32 gintsts;
> > > irqreturn_t retval = IRQ_NONE;
> > >
> > > + spin_lock(&hsotg->lock);
> > > +
> > > if (!dwc2_is_controller_alive(hsotg)) {
> >
> > This is really, really odd. Register accesses are atomic, so the lock
> > isn't really doing anything. Besides, you're calling
> > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are
> > already disabled.
>
> Spinlocks sometimes do more than you think. For instance, here the
> lock prevents the register access from happening while some other CPU
> is holding the lock. If a silicon quirk causes the register access to
> interfere with other activities, this could be important.
readl() (which is used by dwc2_is_controller_alive()) adds a memory
barrier to the register accesses, that should force all register
accesses the be correctly ordered. I fail to see how a silicon quirk
could cause this and if, indeed, it does, I'd be more comfortable with a
proper STARS tickect number from synopsys :-s
Then again, I don't even have a device with this controller and it seems
to only be a problem with Robert's setup, so maybe it's a silicon bug
caused by whoever integrated dwc2 in his silicon.
--
balbi
signature.asc
Description: Digital signature
[patch 5/6] usb: gadget: uvc: make a bunch of stuff static
Sparse rightly complains that these things should be static since they
are only used in the one .c file.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index 1af2686..a0443a2 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -43,7 +43,8 @@ struct uvcg_control_header {
unsignedlinked;
};
-struct uvcg_control_header *to_uvcg_control_header(struct config_item *item)
+static struct uvcg_control_header *to_uvcg_control_header(struct config_item
+ *item)
{
return container_of(item, struct uvcg_control_header, item);
}
@@ -135,7 +136,7 @@ static struct configfs_attribute
*uvcg_control_header_attrs[] = {
NULL,
};
-struct config_item_type uvcg_control_header_type = {
+static struct config_item_type uvcg_control_header_type = {
.ct_item_ops= &uvcg_control_header_item_ops,
.ct_attrs = uvcg_control_header_attrs,
.ct_owner = THIS_MODULE,
@@ -161,7 +162,7 @@ static struct config_item *uvcg_control_header_make(struct
config_group *group,
return &h->item;
}
-void uvcg_control_header_drop(struct config_group *group,
+static void uvcg_control_header_drop(struct config_group *group,
struct config_item *item)
{
struct uvcg_control_header *h = to_uvcg_control_header(item);
@@ -718,7 +719,7 @@ struct uvcg_format {
__u8bmaControls[UVCG_STREAMING_CONTROL_SIZE];
};
-struct uvcg_format *to_uvcg_format(struct config_item *item)
+static struct uvcg_format *to_uvcg_format(struct config_item *item)
{
return container_of(to_config_group(item), struct uvcg_format, group);
}
@@ -795,7 +796,8 @@ struct uvcg_streaming_header {
unsignednum_fmt;
};
-struct uvcg_streaming_header *to_uvcg_streaming_header(struct config_item
*item)
+static struct uvcg_streaming_header *to_uvcg_streaming_header(struct
config_item
+ *item)
{
return container_of(item, struct uvcg_streaming_header, item);
}
@@ -947,7 +949,7 @@ static struct configfs_attribute
*uvcg_streaming_header_attrs[] = {
NULL,
};
-struct config_item_type uvcg_streaming_header_type = {
+static struct config_item_type uvcg_streaming_header_type = {
.ct_item_ops= &uvcg_streaming_header_item_ops,
.ct_attrs = uvcg_streaming_header_attrs,
.ct_owner = THIS_MODULE,
@@ -973,7 +975,7 @@ static struct config_item
return &h->item;
}
-void uvcg_streaming_header_drop(struct config_group *group,
+static void uvcg_streaming_header_drop(struct config_group *group,
struct config_item *item)
{
struct uvcg_streaming_header *h = to_uvcg_streaming_header(item);
@@ -1017,7 +1019,7 @@ struct uvcg_frame {
struct config_item item;
};
-struct uvcg_frame *to_uvcg_frame(struct config_item *item)
+static struct uvcg_frame *to_uvcg_frame(struct config_item *item)
{
return container_of(item, struct uvcg_frame, item);
}
@@ -1260,7 +1262,7 @@ static struct configfs_attribute *uvcg_frame_attrs[] = {
NULL,
};
-struct config_item_type uvcg_frame_type = {
+static struct config_item_type uvcg_frame_type = {
.ct_item_ops= &uvcg_frame_item_ops,
.ct_attrs = uvcg_frame_attrs,
.ct_owner = THIS_MODULE,
@@ -1311,7 +1313,8 @@ static struct config_item *uvcg_frame_make(struct
config_group *group,
return &h->item;
}
-void uvcg_frame_drop(struct config_group *group, struct config_item *item)
+static void uvcg_frame_drop(struct config_group *group,
+ struct config_item *item)
{
struct uvcg_frame *h = to_uvcg_frame(item);
struct uvcg_format *fmt;
@@ -1334,7 +1337,7 @@ struct uvcg_uncompressed {
struct uvc_format_uncompressed desc;
};
-struct uvcg_uncompressed *to_uvcg_uncompressed(struct config_item *item)
+static struct uvcg_uncompressed *to_uvcg_uncompressed(struct config_item *item)
{
return container_of(
container_of(to_config_group(item), struct uvcg_format, group),
@@ -1544,7 +1547,7 @@ static struct configfs_attribute
*uvcg_uncompressed_attrs[] = {
NULL,
};
-struct config_item_type uvcg_uncompressed_type = {
+static struct config_item_type uvcg_uncompressed_type = {
.ct_item_ops= &uvcg_uncompressed_item_ops,
.ct_group_ops = &uvcg_uncompressed_group_ops,
.ct_attrs = uvcg_uncompressed_attrs,
@@ -1582,7 +1585,7 @@ static struct config_group *uvcg_uncompressed_make(struct
config_group *group,
return &h->fmt.group;
}
-void uvcg_uncompressed_drop(struct config_group *group,
+static void uvcg_uncompressed_drop(struct
[patch 4/6] usb: gadget: uvc: memory leak in uvcg_frame_make()
We need to add a kfree(h) on an error path.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index 738d68f..1af2686 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -1300,6 +1300,7 @@ static struct config_item *uvcg_frame_make(struct
config_group *group,
h->fmt_type = UVCG_MJPEG;
} else {
mutex_unlock(&opts->lock);
+ kfree(h);
return ERR_PTR(-EINVAL);
}
++fmt->num_frames;
--
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/6] usb: gadget: uvc: remove an impossible condition
"num" is a u32 so "(num > 0x)" is never true. Also the range is already checked in kstrtou32(). Signed-off-by: Dan Carpenter diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c index 2bd0688..738d68f 100644 --- a/drivers/usb/gadget/function/uvc_configfs.c +++ b/drivers/usb/gadget/function/uvc_configfs.c @@ -1156,8 +1156,6 @@ static inline int __uvcg_fill_frm_intrv(char *buf, void *priv) ret = kstrtou32(buf, 0, &num); if (ret) return ret; - if (num > 0x) - return -EINVAL; interv = priv; **interv = cpu_to_le32(num); -- 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/6] usb: gadget: uvc: cleanup __uvcg_fill_strm()
Static checkers complain about this API:
drivers/usb/gadget/function/uvc_configfs.c:2139
uvcg_streaming_class_allow_link()
warn: did you really mean to pass the address of 'data'?
Indeed, the code is cleaner when we just pass the pointer instead of the
pointer to the pointer.
Signed-off-by: Dan Carpenter
---
Looks obvious enough to me, but I've only compiled this code and haven't
tested it.
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index d112c99..2bd0688 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2009,28 +2009,27 @@ static int __uvcg_cnt_strm(void *priv1, void *priv2,
void *priv3, int n,
return 0;
}
-static int __uvcg_fill_strm(void *priv1, void *priv2, void *priv3, int n,
+static int __uvcg_fill_strm(void *priv1, void *dest, void *priv3, int n,
enum uvcg_strm_type type)
{
- void **dest = priv2;
struct uvc_descriptor_header ***array = priv3;
size_t sz;
- **array = *dest;
+ **array = dest;
++*array;
switch (type) {
case UVCG_HEADER: {
- struct uvc_input_header_descriptor *ihdr = *dest;
+ struct uvc_input_header_descriptor *ihdr = dest;
struct uvcg_streaming_header *h = priv1;
struct uvcg_format_ptr *f;
- memcpy(*dest, &h->desc, sizeof(h->desc));
- *dest += sizeof(h->desc);
+ memcpy(dest, &h->desc, sizeof(h->desc));
+ dest += sizeof(h->desc);
sz = UVCG_STREAMING_CONTROL_SIZE;
list_for_each_entry(f, &h->formats, entry) {
- memcpy(*dest, f->fmt->bmaControls, sz);
- *dest += sz;
+ memcpy(dest, f->fmt->bmaControls, sz);
+ dest += sz;
}
ihdr->bLength = sizeof(h->desc) + h->num_fmt * sz;
ihdr->bNumFormats = h->num_fmt;
@@ -2040,22 +2039,22 @@ static int __uvcg_fill_strm(void *priv1, void *priv2,
void *priv3, int n,
struct uvcg_format *fmt = priv1;
if (fmt->type == UVCG_UNCOMPRESSED) {
- struct uvc_format_uncompressed *unc = *dest;
+ struct uvc_format_uncompressed *unc = dest;
struct uvcg_uncompressed *u =
container_of(fmt, struct uvcg_uncompressed,
fmt);
- memcpy(*dest, &u->desc, sizeof(u->desc));
- *dest += sizeof(u->desc);
+ memcpy(dest, &u->desc, sizeof(u->desc));
+ dest += sizeof(u->desc);
unc->bNumFrameDescriptors = fmt->num_frames;
unc->bFormatIndex = n + 1;
} else if (fmt->type == UVCG_MJPEG) {
- struct uvc_format_mjpeg *mjp = *dest;
+ struct uvc_format_mjpeg *mjp = dest;
struct uvcg_mjpeg *m =
container_of(fmt, struct uvcg_mjpeg, fmt);
- memcpy(*dest, &m->desc, sizeof(m->desc));
- *dest += sizeof(m->desc);
+ memcpy(dest, &m->desc, sizeof(m->desc));
+ dest += sizeof(m->desc);
mjp->bNumFrameDescriptors = fmt->num_frames;
mjp->bFormatIndex = n + 1;
} else {
@@ -2065,15 +2064,15 @@ static int __uvcg_fill_strm(void *priv1, void *priv2,
void *priv3, int n,
break;
case UVCG_FRAME: {
struct uvcg_frame *frm = priv1;
- struct uvc_descriptor_header *h = *dest;
+ struct uvc_descriptor_header *h = dest;
sz = sizeof(frm->frame);
- memcpy(*dest, &frm->frame, sz);
- *dest += sz;
+ memcpy(dest, &frm->frame, sz);
+ dest += sz;
sz = frm->frame.b_frame_interval_type *
sizeof(*frm->dw_frame_interval);
- memcpy(*dest, frm->dw_frame_interval, sz);
- *dest += sz;
+ memcpy(dest, frm->dw_frame_interval, sz);
+ dest += sz;
if (frm->fmt_type == UVCG_UNCOMPRESSED)
h->bLength = UVC_DT_FRAME_UNCOMPRESSED_SIZE(
frm->frame.b_frame_interval_type);
@@ -2136,7 +2135,7 @@ static int uvcg_streaming_class_allow_link(struct
config_item *src,
goto unlock;
}
cl_arr = *class_array;
- ret = __uvcg_iter_strm_cls(target_hdr, &data, &cl_arr,
+ ret = __uvcg_iter_strm_cls(target_hdr, data, &cl_arr,
__uvcg_fill_strm);
if (ret) {
kfree(*cl
[patch 1/6] usb: gadget: uvc: fix some error codes
We're basically saying ERR_CAST(NULL) and PTR_ERR(NULL) here, which is
nonsensical.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index 33d92ab..d112c99 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -148,7 +148,7 @@ static struct config_item *uvcg_control_header_make(struct
config_group *group,
h = kzalloc(sizeof(*h), GFP_KERNEL);
if (!h)
- return ERR_CAST(h);
+ return ERR_PTR(-ENOMEM);
h->desc.bLength = UVC_DT_HEADER_SIZE(1);
h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
@@ -840,7 +840,7 @@ static int uvcg_streaming_header_allow_link(struct
config_item *src,
format_ptr = kzalloc(sizeof(*format_ptr), GFP_KERNEL);
if (!format_ptr) {
- ret = PTR_ERR(format_ptr);
+ ret = -ENOMEM;
goto out;
}
ret = 0;
@@ -960,7 +960,7 @@ static struct config_item
h = kzalloc(sizeof(*h), GFP_KERNEL);
if (!h)
- return ERR_CAST(h);
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&h->formats);
h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
@@ -1278,7 +1278,7 @@ static struct config_item *uvcg_frame_make(struct
config_group *group,
h = kzalloc(sizeof(*h), GFP_KERNEL);
if (!h)
- return ERR_CAST(h);
+ return ERR_PTR(-ENOMEM);
h->frame.b_descriptor_type = USB_DT_CS_INTERFACE;
h->frame.b_frame_index = 1;
@@ -1563,7 +1563,7 @@ static struct config_group *uvcg_uncompressed_make(struct
config_group *group,
h = kzalloc(sizeof(*h), GFP_KERNEL);
if (!h)
- return ERR_CAST(h);
+ return ERR_PTR(-ENOMEM);
h->desc.bLength = UVC_DT_FORMAT_UNCOMPRESSED_SIZE;
h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
@@ -1772,7 +1772,7 @@ static struct config_group *uvcg_mjpeg_make(struct
config_group *group,
h = kzalloc(sizeof(*h), GFP_KERNEL);
if (!h)
- return ERR_CAST(h);
+ return ERR_PTR(-ENOMEM);
h->desc.bLength = UVC_DT_FORMAT_MJPEG_SIZE;
h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
@@ -2124,7 +2124,7 @@ static int uvcg_streaming_class_allow_link(struct
config_item *src,
count += 2; /* color_matching, NULL */
*class_array = kcalloc(count, sizeof(void *), GFP_KERNEL);
if (!*class_array) {
- ret = PTR_ERR(*class_array);
+ ret = -ENOMEM;
goto unlock;
}
--
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: Looking for hire a developer to resolve en issue with xHCI and Lego robotic kit.
On Wed, Jan 14, 2015 at 03:17:28PM -0200, Gustavo Duarte wrote: > Hi guys, first I apologize if the topic of this email isn't proper for > this list. > > First a short background. > > I work for an Uruguayan governmental organization called Plan Ceibal, > http://en.wikipedia.org/wiki/Ceibal_project. > > Since the last two years Ceibal have been adding a new Robotic area > to the educational > platform. It has delivered to schools of the whole > country thousands of robotic kits, > http://www.lego.com/en-us/mindstorms. > > Until now these kits are working pretty well with all the laptop > models, provided by Ceibal. > > However for 2015, Ceibal acquired one new laptop model, with USB > 3.0 and robotic kits aren't working with it, as I tried to explain on > my previous email sent to the list. (linux-usb@vger.kernel.org), > http://marc.info/?t=14186840597&r=1&w=2 You never responded to the requests for you to try in that email thread, so we really don't even know what the problem is, or if it's not already fixed in the latest version of the kernel. 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: [PATCH net-next] r8152: replace tasklet with NAPI
From: Hayes Wang Date: Mon, 12 Jan 2015 12:06:23 +0800 > Replace tasklet with NAPI. > > Add rx_queue to queue the remaining rx packets if the number of the > rx packets is more than the request from poll(). > > Signed-off-by: Hayes Wang Applied, thanks. -- 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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
On Wed, 14 Jan 2015, Felipe Balbi wrote:
> On Wed, Jan 14, 2015 at 07:45:31AM +0100, Robert Baldyga wrote:
> > This patch fixes bug described here:
> > https://lkml.org/lkml/2014/12/22/185
> >
> > Signed-off-by: Robert Baldyga
> > ---
> >
> > Changelog:
> >
> > v2:
> > - fixed comment from Paul Zimmerman
> >
> > v1: https://lkml.org/lkml/2015/1/13/186
> >
> > drivers/usb/dwc2/core_intr.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> > index ad43c5b..02e3e2d 100644
> > --- a/drivers/usb/dwc2/core_intr.c
> > +++ b/drivers/usb/dwc2/core_intr.c
> > @@ -476,13 +476,13 @@ irqreturn_t dwc2_handle_common_intr(int irq, void
> > *dev)
> > u32 gintsts;
> > irqreturn_t retval = IRQ_NONE;
> >
> > + spin_lock(&hsotg->lock);
> > +
> > if (!dwc2_is_controller_alive(hsotg)) {
>
> This is really, really odd. Register accesses are atomic, so the lock
> isn't really doing anything. Besides, you're calling
> dwc2_is_controller_alive() from within the IRQ handler, so IRQs are
> already disabled.
Spinlocks sometimes do more than you think. For instance, here the
lock prevents the register access from happening while some other CPU
is holding the lock. If a silicon quirk causes the register access to
interfere with other activities, this could be important.
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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
On Wed, Jan 14, 2015 at 07:45:31AM +0100, Robert Baldyga wrote:
> This patch fixes bug described here:
> https://lkml.org/lkml/2014/12/22/185
>
> Signed-off-by: Robert Baldyga
> ---
>
> Changelog:
>
> v2:
> - fixed comment from Paul Zimmerman
>
> v1: https://lkml.org/lkml/2015/1/13/186
>
> drivers/usb/dwc2/core_intr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index ad43c5b..02e3e2d 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -476,13 +476,13 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> u32 gintsts;
> irqreturn_t retval = IRQ_NONE;
>
> + spin_lock(&hsotg->lock);
> +
> if (!dwc2_is_controller_alive(hsotg)) {
This is really, really odd. Register accesses are atomic, so the lock
isn't really doing anything. Besides, you're calling
dwc2_is_controller_alive() from within the IRQ handler, so IRQs are
already disabled.
When the problem happens, do you see this "Controller is dead" message ?
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
> From: Robert Baldyga [mailto:r.bald...@samsung.com]
> Sent: Tuesday, January 13, 2015 10:46 PM
>
> This patch fixes bug described here:
> https://lkml.org/lkml/2014/12/22/185
>
> Signed-off-by: Robert Baldyga
Although I don't understand *why* this fixes Robert's issue, it's
certainly a harmless patch, so
Acked-by: Paul Zimmerman
But I suspect Felipe will want a better changelog, I don't think just
a URL is good enough.
--
Paul
> ---
>
> Changelog:
>
> v2:
> - fixed comment from Paul Zimmerman
>
> v1: https://lkml.org/lkml/2015/1/13/186
>
> drivers/usb/dwc2/core_intr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index ad43c5b..02e3e2d 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -476,13 +476,13 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> u32 gintsts;
> irqreturn_t retval = IRQ_NONE;
>
> + spin_lock(&hsotg->lock);
> +
> if (!dwc2_is_controller_alive(hsotg)) {
> dev_warn(hsotg->dev, "Controller is dead\n");
> goto out;
> }
>
> - spin_lock(&hsotg->lock);
> -
> gintsts = dwc2_read_common_intr(hsotg);
> if (gintsts & ~GINTSTS_PRTINT)
> retval = IRQ_HANDLED;
> @@ -515,8 +515,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> }
> }
>
> - spin_unlock(&hsotg->lock);
> out:
> + spin_unlock(&hsotg->lock);
> return retval;
> }
> EXPORT_SYMBOL_GPL(dwc2_handle_common_intr);
> --
> 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: [PATCH 08/12] usb: gadget: at91_udc: Remove non-DT handling code
On Wed, Jan 14, 2015 at 07:35:16PM +0100, Alexandre Belloni wrote: > On 14/01/2015 at 11:38:12 -0600, Felipe Balbi wrote : > > On Wed, Jan 14, 2015 at 05:22:00PM +0100, Alexandre Belloni wrote: > > > From: Boris Brezillon > > > > > > Since non-DT board support has been removed from the at91 architecture we > > > can safely remove non-DT handling code. > > > > > > Signed-off-by: Boris Brezillon > > > --- > > > drivers/usb/gadget/udc/Kconfig| 1 + > > > drivers/usb/gadget/udc/at91_udc.c | 16 ++-- > > > 2 files changed, 3 insertions(+), 14 deletions(-) > > > > > > diff --git a/drivers/usb/gadget/udc/Kconfig > > > b/drivers/usb/gadget/udc/Kconfig > > > index b8e213eb36cc..366e551aeff0 100644 > > > --- a/drivers/usb/gadget/udc/Kconfig > > > +++ b/drivers/usb/gadget/udc/Kconfig > > > @@ -32,6 +32,7 @@ menu "USB Peripheral Controller" > > > config USB_AT91 > > > tristate "Atmel AT91 USB Device Port" > > > depends on ARCH_AT91 > > > + depends on OF || COMPILE_TEST > > > > will this build with !OF builds ? > > > > It should, I'll check but it doesn't matter because it depends on > ARCH_AT91 which selects OF. Missed that line :-) Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 08/12] usb: gadget: at91_udc: Remove non-DT handling code
On 14/01/2015 at 11:38:12 -0600, Felipe Balbi wrote : > On Wed, Jan 14, 2015 at 05:22:00PM +0100, Alexandre Belloni wrote: > > From: Boris Brezillon > > > > Since non-DT board support has been removed from the at91 architecture we > > can safely remove non-DT handling code. > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/usb/gadget/udc/Kconfig| 1 + > > drivers/usb/gadget/udc/at91_udc.c | 16 ++-- > > 2 files changed, 3 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > > index b8e213eb36cc..366e551aeff0 100644 > > --- a/drivers/usb/gadget/udc/Kconfig > > +++ b/drivers/usb/gadget/udc/Kconfig > > @@ -32,6 +32,7 @@ menu "USB Peripheral Controller" > > config USB_AT91 > > tristate "Atmel AT91 USB Device Port" > > depends on ARCH_AT91 > > + depends on OF || COMPILE_TEST > > will this build with !OF builds ? > It should, I'll check but it doesn't matter because it depends on ARCH_AT91 which selects OF. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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] usb/musb: debugfs, fix copy_from_user argument
Hi, On Wed, Jan 14, 2015 at 11:08:12AM -0600, Felipe Balbi wrote: > On Wed, Jan 14, 2015 at 05:12:55PM +0100, 'Markus Pargmann' wrote: > > Hi, > > > > On Wed, Jan 14, 2015 at 03:19:42PM +, David Laight wrote: > > > From: Markus Pargmann > > > > The first arugment has to be a pointer to the memory. buf is a char > > > > array and already a pointer itself. The current code passes a pointer to > > > > a char array to copy_from_user() which is not correct. > > > > > > It doesn't matter, while the type of the argument is subtly different the > > > value passed is the same. > > > > Thanks, I didn't know about this. So the code is actually correct and > > the patch is not a fix. I would still prefer to have it consistent with > > the usage of 'buf' in the code above and below, where 'buf' is directly > > used. > > I modified it like so: > > commit 5db92ebc06ad815a4032f28145531a879b73db08 > Author: Markus Pargmann > Date: Wed Jan 14 16:08:38 2015 +0100 > > usb: musb: debugfs: improve copy_from_user() argument > > While the code is correct and functions well, it's still > a bit misleading to add the reference operator in from of > the buf argument. > > This patch simply removes that operator in order to make > use of buf slightly better to the eyes. > > Signed-off-by: Markus Pargmann > Signed-off-by: Felipe Balbi Looks good, thank you. Best regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
[GIT PULL] USB patches
Hi Greg, Alright, 3 more fixes for v3.19-rc and my queue is finally clean. All three fixes are rather obvious, two of them just took longer to sort out all the stable rules details and I ended up having to fix all that, otherwise we would miss the time frame. Please condiser merging to your greg/usb-linus branch. cheers The following changes since commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5: usb: gadget: udc: atmel: fix possible oops when unloading module (2015-01-09 18:15:11 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.19-rc6 for you to fetch changes up to 39e60635a01520e8c8ed3946a28c2b98e6a46f79: usb: dwc3: gadget: Stop TRB preparation after limit is reached (2015-01-14 11:29:05 -0600) usb: fixes for v3.19-rc6 The final set of fixes for v3.19. Two of the fixes are related to dwc3 scatter/gather implementation when we have more requests queued than available TRBs, while the other is a build fix for mv-usb PHY. Signed-off-by: Felipe Balbi Amit Virdi (2): usb: dwc3: gadget: Fix TRB preparation during SG usb: dwc3: gadget: Stop TRB preparation after limit is reached Arnd Bergmann (1): usb: phy: mv-usb: fix usb_phy build errors drivers/usb/dwc3/gadget.c| 6 -- drivers/usb/phy/phy-mv-usb.c | 5 ++--- 2 files changed, 6 insertions(+), 5 deletions(-) -- 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 09/12] usb: gadget: at91_udc: Simplify probe and remove functions
On Wed, Jan 14, 2015 at 05:22:01PM +0100, Alexandre Belloni wrote:
> From: Boris Brezillon
>
> Make use of devm_ functions to simplify probe and remove code.
>
> Signed-off-by: Boris Brezillon
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/at91_udc.c | 116
> +-
> 1 file changed, 39 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index be7e16037ac4..4dba2c65dfd4 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -1710,15 +1710,6 @@ static int at91udc_probe(struct platform_device *pdev)
> int retval;
> struct resource *res;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENXIO;
> -
> - if (!request_mem_region(res->start, resource_size(res), driver_name)) {
> - DBG("someone's using UDC memory\n");
> - return -EBUSY;
> - }
> -
> /* init software state */
> udc = &controller;
> udc->gadget.dev.parent = dev;
> @@ -1731,13 +1722,13 @@ static int at91udc_probe(struct platform_device *pdev)
> if (cpu_is_at91rm9200()) {
> if (!gpio_is_valid(udc->board.pullup_pin)) {
> DBG("no D+ pullup?\n");
> - retval = -ENODEV;
> - goto fail0;
> + return -ENODEV;
> }
> - retval = gpio_request(udc->board.pullup_pin, "udc_pullup");
> + retval = devm_gpio_request(dev, udc->board.pullup_pin,
> +"udc_pullup");
> if (retval) {
> DBG("D+ pullup is busy\n");
> - goto fail0;
> + return retval;
> }
> gpio_direction_output(udc->board.pullup_pin,
> udc->board.pullup_active_low);
> @@ -1756,32 +1747,32 @@ static int at91udc_probe(struct platform_device *pdev)
> udc->ep[3].maxpacket = 64;
> }
>
> - udc->udp_baseaddr = ioremap(res->start, resource_size(res));
> - if (!udc->udp_baseaddr) {
> - retval = -ENOMEM;
> - goto fail0a;
> - }
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + udc->udp_baseaddr = devm_ioremap_resource(dev, res);
> + if (IS_ERR(udc->udp_baseaddr))
> + return PTR_ERR(udc->udp_baseaddr);
>
> udc_reinit(udc);
>
> /* get interface and function clocks */
> - udc->iclk = clk_get(dev, "pclk");
> - udc->fclk = clk_get(dev, "hclk");
> - if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
> - DBG("clocks missing\n");
> - retval = -ENODEV;
> - goto fail1;
> - }
> + udc->iclk = devm_clk_get(dev, "pclk");
> + if (IS_ERR(udc->iclk))
> + return PTR_ERR(udc->iclk);
> +
> + udc->fclk = devm_clk_get(dev, "hclk");
> + if (IS_ERR(udc->fclk))
> + return PTR_ERR(udc->fclk);
>
> /* don't do anything until we have both gadget driver and VBUS */
> clk_set_rate(udc->fclk, 4800);
> retval = clk_prepare(udc->fclk);
> if (retval)
> - goto fail1;
> + return retval;
>
> retval = clk_prepare_enable(udc->iclk);
> if (retval)
> - goto fail1b;
> + goto err_unprepare_fclk;
> +
> at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
> at91_udp_write(udc, AT91_UDP_IDR, 0x);
> /* Clear all pending interrupts - UDP may be used by bootloader. */
> @@ -1790,18 +1781,21 @@ static int at91udc_probe(struct platform_device *pdev)
>
> /* request UDC and maybe VBUS irqs */
> udc->udp_irq = platform_get_irq(pdev, 0);
> - retval = request_irq(udc->udp_irq, at91_udc_irq,
> - 0, driver_name, udc);
> - if (retval < 0) {
> + retval = devm_request_irq(dev, udc->udp_irq, at91_udc_irq, 0,
> + driver_name, udc);
> + if (retval) {
> DBG("request irq %d failed\n", udc->udp_irq);
> - goto fail1c;
> + goto err_unprepare_iclk;
> }
> +
> if (gpio_is_valid(udc->board.vbus_pin)) {
> - retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
> - if (retval < 0) {
> + retval = devm_gpio_request(dev, udc->board.vbus_pin,
> +"udc_vbus");
> + if (retval) {
> DBG("request vbus pin failed\n");
> - goto fail2;
> + goto err_unprepare_iclk;
> }
> +
> gpio_direction_input(udc->board.vbus_pin);
>
> /*
> @@ -1818,12 +1812,13 @@ static int at91udc_probe(struct platform_device *pdev)
> mod_timer(&udc->vbus_timer,
>
Re: [PATCH 12/12] usb: gadget: at91_udc: Allocate udc instance
On Wed, Jan 14, 2015 at 05:22:04PM +0100, Alexandre Belloni wrote:
> From: Boris Brezillon
>
> Allocate udc structure instead of relying on the statically declared
> object.
>
> Signed-off-by: Boris Brezillon
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/at91_udc.c | 96
> +++
> 1 file changed, 26 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index c0abb9bc76a9..6d285226ab94 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -59,7 +59,15 @@
> #define DRIVER_VERSION "3 May 2006"
>
> static const char driver_name [] = "at91_udc";
> -static const char ep0name[] = "ep0";
> +static const char * const ep_names[] = {
> + "ep0",
> + "ep1",
> + "ep2",
> + "ep3-int",
> + "ep4",
> + "ep5",
> +};
> +#define ep0name ep_names[0]
>
> #define VBUS_POLL_TIMEOUTmsecs_to_jiffies(1000)
>
> @@ -1497,74 +1505,6 @@ static irqreturn_t at91_udc_irq (int irq, void *_udc)
>
> /*-*/
>
> -static struct at91_udc controller = {
> - .gadget = {
> - .ops= &at91_udc_ops,
> - .ep0= &controller.ep[0].ep,
> - .name = driver_name,
> - },
> - .ep[0] = {
> - .ep = {
> - .name = ep0name,
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .maxpacket = 8,
> - .int_mask = 1 << 0,
> - },
> - .ep[1] = {
> - .ep = {
> - .name = "ep1",
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .is_pingpong= 1,
> - .maxpacket = 64,
> - .int_mask = 1 << 1,
> - },
> - .ep[2] = {
> - .ep = {
> - .name = "ep2",
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .is_pingpong= 1,
> - .maxpacket = 64,
> - .int_mask = 1 << 2,
> - },
> - .ep[3] = {
> - .ep = {
> - /* could actually do bulk too */
> - .name = "ep3-int",
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .maxpacket = 8,
> - .int_mask = 1 << 3,
> - },
> - .ep[4] = {
> - .ep = {
> - .name = "ep4",
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .is_pingpong= 1,
> - .maxpacket = 256,
> - .int_mask = 1 << 4,
> - },
> - .ep[5] = {
> - .ep = {
> - .name = "ep5",
> - .ops= &at91_ep_ops,
> - },
> - .udc= &controller,
> - .is_pingpong= 1,
> - .maxpacket = 256,
> - .int_mask = 1 << 5,
> - },
> - /* ep6 and ep7 are also reserved (custom silicon might use them) */
> -};
> -
> static void at91_vbus_update(struct at91_udc *udc, unsigned value)
> {
> value ^= udc->board.vbus_active_low;
> @@ -1872,15 +1812,31 @@ static int at91udc_probe(struct platform_device *pdev)
> struct at91_ep *ep;
> int i;
>
> + udc = devm_kzalloc(dev, sizeof(*udc), GFP_KERNEL);
> + if (!udc)
> + return -ENOMEM;
> +
> /* init software state */
> - udc = &controller;
> udc->gadget.dev.parent = dev;
> at91udc_of_init(udc, pdev->dev.of_node);
> udc->pdev = pdev;
> udc->enabled = 0;
> spin_lock_init(&udc->lock);
>
> + udc->gadget.ops = &at91_udc_ops;
> + udc->gadget.ep0 = &udc->ep[0].ep;
> + udc->gadget.name = driver_name;
> + udc->gadget.dev.init_name = "gadget";
>
> + for (i = 0; i < NUM_ENDPOINTS; i++) {
> + ep = &udc->ep[i];
> + ep->ep.name = ep_names[i];
> + ep->ep.ops = &at91_ep_ops;
> + ep->udc = udc;
> + ep->int_mask = BIT(i);
> + if (i != 0 && i != 3)
> + ep->is_pingpong = 1;
> + }
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> udc->udp_baseaddr = devm_ioremap_resource(dev, res);
> --
> 2.1.0
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 10/12] usb: gadget: at91_udc: Rework for multi-platform kernel support
On Wed, Jan 14, 2015 at 05:22:02PM +0100, Alexandre Belloni wrote:
> From: Boris Brezillon
>
> cpu_is_at91xxx are a set of macros defined in mach/cpu.h and are here used
> to detect the SoC we are booting on.
> Use compatible string + a caps structure to replace those cpu_is_xxx tests.
>
> Remove all mach and asm headers (which are now unused).
>
> Signed-off-by: Boris Brezillon
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/at91_udc.c | 288
> --
> drivers/usb/gadget/udc/at91_udc.h | 7 +
> 2 files changed, 218 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index 4dba2c65dfd4..c0abb9bc76a9 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -31,16 +31,9 @@
> #include
> #include
> #include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> +#include
> +#include
> +#include
>
> #include "at91_udc.h"
>
> @@ -915,8 +908,6 @@ static void clk_off(struct at91_udc *udc)
> */
> static void pullup(struct at91_udc *udc, int is_on)
> {
> - int active = !udc->board.pullup_active_low;
> -
> if (!udc->enabled || !udc->vbus)
> is_on = 0;
> DBG("%sactive\n", is_on ? "" : "in");
> @@ -925,40 +916,15 @@ static void pullup(struct at91_udc *udc, int is_on)
> clk_on(udc);
> at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_RXRSM);
> at91_udp_write(udc, AT91_UDP_TXVC, 0);
> - if (cpu_is_at91rm9200())
> - gpio_set_value(udc->board.pullup_pin, active);
> - else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
> cpu_is_at91sam9g20()) {
> - u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
> -
> - txvc |= AT91_UDP_TXVC_PUON;
> - at91_udp_write(udc, AT91_UDP_TXVC, txvc);
> - } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
> - u32 usbpucr;
> -
> - usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
> - usbpucr |= AT91_MATRIX_USBPUCR_PUON;
> - at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
> - }
> } else {
> stop_activity(udc);
> at91_udp_write(udc, AT91_UDP_IDR, AT91_UDP_RXRSM);
> at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
> - if (cpu_is_at91rm9200())
> - gpio_set_value(udc->board.pullup_pin, !active);
> - else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
> cpu_is_at91sam9g20()) {
> - u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
> -
> - txvc &= ~AT91_UDP_TXVC_PUON;
> - at91_udp_write(udc, AT91_UDP_TXVC, txvc);
> - } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
> - u32 usbpucr;
> -
> - usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
> - usbpucr &= ~AT91_MATRIX_USBPUCR_PUON;
> - at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
> - }
> clk_off(udc);
> }
> +
> + if (udc->caps && udc->caps->pullup)
> + udc->caps->pullup(udc, is_on);
> }
>
> /* vbus is here! turn everything on that's ready */
> @@ -1683,12 +1649,202 @@ static void at91udc_shutdown(struct platform_device
> *dev)
> spin_unlock_irqrestore(&udc->lock, flags);
> }
>
> -static void at91udc_of_init(struct at91_udc *udc,
> - struct device_node *np)
> +static int at91rm9200_udc_init(struct at91_udc *udc)
> +{
> + struct at91_ep *ep;
> + int ret;
> + int i;
> +
> + for (i = 0; i < NUM_ENDPOINTS; i++) {
> + ep = &udc->ep[i];
> +
> + switch (i) {
> + case 0:
> + case 3:
> + ep->maxpacket = 8;
> + break;
> + case 1 ... 2:
> + ep->maxpacket = 64;
> + break;
> + case 4 ... 5:
> + ep->maxpacket = 256;
> + break;
> + }
> + }
> +
> + if (!gpio_is_valid(udc->board.pullup_pin)) {
> + DBG("no D+ pullup?\n");
> + return -ENODEV;
> + }
> +
> + ret = devm_gpio_request(&udc->pdev->dev, udc->board.pullup_pin,
> + "udc_pullup");
> + if (ret) {
> + DBG("D+ pullup is busy\n");
> + return ret;
> + }
> +
> + gpio_direction_output(udc->board.pullup_pin,
> + udc->board.pullup_active_low);
> +
> + return 0;
> +}
> +
> +static void at91rm9200_udc_pullup(struct at91_udc *udc, int is_on)
> +{
> + int active = !udc->board.pullup_active_low;
Re: [PATCH 08/12] usb: gadget: at91_udc: Remove non-DT handling code
On Wed, Jan 14, 2015 at 05:22:00PM +0100, Alexandre Belloni wrote: > From: Boris Brezillon > > Since non-DT board support has been removed from the at91 architecture we > can safely remove non-DT handling code. > > Signed-off-by: Boris Brezillon > --- > drivers/usb/gadget/udc/Kconfig| 1 + > drivers/usb/gadget/udc/at91_udc.c | 16 ++-- > 2 files changed, 3 insertions(+), 14 deletions(-) > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > index b8e213eb36cc..366e551aeff0 100644 > --- a/drivers/usb/gadget/udc/Kconfig > +++ b/drivers/usb/gadget/udc/Kconfig > @@ -32,6 +32,7 @@ menu "USB Peripheral Controller" > config USB_AT91 > tristate "Atmel AT91 USB Device Port" > depends on ARCH_AT91 > + depends on OF || COMPILE_TEST will this build with !OF builds ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 06/12] usb: gadget: at91_udc: Drop uclk clock
On Wed, Jan 14, 2015 at 05:21:58PM +0100, Alexandre Belloni wrote:
> From: Boris Brezillon
>
> Now that at91 system clocks forward set_rate request to their parent we
> can remove the uclk clock and directly call clk_set_rate on fclk.
>
> Signed-off-by: Boris Brezillon
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/at91_udc.c | 27 +++
> drivers/usb/gadget/udc/at91_udc.h | 2 +-
> 2 files changed, 4 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index 9ff2f7e5c6a7..d33f2994b7c4 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -895,8 +895,6 @@ static void clk_on(struct at91_udc *udc)
> return;
> udc->clocked = 1;
>
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_enable(udc->uclk);
> clk_enable(udc->iclk);
> clk_enable(udc->fclk);
> }
> @@ -909,8 +907,6 @@ static void clk_off(struct at91_udc *udc)
> udc->gadget.speed = USB_SPEED_UNKNOWN;
> clk_disable(udc->fclk);
> clk_disable(udc->iclk);
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_disable(udc->uclk);
> }
>
> /*
> @@ -1781,25 +1777,17 @@ static int at91udc_probe(struct platform_device *pdev)
> /* get interface and function clocks */
> udc->iclk = clk_get(dev, "pclk");
> udc->fclk = clk_get(dev, "hclk");
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - udc->uclk = clk_get(dev, "usb_clk");
> - if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) ||
> - (IS_ENABLED(CONFIG_COMMON_CLK) && IS_ERR(udc->uclk))) {
> + if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
> DBG("clocks missing\n");
> retval = -ENODEV;
> goto fail1;
> }
>
> /* don't do anything until we have both gadget driver and VBUS */
> - if (IS_ENABLED(CONFIG_COMMON_CLK)) {
> - clk_set_rate(udc->uclk, 4800);
> - retval = clk_prepare(udc->uclk);
> - if (retval)
> - goto fail1;
> - }
> + clk_set_rate(udc->fclk, 4800);
> retval = clk_prepare(udc->fclk);
> if (retval)
> - goto fail1a;
> + goto fail1;
>
> retval = clk_prepare_enable(udc->iclk);
> if (retval)
> @@ -1873,12 +1861,7 @@ fail1c:
> clk_unprepare(udc->iclk);
> fail1b:
> clk_unprepare(udc->fclk);
> -fail1a:
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_unprepare(udc->uclk);
> fail1:
> - if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
> - clk_put(udc->uclk);
> if (!IS_ERR(udc->fclk))
> clk_put(udc->fclk);
> if (!IS_ERR(udc->iclk))
> @@ -1924,15 +1907,11 @@ static int __exit at91udc_remove(struct
> platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_unprepare(udc->uclk);
> clk_unprepare(udc->fclk);
> clk_unprepare(udc->iclk);
>
> clk_put(udc->iclk);
> clk_put(udc->fclk);
> - if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_put(udc->uclk);
>
> return 0;
> }
> diff --git a/drivers/usb/gadget/udc/at91_udc.h
> b/drivers/usb/gadget/udc/at91_udc.h
> index 017524663381..e647d1c2ada4 100644
> --- a/drivers/usb/gadget/udc/at91_udc.h
> +++ b/drivers/usb/gadget/udc/at91_udc.h
> @@ -126,7 +126,7 @@ struct at91_udc {
> unsignedactive_suspend:1;
> u8 addr;
> struct at91_udc_databoard;
> - struct clk *iclk, *fclk, *uclk;
> + struct clk *iclk, *fclk;
> struct platform_device *pdev;
> struct proc_dir_entry *pde;
> void __iomem*udp_baseaddr;
> --
> 2.1.0
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 05/12] usb: gadget: at91_udc: Fix clock names
On Wed, Jan 14, 2015 at 05:21:57PM +0100, Alexandre Belloni wrote: > From: Boris Brezillon > > The driver is requesting clock by their global name (those declared in the > clk_lookup list), but this only works with !CCF kernels. > > Now that all SoCs have moved to CCF, fix the driver to use local names > (hclk and pclk). > > Signed-off-by: Boris Brezillon Acked-by: Felipe Balbi > --- > drivers/usb/gadget/udc/at91_udc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/udc/at91_udc.c > b/drivers/usb/gadget/udc/at91_udc.c > index c862656d18b8..9ff2f7e5c6a7 100644 > --- a/drivers/usb/gadget/udc/at91_udc.c > +++ b/drivers/usb/gadget/udc/at91_udc.c > @@ -1779,8 +1779,8 @@ static int at91udc_probe(struct platform_device *pdev) > udc_reinit(udc); > > /* get interface and function clocks */ > - udc->iclk = clk_get(dev, "udc_clk"); > - udc->fclk = clk_get(dev, "udpck"); > + udc->iclk = clk_get(dev, "pclk"); > + udc->fclk = clk_get(dev, "hclk"); > if (IS_ENABLED(CONFIG_COMMON_CLK)) > udc->uclk = clk_get(dev, "usb_clk"); > if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) || > -- > 2.1.0 > -- balbi signature.asc Description: Digital signature
[PATCH 1/2] usb: dwc3: gadget: Fix TRB preparation during SG
From: Amit Virdi
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.
The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.
The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.
Fixes: e5ba5ec833aa (usb: dwc3: gadget: fix scatter gather implementation)
Signed-off-by: Amit Virdi
Cc: # v3.9+
Signed-off-by: Felipe Balbi
---
resending with proper fixes line
drivers/usb/dwc3/gadget.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f03b136ecfce..0eec2e917994 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -882,8 +882,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (i == (request->num_mapped_sgs - 1) ||
sg_is_last(s)) {
- if (list_is_last(&req->list,
- &dep->request_list))
+ if (list_empty(&dep->request_list))
last_one = true;
chain = false;
}
--
2.2.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
[PATCH 2/2] usb: dwc3: gadget: Stop TRB preparation after limit is reached
From: Amit Virdi
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer. However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.
Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
- Outer loop over the request_list
- Inner loop over the SG list
The code was missing break to get out of the outer loop.
Fixes: eeb720fb21d6 (usb: dwc3: gadget: add support for SG lists)
Cc: # v3.9+
Signed-off-by: Amit Virdi
Signed-off-by: Felipe Balbi
---
resending with proper fixes line
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0eec2e917994..8f65ab3a3b92 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -900,6 +900,9 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (last_one)
break;
}
+
+ if (last_one)
+ break;
} else {
dma = req->request.dma;
length = req->request.length;
--
2.2.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: [RESEND PATCH 1/2] usb: dwc3: gadget: Fix TRB preparation during SG
On Wed, Jan 14, 2015 at 08:20:19PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/14/2015 08:04 PM, Felipe Balbi wrote:
>
> >From: Amit Virdi
>
> >When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
> >request (dwc3_request). So while preparing TRBs, the 'last' flag should be
> >set
> >only when it is the last TRB being prepared from the last dwc3_request entry.
>
> >The current implementation uses list_is_last to check if the dwc3_request is
> >the
> >last entry from the request_list. However, list_is_last returns false for the
> >last entry too. This is because, while preparing the first TRB from a
> >request,
> >the function dwc3_prepare_one_trb modifies the request's next and prev
> >pointers
> >while moving the URB to req_queued. Hence, list_is_last always returns false
> >no
> >matter what.
>
> >The correct way is not to access the modified pointers of dwc3_request but to
> >use list_empty macro instead.
>
> >Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 ("usb: dwc3: gadget: fix
> >scatter
>
>12-digit SHA1 hash is enough, accoring to Documentation/SubmittingPatches.
>
> >gather implementation"
>
>You forgot the closing paren.
>Perhaps these can be fixed by the maintainer while applying...
I'll fix them, thanks
--
balbi
signature.asc
Description: Digital signature
Re: [RESEND PATCH 1/2] usb: dwc3: gadget: Fix TRB preparation during SG
Hello.
On 01/14/2015 08:04 PM, Felipe Balbi wrote:
From: Amit Virdi
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.
The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.
The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.
Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 ("usb: dwc3: gadget: fix scatter
12-digit SHA1 hash is enough, accoring to Documentation/SubmittingPatches.
gather implementation"
You forgot the closing paren.
Perhaps these can be fixed by the maintainer while applying...
Signed-off-by: Amit Virdi
Cc: # v3.9+
Signed-off-by: Felipe Balbi
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
Looking for hire a developer to resolve en issue with xHCI and Lego robotic kit.
Hi guys, first I apologize if the topic of this email isn't proper for this list. First a short background. I work for an Uruguayan governmental organization called Plan Ceibal, http://en.wikipedia.org/wiki/Ceibal_project. Since the last two years Ceibal have been adding a new Robotic area to the educational platform. It has delivered to schools of the whole country thousands of robotic kits, http://www.lego.com/en-us/mindstorms. Until now these kits are working pretty well with all the laptop models, provided by Ceibal. However for 2015, Ceibal acquired one new laptop model, with USB 3.0 and robotic kits aren't working with it, as I tried to explain on my previous email sent to the list. (linux-usb@vger.kernel.org), http://marc.info/?t=14186840597&r=1&w=2 Since this issue is critical, Ceibal is looking for a developer with experience on xhci driver who can find a solution on this , by hiring this work. If somebody has interest on this kind of work, please contact by private. Gustavo Duarte. gus.dua...@gmail.com uy.linkedin.com/in/duartegustavo -- 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/musb: debugfs, fix copy_from_user argument
On Wed, Jan 14, 2015 at 05:12:55PM +0100, 'Markus Pargmann' wrote: > Hi, > > On Wed, Jan 14, 2015 at 03:19:42PM +, David Laight wrote: > > From: Markus Pargmann > > > The first arugment has to be a pointer to the memory. buf is a char > > > array and already a pointer itself. The current code passes a pointer to > > > a char array to copy_from_user() which is not correct. > > > > It doesn't matter, while the type of the argument is subtly different the > > value passed is the same. > > Thanks, I didn't know about this. So the code is actually correct and > the patch is not a fix. I would still prefer to have it consistent with > the usage of 'buf' in the code above and below, where 'buf' is directly > used. I modified it like so: commit 5db92ebc06ad815a4032f28145531a879b73db08 Author: Markus Pargmann Date: Wed Jan 14 16:08:38 2015 +0100 usb: musb: debugfs: improve copy_from_user() argument While the code is correct and functions well, it's still a bit misleading to add the reference operator in from of the buf argument. This patch simply removes that operator in order to make use of buf slightly better to the eyes. Signed-off-by: Markus Pargmann Signed-off-by: Felipe Balbi diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c index ad3701a97389..bb13e0420140 100644 --- a/drivers/usb/musb/musb_debugfs.c +++ b/drivers/usb/musb/musb_debugfs.c @@ -194,7 +194,7 @@ static ssize_t musb_test_mode_write(struct file *file, memset(buf, 0x00, sizeof(buf)); - if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) + if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) return -EFAULT; if (!strncmp(buf, "force host", 9)) -- balbi signature.asc Description: Digital signature
[RESEND PATCH 1/2] usb: dwc3: gadget: Fix TRB preparation during SG
From: Amit Virdi
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.
The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.
The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.
Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 ("usb: dwc3: gadget: fix scatter
gather implementation"
Signed-off-by: Amit Virdi
Cc: # v3.9+
Signed-off-by: Felipe Balbi
---
resending so it reaches stable
drivers/usb/dwc3/gadget.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f03b136ecfce..0eec2e917994 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -882,8 +882,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (i == (request->num_mapped_sgs - 1) ||
sg_is_last(s)) {
- if (list_is_last(&req->list,
- &dep->request_list))
+ if (list_empty(&dep->request_list))
last_one = true;
chain = false;
}
--
2.2.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
[RESEND PATCH 2/2] usb: dwc3: gadget: Stop TRB preparation after limit is reached
From: Amit Virdi
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer. However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.
Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
- Outer loop over the request_list
- Inner loop over the SG list
The code was missing break to get out of the outer loop.
Signed-off-by: Amit Virdi
Cc: # v3.9+
Signed-off-by: Felipe Balbi
---
resending so it reaches stable
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0eec2e917994..8f65ab3a3b92 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -900,6 +900,9 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (last_one)
break;
}
+
+ if (last_one)
+ break;
} else {
dma = req->request.dma;
length = req->request.length;
--
2.2.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 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Hi,
On Wed, Jan 14, 2015 at 03:08:43PM +0800, Sneeker Yeh wrote:
> Hi Felipe:
>
> thanks for suggestion,
>
> 2015-01-13 1:20 GMT+08:00 Felipe Balbi :
>
> > Hi,
> >
> > On Sun, Jan 11, 2015 at 11:19:55PM +0800, Sneeker Yeh wrote:
> > > > > > enable the quirk only for you. Isn't there a better way of
> > enabling the
> > > > > > quirk based off of revision detection couple with a look on
> > GHWPARAMS*
> > > > > > registers ?
> > > > > >
> > > > > > What's tricking me is this claim that only config-free PHYs would
> > be
> > > > > > affected, why ?
> > > > > >
> > > > >
> > > > > i'm still struggling now to try to get more information about this.
> > > > > some security policy inside Fujitsu make me unable to access full
> > > > > information of this errata today.
> > > > >
> > > > > Someday after i get enough information,
> > > > > i shall take your suggestion here that seems better to incur quirk
> > > > > dynamically via GHWPARAMS,
> > > > > and then send it here again.
> > > >
> > > > ok, hopefully you'll find a way ;-)
> > > >
> > > > I got some update information here finally~
> > > in case i express unclearly i also put a pdf:
> > > https://drive.google.com/file/d/0B18MmcvvKjNNbDF6eEdHSzZCazA/view
> > >
> > > This issue is defined by a two-way race at disconnect, between
> > > 1) class driver interrupt endpoint resheduling attempts if the ISR gave
> > an
> > > ep error event due to device detach (it would try 3 times)
> > > 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
> > > asynchronously
> > > 3) The hardware IP was configured in silicon with
> > >- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 (this is an IP configuration
> >
> > yeah, aparently this is another configuration which is not exposed on
> > HWPARAMS registers. Paul, can you confirm for us ? I couldn't find it on
> > Databook on any of the HWPARAMS registers.
> >
> > > port whose state cannot be checked from software)
> > >- Synopsys IP version is < 3.00a
> >
> > heh, so pretty much everybody :-)
> >
>
> yeah, and I'm really lucky to encounter this @@
>
>
> >
> > >The IP will auto-suspend itself on device detach with some
> > > phy-specific interval after CSC is cleared by 2)
> > >
> > > If 2) and 3) complete before 1), the interrupts it expects will not be
> > > generated by the autosuspended IP, leading to a deadlock. Even later
> > > disconnection procedure would detect that corresponding urb is still
> > > in-progress and issue a ep stop command, auto-suspended IP still won't
> > > respond to that command.
> > >
> > > this defect would result in this when device detached:
> > > ---
> > > [ 99.603544] usb 4-1: USB disconnect, device number 2
> > > [ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
> > > endpoint command.
> > > [ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting
> > > host.
> > > [ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
> > > microseconds.
> > > [ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
> > > halting.
> > > [ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
> > > [ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
> > >
> > > As a result, when device detached, we desired to postpone "PORTCSC clear"
> > > behind "disable slot". it's found that all executed ep command related to
> > > disconnetion, are executed before "disable slot".
> >
> > Now this is all great information and they should all be part of your
> > commit log and probably a big comment should be added to code as well.
> >
>
> I see, thanks.
>
>
> >
> > Thanks for going after all these details, now let's figure out a way to
> > pass dwc3 revision to xhci, or maybe we pass just a flag for the quirk,
> > something like:
> >
> > if (dwc->revision < 3.00a && dwc->has_suspend_on_disconnect)
> > xhci_pdata.delay_portcsc_clear = true;
> >
> > or something similar to that.
> >
>
> Sure, how about i write these like this, that i learn from the way dwc3
> inject XHCI_LPM_SUPPORT to xhci via platform data:
>
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
> pdata.usb3_lpm_capable = 1;
> #endif
>
> + if ((dwc->revision < DWC3_REVISION_300A) &&
> + dwc->suspend_on_disconnect_quirk)
> + pdata.delay_portcsc_clear = 1;
> +
> ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
> if (ret) {
> dev_err(dwc->dev, "couldn't add platform data to xHCI
> device\n");
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
> (pdata && pdata->usb3_lpm_capable))
> xhci->quirks |= XH
Re: dwc3 gadget fails on dra7-evm
Hi, On Wed, Jan 14, 2015 at 05:44:08PM +0200, Roger Quadros wrote: > In 3.19-rc4 on dra7-evm or dra72-evm > > modprobe g_zero > [ 34.680683] zero gadget: Gadget Zero, version: Cinco de Mayo 2008 > [ 34.687074] zero gadget: zero ready > [ 34.694133] dwc3 4889.usb: failed to enable ep0out > [ 34.701600] zero 4889.usb: failed to start zero: -110 > ERROR: could not insert 'g_zero': Connection timed out > > my u-boot version is v2015.01 hmm... it could be that DRA7x also needs the suspend phy quirk. Can you try this ? diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 22771bc1643a..63f8b007bdc5 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -1257,6 +1257,8 @@ tx-fifo-resize; maximum-speed = "super-speed"; dr_mode = "otg"; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; @@ -1278,6 +1280,8 @@ tx-fifo-resize; maximum-speed = "high-speed"; dr_mode = "otg"; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; @@ -1299,6 +1303,8 @@ tx-fifo-resize; maximum-speed = "high-speed"; dr_mode = "otg"; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; }; }; Weird, I remeber testing on X15 and not needing this quirk :-s -- balbi signature.asc Description: Digital signature
[PATCH 03/12] mfd: syscon: Add atmel-smc registers definition
From: Boris Brezillon
Atmel AT91 SoCs have a memory range reserved for SMC (Static Memory
Controller) configuration.
Expose those registers so that drivers can make use of the smc syscon
declared in at91 DTs.
Signed-off-by: Boris Brezillon
Acked-by: Lee Jones
---
include/linux/mfd/syscon/atmel-smc.h | 173 +++
1 file changed, 173 insertions(+)
create mode 100644 include/linux/mfd/syscon/atmel-smc.h
diff --git a/include/linux/mfd/syscon/atmel-smc.h
b/include/linux/mfd/syscon/atmel-smc.h
new file mode 100644
index ..be6ebe64eebe
--- /dev/null
+++ b/include/linux/mfd/syscon/atmel-smc.h
@@ -0,0 +1,173 @@
+/*
+ * Atmel SMC (Static Memory Controller) register offsets and bit definitions.
+ *
+ * Copyright (C) 2014 Atmel
+ * Copyright (C) 2014 Free Electrons
+ *
+ * Author: Boris Brezillon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _LINUX_MFD_SYSCON_ATMEL_SMC_H_
+#define _LINUX_MFD_SYSCON_ATMEL_SMC_H_
+
+#include
+#include
+
+#define AT91SAM9_SMC_GENERIC 0x00
+#define AT91SAM9_SMC_GENERIC_BLK_SZ0x10
+
+#define SAMA5_SMC_GENERIC 0x600
+#define SAMA5_SMC_GENERIC_BLK_SZ 0x14
+
+#define AT91SAM9_SMC_SETUP(o) ((o) + 0x00)
+#define AT91SAM9_SMC_NWESETUP(x) (x)
+#define AT91SAM9_SMC_NCS_WRSETUP(x)((x) << 8)
+#define AT91SAM9_SMC_NRDSETUP(x) ((x) << 16)
+#define AT91SAM9_SMC_NCS_NRDSETUP(x) ((x) << 24)
+
+#define AT91SAM9_SMC_PULSE(o) ((o) + 0x04)
+#define AT91SAM9_SMC_NWEPULSE(x) (x)
+#define AT91SAM9_SMC_NCS_WRPULSE(x)((x) << 8)
+#define AT91SAM9_SMC_NRDPULSE(x) ((x) << 16)
+#define AT91SAM9_SMC_NCS_NRDPULSE(x) ((x) << 24)
+
+#define AT91SAM9_SMC_CYCLE(o) ((o) + 0x08)
+#define AT91SAM9_SMC_NWECYCLE(x) (x)
+#define AT91SAM9_SMC_NRDCYCLE(x) ((x) << 16)
+
+#define AT91SAM9_SMC_MODE(o) ((o) + 0x0c)
+#define SAMA5_SMC_MODE(o) ((o) + 0x10)
+#define AT91_SMC_READMODE BIT(0)
+#define AT91_SMC_READMODE_NCS (0 << 0)
+#define AT91_SMC_READMODE_NRD (1 << 0)
+#define AT91_SMC_WRITEMODE BIT(1)
+#define AT91_SMC_WRITEMODE_NCS (0 << 1)
+#define AT91_SMC_WRITEMODE_NWE (1 << 1)
+#define AT91_SMC_EXNWMODE GENMASK(5, 4)
+#define AT91_SMC_EXNWMODE_DISABLE (0 << 4)
+#define AT91_SMC_EXNWMODE_FROZEN (2 << 4)
+#define AT91_SMC_EXNWMODE_READY(3 << 4)
+#define AT91_SMC_BAT BIT(8)
+#define AT91_SMC_BAT_SELECT(0 << 8)
+#define AT91_SMC_BAT_WRITE (1 << 8)
+#define AT91_SMC_DBW GENMASK(13, 12)
+#define AT91_SMC_DBW_8 (0 << 12)
+#define AT91_SMC_DBW_16(1 << 12)
+#define AT91_SMC_DBW_32(2 << 12)
+#define AT91_SMC_TDF GENMASK(19, 16)
+#define AT91_SMC_TDF_(x) x) - 1) << 16) & AT91_SMC_TDF)
+#define AT91_SMC_TDF_MAX 16
+#define AT91_SMC_TDFMODE_OPTIMIZED BIT(20)
+#define AT91_SMC_PMEN BIT(24)
+#define AT91_SMC_PSGENMASK(29, 28)
+#define AT91_SMC_PS_4 (0 << 28)
+#define AT91_SMC_PS_8 (1 << 28)
+#define AT91_SMC_PS_16 (2 << 28)
+#define AT91_SMC_PS_32 (3 << 28)
+
+
+/*
+ * This function converts a setup timing expressed in nanoseconds into an
+ * encoded value that can be written in the SMC_SETUP register.
+ *
+ * The following formula is described in atmel datasheets (section
+ * "SMC Setup Register"):
+ *
+ * setup length = (128* SETUP[5] + SETUP[4:0])
+ *
+ * where setup length is the timing expressed in cycles.
+ */
+static inline u32 at91sam9_smc_setup_ns_to_cycles(unsigned int clk_rate,
+ u32 timing_ns)
+{
+ u32 clk_period = DIV_ROUND_UP(NSEC_PER_SEC, clk_rate);
+ u32 coded_cycles = 0;
+ u32 cycles;
+
+ cycles = DIV_ROUND_UP(timing_ns, clk_period);
+ if (cycles / 32) {
+ coded_cycles |= 1 << 5;
+ if (cycles < 128)
+ cycles = 0;
+ }
+
+ coded_cycles |= cycles % 32;
+
+ return coded_cycles;
+}
+
+/*
+ * This function converts a pulse timing expressed in nanoseconds into an
+ * encoded value that can be written in the SMC_PULSE register.
+ *
+ * The following formula is described in atmel datasheets (section
+ * "SMC Pulse Register"):
+ *
+ * pulse length = (256* PULSE[6] + PULSE[5:0])
+ *
+ * where pulse length is the timing expressed in cycles.
+ */
+static inline u32 at91sam9_smc_pulse_ns_to_cycles(unsigned int clk_rate,
+ u32 timing_ns)
+{
+ u32 clk_period = DIV_ROUND_UP(NSEC_PER_SEC, clk_rate);
+ u32 coded_cycles = 0;
+
[PATCH 01/12] mfd: syscon: Add atmel-matrix registers definition
From: Boris Brezillon AT91 SoCs have a memory range reserved for internal bus configuration. Expose those registers so that drivers can make use of the matrix syscon declared in at91 DTs. Signed-off-by: Boris Brezillon Acked-by: Lee Jones --- include/linux/mfd/syscon/atmel-matrix.h | 117 1 file changed, 117 insertions(+) create mode 100644 include/linux/mfd/syscon/atmel-matrix.h diff --git a/include/linux/mfd/syscon/atmel-matrix.h b/include/linux/mfd/syscon/atmel-matrix.h new file mode 100644 index ..8293c3e2a82a --- /dev/null +++ b/include/linux/mfd/syscon/atmel-matrix.h @@ -0,0 +1,117 @@ +/* + * Copyright (C) 2014 Atmel Corporation. + * + * Memory Controllers (MATRIX, EBI) - System peripherals registers. + * + * 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. + */ + +#ifndef _LINUX_MFD_SYSCON_ATMEL_MATRIX_H +#define _LINUX_MFD_SYSCON_ATMEL_MATRIX_H + +#define AT91SAM9260_MATRIX_MCFG0x00 +#define AT91SAM9260_MATRIX_SCFG0x40 +#define AT91SAM9260_MATRIX_PRS 0x80 +#define AT91SAM9260_MATRIX_MRCR0x100 +#define AT91SAM9260_MATRIX_EBICSA 0x11c + +#define AT91SAM9261_MATRIX_MRCR0x0 +#define AT91SAM9261_MATRIX_SCFG0x4 +#define AT91SAM9261_MATRIX_TCR 0x24 +#define AT91SAM9261_MATRIX_EBICSA 0x30 +#define AT91SAM9261_MATRIX_USBPUCR 0x34 + +#define AT91SAM9263_MATRIX_MCFG0x00 +#define AT91SAM9263_MATRIX_SCFG0x40 +#define AT91SAM9263_MATRIX_PRS 0x80 +#define AT91SAM9263_MATRIX_MRCR0x100 +#define AT91SAM9263_MATRIX_TCR 0x114 +#define AT91SAM9263_MATRIX_EBI0CSA 0x120 +#define AT91SAM9263_MATRIX_EBI1CSA 0x124 + +#define AT91SAM9RL_MATRIX_MCFG 0x00 +#define AT91SAM9RL_MATRIX_SCFG 0x40 +#define AT91SAM9RL_MATRIX_PRS 0x80 +#define AT91SAM9RL_MATRIX_MRCR 0x100 +#define AT91SAM9RL_MATRIX_TCR 0x114 +#define AT91SAM9RL_MATRIX_EBICSA 0x120 + +#define AT91SAM9G45_MATRIX_MCFG0x00 +#define AT91SAM9G45_MATRIX_SCFG0x40 +#define AT91SAM9G45_MATRIX_PRS 0x80 +#define AT91SAM9G45_MATRIX_MRCR0x100 +#define AT91SAM9G45_MATRIX_TCR 0x110 +#define AT91SAM9G45_MATRIX_DDRMPR 0x118 +#define AT91SAM9G45_MATRIX_EBICSA 0x128 + +#define AT91SAM9N12_MATRIX_MCFG0x00 +#define AT91SAM9N12_MATRIX_SCFG0x40 +#define AT91SAM9N12_MATRIX_PRS 0x80 +#define AT91SAM9N12_MATRIX_MRCR0x100 +#define AT91SAM9N12_MATRIX_EBICSA 0x118 + +#define AT91SAM9X5_MATRIX_MCFG 0x00 +#define AT91SAM9X5_MATRIX_SCFG 0x40 +#define AT91SAM9X5_MATRIX_PRS 0x80 +#define AT91SAM9X5_MATRIX_MRCR 0x100 +#define AT91SAM9X5_MATRIX_EBICSA 0x120 + +#define SAMA5D3_MATRIX_MCFG0x00 +#define SAMA5D3_MATRIX_SCFG0x40 +#define SAMA5D3_MATRIX_PRS 0x80 +#define SAMA5D3_MATRIX_MRCR0x100 + +#define AT91_MATRIX_MCFG(o, x) ((o) + ((x) * 0x4)) +#define AT91_MATRIX_ULBT GENMASK(2, 0) +#define AT91_MATRIX_ULBT_INFINITE (0 << 0) +#define AT91_MATRIX_ULBT_SINGLE(1 << 0) +#define AT91_MATRIX_ULBT_FOUR (2 << 0) +#define AT91_MATRIX_ULBT_EIGHT (3 << 0) +#define AT91_MATRIX_ULBT_SIXTEEN (4 << 0) + +#define AT91_MATRIX_SCFG(o, x) ((o) + ((x) * 0x4)) +#define AT91_MATRIX_SLOT_CYCLE GENMASK(7, 0) +#define AT91_MATRIX_DEFMSTR_TYPE GENMASK(17, 16) +#define AT91_MATRIX_DEFMSTR_TYPE_NONE (0 << 16) +#define AT91_MATRIX_DEFMSTR_TYPE_LAST (1 << 16) +#define AT91_MATRIX_DEFMSTR_TYPE_FIXED (2 << 16) +#define AT91_MATRIX_FIXED_DEFMSTR GENMASK(20, 18) +#define AT91_MATRIX_ARBT GENMASK(25, 24) +#define AT91_MATRIX_ARBT_ROUND_ROBIN (0 << 24) +#define AT91_MATRIX_ARBT_FIXED_PRIORITY(1 << 24) + +#define AT91_MATRIX_ITCM_SIZE GENMASK(3, 0) +#define AT91_MATRIX_ITCM_0 (0 << 0) +#define AT91_MATRIX_ITCM_16(5 << 0) +#define AT91_MATRIX_ITCM_32(6 << 0) +#define AT91_MATRIX_ITCM_64(7 << 0) +#defineAT91_MATRIX_DTCM_SIZE GENM
[PATCH 05/12] usb: gadget: at91_udc: Fix clock names
From: Boris Brezillon The driver is requesting clock by their global name (those declared in the clk_lookup list), but this only works with !CCF kernels. Now that all SoCs have moved to CCF, fix the driver to use local names (hclk and pclk). Signed-off-by: Boris Brezillon --- drivers/usb/gadget/udc/at91_udc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c index c862656d18b8..9ff2f7e5c6a7 100644 --- a/drivers/usb/gadget/udc/at91_udc.c +++ b/drivers/usb/gadget/udc/at91_udc.c @@ -1779,8 +1779,8 @@ static int at91udc_probe(struct platform_device *pdev) udc_reinit(udc); /* get interface and function clocks */ - udc->iclk = clk_get(dev, "udc_clk"); - udc->fclk = clk_get(dev, "udpck"); + udc->iclk = clk_get(dev, "pclk"); + udc->fclk = clk_get(dev, "hclk"); if (IS_ENABLED(CONFIG_COMMON_CLK)) udc->uclk = clk_get(dev, "usb_clk"); if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) || -- 2.1.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
[PATCH 04/12] mfd: syscon: Add Atmel SMC binding doc
From: Boris Brezillon
The SMC registers are used to configure Atmel EBI (External Bus Interface)
to interface with standard memory devices (NAND, NOR, SRAM or specialized
devices like FPGAs).
Declare this memory region as a syscon, so that different drivers can
configure the SMC interface (mostly timing configuration) according to
their need.
Signed-off-by: Boris Brezillon
Acked-by: Lee Jones
---
Documentation/devicetree/bindings/mfd/atmel-smc.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-smc.txt
diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt
b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
new file mode 100644
index ..26eeed373934
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
@@ -0,0 +1,19 @@
+* Device tree bindings for Atmel SMC (Static Memory Controller)
+
+The SMC registers are used to configure Atmel EBI (External Bus Interface)
+to interface with standard memory devices (NAND, NOR, SRAM or specialized
+devices like FPGAs).
+
+Required properties:
+- compatible: Should be one of the following
+ "atmel,at91sam9260-smc", "syscon"
+ "atmel,sama5d3-smc", "syscon"
+- reg: Contains offset/length value of the SMC memory
+ region.
+
+Example:
+
+smc: smc@c000 {
+ compatible = "atmel,sama5d3-smc", "syscon";
+ reg = <0xc000 0x1000>;
+};
--
2.1.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
[PATCH 00/12] Atmel matrix, SMC and UDC rework
Hi Felipe, The following series replace the previous series sent by Boris named: - [PATCH v5 00/11] memory: add Atmel EBI (External Bus Interface) driver - [PATCH 00/11] usb: gadget: at91_udc: Rework for multi-platform support The patches I left out are less urgent and will be resent later, probably for 3.21. Because of the dependancy between the syscon addition and the at91_udc series, this can go through the AT91 tree if you giv your ack on the udc patches. The first 4 patches introduce 2 syscon devices needed to configure the matrix and SMC. The following patches rework the at91_udc driver to prepare at91 for multi-platform support. It also include several fixes: - fix clock names to be consistent with other USB drivers - document clocks and clock-names properties in atmel-usb DT bindings doc and some cleanup changes: - remove useless usb_clk - allocate at91_udc instance instead of using the statically defined one - simplify the probe and remove functions by using devm_ helpers - remove !DT specific code Changes from the previous series: - rebased on 3.19-rc1 Boris Brezillon (12): mfd: syscon: Add atmel-matrix registers definition mfd: syscon: Add Atmel Matrix bus DT binding documentation mfd: syscon: Add atmel-smc registers definition mfd: syscon: Add Atmel SMC binding doc usb: gadget: at91_udc: Fix clock names usb: gadget: at91_udc: Drop uclk clock usb: gadget: at91_udc: Document DT clocks and clock-names property usb: gadget: at91_udc: Remove non-DT handling code usb: gadget: at91_udc: Simplify probe and remove functions usb: gadget: at91_udc: Rework for multi-platform kernel support usb: gadget: at91_udc: Update DT binding documentation usb: gadget: at91_udc: Allocate udc instance .../devicetree/bindings/mfd/atmel-matrix.txt | 24 + .../devicetree/bindings/mfd/atmel-smc.txt | 19 + .../devicetree/bindings/usb/atmel-usb.txt | 10 +- drivers/usb/gadget/udc/Kconfig | 1 + drivers/usb/gadget/udc/at91_udc.c | 525 +++-- drivers/usb/gadget/udc/at91_udc.h | 9 +- include/linux/mfd/syscon/atmel-matrix.h| 117 + include/linux/mfd/syscon/atmel-smc.h | 173 +++ 8 files changed, 623 insertions(+), 255 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/atmel-matrix.txt create mode 100644 Documentation/devicetree/bindings/mfd/atmel-smc.txt create mode 100644 include/linux/mfd/syscon/atmel-matrix.h create mode 100644 include/linux/mfd/syscon/atmel-smc.h -- 2.1.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
[PATCH 07/12] usb: gadget: at91_udc: Document DT clocks and clock-names property
From: Boris Brezillon The at91_udc driver request 2 clocks, and thus need them to be defined in the device tree. Document the clocks and clock-names properties so that everybody use the correct names. Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/usb/atmel-usb.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index bcca3f2a..6007231e0adc 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -36,6 +36,10 @@ Required properties: - compatible: Should be "atmel,at91rm9200-udc" - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt + - clocks: Should reference the peripheral and the AHB clocks + - clock-names: Should contains two strings + "pclk" for the peripheral clock + "hclk" for the AHB clock Optional properties: - atmel,vbus-gpio: If present, specifies a gpio that needs to be -- 2.1.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
[PATCH 06/12] usb: gadget: at91_udc: Drop uclk clock
From: Boris Brezillon
Now that at91 system clocks forward set_rate request to their parent we
can remove the uclk clock and directly call clk_set_rate on fclk.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 27 +++
drivers/usb/gadget/udc/at91_udc.h | 2 +-
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index 9ff2f7e5c6a7..d33f2994b7c4 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -895,8 +895,6 @@ static void clk_on(struct at91_udc *udc)
return;
udc->clocked = 1;
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_enable(udc->uclk);
clk_enable(udc->iclk);
clk_enable(udc->fclk);
}
@@ -909,8 +907,6 @@ static void clk_off(struct at91_udc *udc)
udc->gadget.speed = USB_SPEED_UNKNOWN;
clk_disable(udc->fclk);
clk_disable(udc->iclk);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_disable(udc->uclk);
}
/*
@@ -1781,25 +1777,17 @@ static int at91udc_probe(struct platform_device *pdev)
/* get interface and function clocks */
udc->iclk = clk_get(dev, "pclk");
udc->fclk = clk_get(dev, "hclk");
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- udc->uclk = clk_get(dev, "usb_clk");
- if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) ||
- (IS_ENABLED(CONFIG_COMMON_CLK) && IS_ERR(udc->uclk))) {
+ if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
DBG("clocks missing\n");
retval = -ENODEV;
goto fail1;
}
/* don't do anything until we have both gadget driver and VBUS */
- if (IS_ENABLED(CONFIG_COMMON_CLK)) {
- clk_set_rate(udc->uclk, 4800);
- retval = clk_prepare(udc->uclk);
- if (retval)
- goto fail1;
- }
+ clk_set_rate(udc->fclk, 4800);
retval = clk_prepare(udc->fclk);
if (retval)
- goto fail1a;
+ goto fail1;
retval = clk_prepare_enable(udc->iclk);
if (retval)
@@ -1873,12 +1861,7 @@ fail1c:
clk_unprepare(udc->iclk);
fail1b:
clk_unprepare(udc->fclk);
-fail1a:
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_unprepare(udc->uclk);
fail1:
- if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
- clk_put(udc->uclk);
if (!IS_ERR(udc->fclk))
clk_put(udc->fclk);
if (!IS_ERR(udc->iclk))
@@ -1924,15 +1907,11 @@ static int __exit at91udc_remove(struct platform_device
*pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_unprepare(udc->uclk);
clk_unprepare(udc->fclk);
clk_unprepare(udc->iclk);
clk_put(udc->iclk);
clk_put(udc->fclk);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(udc->uclk);
return 0;
}
diff --git a/drivers/usb/gadget/udc/at91_udc.h
b/drivers/usb/gadget/udc/at91_udc.h
index 017524663381..e647d1c2ada4 100644
--- a/drivers/usb/gadget/udc/at91_udc.h
+++ b/drivers/usb/gadget/udc/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8 addr;
struct at91_udc_databoard;
- struct clk *iclk, *fclk, *uclk;
+ struct clk *iclk, *fclk;
struct platform_device *pdev;
struct proc_dir_entry *pde;
void __iomem*udp_baseaddr;
--
2.1.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
[PATCH 08/12] usb: gadget: at91_udc: Remove non-DT handling code
From: Boris Brezillon
Since non-DT board support has been removed from the at91 architecture we
can safely remove non-DT handling code.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/Kconfig| 1 +
drivers/usb/gadget/udc/at91_udc.c | 16 ++--
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index b8e213eb36cc..366e551aeff0 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -32,6 +32,7 @@ menu "USB Peripheral Controller"
config USB_AT91
tristate "Atmel AT91 USB Device Port"
depends on ARCH_AT91
+ depends on OF || COMPILE_TEST
help
Many Atmel AT91 processors (such as the AT91RM2000) have a
full speed USB Device Port with support for five configurable
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index d33f2994b7c4..be7e16037ac4 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1710,12 +1710,6 @@ static int at91udc_probe(struct platform_device *pdev)
int retval;
struct resource *res;
- if (!dev_get_platdata(dev) && !pdev->dev.of_node) {
- /* small (so we copy it) but critical! */
- DBG("missing platform_data\n");
- return -ENODEV;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
@@ -1728,11 +1722,7 @@ static int at91udc_probe(struct platform_device *pdev)
/* init software state */
udc = &controller;
udc->gadget.dev.parent = dev;
- if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
- at91udc_of_init(udc, pdev->dev.of_node);
- else
- memcpy(&udc->board, dev_get_platdata(dev),
- sizeof(struct at91_udc_data));
+ at91udc_of_init(udc, pdev->dev.of_node);
udc->pdev = pdev;
udc->enabled = 0;
spin_lock_init(&udc->lock);
@@ -1968,14 +1958,12 @@ static int at91udc_resume(struct platform_device *pdev)
#defineat91udc_resume NULL
#endif
-#if defined(CONFIG_OF)
static const struct of_device_id at91_udc_dt_ids[] = {
{ .compatible = "atmel,at91rm9200-udc" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, at91_udc_dt_ids);
-#endif
static struct platform_driver at91_udc_driver = {
.remove = __exit_p(at91udc_remove),
@@ -1984,7 +1972,7 @@ static struct platform_driver at91_udc_driver = {
.resume = at91udc_resume,
.driver = {
.name = (char *) driver_name,
- .of_match_table = of_match_ptr(at91_udc_dt_ids),
+ .of_match_table = at91_udc_dt_ids,
},
};
--
2.1.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
[PATCH 02/12] mfd: syscon: Add Atmel Matrix bus DT binding documentation
From: Boris Brezillon
The Matrix registers are provided to configure internal bus behavior on
at91 SoCs.
Some registers might be accessed by several drivers (e.g. to configure
external memory bus timings), hence we declare this register set as a
syscon device.
Signed-off-by: Boris Brezillon
Acked-by: Lee Jones
---
.../devicetree/bindings/mfd/atmel-matrix.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-matrix.txt
diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
new file mode 100644
index ..e3ef50ca02a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
@@ -0,0 +1,24 @@
+* Device tree bindings for Atmel Bus Matrix
+
+The Bus Matrix registers are used to configure Atmel SoCs internal bus
+behavior (master/slave priorities, undefined burst length type, ...)
+
+Required properties:
+- compatible: Should be one of the following
+ "atmel,at91sam9260-matrix", "syscon"
+ "atmel,at91sam9261-matrix", "syscon"
+ "atmel,at91sam9263-matrix", "syscon"
+ "atmel,at91sam9rl-matrix", "syscon"
+ "atmel,at91sam9g45-matrix", "syscon"
+ "atmel,at91sam9n12-matrix", "syscon"
+ "atmel,at91sam9x5-matrix", "syscon"
+ "atmel,sama5d3-matrix", "syscon"
+- reg: Contains offset/length value of the Bus Matrix
+ memory region.
+
+Example:
+
+matrix: matrix@ec00 {
+ compatible = "atmel,sama5d3-matrix", "syscon";
+ reg = <0xec00 0x200>;
+};
--
2.1.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
[PATCH 09/12] usb: gadget: at91_udc: Simplify probe and remove functions
From: Boris Brezillon
Make use of devm_ functions to simplify probe and remove code.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 116 +-
1 file changed, 39 insertions(+), 77 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index be7e16037ac4..4dba2c65dfd4 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1710,15 +1710,6 @@ static int at91udc_probe(struct platform_device *pdev)
int retval;
struct resource *res;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENXIO;
-
- if (!request_mem_region(res->start, resource_size(res), driver_name)) {
- DBG("someone's using UDC memory\n");
- return -EBUSY;
- }
-
/* init software state */
udc = &controller;
udc->gadget.dev.parent = dev;
@@ -1731,13 +1722,13 @@ static int at91udc_probe(struct platform_device *pdev)
if (cpu_is_at91rm9200()) {
if (!gpio_is_valid(udc->board.pullup_pin)) {
DBG("no D+ pullup?\n");
- retval = -ENODEV;
- goto fail0;
+ return -ENODEV;
}
- retval = gpio_request(udc->board.pullup_pin, "udc_pullup");
+ retval = devm_gpio_request(dev, udc->board.pullup_pin,
+ "udc_pullup");
if (retval) {
DBG("D+ pullup is busy\n");
- goto fail0;
+ return retval;
}
gpio_direction_output(udc->board.pullup_pin,
udc->board.pullup_active_low);
@@ -1756,32 +1747,32 @@ static int at91udc_probe(struct platform_device *pdev)
udc->ep[3].maxpacket = 64;
}
- udc->udp_baseaddr = ioremap(res->start, resource_size(res));
- if (!udc->udp_baseaddr) {
- retval = -ENOMEM;
- goto fail0a;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ udc->udp_baseaddr = devm_ioremap_resource(dev, res);
+ if (IS_ERR(udc->udp_baseaddr))
+ return PTR_ERR(udc->udp_baseaddr);
udc_reinit(udc);
/* get interface and function clocks */
- udc->iclk = clk_get(dev, "pclk");
- udc->fclk = clk_get(dev, "hclk");
- if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
- DBG("clocks missing\n");
- retval = -ENODEV;
- goto fail1;
- }
+ udc->iclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(udc->iclk))
+ return PTR_ERR(udc->iclk);
+
+ udc->fclk = devm_clk_get(dev, "hclk");
+ if (IS_ERR(udc->fclk))
+ return PTR_ERR(udc->fclk);
/* don't do anything until we have both gadget driver and VBUS */
clk_set_rate(udc->fclk, 4800);
retval = clk_prepare(udc->fclk);
if (retval)
- goto fail1;
+ return retval;
retval = clk_prepare_enable(udc->iclk);
if (retval)
- goto fail1b;
+ goto err_unprepare_fclk;
+
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
at91_udp_write(udc, AT91_UDP_IDR, 0x);
/* Clear all pending interrupts - UDP may be used by bootloader. */
@@ -1790,18 +1781,21 @@ static int at91udc_probe(struct platform_device *pdev)
/* request UDC and maybe VBUS irqs */
udc->udp_irq = platform_get_irq(pdev, 0);
- retval = request_irq(udc->udp_irq, at91_udc_irq,
- 0, driver_name, udc);
- if (retval < 0) {
+ retval = devm_request_irq(dev, udc->udp_irq, at91_udc_irq, 0,
+ driver_name, udc);
+ if (retval) {
DBG("request irq %d failed\n", udc->udp_irq);
- goto fail1c;
+ goto err_unprepare_iclk;
}
+
if (gpio_is_valid(udc->board.vbus_pin)) {
- retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
- if (retval < 0) {
+ retval = devm_gpio_request(dev, udc->board.vbus_pin,
+ "udc_vbus");
+ if (retval) {
DBG("request vbus pin failed\n");
- goto fail2;
+ goto err_unprepare_iclk;
}
+
gpio_direction_input(udc->board.vbus_pin);
/*
@@ -1818,12 +1812,13 @@ static int at91udc_probe(struct platform_device *pdev)
mod_timer(&udc->vbus_timer,
jiffies + VBUS_POLL_TIMEOUT);
} else {
- if (request_irq(gpio_to_irq(udc->board.vbus_pin),
-
[PATCH 10/12] usb: gadget: at91_udc: Rework for multi-platform kernel support
From: Boris Brezillon
cpu_is_at91xxx are a set of macros defined in mach/cpu.h and are here used
to detect the SoC we are booting on.
Use compatible string + a caps structure to replace those cpu_is_xxx tests.
Remove all mach and asm headers (which are now unused).
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 288 --
drivers/usb/gadget/udc/at91_udc.h | 7 +
2 files changed, 218 insertions(+), 77 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index 4dba2c65dfd4..c0abb9bc76a9 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -31,16 +31,9 @@
#include
#include
#include
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
+#include
+#include
+#include
#include "at91_udc.h"
@@ -915,8 +908,6 @@ static void clk_off(struct at91_udc *udc)
*/
static void pullup(struct at91_udc *udc, int is_on)
{
- int active = !udc->board.pullup_active_low;
-
if (!udc->enabled || !udc->vbus)
is_on = 0;
DBG("%sactive\n", is_on ? "" : "in");
@@ -925,40 +916,15 @@ static void pullup(struct at91_udc *udc, int is_on)
clk_on(udc);
at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, 0);
- if (cpu_is_at91rm9200())
- gpio_set_value(udc->board.pullup_pin, active);
- else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
cpu_is_at91sam9g20()) {
- u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
-
- txvc |= AT91_UDP_TXVC_PUON;
- at91_udp_write(udc, AT91_UDP_TXVC, txvc);
- } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
- u32 usbpucr;
-
- usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
- usbpucr |= AT91_MATRIX_USBPUCR_PUON;
- at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
- }
} else {
stop_activity(udc);
at91_udp_write(udc, AT91_UDP_IDR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
- if (cpu_is_at91rm9200())
- gpio_set_value(udc->board.pullup_pin, !active);
- else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
cpu_is_at91sam9g20()) {
- u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
-
- txvc &= ~AT91_UDP_TXVC_PUON;
- at91_udp_write(udc, AT91_UDP_TXVC, txvc);
- } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
- u32 usbpucr;
-
- usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
- usbpucr &= ~AT91_MATRIX_USBPUCR_PUON;
- at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
- }
clk_off(udc);
}
+
+ if (udc->caps && udc->caps->pullup)
+ udc->caps->pullup(udc, is_on);
}
/* vbus is here! turn everything on that's ready */
@@ -1683,12 +1649,202 @@ static void at91udc_shutdown(struct platform_device
*dev)
spin_unlock_irqrestore(&udc->lock, flags);
}
-static void at91udc_of_init(struct at91_udc *udc,
-struct device_node *np)
+static int at91rm9200_udc_init(struct at91_udc *udc)
+{
+ struct at91_ep *ep;
+ int ret;
+ int i;
+
+ for (i = 0; i < NUM_ENDPOINTS; i++) {
+ ep = &udc->ep[i];
+
+ switch (i) {
+ case 0:
+ case 3:
+ ep->maxpacket = 8;
+ break;
+ case 1 ... 2:
+ ep->maxpacket = 64;
+ break;
+ case 4 ... 5:
+ ep->maxpacket = 256;
+ break;
+ }
+ }
+
+ if (!gpio_is_valid(udc->board.pullup_pin)) {
+ DBG("no D+ pullup?\n");
+ return -ENODEV;
+ }
+
+ ret = devm_gpio_request(&udc->pdev->dev, udc->board.pullup_pin,
+ "udc_pullup");
+ if (ret) {
+ DBG("D+ pullup is busy\n");
+ return ret;
+ }
+
+ gpio_direction_output(udc->board.pullup_pin,
+ udc->board.pullup_active_low);
+
+ return 0;
+}
+
+static void at91rm9200_udc_pullup(struct at91_udc *udc, int is_on)
+{
+ int active = !udc->board.pullup_active_low;
+
+ if (is_on)
+ gpio_set_value(udc->board.pullup_pin, active);
+ else
+ gpio_set_value(udc->board.pullup_pin, !active);
+}
+
+static const struct at91_udc_caps at91rm9200_udc_caps = {
+ .init
[PATCH 11/12] usb: gadget: at91_udc: Update DT binding documentation
From: Boris Brezillon
Three compatible strings have been added to the at91_udc driver.
Update the documentation accordingly.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/usb/atmel-usb.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 6007231e0adc..54a81219caae 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -33,7 +33,11 @@ usb1: ehci@0080 {
AT91 USB device controller
Required properties:
- - compatible: Should be "atmel,at91rm9200-udc"
+ - compatible: Should be one of the following
+ "atmel,at91rm9200-udc"
+ "atmel,at91sam9260-udc"
+ "atmel,at91sam9261-udc"
+ "atmel,at91sam9263-udc"
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- clocks: Should reference the peripheral and the AHB clocks
--
2.1.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
[PATCH 12/12] usb: gadget: at91_udc: Allocate udc instance
From: Boris Brezillon
Allocate udc structure instead of relying on the statically declared
object.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 96 +++
1 file changed, 26 insertions(+), 70 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index c0abb9bc76a9..6d285226ab94 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -59,7 +59,15 @@
#defineDRIVER_VERSION "3 May 2006"
static const char driver_name [] = "at91_udc";
-static const char ep0name[] = "ep0";
+static const char * const ep_names[] = {
+ "ep0",
+ "ep1",
+ "ep2",
+ "ep3-int",
+ "ep4",
+ "ep5",
+};
+#define ep0nameep_names[0]
#define VBUS_POLL_TIMEOUT msecs_to_jiffies(1000)
@@ -1497,74 +1505,6 @@ static irqreturn_t at91_udc_irq (int irq, void *_udc)
/*-*/
-static struct at91_udc controller = {
- .gadget = {
- .ops= &at91_udc_ops,
- .ep0= &controller.ep[0].ep,
- .name = driver_name,
- },
- .ep[0] = {
- .ep = {
- .name = ep0name,
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .maxpacket = 8,
- .int_mask = 1 << 0,
- },
- .ep[1] = {
- .ep = {
- .name = "ep1",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 64,
- .int_mask = 1 << 1,
- },
- .ep[2] = {
- .ep = {
- .name = "ep2",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 64,
- .int_mask = 1 << 2,
- },
- .ep[3] = {
- .ep = {
- /* could actually do bulk too */
- .name = "ep3-int",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .maxpacket = 8,
- .int_mask = 1 << 3,
- },
- .ep[4] = {
- .ep = {
- .name = "ep4",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 256,
- .int_mask = 1 << 4,
- },
- .ep[5] = {
- .ep = {
- .name = "ep5",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 256,
- .int_mask = 1 << 5,
- },
- /* ep6 and ep7 are also reserved (custom silicon might use them) */
-};
-
static void at91_vbus_update(struct at91_udc *udc, unsigned value)
{
value ^= udc->board.vbus_active_low;
@@ -1872,15 +1812,31 @@ static int at91udc_probe(struct platform_device *pdev)
struct at91_ep *ep;
int i;
+ udc = devm_kzalloc(dev, sizeof(*udc), GFP_KERNEL);
+ if (!udc)
+ return -ENOMEM;
+
/* init software state */
- udc = &controller;
udc->gadget.dev.parent = dev;
at91udc_of_init(udc, pdev->dev.of_node);
udc->pdev = pdev;
udc->enabled = 0;
spin_lock_init(&udc->lock);
+ udc->gadget.ops = &at91_udc_ops;
+ udc->gadget.ep0 = &udc->ep[0].ep;
+ udc->gadget.name = driver_name;
+ udc->gadget.dev.init_name = "gadget";
+ for (i = 0; i < NUM_ENDPOINTS; i++) {
+ ep = &udc->ep[i];
+ ep->ep.name = ep_names[i];
+ ep->ep.ops = &at91_ep_ops;
+ ep->udc = udc;
+ ep->int_mask = BIT(i);
+ if (i != 0 && i != 3)
+ ep->is_pingpong = 1;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
udc->udp_baseaddr = devm_ioremap_resource(dev, res);
--
2.1.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] usb/musb: debugfs, fix copy_from_user argument
Hi, On Wed, Jan 14, 2015 at 03:19:42PM +, David Laight wrote: > From: Markus Pargmann > > The first arugment has to be a pointer to the memory. buf is a char > > array and already a pointer itself. The current code passes a pointer to > > a char array to copy_from_user() which is not correct. > > It doesn't matter, while the type of the argument is subtly different the > value passed is the same. Thanks, I didn't know about this. So the code is actually correct and the patch is not a fix. I would still prefer to have it consistent with the usage of 'buf' in the code above and below, where 'buf' is directly used. Best regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
dwc3 gadget fails on dra7-evm
Hi, In 3.19-rc4 on dra7-evm or dra72-evm modprobe g_zero [ 34.680683] zero gadget: Gadget Zero, version: Cinco de Mayo 2008 [ 34.687074] zero gadget: zero ready [ 34.694133] dwc3 4889.usb: failed to enable ep0out [ 34.701600] zero 4889.usb: failed to start zero: -110 ERROR: could not insert 'g_zero': Connection timed out my u-boot version is v2015.01 cheers, -roger -- 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/4] cdc-wdm: add sanity checks
Check the CDC headers for elements with insufficient length.
Other popular operating systems filter then, too.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-wdm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index a051a7a..6647f37 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -875,6 +875,7 @@ static int wdm_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct usb_cdc_dmm_desc *dmhd;
u8 *buffer = intf->altsetting->extra;
int buflen = intf->altsetting->extralen;
+ unsigned int elen = 0;
u16 maxcom = WDM_DEFAULT_BUFSIZE;
if (!buffer)
@@ -884,11 +885,13 @@ static int wdm_probe(struct usb_interface *intf, const
struct usb_device_id *id)
dev_err(&intf->dev, "skipping garbage\n");
goto next_desc;
}
-
+ elen = buffer[0];
switch (buffer[2]) {
case USB_CDC_HEADER_TYPE:
break;
case USB_CDC_DMM_TYPE:
+ if (elen < sizeof(struct usb_cdc_dmm_desc))
+ break;
dmhd = (struct usb_cdc_dmm_desc *)buffer;
maxcom = le16_to_cpu(dmhd->wMaxCommand);
dev_dbg(&intf->dev,
@@ -901,8 +904,8 @@ static int wdm_probe(struct usb_interface *intf, const
struct usb_device_id *id)
break;
}
next_desc:
- buflen -= buffer[0];
- buffer += buffer[0];
+ buflen -= elen;
+ buffer += elen;
}
iface = intf->cur_altsetting;
--
1.8.4.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] usb/musb: debugfs, fix copy_from_user argument
From: Markus Pargmann > The first arugment has to be a pointer to the memory. buf is a char > array and already a pointer itself. The current code passes a pointer to > a char array to copy_from_user() which is not correct. It doesn't matter, while the type of the argument is subtly different the value passed is the same. David > Signed-off-by: Markus Pargmann > --- > drivers/usb/musb/musb_debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c > index ad3701a97389..bb13e0420140 100644 > --- a/drivers/usb/musb/musb_debugfs.c > +++ b/drivers/usb/musb/musb_debugfs.c > @@ -194,7 +194,7 @@ static ssize_t musb_test_mode_write(struct file *file, > > memset(buf, 0x00, sizeof(buf)); > > - if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) > + if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) > return -EFAULT; > > if (!strncmp(buf, "force host", 9)) > -- > 2.1.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 -- 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/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
On Wed, Jan 14, 2015 at 02:39:55PM +0530, Amit Virdi wrote: > >Alright, I just applied your patches to testing/fixes. I'll start > >testing today and should be able to send a pull request to Greg by the > >end of the week, hopefully. > > > > Thanks! Just a small clarification - git failed to send patches to stable > kernel list again (unfortunately I used the older configuration; so older > git version - my bad). > > Does these patches land up in the stable trees through maintainers or I > should explicitly cc sta...@vger.kernel.org now? Please read Documentation/stable_kernel_rules.txt for how to get patches accepted into the stable trees. 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
[PATCH 3/4] cdc-acm: kill unnecessary messages
Memory allocation failures are reported by a central facility.
No need to repeat the job.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 33 +
1 file changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 8eadb38..74c605a 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1297,10 +1297,8 @@ made_compressed_probe:
dev_dbg(&intf->dev, "interfaces are valid\n");
acm = kzalloc(sizeof(struct acm), GFP_KERNEL);
- if (acm == NULL) {
- dev_err(&intf->dev, "out of memory (acm kzalloc)\n");
+ if (acm == NULL)
goto alloc_fail;
- }
minor = acm_alloc_minor(acm);
if (minor == ACM_TTY_MINORS) {
@@ -1339,42 +1337,32 @@ made_compressed_probe:
acm->quirks = quirks;
buf = usb_alloc_coherent(usb_dev, ctrlsize, GFP_KERNEL, &acm->ctrl_dma);
- if (!buf) {
- dev_err(&intf->dev, "out of memory (ctrl buffer alloc)\n");
+ if (!buf)
goto alloc_fail2;
- }
acm->ctrl_buffer = buf;
- if (acm_write_buffers_alloc(acm) < 0) {
- dev_err(&intf->dev, "out of memory (write buffer alloc)\n");
+ if (acm_write_buffers_alloc(acm) < 0)
goto alloc_fail4;
- }
acm->ctrlurb = usb_alloc_urb(0, GFP_KERNEL);
- if (!acm->ctrlurb) {
- dev_err(&intf->dev, "out of memory (ctrlurb kmalloc)\n");
+ if (!acm->ctrlurb)
goto alloc_fail5;
- }
+
for (i = 0; i < num_rx_buf; i++) {
struct acm_rb *rb = &(acm->read_buffers[i]);
struct urb *urb;
rb->base = usb_alloc_coherent(acm->dev, readsize, GFP_KERNEL,
&rb->dma);
- if (!rb->base) {
- dev_err(&intf->dev, "out of memory "
- "(read bufs usb_alloc_coherent)\n");
+ if (!rb->base)
goto alloc_fail6;
- }
rb->index = i;
rb->instance = acm;
urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!urb) {
- dev_err(&intf->dev,
- "out of memory (read urbs usb_alloc_urb)\n");
+ if (!urb)
goto alloc_fail6;
- }
+
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
urb->transfer_dma = rb->dma;
if (acm->is_int_ep) {
@@ -1399,11 +1387,8 @@ made_compressed_probe:
struct acm_wb *snd = &(acm->wb[i]);
snd->urb = usb_alloc_urb(0, GFP_KERNEL);
- if (snd->urb == NULL) {
- dev_err(&intf->dev,
- "out of memory (write urbs usb_alloc_urb)\n");
+ if (snd->urb == NULL)
goto alloc_fail7;
- }
if (usb_endpoint_xfer_int(epwrite))
usb_fill_int_urb(snd->urb, usb_dev,
--
1.8.4.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 1/4] cdc-acm: add sanity checks
Check the special CDC headers for a plausible minimum length.
Another big operating systems ignores such garbage.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 546a17e8..8eadb38 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1091,6 +1091,7 @@ static int acm_probe(struct usb_interface *intf,
unsigned long quirks;
int num_rx_buf;
int i;
+ unsigned int elength = 0;
int combined_interfaces = 0;
struct device *tty_dev;
int rv = -ENOMEM;
@@ -1136,9 +1137,12 @@ static int acm_probe(struct usb_interface *intf,
dev_err(&intf->dev, "skipping garbage\n");
goto next_desc;
}
+ elength = buffer[0];
switch (buffer[2]) {
case USB_CDC_UNION_TYPE: /* we've found it */
+ if (elength < sizeof(struct usb_cdc_union_desc))
+ break;
if (union_header) {
dev_err(&intf->dev, "More than one "
"union descriptor, skipping ...\n");
@@ -1147,14 +1151,20 @@ static int acm_probe(struct usb_interface *intf,
union_header = (struct usb_cdc_union_desc *)buffer;
break;
case USB_CDC_COUNTRY_TYPE: /* export through sysfs*/
+ if (elength < sizeof(struct
usb_cdc_country_functional_desc))
+ break;
cfd = (struct usb_cdc_country_functional_desc *)buffer;
break;
case USB_CDC_HEADER_TYPE: /* maybe check version */
break; /* for now we ignore it */
case USB_CDC_ACM_TYPE:
+ if (elength < 3)
+ break;
ac_management_function = buffer[3];
break;
case USB_CDC_CALL_MANAGEMENT_TYPE:
+ if (elength < 4)
+ break;
call_management_function = buffer[3];
call_interface_num = buffer[4];
break;
@@ -1163,13 +1173,13 @@ static int acm_probe(struct usb_interface *intf,
* could legitimately be found here.
*/
dev_dbg(&intf->dev, "Ignoring descriptor: "
- "type %02x, length %d\n",
- buffer[2], buffer[0]);
+ "type %02x, length %ud\n",
+ buffer[2], elength);
break;
}
next_desc:
- buflen -= buffer[0];
- buffer += buffer[0];
+ buflen -= elength;
+ buffer += elength;
}
if (!union_header) {
--
1.8.4.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] usb/musb: debugfs, fix copy_from_user argument
The first arugment has to be a pointer to the memory. buf is a char array and already a pointer itself. The current code passes a pointer to a char array to copy_from_user() which is not correct. Signed-off-by: Markus Pargmann --- drivers/usb/musb/musb_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c index ad3701a97389..bb13e0420140 100644 --- a/drivers/usb/musb/musb_debugfs.c +++ b/drivers/usb/musb/musb_debugfs.c @@ -194,7 +194,7 @@ static ssize_t musb_test_mode_write(struct file *file, memset(buf, 0x00, sizeof(buf)); - if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) + if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) return -EFAULT; if (!strncmp(buf, "force host", 9)) -- 2.1.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] Added PIDs for Actisense USB Devices
Mark Glover wrote: > From: Mark Glover > > Signed-off-by: Mark Glover There's an extraneous leading whitespace on the Signed-off-by line. > +#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */ The typo remains. "Apadter" here ^ //Peter -- 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] Added PIDs for Actisense USB Devices
From: Mark Glover
Signed-off-by: Mark Glover
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb351..a118e5b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -978,6 +978,23 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ /* Active Research (Actisense) devices */
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NDC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_USG_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGT_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGW_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AF_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASWITCH_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_NMEA2000_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ETHERNET_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_WIFI_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serials/ftdi_sio_ids.h
index e52409c..8ccd1b6 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1438,3 +1438,24 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Active Research (Actisense) devices
+ */
+#define ACTISENSE_NDC_PID 0xD9A8 /* NDC USB Serial Adapter */
+#define ACTISENSE_USG_PID 0xD9A9 /* USG USB Serial Adapter */
+#define ACTISENSE_NGT_PID 0xD9AA /* NGT NMEA2000 Interface */
+#define ACTISENSE_NGW_PID 0xD9AB /* NGW NMEA2000 Gateway */
+#define ACTISENSE_D9AC_PID 0xD9AC /* Actisense Reserved */
+#define ACTISENSE_D9AD_PID 0xD9AD /* Actisense Reserved */
+#define ACTISENSE_D9AE_PID 0xD9AE /* Actisense Reserved */
+#define ACTISENSE_D9AF_PID 0xD9AF /* Actisense Reserved */
+#define CHETCO_SEAGAUGE_PID0xA548 /* SeaGauge USB Adapter */
+#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */
+#define CHETCO_SEASMART_NMEA2000_PID 0xA54A /* SeaSmart NMEA2000 Gateway */
+#define CHETCO_SEASMART_ETHERNET_PID 0xA54B /* SeaSmart Ethernet Gateway */
+#define CHETCO_SEASMART_WIFI_PID 0xA5AC /* SeaSmart Wifi Gateway */
+#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
+#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
+#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
--
1.7.9.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: [Bug 90941] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
On 08.01.2015 02:02, Cristian wrote: > Hello Gurus, > > See message of dmesg: > > [ 5136.529349] xhci_hcd :00:14.0: Setup ERROR: setup context > command for slot 1. > [ 5136.529351] usb 1-1: hub failed to enable device, error -22 > [ 5136.788988] usb 1-1: reset low-speed USB device number 2 using xhci_hcd > [ 5136.789008] xhci_hcd :00:14.0: Setup ERROR: setup context > command for slot 1. > [ 5136.789011] usb 1-1: hub failed to enable device, error -22 > > https://bugzilla.kernel.org/show_bug.cgi?id=90941 > > Many thanks for you work, > This should be fixed by: commit f161ead70fa6a62e432dff6e9dab8e3cfbeabea6 xhci: Check if slot is already in default state before moving it there In Greg's usb-linus tree, It's on its way to Linus tree and should be in final 3.19 (Added same info to bugzilla) -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
Re: [PATCH] Added PIDs for Actisense USB Devices Signed-off-by: Mark Glover
Please update your commit message to leave one blank line between the commit message summary and the rest of the message. (This avoids your signed-off-by ending up in the email subject.) Mark Glover wrote: > +++ b/drivers/usb/serial/ftdi_sio_ids.h .. > +#define CHETCO_SEAGAUGE_PID 0xA548 /* SeaGauge USB Adapter */ > +#define CHETCO_SEAGAUGE__PID 0xA549 /* SeaSwitch USG Apadter */ Please make the macro name match the product name. Also note typo^ here. //Peter -- 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] Added PIDs for Actisense USB Devices Signed-off-by: Mark Glover
From: Mark Glover
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb351..a118e5b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -978,6 +978,23 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ /* Active Research (Actisense) devices */
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NDC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_USG_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGT_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGW_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AF_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE__PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_NMEA2000_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ETHERNET_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_WIFI_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e52409c..8ccd1b6 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1438,3 +1438,24 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Active Research (Actisense) devices
+ */
+#define ACTISENSE_NDC_PID 0xD9A8 /* NDC USB Serial Adapter */
+#define ACTISENSE_USG_PID 0xD9A9 /* USG USB Serial Adapter */
+#define ACTISENSE_NGT_PID 0xD9AA /* NGT NMEA2000 Interface */
+#define ACTISENSE_NGW_PID 0xD9AB /* NGW NMEA2000 Gateway */
+#define ACTISENSE_D9AC_PID 0xD9AC /* Actisense Reserved */
+#define ACTISENSE_D9AD_PID 0xD9AD /* Actisense Reserved */
+#define ACTISENSE_D9AE_PID 0xD9AE /* Actisense Reserved */
+#define ACTISENSE_D9AF_PID 0xD9AF /* Actisense Reserved */
+#define CHETCO_SEAGAUGE_PID0xA548 /* SeaGauge USB Adapter */
+#define CHETCO_SEAGAUGE__PID 0xA549 /* SeaSwitch USG Apadter */
+#define CHETCO_SEASMART_NMEA2000_PID 0xA54A /* SeaSmart NMEA2000 Gateway */
+#define CHETCO_SEASMART_ETHERNET_PID 0xA54B /* SeaSmart Ethernet Gateway */
+#define CHETCO_SEASMART_WIFI_PID 0xA5AC /* SeaSmart Wifi Gateway */
+#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
+#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
+#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
--
1.7.9.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: BUG: xhci_queue_new_dequeue_state dereference a NULL pointer
Hi On 14.01.2015 08:04, c-aries wrote: > I have an x86 PC, it oops, and I took a screenshot: > http://babyaries.org/mirror/picture/2015-01-13-165845_1600x900_scrot.png > > > Then I browsed the xhci source code, compared with the oops machine code: > http://babyaries.org/mirror/picture/2015-01-14-113248_1600x900_scrot.png > > I found that it's because deq_state->new_deq_seg is an invalid pointer > that makes my PC oops. > -- >From the logs it looks like you're using a 3.13 kernel. There were some major changes in 3.17 regarding finding the new dequeue pointer (e.g. new_deq_seg and new_deq_ptr) in: commit 365038d83313951d6ace15342eb24624bbef1666 xhci: rework cycle bit checking for new dequeue pointers It sets the new deq_seg and deq_ptr to NULL if the new state can't be found, also adds checks for those pointers before calling xhci_queue_new_dequeue_state() Have you seen this with a 3.17 or later kernel? -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
Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
Alright, I just applied your patches to testing/fixes. I'll start testing today and should be able to send a pull request to Greg by the end of the week, hopefully. Thanks! Just a small clarification - git failed to send patches to stable kernel list again (unfortunately I used the older configuration; so older git version - my bad). Does these patches land up in the stable trees through maintainers or I should explicitly cc sta...@vger.kernel.org now? -- 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
USB-serial fixes for v3.19-rc5
Hi Greg, Here's my first set of fixes for 3.19, somewhat late partially due to the holidays. Please pull. Thanks, Johan The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6: Linux 3.19-rc2 (2014-12-28 16:49:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.19-rc5 for you to fetch changes up to 04f9c6e6d17584340fb6c8a9469a0e6df28876d2: usb: serial: handle -ENODEV quietly in generic_submit_read_urb (2015-01-12 10:23:54 +0100) USB-serial fixes for v3.18-rc5 Here are a few fixes for reported problems including a possible null-deref on probe with keyspan, a misbehaving modem, and a couple of issues with the USB console. Some new device IDs are also added. Signed-off-by: Johan Hovold David Peterson (1): USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices Jeremiah Mahler (2): usb: serial: silence all non-critical read errors usb: serial: handle -ENODEV quietly in generic_submit_read_urb Johan Hovold (3): USB: keyspan: fix null-deref at probe USB: console: fix uninitialised ldisc semaphore USB: console: fix potential use after free Preston Fick (1): USB: cp210x: fix ID for production CEL MeshConnect USB Stick Reinhard Speyerer (1): USB: qcserial/option: make AT URCs work for Sierra Wireless MC73xx drivers/usb/serial/console.c | 16 +++- drivers/usb/serial/cp210x.c | 4 +++- drivers/usb/serial/generic.c | 4 ++-- drivers/usb/serial/keyspan.c | 20 +++- drivers/usb/serial/option.c | 11 ++- drivers/usb/serial/qcserial.c | 1 - 6 files changed, 41 insertions(+), 15 deletions(-) -- 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
