usb3 disk drive not being recognized properly
I have a Seagate backup plus 3TB usb3 drive that seems to be recognized. I get no /dev/sdx device associated with it unless I unplug it and plug it in after the kernel is loaded. I can see this. Bus 004 Device 002: ID 0bc2:a0a1 Seagate RSS LLC But the light on the device turns completely off and I have no /dev/sdb Once I unplug it and plug it in again, the light comes on. Bus 004 Device 003: ID 0bc2:a0a1 Seagate RSS LLC And the /dev/sdb is created. Relevant dmesg output. http://pastebin.com/3DXFyGCf -- 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: usb3 disk drive not being recognized properly
vekin vekinn@... writes: I have a Seagate backup plus 3TB usb3 drive that seems to be recognized. I get no /dev/sdx device associated with it unless I unplug it and plug it in after the kernel is loaded. I only now just realized that the problem only occurs when I use reboot not shutdown -h now. If I shutdown -h now the drive works as expected on the next boot. -- 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
Why usb's remote wakeup relys on CONFIG_USB_SUSPEND
I am a new fish of linux usb host driver developper. Recently, when developping the host's PM function, I found that usb's remote wakeup relys on CONFIG_USB_SUSPEND. I do not know why we need such a restriction. Is it means if a usb host driver without the implementation of runtime suspend also can not(should not) support remote wakeup? Anyone would like to give me some help? Best Regards! ShiJinghui -- 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] usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep
When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip,
which for a request with USB_RECIP_ENDPOINT tries to map this to an interface
to see if this interface is claimed, except for ctrl-requests with a type of
USB_TYPE_VENDOR.
When trying to use this device: http://www.akaipro.com/eiepro
redirected to a Windows vm running on qemu on top of Linux.
The windows driver makes a ctrl-req with USB_TYPE_CLASS and
USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to
the interface fails since ep 0 is the ctrl endpoint and thus never is
part of an interface.
This patch fixes this ctrl-req failing by skipping the checkintf call for
USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint.
Reported-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl
Tested-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/devio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 8823e98..caefc80 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -739,6 +739,8 @@ static int check_ctrlrecip(struct dev_state *ps, unsigned
int requesttype,
index = 0xff;
switch (requesttype USB_RECIP_MASK) {
case USB_RECIP_ENDPOINT:
+ if ((index ~USB_DIR_IN) == 0)
+ return 0;
ret = findintfep(ps-dev, index);
if (ret = 0)
ret = checkintf(ps, ret);
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable-3.8] net: cdc_mbim: remove bogus sizeof()
The intention was to test against the constant, not the size of
the constant.
Signed-off-by: Bjørn Mork bj...@mork.no
---
This should go to stable-3.8 (and stable-3.9 if too late for v3.9).
Thanks.
Bjørn
drivers/net/usb/cdc_mbim.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 16c8429..6bd9167 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -134,7 +134,7 @@ static struct sk_buff *cdc_mbim_tx_fixup(struct usbnet
*dev, struct sk_buff *skb
goto error;
if (skb) {
- if (skb-len = sizeof(ETH_HLEN))
+ if (skb-len = ETH_HLEN)
goto error;
/* mapping VLANs to MBIM sessions:
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] drivers: phy: add generic PHY framework
Hi,
On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Hi Kishon,
For review purposes, I'll skip most of the implementation and focus on
the data structures. I think you need to take another look at the
approach your using. The kernel already provides a lot of support for
implementing devices and binding them to drivers that you should be
able to use...
[...]
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @label: label given to phy
+ * @type: specifies the phy type
+ * @of_node: device node of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+ struct device dev;
+ const char *label;
+ int type;
+ struct bus_type *bus;
+ struct device_node *of_node;
+ struct phy_ops *ops;
+};
Alright, so the core of the functionality is this 'struct phy' which
tracks all the instances of PHY devices. As I understand it each
physical phy will have a 'struct phy' instance tracking it. That makes
sense.
struct phy embeds a struct device. Also good. The linux driver model
knows all about devices and how to handle them. However, most of the
rest of this structure looks to be reinventing stuff the driver model
already does.
'label' seems unnecessary. struct device embeds a struct kobject, which
means it has a name and shows up in sysfs. Is there a reason that the
device name cannot be used directly?
hmm.. the label name is supposed to be a simpler name than device name.
Say for instance omap-usb2.1.auto device name can simply be
omap-usb2-phy. Further the device name while using dt will have
register address in it. However it's used only for displaying the label
in sysfs entry (/sys/class/phy/phy/label).
I wouldn't go mucking with names in that way. Stick with one name and
drop the separate label. Otherwise you introduce addtional sources of
confusion.
hmm.. ok.
'type' I just don't understand. I don't see any users of it in this
patch. I only see where it is set.
yeah. Was planning to remove this in my next version (btw the latest is
version 5).
'bus' absolutely should not be here. The bus type should be set in the
struct device by this subsystem when the device gets registered. There
is no reason to have a pointer to it here.
right. I had removed it in version 5 of this patch series.
'of_node' is already in struct device
I wasn't sure if we can manually assign the of_node of one device to
of_node of an another device. Here the of_node comes from _phy provider_.
There is no problem with multiple devices referencing the same node. The
only time it may cause problems is when two devices of the same bus type
are referencing the same of_node. In that situation the device will get
probed more than once. You're not in that situation.
right. Will re-use of_node.
Finally, it really doesn't look right for a device object to have an
'ops' structure. The whole point of the driver model is that a struct
device doesn't encapsulate any behaviour. A device gets registers to a
bus type, and then the driver core will associate a struct device_driver
We have decided not to implement the PHY layer as a separate bus layer.
The PHY provider can be part of any other bus. Making the PHY layer as a
bus will make the PHY provider to be part of multiple buses which will
lead to bad design. All we are trying to do here is keep the pool of PHY
devices under PHY class in this layer and help any controller that wants
to use the PHY to get it.
If you're using a class, then you already have your list of registered
phy devices! :-) No need to create another global list that you need to
manage.
right. We already use _class_dev_iter_ for finding the phy device.
.
.
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
[RFC PATCH 1/2] USB: OHCI: prepare to make ohci-hcd a library module
From: Manjunath Goudar manjunath.gou...@linaro.org
This patch prepares ohci-hcd for being split up into a core
library and separate platform driver modules. A generic
ohci_hc_driver structure is created, containing all the standard
values, and a new mechanism is added whereby a driver module can
specify a set of overrides to those values. In addition the
ohci_init(),ohci_restart(),ohci_hcd_init(),ohci_run() ohci_stop(),
ohci_suspend() and ohci_resume() routines need to be EXPORTed
for use by the drivers.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-hcd.c | 87 ---
drivers/usb/host/ohci-mem.c |3 +-
drivers/usb/host/ohci.h | 39 +++
3 files changed, 115 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 9e6de95..fb869fc 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -79,12 +79,6 @@ static const charhcd_name [] = ohci_hcd;
#include pci-quirks.h
static void ohci_dump (struct ohci_hcd *ohci, int verbose);
-static int ohci_init (struct ohci_hcd *ohci);
-static void ohci_stop (struct usb_hcd *hcd);
-
-#if defined(CONFIG_PM) || defined(CONFIG_PCI)
-static int ohci_restart (struct ohci_hcd *ohci);
-#endif
#ifdef CONFIG_PCI
static void sb800_prefetch(struct ohci_hcd *ohci, int on);
@@ -520,7 +514,7 @@ done:
/* init memory, and kick BIOS/SMM off */
-static int ohci_init (struct ohci_hcd *ohci)
+int ohci_init(struct ohci_hcd *ohci)
{
int ret;
struct usb_hcd *hcd = ohci_to_hcd(ohci);
@@ -590,6 +584,7 @@ static int ohci_init (struct ohci_hcd *ohci)
return ret;
}
+EXPORT_SYMBOL_GPL(ohci_init);
/*-*/
@@ -597,7 +592,7 @@ static int ohci_init (struct ohci_hcd *ohci)
* resets USB and controller
* enable interrupts
*/
-static int ohci_run (struct ohci_hcd *ohci)
+int ohci_run(struct ohci_hcd *ohci)
{
u32 mask, val;
int first = ohci-fminterval == 0;
@@ -767,6 +762,7 @@ retry:
return 0;
}
+EXPORT_SYMBOL_GPL(ohci_run);
/*-*/
@@ -914,7 +910,7 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
/*-*/
-static void ohci_stop (struct usb_hcd *hcd)
+void ohci_stop(struct usb_hcd *hcd)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
@@ -943,13 +939,14 @@ static void ohci_stop (struct usb_hcd *hcd)
ohci-hcca_dma = 0;
}
}
+EXPORT_SYMBOL_GPL(ohci_stop);
/*-*/
#if defined(CONFIG_PM) || defined(CONFIG_PCI)
/* must not be called from interrupt context */
-static int ohci_restart (struct ohci_hcd *ohci)
+int ohci_restart(struct ohci_hcd *ohci)
{
int temp;
int i;
@@ -1008,12 +1005,13 @@ static int ohci_restart (struct ohci_hcd *ohci)
ohci_dbg(ohci, restart complete\n);
return 0;
}
+EXPORT_SYMBOL_GPL(ohci_restart);
#endif
#ifdef CONFIG_PM
-static int __maybe_unused ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
+int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
unsigned long flags;
@@ -1031,9 +1029,9 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
*hcd, bool do_wakeup)
return 0;
}
+EXPORT_SYMBOL_GPL(ohci_suspend);
-
-static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
+int ohci_resume(struct usb_hcd *hcd, bool hibernated)
{
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
int port;
@@ -1081,11 +1079,74 @@ static int __maybe_unused ohci_resume(struct usb_hcd
*hcd, bool hibernated)
return 0;
}
+EXPORT_SYMBOL_GPL(ohci_resume);
#endif
/*-*/
+/*
+ * Generic structure: This gets copied for platform drivers so that
+ * individual entries can be overridden as needed.
+ */
+
+static const struct hc_driver ohci_hc_driver = {
+ .description = hcd_name,
+ .product_desc = OHCI Host Controller,
+ .hcd_priv_size =sizeof(struct ohci_hcd),
+
+ /*
+* generic hardware linkage
+ */
+ .irq = ohci_irq,
+ .flags =HCD_MEMORY | HCD_USB11,
+
+ /*
+ * basic lifecycle operations
+ */
+ .start =ohci_run,
+ .stop = ohci_stop,
+ .shutdown = ohci_shutdown,
+
+ /*
+* managing i/o requests and
[RFC PATCH 2/2] USB: OHCI: make ohci-pci a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
This patch splits the PCI portion of ohci-hcd out into its
own separate driver module, called ohci-pci. Consistently with the
current practice, the decision whether to build this module is not
user-configurable. If OHCI_PCI are enabled then the module will
be built, always.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig|5 +++
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-hcd.c | 31 +--
drivers/usb/host/ohci-mem.c |1 -
drivers/usb/host/ohci-pci.c | 93 ++-
drivers/usb/host/ohci.h |6 ++-
6 files changed, 51 insertions(+), 86 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7a1a248..8bd53e2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -333,6 +333,11 @@ config USB_ISP1362_HCD
To compile this driver as a module, choose M here: the
module will be called isp1362-hcd.
+config USB_OHCI_PCI
+ tristate OHCI PCI support
+ depends on USB_OHCI_HCD
+ default y
+
config USB_OHCI_HCD
tristate OHCI HCD support
depends on USB USB_ARCH_HAS_OHCI
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 58c14c1..39ddcca 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_USB_OXU210HP_HCD)+= oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
+obj-$(CONFIG_USB_OHCI_PCI) += ohci-pci.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index fb869fc..3259ff9 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -78,24 +78,13 @@ static const char hcd_name [] = ohci_hcd;
#include ohci.h
#include pci-quirks.h
-static void ohci_dump (struct ohci_hcd *ohci, int verbose);
-
-#ifdef CONFIG_PCI
-static void sb800_prefetch(struct ohci_hcd *ohci, int on);
-#else
-static inline void sb800_prefetch(struct ohci_hcd *ohci, int on)
-{
- return;
-}
-#endif
-
+static void ohci_dump(struct ohci_hcd *ohci, int verbose);
#include ohci-hub.c
#include ohci-dbg.c
#include ohci-mem.c
#include ohci-q.c
-
/*
* On architectures with edge-triggered interrupts we must never return
* IRQ_NONE.
@@ -585,7 +574,6 @@ int ohci_init(struct ohci_hcd *ohci)
return ret;
}
EXPORT_SYMBOL_GPL(ohci_init);
-
/*-*/
/* Start an OHCI controller, set the BUS operational
@@ -1151,11 +1139,6 @@ MODULE_AUTHOR (DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE (GPL);
-#ifdef CONFIG_PCI
-#include ohci-pci.c
-#define PCI_DRIVER ohci_pci_driver
-#endif
-
#if defined(CONFIG_ARCH_SA1100) defined(CONFIG_SA)
#include ohci-sa.c
#define SA_DRIVER ohci_hcd_sa_driver
@@ -1251,7 +1234,7 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERohci_platform_driver
#endif
-#if!defined(PCI_DRIVER) \
+#if!IS_ENABLED(CONFIG_USB_OHCI_PCI) \
!defined(PLATFORM_DRIVER) \
!defined(OMAP1_PLATFORM_DRIVER) \
!defined(OMAP3_PLATFORM_DRIVER) \
@@ -1326,12 +1309,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_sa;
#endif
-#ifdef PCI_DRIVER
- retval = pci_register_driver(PCI_DRIVER);
- if (retval 0)
- goto error_pci;
-#endif
-
#ifdef SM501_OHCI_DRIVER
retval = platform_driver_register(SM501_OHCI_DRIVER);
if (retval 0)
@@ -1425,10 +1402,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(SM501_OHCI_DRIVER);
error_sm501:
#endif
-#ifdef PCI_DRIVER
- pci_unregister_driver(PCI_DRIVER);
- error_pci:
-#endif
#ifdef SA_DRIVER
sa_driver_unregister(SA_DRIVER);
error_sa:
diff --git a/drivers/usb/host/ohci-mem.c b/drivers/usb/host/ohci-mem.c
index 1a4dede..f98727f 100644
--- a/drivers/usb/host/ohci-mem.c
+++ b/drivers/usb/host/ohci-mem.c
@@ -30,7 +30,6 @@ void ohci_hcd_init (struct ohci_hcd *ohci)
INIT_LIST_HEAD (ohci-pending);
}
EXPORT_SYMBOL_GPL(ohci_hcd_init);
-
/*-*/
static int ohci_mem_init (struct ohci_hcd *ohci)
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index 951514e..f9c6c2e 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -14,12 +14,19 @@
* This file is licenced under the GPL.
*/
-#ifndef
Re: Why usb's remote wakeup relys on CONFIG_USB_SUSPEND
On Tue, 16 Apr 2013, linux fddl wrote: I am a new fish of linux usb host driver developper. Recently, when developping the host's PM function, I found that usb's remote wakeup relys on CONFIG_USB_SUSPEND. I do not know why we need such a restriction. Is it means if a usb host driver without the implementation of runtime suspend also can not(should not) support remote wakeup? Anyone would like to give me some help? You are right; kernels built without runtime suspend also do not support USB remote wakeup. The reason is historical; the two features were added at the same time and they shared the same implementation. The situation will be different starting in the 3.10 kernel. USB remote wakeup will be supported whenever CONFIG_PM is enabled. 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] usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep
On Tue, 16 Apr 2013, Hans de Goede wrote:
When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip,
which for a request with USB_RECIP_ENDPOINT tries to map this to an interface
to see if this interface is claimed, except for ctrl-requests with a type of
USB_TYPE_VENDOR.
When trying to use this device: http://www.akaipro.com/eiepro
redirected to a Windows vm running on qemu on top of Linux.
The windows driver makes a ctrl-req with USB_TYPE_CLASS and
USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to
the interface fails since ep 0 is the ctrl endpoint and thus never is
part of an interface.
This is bizarre. Why would a class specification include a class-type
request to endpoint 0 with the endpoint as the recipient? The
recipient should be the interface.
This patch fixes this ctrl-req failing by skipping the checkintf call for
USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint.
Reported-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl
Tested-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/devio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 8823e98..caefc80 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -739,6 +739,8 @@ static int check_ctrlrecip(struct dev_state *ps, unsigned
int requesttype,
index = 0xff;
switch (requesttype USB_RECIP_MASK) {
case USB_RECIP_ENDPOINT:
+ if ((index ~USB_DIR_IN) == 0)
+ return 0;
ret = findintfep(ps-dev, index);
if (ret = 0)
ret = checkintf(ps, ret);
Anyway, this looks fine.
Acked-by: Alan Stern st...@rowland.harvard.edu
--
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] usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep
Hello. On 16-04-2013 13:08, Hans de Goede wrote: When usbfs USBFS support has been removed some months ago. Maybe you meant 'usbdevfs'?.. receives a ctrl-request from userspace it calls check_ctrlrecip, which for a request with USB_RECIP_ENDPOINT tries to map this to an interface to see if this interface is claimed, except for ctrl-requests with a type of USB_TYPE_VENDOR. When trying to use this device: http://www.akaipro.com/eiepro redirected to a Windows vm running on qemu on top of Linux. The windows driver makes a ctrl-req with USB_TYPE_CLASS and USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to the interface fails since ep 0 is the ctrl endpoint and thus never is part of an interface. This patch fixes this ctrl-req failing by skipping the checkintf call for USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint. Reported-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl Tested-by: Dave Stikkolorum d.r.stikkolo...@hhs.nl Signed-off-by: Hans de Goede hdego...@redhat.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
On Tuesday 16 April 2013 09:15:45 Ming Lei wrote: On Mon, Apr 15, 2013 at 11:59 PM, Dan Williams d...@redhat.com wrote: So, what was the general consensus on this one? I know Oliver signed off on it, but the discussion about memflags seemed to die out without a specific conclusion. davem might be looking for that conclusion before moving forward with the series :) Suggest to remove the memflags parameter, because: - the probable issue addressed by introducing memflags is a general issue of all USB drivers, also very corener one, not a specific one on usbnet, and the issue only exists on devices with at least one mass storage interface and another non-mass-storage interface, and it is not considered by other USB drivers now. Generally, saying that somebody else has a problem is not an argument as long as the fix is very simple. Of course it is a corner case, but why fail to solve it as long as the cost is extremely low? - usbnet_status_start() is called from either probe() or work queue scheduled from probe(), if we want to address the probable issue, the memflags should No, we export this symbol. So we keep it generic if that is possible at low cost. We cannot assume that the conditions it would be called in now, remain so. Of course we don't add stuff needlessly, but here the fix is trivial. always be GFP_NOIO under the two situations, __or__ GFP_KERNEL if we choose to ignore the very corner case like other USB drivers. So hardcoded GFP_NOIO or GFP_KERNEL should be accepted. Oliver, do you have objections on not adding the memflags parameter now? Yes, it is a change of almost no gain and a known problem. It should be added with mem_flags. Williams, looks there is another problem in your patch, sorry for not finding it previously. usb_autopm_get_interface() need to be called before submitting URB inside usbnet_status_start(), and usb_autopm_put_interface() need to be called after killing URB inside usbnet_status_stop(). Otherwise your patch doesn't work as you expected under runtime PM situation. Again, no. This is a generic API. It may be called for devices which need their status polled forever and we cannot block them from sleeping. If a driver wants to block suspend while a status URB is on, it should call the autopm method. This is the way we do it while the connection is up. Regards Oliver -- 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] usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep
On 16-04-2013 18:12, Sergei Shtylyov wrote: When usbfs USBFS support has been removed some months ago. Maybe you meant 'usbdevfs'?.. Or was it vice versa, or is there two entities dubbed 'usbfs'? Anyway, here's the commit removing CONFIG_USB_DEVICEFS (under /proc/bus/usb/): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb28d58b72aa9215b26f1d5478462af394a4d253 WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for PL-2303 HX not working
Am 15.04.2013 18:16, schrieb Greg KH: If you can't do the bisection, can you point me at the exact device you are using here so I can buy one and try to track this down? It seems that exact the same adapter is out of stock. But this seems to be nearly exact the same one: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=360497981785 or http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=270845320234 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] usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep
On Tue, 16 Apr 2013, Sergei Shtylyov wrote: On 16-04-2013 18:12, Sergei Shtylyov wrote: When usbfs USBFS support has been removed some months ago. Maybe you meant 'usbdevfs'?.. Or was it vice versa, or is there two entities dubbed 'usbfs'? Anyway, here's the commit removing CONFIG_USB_DEVICEFS (under /proc/bus/usb/): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb28d58b72aa9215b26f1d5478462af394a4d253 Two entities using the same name. One was the now-defunct filesystem under /proc/bus/usb -- that's where the usbfs name came from (it is a shortened form of the original name, usbdevfs). The other was the driver that implements this interface; see the definition of usbfs_driver in core/devio.c (in particular, the .name member). 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: usb3 disk drive not being recognized properly
On Tue, 16 Apr 2013, vekin wrote: I have a Seagate backup plus 3TB usb3 drive that seems to be recognized. I get no /dev/sdx device associated with it unless I unplug it and plug it in after the kernel is loaded. I can see this. Bus 004 Device 002: ID 0bc2:a0a1 Seagate RSS LLC But the light on the device turns completely off and I have no /dev/sdb Once I unplug it and plug it in again, the light comes on. Bus 004 Device 003: ID 0bc2:a0a1 Seagate RSS LLC And the /dev/sdb is created. Relevant dmesg output. http://pastebin.com/3DXFyGCf This sounds like a bug in the drive (or the drive's USB interface) -- it doesn't reset itself the way it should following the reboot. However, without more details there's no way to know for sure. 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: USB2.0 disk format failure in windows guest
On Tue, 16 Apr 2013, Gonglei (Arei) wrote:
Yes, this disk was using EHCI, since guest QEMU and Linux kernel both
prints matching EHCI logs, such as transfer types and transfer sizes.
There are many buck-out URBs whose sizes are 31 or 4064 that are not
multiples of 512. Since URB size 31 does occur without guest format
USB 2.0 disk sceneiro, did you mean that buck-out size 4064 should
not occur? /* EHCI spec version 1.0 Section 4.10.6 */
That's right; it should not occur.
It's okay to have an URB size that isn't a multiple of 512 if that URB
is the last one in a transfer. For example, the 31-byte URBs were the
only URBs in their transfers, so they were okay. But the 4064-byte
URBs occurred at the start and in the middle of their transfers, so
they were wrong.
Alan, the code which get the virtual machine USB packet in the Qemu is as
follows:
# /qemu-1.4.0/hw/usb/hcd-ehci.c
static int ehci_init_transfer(EHCIPacket *p)
{
uint32_t cpage, offset, bytes, plen;
dma_addr_t page;
cpage = get_field(p-qtd.token, QTD_TOKEN_CPAGE);
bytes = get_field(p-qtd.token, QTD_TOKEN_TBYTES);
offset = p-qtd.bufptr[0] ~QTD_BUFPTR_MASK;
pci_dma_sglist_init(p-sgl, p-queue-ehci-dev, 5);
while (bytes 0) {
if (cpage 4) {
fprintf(stderr, cpage out of range (%d)\n, cpage);
return USB_RET_PROCERR;
}
page = p-qtd.bufptr[cpage] QTD_BUFPTR_MASK;
page += offset;
plen = bytes;
if (plen 4096 - offset) {
plen = 4096 - offset;
offset = 0;
cpage++;
}
qemu_sglist_add(p-sgl, page, plen);
bytes -= plen;
}
return 0;
}
I see.
After our repeated verification and debug, we found that windows
virtual machine USB disk format will send a 64Kbits's URB packet
which was divided into four QTD (Size: 19968,16384,16384,12800):
That's okay.
The first QTD offset is 32, split into five URB
4064/4096/4096/4096/3616 bits ( we don't understand why the offset is
always 32, but the linux virtual machine is always 0)
I guess Windows uses strange offsets. Are the pages that make up the
qTD adjacent in the host's virtual memory?
The second QTD offset 3616, split into five URB
480/4096/4096/4096/3616 bits
Third QTD offset is 3616, split into five URB 480/4096/4096/4096/3616 bits
Fourth QTD offset is 3616, split into five URB 480/4096/4096/4096/32 bits
Fixing this will require qemu to copy the beginning and ending parts of
these non-aligned qTDs into separate bounce buffers so that the URB
length can be divisible by 512. For example, with the first qTD above,
qemu could send one URB of length 3584 at offset 32. Then qemu would
copy the last 480 bytes from that page and the first 32 bytes from the
next page into a bounce buffer, and send a 512-byte URB for that
buffer. Then qemu would send a 3584-byte URB starting at offset 480 in
the second page, and so on.
Of course, this can be optimized in the case where the pages happen to
be adjacent in the host's memory. It's okay to let an URB span a page
boundary. But if the pages aren't adjacent, you will have to use a
bounce buffer.
By the way, this approach has to be used for control and interrupt
transfers as well as bulk transfers. If a guest's qTD has be to split
up, all the pieces except the last must be a multiple of the
wMaxPacketSize value.
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: Linux USB file storage gadget with new UDC
On Tue, 16 Apr 2013, victor yeo wrote: From the usbmon trace and driver log, i can only see that TEST UNIT READY command is sent out but UDC driver does not receive it. May i ask, under what circumstances, is gadget driver calling start_transfer() to schedule reading from bulk-out endpoint ? file_storage.c calls start_transfer() whenever it expects the host to send a bulk-out packet. These times include: When the gadget is waiting for the host to send a CBW packet containing a SCSI command; When the gadget is waiting for the host to send the data part of a WRITE command. The driver also calls start_transfer() whenever it wants to send a bulk-in packet to the host: When the gadget wants to send the data part of a reply to a command such as READ or READ CAPACITY; When the gadget wants to send a CSW packet containing the status of a completed SCSI command. 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 1/2] USB: ehci-omap: Don't select any PHY driver
On Mon, 15 Apr 2013, Roger Quadros wrote: Don't select NOP_USB_XCEIV. Instead, board config must select USB_PHY and the appropriate PHY driver. Also add a hint in Kconfig so that users enabling this driver manually enable the right PHY drivers as well. Gets rid of the below warnings when USB_EHCI_HCD_OMAP is enabled. warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT USB_PHY) warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT USB_PHY) CC: Alan Stern st...@rowland.harvard.edu Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index c0be25c..c558472 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,11 +150,13 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate EHCI support for OMAP3 and later chips depends on ARCH_OMAP - select NOP_USB_XCEIV default y ---help--- Enables support for the on-chip EHCI controller on OMAP3 and later chips. + If your system uses a PHY on the USB port, you will need to + enable USB_PHY and the appropriate PHY driver as well. Most + boards need the NOP_USB_XCEIV PHY driver. config USB_EHCI_HCD_ORION tristate Support for Marvell EBU on-chip EHCI USB controller Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: ehci-omap: Improve PHY error handling
On Mon, 15 Apr 2013, Roger Quadros wrote:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
If we fail to get the PHY device it could be due
to missing USB PHY drivers. Give this hint to the user
in the error message.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 5de3e43..2e34ddd 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -175,13 +175,13 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
phy = devm_usb_get_phy_by_phandle(dev, phys, i);
else
phy = devm_usb_get_phy_dev(dev, i);
- if (IS_ERR(phy) || !phy) {
+ if (IS_ERR(phy)) {
/* Don't bail out if PHY is not absolutely necessary */
if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
continue;
- ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
- dev_err(dev, Can't get PHY device for port %d: %d\n,
+ ret = PTR_ERR(phy);
+ dev_err(dev, Can't get PHY device for port %d: %d. Is
USB_PHY driver enabled?\n,
i, ret);
goto err_phy;
}
Getting rid of the !phy test is good. But I'm doubtful about the
change to the error message. Are you going to make a similar change to
every platform driver? There doesn't seem to be any reason to do this
for ehci-omap but not the others.
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: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
On Mon, 15 Apr 2013, Michael Braun wrote: Hi, I'm running OpenWRT Kernel 3.8.3 (which already has f66dea709cd9309b2ee9f715697818001fb518de and 5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN (QorlQ, PPC) device. Before updating the kernel from 3.3.0, USB host support was working fine. Now I get fsl-ehci: USB PHY clock invalid messages in dmesg and the lsusb output is empty, so USB host support is not working. When I apply the following patch, USB host support starts working again, so I guess 3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause. Why didn't you CC: the author of that commit? Isn't he the person most likely to be able to fix it? 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: USB2.0 disk format failure in windows guest
Hi, Fixing this will require qemu to copy the beginning and ending parts of these non-aligned qTDs into separate bounce buffers so that the URB length can be divisible by 512. Worth trying: http://www.kraxel.org/cgit/qemu/log/?h=usb.80 It puts the qemu usb passthrough code upside down. All xfers will go through a bounce buffer, requests are submitted via libusbx. That should fix it. Of course there is the risk of regressions in other areas as it is all new code. Also make sure you have libusbx-devel installed, otherwise qemu will fallback to the old code which uses usbfs ioctls directly. cheers, Gerd -- 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: gadget: fix enumeration on heavy-loaded systems
From musb point of view, the Address Assignment sequence during
device enumeration is next:
- first ep0 interrupt:
* read the address from USB_REQ_SET_ADDRESS request
* set up CSR0L.DataEnd bit (that is ACK
signalization for the host)
- second ep0 interrupt:
* indicates that the request completed successfully
* set up musb device address
Now musb device should answer to this address
From the host perspective, if peripheral device acquires
SET_ADDRESS request, it now may be accessed only using that address.
However, on heavy loaded systems, time between first and
second musb ep0 interrupts may be too long and musb controller
misses requests between. As result, device enumeration may be
unsuccessful. This can be checked on USB3.0 Host and
using USB3.0 test suite (from usb.org) running ch9 tests
for USB2.0 devices.
Usually 'Addressed state/TD9.1: Device Descriptor Test' will fail
The fix consists in checking CSR0L.DataEnd state and assigning
the device address in the first ep0 interrupt handling, so
delay is as minimal as possible
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_gadget_ep0.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index c9c1ac4..59bc5a5 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -885,6 +885,37 @@ stall:
finish:
musb_writew(regs, MUSB_CSR0,
musb-ackpend);
+
+ /*
+* If we are at end of SET_ADDRESS sequence,
+* update the address immediately if possible,
+* otherwise we may miss packets between
+* sending ACK from musb side and musb's next
+* interrupt handler firing (in which we update
+* the address). At least this fixes next
+* USB2.0 ch9 test of USB30CV utility:
+* Addressed state - Device Descriptor test
+*/
+ if (musb-set_address (musb-ackpend
+ MUSB_CSR0_P_DATAEND)
+ (musb-ep0_state ==
+ MUSB_EP0_STAGE_STATUSIN)) {
+ u16 ack_delay = 500;
+
+ while ((musb_readw(regs, MUSB_CSR0)
+ MUSB_CSR0_P_DATAEND)
+ --ack_delay) {
+ cpu_relax();
+ udelay(1);
+ }
+
+ if (ack_delay) {
+ musb-set_address = false;
+ musb_writeb(mbase, MUSB_FADDR,
+ musb-address);
+ }
+ }
+
musb-ackpend = 0;
}
}
--
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
[PATCH 12/12] USB: symbolserial: move private-data allocation to port_probe
Allocate port-private data in port-probe rather than in attach.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/symbolserial.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/symbolserial.c
b/drivers/usb/serial/symbolserial.c
index 2c2bfa1..9b16489 100644
--- a/drivers/usb/serial/symbolserial.c
+++ b/drivers/usb/serial/symbolserial.c
@@ -1,6 +1,7 @@
/*
* Symbol USB barcode to serial driver
*
+ * Copyright (C) 2013 Johan Hovold jhov...@gmail.com
* Copyright (C) 2009 Greg Kroah-Hartman gre...@suse.de
* Copyright (C) 2009 Novell Inc.
*
@@ -35,7 +36,7 @@ struct symbol_private {
static void symbol_int_callback(struct urb *urb)
{
struct usb_serial_port *port = urb-context;
- struct symbol_private *priv = usb_get_serial_data(port-serial);
+ struct symbol_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb-transfer_buffer;
int status = urb-status;
int result;
@@ -153,30 +154,36 @@ static void symbol_unthrottle(struct tty_struct *tty)
static int symbol_startup(struct usb_serial *serial)
{
- struct symbol_private *priv;
-
if (!serial-num_interrupt_in) {
dev_err(serial-dev-dev, no interrupt-in endpoint\n);
return -ENODEV;
}
- /* create our private serial structure */
+ return 0;
+}
+
+static int symbol_port_probe(struct usb_serial_port *port)
+{
+ struct symbol_private *priv;
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (priv == NULL) {
- dev_err(serial-dev-dev, %s - Out of memory\n, __func__);
+ if (!priv)
return -ENOMEM;
- }
+
spin_lock_init(priv-lock);
- usb_set_serial_data(serial, priv);
+ usb_set_serial_port_data(port, priv);
+
return 0;
}
-static void symbol_release(struct usb_serial *serial)
+static int symbol_port_remove(struct usb_serial_port *port)
{
- struct symbol_private *priv = usb_get_serial_data(serial);
+ struct symbol_private *priv = usb_get_serial_port_data(port);
kfree(priv);
+
+ return 0;
}
static struct usb_serial_driver symbol_device = {
@@ -187,9 +194,10 @@ static struct usb_serial_driver symbol_device = {
.id_table = id_table,
.num_ports =1,
.attach = symbol_startup,
+ .port_probe = symbol_port_probe,
+ .port_remove = symbol_port_remove,
.open = symbol_open,
.close =symbol_close,
- .release = symbol_release,
.throttle = symbol_throttle,
.unthrottle = symbol_unthrottle,
.read_int_callback =symbol_int_callback,
--
1.8.1.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 03/12] USB: omninet: clean up protocol defines
Remove redundant data-offset define, which was really just the header
length.
Add payload-size define and use the bulk-out size define for the actual
bulk-out size.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/omninet.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index ec16b92..9dcaa77 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -154,9 +154,9 @@ static void omninet_close(struct usb_serial_port *port)
}
-#define OMNINET_DATAOFFSET 0x04
-#define OMNINET_HEADERLEN sizeof(struct omninet_header)
-#define OMNINET_BULKOUTSIZE(64 - OMNINET_HEADERLEN)
+#define OMNINET_HEADERLEN 4
+#define OMNINET_BULKOUTSIZE64
+#define OMNINET_PAYLOADSIZE(OMNINET_BULKOUTSIZE - OMNINET_HEADERLEN)
static void omninet_read_bulk_callback(struct urb *urb)
{
@@ -173,7 +173,7 @@ static void omninet_read_bulk_callback(struct urb *urb)
}
if (urb-actual_length header-oh_len) {
- tty_insert_flip_string(port-port, data + OMNINET_DATAOFFSET,
+ tty_insert_flip_string(port-port, data + OMNINET_HEADERLEN,
header-oh_len);
tty_flip_buffer_push(port-port);
}
@@ -208,9 +208,9 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
return 0;
}
- count = (count OMNINET_BULKOUTSIZE) ? OMNINET_BULKOUTSIZE : count;
+ count = (count OMNINET_PAYLOADSIZE) ? OMNINET_PAYLOADSIZE : count;
- memcpy(wport-write_urb-transfer_buffer + OMNINET_DATAOFFSET,
+ memcpy(wport-write_urb-transfer_buffer + OMNINET_HEADERLEN,
buf, count);
usb_serial_debug_data(port-dev, __func__, count,
@@ -222,7 +222,7 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
header-oh_pad = 0x00;
/* send the data out the bulk port, always 64 bytes */
- wport-write_urb-transfer_buffer_length = 64;
+ wport-write_urb-transfer_buffer_length = OMNINET_BULKOUTSIZE;
result = usb_submit_urb(wport-write_urb, GFP_ATOMIC);
if (result) {
--
1.8.1.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 04/12] USB: omninet: refactor read-urb processing
Refactor read-urb processing, and add sanity checks on header and data
lengths.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/omninet.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 9dcaa77..7aaf969 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -158,11 +158,26 @@ static void omninet_close(struct usb_serial_port *port)
#define OMNINET_BULKOUTSIZE64
#define OMNINET_PAYLOADSIZE(OMNINET_BULKOUTSIZE - OMNINET_HEADERLEN)
+static void omninet_process_read_urb(struct urb *urb)
+{
+ struct usb_serial_port *port = urb-context;
+ const struct omninet_header *hdr = urb-transfer_buffer;
+ const unsigned char *data;
+ size_t data_len;
+
+ if (urb-actual_length = OMNINET_HEADERLEN || !hdr-oh_len)
+ return;
+
+ data = (char *)urb-transfer_buffer + OMNINET_HEADERLEN;
+ data_len = min_t(size_t, urb-actual_length - OMNINET_HEADERLEN,
+ hdr-oh_len);
+ tty_insert_flip_string(port-port, data, data_len);
+ tty_flip_buffer_push(port-port);
+}
+
static void omninet_read_bulk_callback(struct urb *urb)
{
struct usb_serial_port *port = urb-context;
- unsigned char *data = urb-transfer_buffer;
- struct omninet_header *header = (struct omninet_header *) data[0];
int status = urb-status;
int result;
@@ -172,11 +187,7 @@ static void omninet_read_bulk_callback(struct urb *urb)
return;
}
- if (urb-actual_length header-oh_len) {
- tty_insert_flip_string(port-port, data + OMNINET_HEADERLEN,
- header-oh_len);
- tty_flip_buffer_push(port-port);
- }
+ omninet_process_read_urb(urb);
/* Continue trying to always read */
result = usb_submit_urb(urb, GFP_ATOMIC);
--
1.8.1.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 01/12] USB: omninet: use kzalloc for private data
Make sure the port private data, which contains the write sequence
number, is cleared at allocation.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/omninet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 1e1cafe..ea1105c 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -112,7 +112,7 @@ static int omninet_port_probe(struct usb_serial_port *port)
{
struct omninet_data *od;
- od = kmalloc(sizeof(struct omninet_data), GFP_KERNEL);
+ od = kzalloc(sizeof(*od), GFP_KERNEL);
if (!od)
return -ENOMEM;
--
1.8.1.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 00/12] USB: serial: patches for 3.10
These patches against usb-next replace the omninet custom read implementation with the generic one, fix some port-data abuse in mct_u232, and make kobil_sct and symbolserial use the port interrupt urbs rather than private ones, while cleaning up all four drivers somwehat. All patches have been compile-tested only. Johan Johan Hovold (12): USB: omninet: use kzalloc for private data USB: omninet: clean up protocol description USB: omninet: clean up protocol defines USB: omninet: refactor read-urb processing USB: omninet: switch to generic read implementation USB: kobil_sct: fix broken debug code USB: kobil_sct: remove unused endpoint address USB: kobil_sct: use port interrupt-out urb USB: mct_u232: clean up read implementation USB: symbolserial: use port interrupt-in urb USB: symbolserial: remove unused private data USB: symbolserial: move private-data allocation to port_probe drivers/usb/serial/kobil_sct.c| 103 +++--- drivers/usb/serial/mct_u232.c | 37 --- drivers/usb/serial/omninet.c | 81 drivers/usb/serial/symbolserial.c | 130 -- 4 files changed, 76 insertions(+), 275 deletions(-) -- 1.8.1.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 06/12] USB: kobil_sct: fix broken debug code
Replace broken and commented-out debug code with usb_serial_debug_data.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/kobil_sct.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
index 903d938..da1a372 100644
--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -333,24 +333,8 @@ static void kobil_read_int_callback(struct urb *urb)
}
if (urb-actual_length) {
-
- /* BEGIN DEBUG */
- /*
- char *dbg_data;
-
- dbg_data = kzalloc((3 * purb-actual_length + 10)
- * sizeof(char), GFP_KERNEL);
- if (! dbg_data) {
- return;
- }
- for (i = 0; i purb-actual_length; i++) {
- sprintf(dbg_data +3*i, %02X , data[i]);
- }
- dev_dbg(port-dev, -- %s\n, dbg_data);
- kfree(dbg_data);
- */
- /* END DEBUG */
-
+ usb_serial_debug_data(port-dev, __func__, urb-actual_length,
+ data);
tty_insert_flip_string(port-port, data, urb-actual_length);
tty_flip_buffer_push(port-port);
}
--
1.8.1.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 08/12] USB: kobil_sct: use port interrupt-out urb
Use the port interrupt-out urb rather than abusing the port write_urb
pointer and allocating a new urb at every open (but the first...).
Note that the write_urb abuse would have led to a double free should
there ever be interfaces with a bulk-out endpoint.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/kobil_sct.c | 75 +-
1 file changed, 8 insertions(+), 67 deletions(-)
diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
index 5bcfd57..78b48c3 100644
--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -65,7 +65,7 @@ static int kobil_tiocmget(struct tty_struct *tty);
static int kobil_tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear);
static void kobil_read_int_callback(struct urb *urb);
-static void kobil_write_callback(struct urb *purb);
+static void kobil_write_int_callback(struct urb *urb);
static void kobil_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old);
static void kobil_init_termios(struct tty_struct *tty);
@@ -99,6 +99,7 @@ static struct usb_serial_driver kobil_device = {
.write =kobil_write,
.write_room = kobil_write_room,
.read_int_callback =kobil_read_int_callback,
+ .write_int_callback = kobil_write_int_callback,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -106,7 +107,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
};
struct kobil_private {
- int write_int_endpoint_address;
unsigned char buf[KOBIL_BUF_LENGTH]; /* buffer for the APDU to send */
int filled; /* index of the last char in buf */
int cur_pos; /* index of the next char to send in buf */
@@ -116,14 +116,8 @@ struct kobil_private {
static int kobil_port_probe(struct usb_serial_port *port)
{
- int i;
struct usb_serial *serial = port-serial;
struct kobil_private *priv;
- struct usb_device *pdev;
- struct usb_host_config *actconfig;
- struct usb_interface *interface;
- struct usb_host_interface *altsetting;
- struct usb_host_endpoint *endpoint;
priv = kmalloc(sizeof(struct kobil_private), GFP_KERNEL);
if (!priv)
@@ -149,23 +143,6 @@ static int kobil_port_probe(struct usb_serial_port *port)
}
usb_set_serial_port_data(port, priv);
- /* search for the necessary endpoints */
- pdev = serial-dev;
- actconfig = pdev-actconfig;
- interface = actconfig-interface[0];
- altsetting = interface-cur_altsetting;
- endpoint = altsetting-endpoint;
-
- for (i = 0; i altsetting-desc.bNumEndpoints; i++) {
- endpoint = altsetting-endpoint[i];
- if (usb_endpoint_is_int_out(endpoint-desc)) {
- dev_dbg(serial-dev-dev,
- %s Found interrupt out endpoint. Address:
%d\n,
- __func__, endpoint-desc.bEndpointAddress);
- priv-write_int_endpoint_address =
- endpoint-desc.bEndpointAddress;
- }
- }
return 0;
}
@@ -197,7 +174,6 @@ static int kobil_open(struct tty_struct *tty, struct
usb_serial_port *port)
struct kobil_private *priv;
unsigned char *transfer_buffer;
int transfer_buffer_length = 8;
- int write_urb_transfer_buffer_length = 8;
priv = usb_get_serial_port_data(port);
@@ -206,27 +182,6 @@ static int kobil_open(struct tty_struct *tty, struct
usb_serial_port *port)
if (!transfer_buffer)
return -ENOMEM;
- /* allocate write_urb */
- if (!port-write_urb) {
- dev_dbg(dev, %s - Allocating port-write_urb\n, __func__);
- port-write_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!port-write_urb) {
- dev_dbg(dev, %s - usb_alloc_urb failed\n, __func__);
- kfree(transfer_buffer);
- return -ENOMEM;
- }
- }
-
- /* allocate memory for write_urb transfer buffer */
- port-write_urb-transfer_buffer =
- kmalloc(write_urb_transfer_buffer_length, GFP_KERNEL);
- if (!port-write_urb-transfer_buffer) {
- kfree(transfer_buffer);
- usb_free_urb(port-write_urb);
- port-write_urb = NULL;
- return -ENOMEM;
- }
-
/* get hardware version */
result = usb_control_msg(port-serial-dev,
usb_rcvctrlpipe(port-serial-dev, 0),
@@ -302,12 +257,7 @@ static int kobil_open(struct tty_struct *tty, struct
usb_serial_port *port)
static void kobil_close(struct usb_serial_port *port)
{
/* FIXME: Add rts/dtr methods */
- if (port-write_urb) {
-
[PATCH 10/12] USB: symbolserial: use port interrupt-in urb
Use the port interrupt-in urb rather managing a private one.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/symbolserial.c | 102 +-
1 file changed, 12 insertions(+), 90 deletions(-)
diff --git a/drivers/usb/serial/symbolserial.c
b/drivers/usb/serial/symbolserial.c
index be05e6c..32ebddf 100644
--- a/drivers/usb/serial/symbolserial.c
+++ b/drivers/usb/serial/symbolserial.c
@@ -29,13 +29,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
/* This structure holds all of the individual device information */
struct symbol_private {
struct usb_device *udev;
- struct usb_serial *serial;
- struct usb_serial_port *port;
- unsigned char *int_buffer;
- struct urb *int_urb;
- int buffer_size;
- u8 bInterval;
- u8 int_address;
spinlock_t lock;/* protects the following flags */
bool throttled;
bool actually_throttled;
@@ -44,9 +37,9 @@ struct symbol_private {
static void symbol_int_callback(struct urb *urb)
{
- struct symbol_private *priv = urb-context;
+ struct usb_serial_port *port = urb-context;
+ struct symbol_private *priv = usb_get_serial_data(port-serial);
unsigned char *data = urb-transfer_buffer;
- struct usb_serial_port *port = priv-port;
int status = urb-status;
int result;
int data_length;
@@ -94,12 +87,7 @@ exit:
/* Continue trying to always read if we should */
if (!priv-throttled) {
- usb_fill_int_urb(priv-int_urb, priv-udev,
-usb_rcvintpipe(priv-udev,
- priv-int_address),
-priv-int_buffer, priv-buffer_size,
-symbol_int_callback, priv, priv-bInterval);
- result = usb_submit_urb(priv-int_urb, GFP_ATOMIC);
+ result = usb_submit_urb(port-interrupt_in_urb, GFP_ATOMIC);
if (result)
dev_err(port-dev,
%s - failed resubmitting read urb, error %d\n,
@@ -118,15 +106,10 @@ static int symbol_open(struct tty_struct *tty, struct
usb_serial_port *port)
spin_lock_irqsave(priv-lock, flags);
priv-throttled = false;
priv-actually_throttled = false;
- priv-port = port;
spin_unlock_irqrestore(priv-lock, flags);
/* Start reading from the device */
- usb_fill_int_urb(priv-int_urb, priv-udev,
-usb_rcvintpipe(priv-udev, priv-int_address),
-priv-int_buffer, priv-buffer_size,
-symbol_int_callback, priv, priv-bInterval);
- result = usb_submit_urb(priv-int_urb, GFP_KERNEL);
+ result = usb_submit_urb(port-interrupt_in_urb, GFP_KERNEL);
if (result)
dev_err(port-dev,
%s - failed resubmitting read urb, error %d\n,
@@ -136,10 +119,7 @@ static int symbol_open(struct tty_struct *tty, struct
usb_serial_port *port)
static void symbol_close(struct usb_serial_port *port)
{
- struct symbol_private *priv = usb_get_serial_data(port-serial);
-
- /* shutdown our urbs */
- usb_kill_urb(priv-int_urb);
+ usb_kill_urb(port-interrupt_in_urb);
}
static void symbol_throttle(struct tty_struct *tty)
@@ -166,7 +146,7 @@ static void symbol_unthrottle(struct tty_struct *tty)
spin_unlock_irq(priv-lock);
if (was_throttled) {
- result = usb_submit_urb(priv-int_urb, GFP_KERNEL);
+ result = usb_submit_urb(port-interrupt_in_urb, GFP_KERNEL);
if (result)
dev_err(port-dev,
%s - failed submitting read urb, error %d\n,
@@ -177,10 +157,11 @@ static void symbol_unthrottle(struct tty_struct *tty)
static int symbol_startup(struct usb_serial *serial)
{
struct symbol_private *priv;
- struct usb_host_interface *intf;
- int i;
- int retval = -ENOMEM;
- bool int_in_found = false;
+
+ if (!serial-num_interrupt_in) {
+ dev_err(serial-dev-dev, no interrupt-in endpoint\n);
+ return -ENODEV;
+ }
/* create our private serial structure */
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
@@ -189,75 +170,16 @@ static int symbol_startup(struct usb_serial *serial)
return -ENOMEM;
}
spin_lock_init(priv-lock);
- priv-serial = serial;
- priv-port = serial-port[0];
priv-udev = serial-dev;
- /* find our interrupt endpoint */
- intf = serial-interface-altsetting;
- for (i = 0; i intf-desc.bNumEndpoints; ++i) {
- struct usb_endpoint_descriptor *endpoint;
-
- endpoint = intf-endpoint[i].desc;
- if (!usb_endpoint_is_int_in(endpoint))
- continue;
-
- priv-int_urb =
[PATCH 05/12] USB: omninet: switch to generic read implementation
Switch to the more efficient generic read implementation.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/omninet.c | 43 +++
1 file changed, 3 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 7aaf969..5739bf6 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -33,8 +33,7 @@
/* function prototypes */
static int omninet_open(struct tty_struct *tty, struct usb_serial_port *port);
-static void omninet_close(struct usb_serial_port *port);
-static void omninet_read_bulk_callback(struct urb *urb);
+static void omninet_process_read_urb(struct urb *urb);
static void omninet_write_bulk_callback(struct urb *urb);
static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
const unsigned char *buf, int count);
@@ -61,11 +60,10 @@ static struct usb_serial_driver zyxel_omninet_device = {
.port_probe = omninet_port_probe,
.port_remove = omninet_port_remove,
.open = omninet_open,
- .close =omninet_close,
.write =omninet_write,
.write_room = omninet_write_room,
- .read_bulk_callback = omninet_read_bulk_callback,
.write_bulk_callback = omninet_write_bulk_callback,
+ .process_read_urb = omninet_process_read_urb,
.disconnect = omninet_disconnect,
};
@@ -134,26 +132,13 @@ static int omninet_open(struct tty_struct *tty, struct
usb_serial_port *port)
{
struct usb_serial *serial = port-serial;
struct usb_serial_port *wport;
- int result = 0;
wport = serial-port[1];
tty_port_tty_set(wport-port, tty);
- /* Start reading from the device */
- result = usb_submit_urb(port-read_urb, GFP_KERNEL);
- if (result)
- dev_err(port-dev,
- %s - failed submitting read urb, error %d\n,
- __func__, result);
- return result;
-}
-
-static void omninet_close(struct usb_serial_port *port)
-{
- usb_kill_urb(port-read_urb);
+ return usb_serial_generic_open(tty, port);
}
-
#define OMNINET_HEADERLEN 4
#define OMNINET_BULKOUTSIZE64
#define OMNINET_PAYLOADSIZE(OMNINET_BULKOUTSIZE - OMNINET_HEADERLEN)
@@ -175,28 +160,6 @@ static void omninet_process_read_urb(struct urb *urb)
tty_flip_buffer_push(port-port);
}
-static void omninet_read_bulk_callback(struct urb *urb)
-{
- struct usb_serial_port *port = urb-context;
- int status = urb-status;
- int result;
-
- if (status) {
- dev_dbg(port-dev, %s - nonzero read bulk status received:
%d\n,
- __func__, status);
- return;
- }
-
- omninet_process_read_urb(urb);
-
- /* Continue trying to always read */
- result = usb_submit_urb(urb, GFP_ATOMIC);
- if (result)
- dev_err(port-dev,
- %s - failed resubmitting read urb, error %d\n,
- __func__, result);
-}
-
static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
const unsigned char *buf, int count)
{
--
1.8.1.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 09/12] USB: mct_u232: clean up read implementation
The device uses the second interrupt-in endpoint of the interface for
reading. Stop abusing the port read urb and store a pointer to the
second interrupt-in urb as port-private data instead.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mct_u232.c | 37 +++--
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
index 3353c9e..6a15adf 100644
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -43,7 +43,6 @@
/*
* Function prototypes
*/
-static int mct_u232_startup(struct usb_serial *serial);
static int mct_u232_port_probe(struct usb_serial_port *port);
static int mct_u232_port_remove(struct usb_serial_port *remove);
static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port
*port);
@@ -91,7 +90,6 @@ static struct usb_serial_driver mct_u232_device = {
.tiocmget = mct_u232_tiocmget,
.tiocmset = mct_u232_tiocmset,
.tiocmiwait =usb_serial_generic_tiocmiwait,
- .attach =mct_u232_startup,
.port_probe =mct_u232_port_probe,
.port_remove = mct_u232_port_remove,
.get_icount =usb_serial_generic_get_icount,
@@ -102,6 +100,7 @@ static struct usb_serial_driver * const serial_drivers[] = {
};
struct mct_u232_private {
+ struct urb *read_urb;
spinlock_t lock;
unsigned int control_state; /* Modem Line Setting (TIOCM) */
unsigned charlast_lcr; /* Line Control Register */
@@ -376,22 +375,6 @@ static void mct_u232_msr_to_state(struct usb_serial_port
*port,
* Driver's tty interface functions
*/
-static int mct_u232_startup(struct usb_serial *serial)
-{
- struct usb_serial_port *port, *rport;
-
- /* Puh, that's dirty */
- port = serial-port[0];
- rport = serial-port[1];
- /* No unlinking, it wasn't submitted yet. */
- usb_free_urb(port-read_urb);
- port-read_urb = rport-interrupt_in_urb;
- rport-interrupt_in_urb = NULL;
- port-read_urb-context = port;
-
- return 0;
-} /* mct_u232_startup */
-
static int mct_u232_port_probe(struct usb_serial_port *port)
{
struct mct_u232_private *priv;
@@ -400,6 +383,10 @@ static int mct_u232_port_probe(struct usb_serial_port
*port)
if (!priv)
return -ENOMEM;
+ /* Use second interrupt-in endpoint for reading. */
+ priv-read_urb = port-serial-port[1]-interrupt_in_urb;
+ priv-read_urb-context = port;
+
spin_lock_init(priv-lock);
usb_set_serial_port_data(port, priv);
@@ -463,17 +450,17 @@ static int mct_u232_open(struct tty_struct *tty, struct
usb_serial_port *port)
mct_u232_msr_to_state(port, priv-control_state, priv-last_msr);
spin_unlock_irqrestore(priv-lock, flags);
- retval = usb_submit_urb(port-read_urb, GFP_KERNEL);
+ retval = usb_submit_urb(priv-read_urb, GFP_KERNEL);
if (retval) {
dev_err(port-dev,
- usb_submit_urb(read bulk) failed pipe 0x%x err %d\n,
+ usb_submit_urb(read) failed pipe 0x%x err %d\n,
port-read_urb-pipe, retval);
goto error;
}
retval = usb_submit_urb(port-interrupt_in_urb, GFP_KERNEL);
if (retval) {
- usb_kill_urb(port-read_urb);
+ usb_kill_urb(priv-read_urb);
dev_err(port-dev,
usb_submit_urb(read int) failed pipe 0x%x err %d,
port-interrupt_in_urb-pipe, retval);
@@ -503,11 +490,9 @@ static void mct_u232_dtr_rts(struct usb_serial_port *port,
int on)
static void mct_u232_close(struct usb_serial_port *port)
{
- /*
-* Must kill the read urb as it is actually an interrupt urb, which
-* generic close thus fails to kill.
-*/
- usb_kill_urb(port-read_urb);
+ struct mct_u232_private *priv = usb_get_serial_port_data(port);
+
+ usb_kill_urb(priv-read_urb);
usb_kill_urb(port-interrupt_in_urb);
usb_serial_generic_close(port);
--
1.8.1.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 11/12] USB: symbolserial: remove unused private data
Use port device for debug messages in interrupt-urb callback and remove
unused private data.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/symbolserial.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/usb/serial/symbolserial.c
b/drivers/usb/serial/symbolserial.c
index 32ebddf..2c2bfa1 100644
--- a/drivers/usb/serial/symbolserial.c
+++ b/drivers/usb/serial/symbolserial.c
@@ -26,13 +26,10 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
-/* This structure holds all of the individual device information */
struct symbol_private {
- struct usb_device *udev;
spinlock_t lock;/* protects the following flags */
bool throttled;
bool actually_throttled;
- bool rts;
};
static void symbol_int_callback(struct urb *urb)
@@ -77,7 +74,7 @@ static void symbol_int_callback(struct urb *urb)
tty_insert_flip_string(port-port, data[1], data_length);
tty_flip_buffer_push(port-port);
} else {
- dev_dbg(priv-udev-dev,
+ dev_dbg(port-dev,
Improper amount of data received from the device,
%d bytes, urb-actual_length);
}
@@ -170,7 +167,6 @@ static int symbol_startup(struct usb_serial *serial)
return -ENOMEM;
}
spin_lock_init(priv-lock);
- priv-udev = serial-dev;
usb_set_serial_data(serial, priv);
return 0;
--
1.8.1.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 07/12] USB: kobil_sct: remove unused endpoint address
Remove unused interrupt-in endpoint address from private data.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/kobil_sct.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
index da1a372..5bcfd57 100644
--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -107,7 +107,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
struct kobil_private {
int write_int_endpoint_address;
- int read_int_endpoint_address;
unsigned char buf[KOBIL_BUF_LENGTH]; /* buffer for the APDU to send */
int filled; /* index of the last char in buf */
int cur_pos; /* index of the next char to send in buf */
@@ -166,13 +165,6 @@ static int kobil_port_probe(struct usb_serial_port *port)
priv-write_int_endpoint_address =
endpoint-desc.bEndpointAddress;
}
- if (usb_endpoint_is_int_in(endpoint-desc)) {
- dev_dbg(serial-dev-dev,
- %s Found interrupt in endpoint. Address:
%d\n,
- __func__, endpoint-desc.bEndpointAddress);
- priv-read_int_endpoint_address =
- endpoint-desc.bEndpointAddress;
- }
}
return 0;
}
--
1.8.1.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 07/10] staging: dwc2: Don't always return IRQ_HANDLED in dwc2_hcd_intr()
Hi Felipe,
by by this commit message ??
Hmm, not sure what my brain was doing there. Will be fixed in the next version.
--- a/drivers/staging/dwc2/hcd_intr.c
+++ b/drivers/staging/dwc2/hcd_intr.c
@@ -2083,7 +2083,8 @@ irqreturn_t dwc2_hcd_intr(struct dwc2_hsotg *hsotg)
return 0;
this return 0 seems bogus...
How do you mean bogus? Do you mean that the entire construct:
if (!gintsts) {
spin_unlock(hsotg-lock);
return retval;
}
could be removed? Or do you mean (as Paul already pointed out in
another commit) that the 0 should be retval (or at least IRQ_NONE)?
- retval = IRQ_HANDLED;
+ if (gintsts GINTMSK_HOST)
+ retval = IRQ_HANDLED;
you gotta be really careful with this sort of changes, it can force IRQ
subsystem to disable your IRQ line.
Only if you actually trigger IRQs that you don't handle, I think. Given
that GINTMSK_HOST contains all the host interrupts that are ever
disabled (and also all the ones that are handled by the interrupt
handler), I think this should be safe. I would say that setting the flag
without actually handling anything can also cause problems, especially
when an irq line is shared (not sure if/when that's possible, though)?
Gr.
Matthijs
--
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 03/10] staging: dwc2: move some interrupt enabling around
Hi Paul, Before, the DISCONNINT interrupt was enabled in dwc2_enable_host_interrupts, but handled in dwc2_handle_common_intr, while the RXFLVL interrupt was enabled in dwc2_enable_commont_interrupts and handled in dwc_handle_hcd_intr. I guess you meant dwc2_hcd_intr, not dwc_handle_hcd_intr. Ah, indeed. I'll submit a new patch to rename that function for consistency :-) I'll reply to your comment about the actual commit later. Gr. Matthijs -- 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 10/10] staging: dwc2: properly separate common and host interrupt enabling
Hi Paul, --- a/drivers/staging/dwc2/core.c +++ b/drivers/staging/dwc2/core.c ... + /* Enable common interrupts without disturbing host mode interrupts */ + intmsk = readl(hsotg-regs + GINTMSK); + intmsk |= GINTSTS_DISCONNINT | GINTSTS_MODEMIS | GINTSTS_OTGINT | + GINTSTS_CONIDSTSCHNG | GINTSTS_WKUPINT | GINTSTS_USBSUSP | GINTSTS_SESSREQINT; This should use the interrupt list that you just added in patch 8/10, right? Well, the list is not necessarily the same. For the common interrupts, the GINTSTS_RESTOREDONE interrupt is in GINTMSK_COMMON, but it is never enabled. There is only some dummy handling for this interrupt, so I'll submit a separate patch to remove that dummy handling (just like for I2CINT). This should make GINTMSK_COMMON identical to the above list. However, for host-mode interrupts, there are a number of interrupts that are not enabled in dwc2_enable_host_interrupts, but later on when needed. They still need to be in GINTMSK_HOST, since they must be handled by dwc2_handle_hcd_intr and disabled by dwc2_disable_host_interrupts (both of which use GINTMSK_HOST). Given that dwc2_enable_host_interrupts cannot simply use GINTMSK_HOST, it makes sense to not use GINTMSK_COMMON in dwc2_enable_common_interrupts either. However, I did ponder about using these masks in the enable functions, since it helps robustness if you cannot accidentally enable an interrupt that is never disabled. How about the following: - in dwc2_enable_common_interrupts we just enable GINTMSK_COMMON - in dwc2_enable_host_interrupts we enable GINTMSK_HOST ~(GINTSTS_SOF|GINTSTS_PTXFEMP|GINTSTS_NPTXFEMP) (e.g., writing a list of interrupts to enable later, instead of only specifying the interrupts to enable now). The status of GINTSTS_RXFLVL would need to be handled separately, as it is now, of course. How does that look? Gr. Matthijs -- 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 02/10] staging: dwc2: do not handle PRTINT in dwc2_handle_common_intr
Hi Paul, On Mon, Apr 15, 2013 at 10:22:12PM +, Paul Zimmerman wrote: Resending as plain text. From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Monday, April 15, 2013 7:14 AM For host mode, this interrupt is already handled by the hcd interrupt handler. The common interrupt handler additionally did a noop handling (it only cleared the flag and nothing else) when in device mode. Since the driver currently supports only host mode, this shouldn't result in any behaviour change in the driver. When device mode is implemented later on, this interrupt should be properly handled by the device interupt handler, if needed. This change allows to make a clean cut between common interrupts and host interrupts, since there are no longer any interrupts handled by both. Hi Matthijs, I'd rather keep this code as-is. The reason is, even though the driver is currently host-only, the core that it is operating may not be. In that case, when the USB cable is unplugged, the core will switch to device mode. In that case the interrupt handler for host mode will exit without clearing the interrupt. Ok, so if I understand this correctly this interrupt is really not a common interrupt, but it is a host interrupt as well as a device interrupt? And the code in dwc2_handle_common_intr would be moved to the device-mode interrupt handler once it gets added? If so, I could replace this patch with a comment stating that. However, the fact that an interrupt can be both a host and a device interrupt, might complicate things. I'll think a bit about this (also considering your other comments that I haven't answered yet) and see what this means for the separation I have been trying to achieve :-) Gr. Matthijs -- 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: gadget: fix enumeration on heavy-loaded systems
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Bilovol, Ruslan
Sent: Tuesday, April 16, 2013 9:12 PM
To: Balbi, Felipe; gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: [PATCH] usb: musb: gadget: fix enumeration on heavy-loaded
systems
From musb point of view, the Address Assignment sequence during
device enumeration is next:
- first ep0 interrupt:
* read the address from USB_REQ_SET_ADDRESS request
* set up CSR0L.DataEnd bit (that is ACK
signalization for the host)
- second ep0 interrupt:
* indicates that the request completed successfully
* set up musb device address
Now musb device should answer to this address
From the host perspective, if peripheral device acquires
SET_ADDRESS request, it now may be accessed only using that address.
However, on heavy loaded systems, time between first and
second musb ep0 interrupts may be too long and musb controller
misses requests between.
What is meant by heavily loaded system? Is the device is heavily loaded during
enumeration stage? Why second ep0 interrupt is too long? whether interrupt
occurrence to interrupt service is taking too long?
As result, device enumeration may be
unsuccessful. This can be checked on USB3.0 Host and
using USB3.0 test suite (from usb.org) running ch9 tests
for USB2.0 devices.
You mean the usb2.0 musb controller (in device mode) connected to USB3.0 host?
Usually 'Addressed state/TD9.1: Device Descriptor Test' will fail
The fix consists in checking CSR0L.DataEnd state and assigning
the device address in the first ep0 interrupt handling, so
delay is as minimal as possible
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_gadget_ep0.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index c9c1ac4..59bc5a5 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -885,6 +885,37 @@ stall:
finish:
musb_writew(regs, MUSB_CSR0,
musb-ackpend);
+
+ /*
+ * If we are at end of SET_ADDRESS sequence,
+ * update the address immediately if possible,
+ * otherwise we may miss packets between
+ * sending ACK from musb side and musb's next
+ * interrupt handler firing (in which we update
+ * the address). At least this fixes next
+ * USB2.0 ch9 test of USB30CV utility:
+ * Addressed state - Device Descriptor test
+ */
+ if (musb-set_address (musb-ackpend
+ MUSB_CSR0_P_DATAEND)
+ (musb-ep0_state ==
+ MUSB_EP0_STAGE_STATUSIN)) {
+ u16 ack_delay = 500;
+
+ while ((musb_readw(regs, MUSB_CSR0)
+ MUSB_CSR0_P_DATAEND)
+ --ack_delay) {
+ cpu_relax();
+ udelay(1);
+ }
+
+ if (ack_delay) {
+ musb-set_address = false;
+ musb_writeb(mbase, MUSB_FADDR,
+ musb-address);
+ }
+ }
+
musb-ackpend = 0;
}
}
--
Ravi B
--
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 v4 00/11] usb: musb: add back support for host mode
On 10.04.2013 21:55, Daniel Mack wrote:
Hi all,
here are some patches to separate the HCD and gadget part of the musb
driver so they can be deselected in Kconfig. They also make the driver
keep track of the configured port mode that is set from DT, so the
actual runtime configuration can be selected dynamically.
One thing that is still broken is that once pm_suspend() was called on
a musb device on a USB disconnect, the port won't wake up again when a
device is plugged back in. I doubt this is related to my patches, but I
might be wrong. If that effect rings a bell to anyone, please let me
know.
Felipe, are you happy with this version?
Changes from v3:
* removed unnecessary indirection level via struct musb_hdc_link
* fixed a typo in commit log of patch 10/11
(all reported by Peter Korsgaard, thanks!)
Changes from v2:
* simplified Makefile rework
* really remove musb_to_hcd
* fixed some types
(all reported by Peter Korsgaard, thanks!)
Changes from v1:
* fixed some typos in commit logs
* factor out musb_host_resume_root_hub and
musb_host_poke_root_hub()
* split some changes into separate patches
* some minor cosmetics fixed
Daniel Mack (11):
usb: gadget: drop unused USB_GADGET_MUSB_HDRC
usb: musb: move function declarations to musb_{host,gadget}.h
usb: musb: factor some host-specific functions
usb: musb: gadget: remove hcd initialization
usb: musb: move musb_start to musb_virthub.c
usb: musb: factor out hcd initalization
usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
usb: musb: add musb_host_setup() and musb_host_cleanup()
usb: musb: re-introduce musb-port_mode
usb: musb: use musb-port_mode
usb: musb: eliminate musb_to_hcd
drivers/usb/gadget/Kconfig | 8 ---
drivers/usb/musb/Kconfig| 29 +
drivers/usb/musb/Makefile | 4 +-
drivers/usb/musb/musb_core.c| 127
+++-
drivers/usb/musb/musb_core.h| 26 +++-
drivers/usb/musb/musb_gadget.c | 10
drivers/usb/musb/musb_gadget.h | 38 ++--
drivers/usb/musb/musb_host.c| 82 +++---
drivers/usb/musb/musb_host.h| 57 ++
drivers/usb/musb/musb_virthub.c | 51 +++-
drivers/usb/musb/omap2430.c | 2 +-
11 files changed, 286 insertions(+), 148 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 10/10] staging: dwc2: properly separate common and host interrupt enabling
From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Tuesday, April 16, 2013 9:47 AM --- a/drivers/staging/dwc2/core.c +++ b/drivers/staging/dwc2/core.c ... + /* Enable common interrupts without disturbing host mode interrupts */ + intmsk = readl(hsotg-regs + GINTMSK); + intmsk |= GINTSTS_DISCONNINT | GINTSTS_MODEMIS | GINTSTS_OTGINT | + GINTSTS_CONIDSTSCHNG | GINTSTS_WKUPINT | GINTSTS_USBSUSP | GINTSTS_SESSREQINT; This should use the interrupt list that you just added in patch 8/10, right? Well, the list is not necessarily the same. For the common interrupts, the GINTSTS_RESTOREDONE interrupt is in GINTMSK_COMMON, but it is never enabled. There is only some dummy handling for this interrupt, so I'll submit a separate patch to remove that dummy handling (just like for I2CINT). This should make GINTMSK_COMMON identical to the above list. However, for host-mode interrupts, there are a number of interrupts that are not enabled in dwc2_enable_host_interrupts, but later on when needed. They still need to be in GINTMSK_HOST, since they must be handled by dwc2_handle_hcd_intr and disabled by dwc2_disable_host_interrupts (both of which use GINTMSK_HOST). Given that dwc2_enable_host_interrupts cannot simply use GINTMSK_HOST, it makes sense to not use GINTMSK_COMMON in dwc2_enable_common_interrupts either. I don't really see why. However, I did ponder about using these masks in the enable functions, since it helps robustness if you cannot accidentally enable an interrupt that is never disabled. How about the following: - in dwc2_enable_common_interrupts we just enable GINTMSK_COMMON - in dwc2_enable_host_interrupts we enable GINTMSK_HOST ~(GINTSTS_SOF|GINTSTS_PTXFEMP|GINTSTS_NPTXFEMP) (e.g., writing a list of interrupts to enable later, instead of only specifying the interrupts to enable now). The status of GINTSTS_RXFLVL would need to be handled separately, as it is now, of course. How does that look? Yeah, I think that's better. And maybe add a comment saying these three interrupts will be enabled later if needed or something like that. -- 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 02/10] staging: dwc2: do not handle PRTINT in dwc2_handle_common_intr
From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Tuesday, April 16, 2013 9:53 AM On Mon, Apr 15, 2013 at 10:22:12PM +, Paul Zimmerman wrote: From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Monday, April 15, 2013 7:14 AM For host mode, this interrupt is already handled by the hcd interrupt handler. The common interrupt handler additionally did a noop handling (it only cleared the flag and nothing else) when in device mode. Since the driver currently supports only host mode, this shouldn't result in any behaviour change in the driver. When device mode is implemented later on, this interrupt should be properly handled by the device interupt handler, if needed. This change allows to make a clean cut between common interrupts and host interrupts, since there are no longer any interrupts handled by both. Hi Matthijs, I'd rather keep this code as-is. The reason is, even though the driver is currently host-only, the core that it is operating may not be. In that case, when the USB cable is unplugged, the core will switch to device mode. In that case the interrupt handler for host mode will exit without clearing the interrupt. Ok, so if I understand this correctly this interrupt is really not a common interrupt, but it is a host interrupt as well as a device interrupt? No, the interrupt is strictly a host interrupt. But due to the design of the hardware, there's a race condition: Say the user unplugs the A connector from the host. The disconnect interrupt gets triggered, and the driver starts to process it. But unplugging the A connector also causes the core to switch to device mode, on its own, without any input from the driver. So by the time the CPU gets to the point in dwc2_hcd_intr() where it checks to see what mode the core is in, it could now be in device mode, even though the interrupt was triggered while in host mode. So there is an inherent race condition due to the way the hardware works. And the code in dwc2_handle_common_intr would be moved to the device-mode interrupt handler once it gets added? If so, I could replace this patch with a comment stating that. No, PRTINT has no meaning in device mode. However, the fact that an interrupt can be both a host and a device interrupt, might complicate things. I'll think a bit about this (also considering your other comments that I haven't answered yet) and see what this means for the separation I have been trying to achieve :-) -- 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 02/10] staging: dwc2: do not handle PRTINT in dwc2_handle_common_intr
Hi Paul, No, the interrupt is strictly a host interrupt. But due to the design of the hardware, there's a race condition: Say the user unplugs the A connector from the host. The disconnect interrupt gets triggered, and the driver starts to process it. But unplugging the A connector also causes the core to switch to device mode, on its own, without any input from the driver. So by the time the CPU gets to the point in dwc2_hcd_intr() where it checks to see what mode the core is in, it could now be in device mode, even though the interrupt was triggered while in host mode. Ah, right. This sounds like its the same as for the DISCONNINT. Perhaps the handling for PRTINT can be the same as you proposed for DISCONNINT: handle it in dwc_hcd_intr, but before the check for host mode? Gr. Matthijs -- 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 02/10] staging: dwc2: do not handle PRTINT in dwc2_handle_common_intr
From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Tuesday, April 16, 2013 12:03 PM No, the interrupt is strictly a host interrupt. But due to the design of the hardware, there's a race condition: Say the user unplugs the A connector from the host. The disconnect interrupt gets triggered, and the driver starts to process it. But unplugging the A connector also causes the core to switch to device mode, on its own, without any input from the driver. So by the time the CPU gets to the point in dwc2_hcd_intr() where it checks to see what mode the core is in, it could now be in device mode, even though the interrupt was triggered while in host mode. Ah, right. This sounds like its the same as for the DISCONNINT. Perhaps the handling for PRTINT can be the same as you proposed for DISCONNINT: handle it in dwc_hcd_intr, but before the check for host mode? Yes. Actually, it would probably be best to check the core's mode at the start of the host interrupt handler, and if it's in device mode, just clear ALL asserted host-only interrupts and return without doing anything further. According to the databook, the host-only interrupts are DisconnInt, PTxFEmp, HChInt, and PrtInt. DisconnInt is cleared via the GINTSTS register, HChInt is cleared via the HCINTn register, and PrtInt is cleared via the HPRT register. PTxFEmp can't be cleared without writing data to the FIFO, so I guess that one should just be disabled in GINTMSK. Want to take a crack at that? -- 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: USB PCI quirk issue
Excellent. The quirk is no longer triggering resource issues. This leaves an issue with dev-enable_cnt in pci_disable_device. We still get the message 'disabling already-disabled device'. I was hoping by not having the resource errors, enable_cnt would be more accurate. This occurs after: - clean boot - hot remove devices (effectively half of machine's PCI devices) - hot add devices (returned to service as described in original mail) - hot remove devices *** this is where we get 'disabling already-disabled device' I'll dig into this tomorrow. Thank you for this first step. -Original Message- From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of Yinghai Lu Sent: Monday, April 15, 2013 4:41 PM To: Sarah Sharp; Bulkow, David Cc: Lawrence, Joe; linux-...@vger.kernel.org; linux-usb@vger.kernel.org; Bjorn Helgaas; Rafael J. Wysocki Subject: Re: USB PCI quirk issue On Mon, Apr 15, 2013 at 11:26 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Cc-ing the public Linux PCI and USB mailing lists. On Fri, Apr 12, 2013 at 02:59:29PM -0400, Bulkow, David wrote: Susan, I'm Sarah. :) While testing Linux 3.9 we ran into an issue which I believe is a conflict between a couple of PCI changes. Stratus has hardware that can hot add/remove chunks of its PCI hierarchy which has tickled some of the newer code. I am mailing you because I believe the second change I list below holds the key. I believe we are experiencing a collision between two changes. The first: PCI: Put pci_dev in device tree as early as possible https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi t/?id=4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 is causing device_add to be called during pci_scan_slot. The second: USB: Fix handoff when BIOS disables host PCI device https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi t/?id=cab928ee1f221c9cc48d6615070fefe2e444384a is getting activated by device_add. looks like we call quirk_final too early for hotadd path. Please check if attached can workaround the problem. Thanks Yinghai -- 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,stable-3.8] net: cdc_mbim: remove bogus sizeof()
From: Bjørn Mork bj...@mork.no Date: Tue, 16 Apr 2013 12:17:07 +0200 The intention was to test against the constant, not the size of the constant. Signed-off-by: Bjørn Mork bj...@mork.no 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
[PATCH v3 0/4] Add USB support to R8A7778/BOCK-W
Hello. Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/4] rcar-phy: add R8A7778 support [2/4] ARM: shmobile: r8a7778: add USB support [3/4] ARM: shmobile: BOCK-W: add USB support [4/4] ARM: shmobile: BOCK-W: enable USB in defconfig WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] rcar-phy: add R8A7778 support
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.
Also mark in the driver's Kconfig section that R8A7778 is now supported and
generally clarify that section, uppercasing the word phy, while at it...
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since version 2:
- moved 'ferrite_bead' bitfield to the start of 'struct rcar_phy_platform_data'
which allowed to cut the size of the structure from 8 bytes back to 4;
- added a comment about only 2 USB ports on R8A7778'
- added an ACK from Felipe Balbi.
Changes since the original posting:
- made the necessary changes atop of the R8A7779/Marzen pathset version 4.
drivers/usb/phy/Kconfig |8
drivers/usb/phy/rcar-phy.c | 38 --
include/linux/usb/rcar-phy.h |4 +++-
3 files changed, 39 insertions(+), 11 deletions(-)
Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
SoC.
config USB_RCAR_PHY
- tristate Renesas R-Car USB phy support
+ tristate Renesas R-Car USB PHY support
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
To compile this driver as a module, choose M here: the
module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,15 +26,21 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
/* USBPCTRL0 */
-#define OVC2 (1 10) /* Switches the OVC input pin for port 2: */
+#define OVC2 (1 10) /* (R8A7779 only) */
+ /* Switches the OVC input pin for port 2: */
/* 1: USB_OVC2, 0: OVC2 */
#define OVC1_VBUS1 (1 9) /* Switches the OVC input pin for port 1: */
/* 1: USB_OVC1, 0: OVC1/VBUS1 */
/* Function mode: set to 0 */
#define OVC0 (1 8) /* Switches the OVC input pin for port 0: */
/* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT (1 6) /* Host mode: OVC2 polarity: */
+#define OVC2_ACT (1 6) /* (R8A7779 only) */
+ /* Host mode: OVC2 polarity:*/
/* 1: active-high, 0: active-low*/
#define PENC (1 4) /* Function mode: output level of PENC1 pin: */
/* 1: high, 0: low */
@@ -59,6 +65,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
+ void __iomem *reg1;
int counter;
};
@@ -78,6 +85,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy-dev;
struct rcar_phy_platform_data *pdata = dev-platform_data;
void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
@@ -96,7 +104,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
- /* (3) USB module status check */
+ /* (3) set USB-PHY in accord with the conditions of usage */
+ if (reg1) {
+ u32 hsqctl1 = pdata-ferrite_bead ? 0x41 : 0;
+ u32 hsqctl2 = pdata-ferrite_bead ? 0x0d : 7;
+
+ iowrite32(hsqctl1, reg1 + HSQCTL1);
+
[PATCH v3 2/4] ARM: shmobile: r8a7778: add USB support
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes since version 2:
- refreshed the patch.
Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.
arch/arm/mach-shmobile/Kconfig|2
arch/arm/mach-shmobile/clock-r8a7778.c|4
arch/arm/mach-shmobile/include/mach/r8a7778.h |3
arch/arm/mach-shmobile/setup-r8a7778.c| 108 ++
4 files changed, 117 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+ select USB_ARCH_HAS_EHCI
+ select USB_ARCH_HAS_OHCI
config ARCH_R8A7779
bool R-Car H1 (R8A77790)
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -104,12 +104,14 @@ static struct clk *main_clks[] = {
enum {
MSTP114,
+ MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
static struct clk mstp_clks[MSTP_NR] = {
[MSTP114] = SH_CLK_MSTP32(p_clk, MSTPCR1, 14, 0), /* Ether */
+ [MSTP100] = SH_CLK_MSTP32(p_clk, MSTPCR1, 0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(p_clk, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(p_clk, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -123,6 +125,8 @@ static struct clk mstp_clks[MSTP_NR] = {
static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID(sh-eth, mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID(ehci-platform, mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
+ CLKDEV_DEV_ID(ohci-platform, mstp_clks[MSTP100]), /* USB OHCI
port0/1 */
CLKDEV_DEV_ID(sh-sci.0, mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID(sh-sci.1, mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID(sh-sci.2, mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
#define __ASM_R8A7778_H__
#include linux/sh_eth.h
+#include linux/usb/rcar-phy.h
extern void r8a7778_add_standard_devices(void);
extern void r8a7778_add_standard_devices_dt(void);
extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
extern void r8a7778_init_delay(void);
extern void r8a7778_init_irq(void);
extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
#include linux/irqchip.h
#include linux/serial_sci.h
#include linux/sh_timer.h
+#include linux/pm_runtime.h
+#include linux/usb/phy.h
+#include linux/usb/hcd.h
+#include linux/usb/ehci_pdriver.h
+#include linux/usb/ohci_pdriver.h
+#include linux/dma-mapping.h
#include mach/irqs.h
#include mach/r8a7778.h
#include mach/common.h
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
sh_tmu##idx##_platform_data, \
sizeof(sh_tmu##idx##_platform_data))
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+ DEFINE_RES_MEM(0xffe70800, 0x100),
+ DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+ platform_device_register_resndata(platform_bus, rcar_usb_phy, -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+ if (!phy)
+ return -EIO;
+
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+
+
[PATCH v3 3/4] ARM: shmobile: BOCK-W: add USB support
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes since version 2:
- refreshed the patch.
Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
modified the comment to the 'ferrite_bead' field initializer.
arch/arm/mach-shmobile/board-bockw.c |6 ++
1 file changed, 6 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -54,6 +54,10 @@ static struct resource smsc911x_resource
DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
};
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+ .ferrite_bead = true, /* not sure about this... */
+};
+
static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT(sh-sci.0, pfc-r8a7778,
@@ -70,6 +74,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+ r8a7778_add_usb_phy_device(usb_phy_platform_data);
pinctrl_register_mappings(bockw_pinctrl_map,
ARRAY_SIZE(bockw_pinctrl_map));
@@ -110,4 +115,5 @@ DT_MACHINE_START(BOCKW_DT, bockw)
.init_machine = bockw_init,
.init_time = shmobile_timer_init,
.dt_compat = bockw_boards_compat_dt,
+ .init_late = r8a7778_init_late,
MACHINE_END
--
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 v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. Enable USB storage driver and SCSI disk driver that it needs as well... Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- arch/arm/configs/bockw_defconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) Index: renesas/arch/arm/configs/bockw_defconfig === --- renesas.orig/arch/arm/configs/bockw_defconfig +++ renesas/arch/arm/configs/bockw_defconfig @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # CONFIG_NET_CADENCE is not set # CONFIG_NET_VENDOR_BROADCOM is not set @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 CONFIG_SERIAL_SH_SCI_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_STORAGE=y +CONFIG_USB_RCAR_PHY=y CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=y # CONFIG_IOMMU_SUPPORT is not set -- 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
[RFC] [PATCH] isp1760-hcd: Re-add 195ns timing delay for processing SKIPMAP
Hi I am using an isp1763 on MPC8360 and linux-3.0.0-2 from debian. The driver is ported from Sebastian's original isp1760 and I am forward porting to Arvid's version. I noticed that a custom timing delay is missing on the new isp1760. This delay is added in [1] and an mmiowb() is added in [2] In my port to the isp1763, not having this delay makes usb mass storage detection unstable. Adding the code back improves things, but I am still having some timing issues. Here is the patch for the missing delay... diff diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c index 125e261..b07879c 100644 --- a/drivers/usb/host/isp1760-hcd.c +++ b/drivers/usb/host/isp1760-hcd.c @@ -1103,6 +1103,17 @@ static void handle_done_ptds(struct usb_hcd *hcd) int modified; int skip_map; + /* +* When this function is called from the interrupt handler to enqueue +* a follow-up packet, the SKIP register gets written and read back +* almost immediately. With ISP1761, this register requires a delay of +* 195ns between a write and subsequent read (see section 15.1.1.3). +* memory barrier is used to ensure the delay is counted after the write +* is finished on the device. +*/ + mmiowb(); + ndelay(195); + skip_map = reg_read32(hcd-regs, HC_INT_PTD_SKIPMAP_REG); priv-int_done_map = ~skip_map; skip_map = reg_read32(hcd-regs, HC_ATL_PTD_SKIPMAP_REG); /diff The symptoms I am experiencing is very similar to this case [3] where only some usb mass storage device works and others do not. My debugging seems to lead to ptd_error like this: nxp-isp1763 f801.usb: check_atl_transfer: ptd error: dw0: a8f8 dw1: 2021 dw2: 0001a000 dw3: 5600 dw4: dw5: dw6: dw7: usb 1-1.2: reset high speed USB device number 4 using nxp-isp1763 sd 2:0:0:0: [sdb] No Caching mode page present sd 2:0:0:0: [sdb] Assuming drive cache: write through nxp-isp1763 f801.usb: check_atl_transfer: ptd error: dw0: 28008000 dw1: 2420 dw2: 00038000 dw3: 5200 dw4: dw5: dw6: dw7: usb 1-1.2: reset high speed USB device number 4 using nxp-isp1763 Q1: Is my understanding correct (that we need to re-add the ndelay(195) to not violate timing?) Q2: Any ideas on how I should proceed further in debugging? References: [1] http://kerneltrap.org/mailarchive/linux-usb/2009/3/25/5238724 [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/usb/host/isp1760-hcd.c?id=ebb8a4e48722c8f5e04a6490b197d2fbc894a0f6 [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/usb/host/isp1760-hcd.c?id=0954e1c258c4018bfd370da41fbb5deb34582976 Thanks for everyone's time. -- Richard Retanubun -- 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 v3 1/4] rcar-phy: add R8A7778 support
On 04/17/2013 01:32 AM, I wrote: The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY has extra register range containing two high-speed signal quality characteristic control registers which should be set up during USB-PHY startup depending on whether a ferrite bead is in use or not. So, we now handle an optional second memory range in the driver's probe method, add the 'ferrite_bead' field to the driver's platform data, and add an extra (optional) step to the USB-PHY startup routine which sets up the extended registers. Also mark in the driver's Kconfig section that R8A7778 is now supported and generally clarify that section, uppercasing the word phy, while at it... The patch has been tested on the Marzen and BOCK-W boards. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Felipe Balbi ba...@ti.com [...] @@ -109,10 +126,11 @@ static int rcar_usb_phy_init(struct usb_ goto phy_init_end; } - /* (4) USB-PHY reset clear */ + /* (5) USB-PHY reset clear */ iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1)); /* Board specific port settings */ + printk(sizeof(*pdata) = %d\n, sizeof(*pdata)); Shoot! I thought I'd killed that... :-( WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.1 1/4] rcar-phy: add R8A7778 support
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.
Also mark in the driver's Kconfig section that R8A7778 is now supported and
generally clarify that section, uppercasing the word phy, while at it...
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since version 3:
- removed stray debugging printk() call.
Changes since version 2:
- moved 'ferrite_bead' bitfield to the start of 'struct rcar_phy_platform_data'
which allowed to cut the size of the structure from 8 bytes back to 4;
- added a comment about only 2 USB ports on R8A7778'
- added an ACK from Felipe Balbi.
Changes since the original posting:
- made the necessary changes atop of the R8A7779/Marzen pathset version 4.
drivers/usb/phy/Kconfig |8
drivers/usb/phy/rcar-phy.c | 37 +++--
include/linux/usb/rcar-phy.h |4 +++-
3 files changed, 38 insertions(+), 11 deletions(-)
Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
SoC.
config USB_RCAR_PHY
- tristate Renesas R-Car USB phy support
+ tristate Renesas R-Car USB PHY support
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
To compile this driver as a module, choose M here: the
module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,15 +26,21 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
/* USBPCTRL0 */
-#define OVC2 (1 10) /* Switches the OVC input pin for port 2: */
+#define OVC2 (1 10) /* (R8A7779 only) */
+ /* Switches the OVC input pin for port 2: */
/* 1: USB_OVC2, 0: OVC2 */
#define OVC1_VBUS1 (1 9) /* Switches the OVC input pin for port 1: */
/* 1: USB_OVC1, 0: OVC1/VBUS1 */
/* Function mode: set to 0 */
#define OVC0 (1 8) /* Switches the OVC input pin for port 0: */
/* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT (1 6) /* Host mode: OVC2 polarity: */
+#define OVC2_ACT (1 6) /* (R8A7779 only) */
+ /* Host mode: OVC2 polarity:*/
/* 1: active-high, 0: active-low*/
#define PENC (1 4) /* Function mode: output level of PENC1 pin: */
/* 1: high, 0: low */
@@ -59,6 +65,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
+ void __iomem *reg1;
int counter;
};
@@ -78,6 +85,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy-dev;
struct rcar_phy_platform_data *pdata = dev-platform_data;
void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
@@ -96,7 +104,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
- /* (3) USB module status check */
+ /* (3) set USB-PHY in accord with the conditions of usage */
+ if (reg1) {
+ u32 hsqctl1 = pdata-ferrite_bead ? 0x41 : 0;
+ u32 hsqctl2 = pdata-ferrite_bead ? 0x0d : 7;
+
+
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hi Sergei I'm going to post R8A7778/BOCK-W series following this one, and all the patches in 1st series should additionally be tested on BOCK-W. Well, I probably can hold up posting version 3 until I have the second series verified. BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not on BOCK-W board? PHY initialization seems to work with either settings... I can ask it to HW team if you want me. Yes, ask them please. Now, I'm asking it to HW team Please wait Best regards --- Kuninori Morimoto -- 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: [V9 PATCH 00/12] mv-usb phy driver
On Wed, Apr 17, 2013 at 9:17 AM, Chao Xie xiechao.m...@gmail.com wrote: On Sun, Apr 7, 2013 at 6:29 PM, Chao Xie chao@marvell.com wrote: The patches create the mv-usb phy driver directly use devm_usb_get_phy_dev return value for error return. v9-v8 Remove u2o_xxx. Add prefix for register definition Move mutex to common PHY layer Use module_platform_driver() to register driver Use usleep_range to replace udelay Chao Xie (12): usb: phy: protect phy init and shutdown for mutiple deivces usb: phy: mv_usb2: add PHY driver for marvell usb2 controller usb: gadget: mv_udc: use PHY driver for udc usb: ehci: ehci-mv: use PHY driver for ehci usb: phy: phy-mv-usb: use USB2 PHY driver for otg usb: mv_u3d: usb phy drivers for phy operation arm: mmp2: change the defintion of usb devices arm: pxa910: change the defintion of usb devices arm: ttc_dkb: modify usb support arm: mmp: remove unused usb devices arm: brownstone: add usb support for the board usb: mv_usb: remove the phy callbacks in pdata arch/arm/mach-mmp/brownstone.c | 56 + arch/arm/mach-mmp/include/mach/mmp2.h |4 + arch/arm/mach-mmp/include/mach/pxa910.h |7 +- arch/arm/mach-mmp/mmp2.c|4 + arch/arm/mach-mmp/pxa910.c |4 + arch/arm/mach-mmp/ttc_dkb.c | 39 +++- drivers/usb/gadget/mv_u3d.h |3 +- drivers/usb/gadget/mv_u3d_core.c| 54 ++--- drivers/usb/gadget/mv_udc.h |2 +- drivers/usb/gadget/mv_udc_core.c| 50 ++--- drivers/usb/host/ehci-mv.c | 49 ++--- drivers/usb/phy/Kconfig |6 + drivers/usb/phy/Makefile|1 + drivers/usb/phy/phy-mv-usb.c| 53 ++--- drivers/usb/phy/phy-mv-usb.h|2 +- drivers/usb/phy/phy-mv-usb2.c | 380 +++ drivers/usb/phy/phy.c |6 + include/linux/platform_data/mv_usb.h|3 - include/linux/usb/mv_usb2.h | 29 +++ include/linux/usb/phy.h | 22 ++- 20 files changed, 624 insertions(+), 150 deletions(-) create mode 100644 drivers/usb/phy/phy-mv-usb2.c create mode 100644 include/linux/usb/mv_usb2.h -- 1.7.4.1 hi, balbi You have given many valuable comments and suggestions for previous version. So i modified the driver based on your review feedback. Can you help to review the new version? 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 1/2 v5] usbnet: allow status interrupt URB to always be active
On Tue, Apr 16, 2013 at 3:57 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 16 April 2013 09:15:45 Ming Lei wrote: On Mon, Apr 15, 2013 at 11:59 PM, Dan Williams d...@redhat.com wrote: So, what was the general consensus on this one? I know Oliver signed off on it, but the discussion about memflags seemed to die out without a specific conclusion. davem might be looking for that conclusion before moving forward with the series :) Suggest to remove the memflags parameter, because: - the probable issue addressed by introducing memflags is a general issue of all USB drivers, also very corener one, not a specific one on usbnet, and the issue only exists on devices with at least one mass storage interface and another non-mass-storage interface, and it is not considered by other USB drivers now. Generally, saying that somebody else has a problem is not an argument as long as the fix is very simple. Of course it is a corner case, but why fail to solve it as long as the cost is extremely low? The cost isn't low because users have to decide(learn) when to use GFP_NOIO and when to use GFP_KERNEL, and GFP_NOIO isn't easy to use, especially in the corner case which isn't easy to understand too. I bet few of guys can think of the case and the usage if they don't recall previous threads. If you want to avoid the corner case, just hardcode GFP_NOIO in the API. As we see, both current usage of the API may have the corner case. - usbnet_status_start() is called from either probe() or work queue scheduled from probe(), if we want to address the probable issue, the memflags should No, we export this symbol. So we keep it generic if that is possible at low cost. We cannot assume that the conditions it would be called in now, remain so. Of course we don't add stuff needlessly, but here the fix is trivial. Why we can't assume the conditions? The API is introduced just for solving one specific problem of sierra net, and shouldn't apply to general situations and its usage is __not__ encouraged since it introduces extra power consumption. If you have other use cases which need the API, please post them out for discussion. In fact, it is sort of a workaround for sierra device only, so we don't need to make it general in the extreme, IMO. The fix isn't trivial since GFP_NOIO isn't trivial and the corner case isn't easy to understand, as I said above. always be GFP_NOIO under the two situations, __or__ GFP_KERNEL if we choose to ignore the very corner case like other USB drivers. So hardcoded GFP_NOIO or GFP_KERNEL should be accepted. Oliver, do you have objections on not adding the memflags parameter now? Yes, it is a change of almost no gain and a known problem. It should be added with mem_flags. Williams, looks there is another problem in your patch, sorry for not finding it previously. usb_autopm_get_interface() need to be called before submitting URB inside usbnet_status_start(), and usb_autopm_put_interface() need to be called after killing URB inside usbnet_status_stop(). Otherwise your patch doesn't work as you expected under runtime PM situation. Again, no. This is a generic API. It may be called for devices which need their status polled forever and we cannot block them from sleeping. If a driver wants to block suspend while a status URB is on, it should call the autopm method. This is the way we do it while the connection is up. The API can't be called in atomic context at all since mutex is to be held. Also I am wondering there is valid use case for such usage, if you have, please post them out. Thanks, -- Ming Lei -- 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/1] usb: gadget/uvc: Add support to allocate UVC payload and header as SG elements
This patch adds the support in UVC webcam gadget to allocate UVC header and
payload as Scatter-Gather elements which can be used on a SG-capable UDC
controller.
A module parameter has been introduced for the same. One can set the
module parameter 'sg_mode' to 1 to turn on this feature (by default this
feature is turned-off).
This ensures that we don't require a memcpy from CPU side to append UVC
header in front of the UVC payload atleast for SG capable UDC contollers.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
Note that to ease review and integration of this patch, I have rebased it
on the following patch already circulated for review last week:
[PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as
Video Streaming ep
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19546.html
The above patch was rebased on Laurent's UVC gadget git tree available here
(head uvc-gadget):
git://linuxtv.org/pinchartl/uvcvideo.git
This will allow the patches to be pulled into Felipe's repo in one go
after review and any subsequent rework (if required).
drivers/usb/gadget/f_uvc.c |8 +++
drivers/usb/gadget/uvc.h |2 +
drivers/usb/gadget/uvc_video.c | 113 +++-
3 files changed, 109 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index e5953eb..ccf0253 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -50,6 +50,11 @@ module_param(bulk_streaming_ep, bool, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(bulk_streaming_ep, 0 (Use ISOC video streaming ep) /
1 (Use BULK video streaming ep));
+static bool sg_mode;
+module_param(sg_mode, bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(sg_mode, 0 (Don't use SG feature) /
+ 1 (Use scatterlist for SG-capable controllers));
+
/* --
* Function descriptors
*/
@@ -888,6 +893,9 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f)
uvc-control_req-complete = uvc_function_ep0_complete;
uvc-control_req-context = uvc;
+ /* Use SG mode ? */
+ uvc-video.sg_mode = sg_mode;
+
/* Avoid letting this gadget enumerate until the userspace server is
* active.
*/
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 8756853..3a54510 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -122,6 +122,7 @@ struct uvc_video
struct usb_request *req[UVC_NUM_REQUESTS];
__u8 *req_buffer[UVC_NUM_REQUESTS];
struct list_head req_free;
+ unsigned char *header_buf;
spinlock_t req_lock;
void (*encode) (struct usb_request *req, struct uvc_video *video,
@@ -135,6 +136,7 @@ struct uvc_video
unsigned int fid;
bool bulk_streaming_ep;
+ bool sg_mode;
};
enum uvc_state
diff --git a/drivers/usb/gadget/uvc_video.c b/drivers/usb/gadget/uvc_video.c
index 87ac526..5f92f93 100644
--- a/drivers/usb/gadget/uvc_video.c
+++ b/drivers/usb/gadget/uvc_video.c
@@ -39,6 +39,25 @@ uvc_video_encode_header(struct uvc_video *video, struct
uvc_buffer *buf,
}
static int
+uvc_video_encode_header_sg(struct uvc_video *video, struct uvc_buffer *buf,
+ int len)
+{
+ unsigned char *data = video-header_buf;
+
+ *data++ = 2;
+ *data = UVC_STREAM_EOH | video-fid;
+
+ if (!video-bulk_streaming_ep) {
+ if (buf-bytesused - video-queue.buf_used = len - 2)
+ *data |= UVC_STREAM_EOF;
+ } else {
+ *data |= UVC_STREAM_EOF;
+ }
+
+ return 2;
+}
+
+static int
uvc_video_encode_data(struct uvc_video *video, struct uvc_buffer *buf,
u8 *data, int len)
{
@@ -56,25 +75,57 @@ uvc_video_encode_data(struct uvc_video *video, struct
uvc_buffer *buf,
return nbytes;
}
+static int
+uvc_video_encode_data_sg(struct uvc_video *video, struct uvc_buffer *buf,
+struct scatterlist *sg, int len)
+{
+ struct uvc_video_queue *queue = video-queue;
+ unsigned int nbytes;
+
+ /* Pass pointer of video frame data to the USB req-sg. */
+ nbytes = min((unsigned int)len, buf-bytesused - queue-buf_used);
+
+ sg_set_buf(sg, (void *)(buf-mem + queue-buf_used), len);
+ queue-buf_used += nbytes;
+
+ return nbytes;
+}
+
static void
uvc_video_encode_bulk(struct usb_request *req, struct uvc_video *video,
struct uvc_buffer *buf)
{
- void *mem = req-buf;
+ struct scatterlist *sg = NULL;
+ void *mem = NULL;
int len = video-req_size;
int ret;
/* Add a header at the beginning of the payload. */
+ if (!video-sg_mode)
+ mem = req-buf;
+ else
+ sg = req-sg;
+
if
RE: [Test Application PATCH 0/2] UVC gadget test application enhancements
Hi Laurent, Hi Bhupesh, On Wednesday 10 April 2013 18:37:42 Bhupesh SHARMA wrote: Hi Laurent, This patchset tries to enhance the UVC gadget test application and is based on Laurent's git tree available here (project: uvc-gadget.git): git://git.ideasonboard.org/uvc-gadget.git The patch 2/2 in this patchset also adds a README file describing the UVC gadget test application, it's possible use-case scenarios and IO method support in detail. The 'linux-usb' list is also added to CC of this patchset (although this is a test application related change), as I have received interest from a number of users on the list regarding availability of this patchset. Bhupesh Sharma (2): UVC gadget: Add support for integration with a video-capture device and other fixes UVC gadget: Add a README file describing the UVC gadget test application README | 209 ++ uvc-gadget.c | 2156 +++-- 2 files changed, 2159 insertions(+), 206 deletions(-) create mode 100644 README -- 1.7.2.2 Can you please review this patchset and let me know if I need to change something here? @ Ammar, can you please test this application patch at your end and provide your feedbacks? The first patch is pretty big, but I'll try to review it soon. Next time could you please try to split those large patches in a set of smaller patches ? Sure. I have also sent out two more patches related to UVC webcam gadget driver, which can be seen here: 1. [PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as Video Streaming ep http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19546.html 2. [PATCH 1/1] usb: gadget/uvc: Add support to allocate UVC payload and header as SG elements http://comments.gmane.org/gmane.linux.usb.general/85292 I would request you to please go through these patches as well and let me know your review comments. Also, as I am in-between jobs, I would request you/other reviewers to use my personal ID for future communications: bhupesh.li...@gmail.com Regards, Bhupesh
[PATCH] usb: storage: Add usb_stor_dbg, reduce object size
Reduce the size of the objects by consolidating
the duplicated USB_STORAGE into a single function.
Add function usb_stor_dbg to emit debugging messages.
Always validate the format and arguments.
Reduce the number of uses of CONFIG_USB_STORAGE_DEBUG.
Reduces size of objects ~7KB when CONFIG_USB_STORAGE_DEBUG
is set.
$ size drivers/usb/storage/built-in.o*
textdata bss dec hex filename
140133 55296 70312 265741 40e0d drivers/usb/storage/built-in.o.new
147494 55248 70296 273038 42a8e drivers/usb/storage/built-in.o.old
Signed-off-by: Joe Perches j...@perches.com
---
drivers/usb/storage/debug.c | 20 +++-
drivers/usb/storage/debug.h | 14 +-
drivers/usb/storage/isd200.c | 12 ++--
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/storage/debug.c b/drivers/usb/storage/debug.c
index a2b5526..b428129 100644
--- a/drivers/usb/storage/debug.c
+++ b/drivers/usb/storage/debug.c
@@ -150,7 +150,7 @@ void usb_stor_show_command(struct scsi_cmnd *srb)
default: what = (unknown command); break;
}
US_DEBUGP(Command %s (%d bytes)\n, what, srb-cmd_len);
- US_DEBUGP();
+ US_DEBUGP(bytes: );
for (i = 0; i srb-cmd_len i 16; i++)
US_DEBUGPX( %02x, srb-cmnd[i]);
US_DEBUGPX(\n);
@@ -175,3 +175,21 @@ void usb_stor_show_sense(
US_DEBUGPX(what, ascq);
US_DEBUGPX(\n);
}
+
+int usb_stor_dbg(const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int r;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = args;
+
+ r = printk(KERN_DEBUG USB_STORAGE %pV, vaf);
+
+ va_end(args);
+
+ return r;
+}
diff --git a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h
index dbb985d..d4280e1 100644
--- a/drivers/usb/storage/debug.h
+++ b/drivers/usb/storage/debug.h
@@ -50,12 +50,16 @@
void usb_stor_show_command(struct scsi_cmnd *srb);
void usb_stor_show_sense( unsigned char key,
unsigned char asc, unsigned char ascq );
-#define US_DEBUGP(x...) printk( KERN_DEBUG USB_STORAGE x )
-#define US_DEBUGPX(x...) printk( x )
-#define US_DEBUG(x) x
+__printf(1, 2) int usb_stor_dbg(const char *fmt, ...);
+
+#define US_DEBUGP(fmt, ...)usb_stor_dbg(fmt, ##__VA_ARGS__)
+#define US_DEBUGPX(fmt, ...) printk(fmt, ##__VA_ARGS__)
+#define US_DEBUG(x)x
#else
-#define US_DEBUGP(x...)
-#define US_DEBUGPX(x...)
+#define US_DEBUGP(fmt, ...)\
+ do { if (0) printk(fmt, ##__VA_ARGS__); } while (0)
+#define US_DEBUGPX(fmt, ...) \
+ do { if (0) printk(fmt, ##__VA_ARGS__); } while (0)
#define US_DEBUG(x)
#endif
diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index 06a3d22..55571ae 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -926,10 +926,6 @@ static int isd200_try_enum(struct us_data *us, unsigned
char master_slave,
/* loop until we detect !BSY or timeout */
while(1) {
-#ifdef CONFIG_USB_STORAGE_DEBUG
- char* mstr = master_slave == ATA_ADDRESS_DEVHEAD_STD ?
- Master : Slave;
-#endif
status = isd200_action( us, ACTION_ENUM, NULL, master_slave );
if ( status != ISD200_GOOD )
@@ -942,9 +938,13 @@ static int isd200_try_enum(struct us_data *us, unsigned
char master_slave,
if (!detect) {
if (regs[ATA_REG_STATUS_OFFSET] ATA_BUSY) {
- US_DEBUGP( %s status is still BSY, try
again...\n,mstr);
+ US_DEBUGP( %s status is still BSY, try
again...\n,
+ master_slave ==
ATA_ADDRESS_DEVHEAD_STD ?
+ Master : Slave);
} else {
- US_DEBUGP( %s status !BSY, continue with
next operation\n,mstr);
+ US_DEBUGP( %s status !BSY, continue with
next operation\n,
+ master_slave ==
ATA_ADDRESS_DEVHEAD_STD ?
+ Master : Slave);
break;
}
}
--
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
