RE: [PATCH v4 9/9] usb: chipidea: add support to the generic PHY framework in ChipIdea
Hi, -Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Antoine Tenart Sent: Wednesday, September 03, 2014 3:41 PM To: ba...@ti.com; gre...@linuxfoundation.org; Chen Peter-B29397; kis...@ti.com; st...@rowland.harvard.edu Cc: Antoine Tenart; sergei.shtyl...@cogentembedded.com; yoshihiro.shimoda...@renesas.com; alexandre.bell...@free-electrons.com; thomas.petazz...@free-electrons.com; z...@marvell.com; jszh...@marvell.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org Subject: [PATCH v4 9/9] usb: chipidea: add support to the generic PHY framework in ChipIdea This patch adds support of the PHY framework for ChipIdea drivers. Changes are done in both the ChipIdea common code and in the drivers accessing the PHY. This is done by adding a new PHY member in ChipIdea's structures and by taking care of it in the code. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/usb/chipidea/ci.h | 5 ++- drivers/usb/chipidea/core.c| 74 ++ drivers/usb/chipidea/debug.c | 3 +- drivers/usb/chipidea/host.c| 5 ++- drivers/usb/chipidea/otg_fsm.c | 6 +++- include/linux/usb/chipidea.h | 2 ++ 6 files changed, 78 insertions(+), 17 deletions(-) ... diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index 5a7ea93011dd..999e9d683d7a 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -219,7 +219,8 @@ static int ci_otg_show(struct seq_file *s, void *unused) fsm = ci-fsm; /* -- State - */ - usb_otg_state_string(ci-usb_phy-otg.state)); + seq_printf(s, OTG state: %s\n\n, Still not resolve this? Li Jun + usb_otg_state_string(ci-otg.state)); /* -- State Machine Variables - */ seq_printf(s, a_bus_drop: %d\n, fsm-a_bus_drop); diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c index -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 3, 2014 at 8:12 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Sep 03, 2014 at 12:59:27PM +0530, Vivek Gautam wrote: On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK(0x3f 1) #define LINKSYSTEM_FLADJ(_x) ((_x) 1) #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) #define EXYNOS5_DRD_PHYUTMI 0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE 0x0c #define EXYNOS5_DRD_PHYCLKRST0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 21) #define PHYCLKRST_SSC_RANGE(_x) ((_x) 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 8) #define PHYCLKRST_FSEL(_x) ((_x) 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - #define PHYCLKRST_PORTRESET BIT(1) #define PHYCLKRST_COMMONONN BIT(0) #define EXYNOS5_DRD_PHYREG0 0x14 +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) +#define PHYREG0_SSC_RANGEBIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READ BIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) 2) +#define PHYREG0_CR_CAP_DATA BIT(1) +#define PHYREG0_CR_CAP_ADDR BIT(0) + #define EXYNOS5_DRD_PHYREG1 0x18 +#define PHYREG1_CR_DATA_OUT(_x) ((_x) 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM00x1c - #define PHYPARAM0_REF_USE_PADBIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 26) #define EXYNOS5_DRD_PHYPARAM10x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f 0) #define PHYPARAM1_PCS_TXDEEMPH
[PATCH v7 1/2] usb: gadget: f_fs: add ioctl returning ep descriptor
This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/function/f_fs.c | 23 +++
include/uapi/linux/usb/functionfs.h | 6 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 0dc3552d..978a4c9 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1032,6 +1032,29 @@ static long ffs_epfile_ioctl(struct file *file, unsigned
code,
case FUNCTIONFS_ENDPOINT_REVMAP:
ret = epfile-ep-num;
break;
+ case FUNCTIONFS_ENDPOINT_DESC:
+ {
+ int desc_idx;
+ struct usb_endpoint_descriptor *desc;
+
+ switch (epfile-ffs-gadget-speed) {
+ case USB_SPEED_SUPER:
+ desc_idx = 2;
+ break;
+ case USB_SPEED_HIGH:
+ desc_idx = 1;
+ break;
+ default:
+ desc_idx = 0;
+ }
+ desc = epfile-ep-descs[desc_idx];
+
+ spin_unlock_irq(epfile-ffs-eps_lock);
+ ret = copy_to_user((void *)value, desc, sizeof(*desc));
+ if (ret)
+ ret = -EFAULT;
+ return ret;
+ }
default:
ret = -ENOTTY;
}
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..7677108 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -265,6 +265,12 @@ struct usb_functionfs_event {
*/
#defineFUNCTIONFS_ENDPOINT_REVMAP _IO('g', 129)
+/*
+ * Returns endpoint descriptor. If function is not active returns -ENODEV.
+ */
+#defineFUNCTIONFS_ENDPOINT_DESC_IOR('g', 130, \
+struct usb_endpoint_descriptor)
+
#endif /* _UAPI__LINUX_FUNCTIONFS_H__ */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/2] usb: gadget: f_fs: userspace API fixes and improvements
This patchset contains changes in FunctionFS making it easier and safer to use. It fixes bug in endpoint files handling code, adds new ioctl allowing to obtain endpoint descriptor, and introduces virtual address mapping which allows to separate endpoint address space in function from physical endpoint addresses, and introduces new endpoint files naming convention. Changelog: v7: - return proper value from ffs_epfile_ioctl() function - remove patch usb: gadget: f_fs: fix the redundant ep files problem from this patchset because it's already in Gregs tree v6: https://lkml.org/lkml/2014/8/25/101 - unlock spinlock before copy_to_user() call - remove duplicated eps_count value check - few minor fixes v5: https://lkml.org/lkml/2014/8/21/252 - fix typo pointed by Sergei Shtylyov v4: https://lkml.org/lkml/2014/8/20/277 - change if() sequence into switch() statement v3: https://lkml.org/lkml/2014/7/30/115 - move fix for the redundant ep files problem into sepatare patch - merge user space API affecting changes into single patch - add flag switching between old and new style API v2: https://lkml.org/lkml/2014/7/25/296 - return proper endpont address in setup request handling - add patch usb: gadget: f_fs: add ioctl returning ep descriptor - add patch usb: gadget: f_fs: make numbers in ep file names the same as ep addresses v1: https://lkml.org/lkml/2014/7/18/1010 Robert Baldyga (2): usb: gadget: f_fs: add ioctl returning ep descriptor usb: gadget: f_fs: virtual endpoint address mapping drivers/usb/gadget/function/f_fs.c | 46 +++-- drivers/usb/gadget/function/u_fs.h | 2 ++ include/uapi/linux/usb/functionfs.h | 7 ++ 3 files changed, 53 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping
This patch introduces virtual endpoint address mapping. It separates
function logic form physical endpoint addresses making it more hardware
independent.
Following modifications changes user space API, so to enable them user
have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.
Endpoints are now refered using virtual endpoint addresses chosen by
user in endpoint descpriptors. This applies to each context when endpoint
address can be used:
- when accessing endpoint files in FunctionFS filesystemi (in file name),
- in setup requests directed to specific endpoint (in wIndex field),
- in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.
In endpoint file names the endpoint address number is formatted as
double-digit hexadecimal value (ep%02x) which has few advantages -
it is easy to parse, allows to easly recognize endpoint direction basing
on its name (IN endpoint number starts with digit 8, and OUT with 0)
which can be useful for debugging purpose, and it makes easier to introduce
further features allowing to use each endpoint number in both directions
to have more endpoints available for function if hardware supports this
(for example we could have ep01 which is endpoint 1 with OUT direction,
and ep81 which is endpoint 1 with IN direction).
Physical endpoint address can be still obtained using ioctl named
FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
USB transactions properly.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/function/f_fs.c | 23 +--
drivers/usb/gadget/function/u_fs.h | 2 ++
include/uapi/linux/usb/functionfs.h | 1 +
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 978a4c9..4d3a0d5 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1557,7 +1557,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
epfile-ffs = ffs;
mutex_init(epfile-mutex);
init_waitqueue_head(epfile-wait);
- sprintf(epfiles-name, ep%u, i);
+ if (ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ sprintf(epfiles-name, ep%02x, ffs-eps_addrmap[i]);
+ else
+ sprintf(epfiles-name, ep%u, i);
if (!unlikely(ffs_sb_create_file(ffs-sb, epfiles-name, epfile,
ffs_epfile_operations,
epfile-dentry))) {
@@ -2106,10 +2109,12 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
break;
case FUNCTIONFS_DESCRIPTORS_MAGIC_V2:
flags = get_unaligned_le32(data + 8);
+ ffs-user_flags = flags;
if (flags ~(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC |
FUNCTIONFS_HAS_SS_DESC |
- FUNCTIONFS_HAS_MS_OS_DESC)) {
+ FUNCTIONFS_HAS_MS_OS_DESC |
+ FUNCTIONFS_VIRTUAL_ADDR)) {
ret = -ENOSYS;
goto error;
}
@@ -2464,7 +2469,13 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
} else {
struct usb_request *req;
struct usb_ep *ep;
+ u8 bEndpointAddress;
+ /*
+* We back up bEndpointAddress because autoconfig overwrites
+* it with physical endpoint address.
+*/
+ bEndpointAddress = ds-bEndpointAddress;
pr_vdebug(autoconfig\n);
ep = usb_ep_autoconfig(func-gadget, ds);
if (unlikely(!ep))
@@ -2479,6 +2490,12 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
ffs_ep-req = req;
func-eps_revmap[ds-bEndpointAddress
USB_ENDPOINT_NUMBER_MASK] = idx + 1;
+ /*
+* If we use virtual address mapping, we restore
+* original bEndpointAddress value.
+*/
+ if (func-ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ ds-bEndpointAddress = bEndpointAddress;
}
ffs_dump_mem(: Rewritten ep desc, ds, ds-bLength);
@@ -2923,6 +2940,8 @@ static int ffs_func_setup(struct usb_function *f,
ret = ffs_func_revmap_ep(func, le16_to_cpu(creq-wIndex));
if (unlikely(ret 0))
return ret;
+ if (func-ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ ret = func-ffs-eps_addrmap[ret];
break;
default:
diff --git a/drivers/usb/gadget/function/u_fs.h
b/drivers/usb/gadget/function/u_fs.h
index
RE: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
-Original Message- From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] Sent: Tuesday, August 19, 2014 3:01 PM To: Sharma, Sanjeev Cc: kra...@redhat.com; mdharm-...@one-eyed-alien.net; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; linux-s...@vger.kernel.org; Hans de Goede Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held() On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote: Hi Greg, Any feedback on this patch ? The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, _and_ my queue is currently sitting at: $ mdfrm -c ~/mail/todo/ 1317 messages in /home/gregkh/mail/todo/ So please be patient. I'll get to it in a few weeks. Please let me know when this is going to be merged ? Thanks Sanjeev 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 resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
Johan,
I noticed I submitted an error here. Will resend later today.
On Mon, Sep 1, 2014 at 11:39 AM, Frans Klaver frans.kla...@xsens.com wrote:
Probe is testing if the current interface provides two bulk endpoints.
While this achieves the goal of only binding to the correct interface,
we already know we can find the device on interface number 1. Stop
checking the endpoints and just return successfully when interface
number 1 is probed.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/usb/serial/xsens_mt.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
index d500ccd..ea67ed9 100644
--- a/drivers/usb/serial/xsens_mt.c
+++ b/drivers/usb/serial/xsens_mt.c
@@ -41,28 +41,13 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
-static int has_required_endpoints(const struct usb_host_interface *interface)
-{
- __u8 i;
- int has_bulk_in = 0;
- int has_bulk_out = 0;
-
- for (i = 0; i interface-desc.bNumEndpoints; ++i) {
- if (usb_endpoint_is_bulk_in(interface-endpoint[i].desc))
- has_bulk_in = 1;
- else if
(usb_endpoint_is_bulk_out(interface-endpoint[i].desc))
- has_bulk_out = 1;
- }
-
- return has_bulk_in has_bulk_out;
-}
-
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial-interface-cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial-interface-cur_altsetting.desc.bInterfaceNumber == 1)
This should be
if (serial-interface-cur_altsetting-desc.bInterfaceNumber == 1)
+ return 0;
+
+ return -ENODEV;
}
static struct usb_serial_driver xsens_mt_device = {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: serial: xsens_mt: always bind to interface number 1
Probe is testing if the current interface provides two bulk endpoints.
While this achieves the goal of only binding to the correct interface,
we already know we can find the device on interface number 1. Stop
checking the endpoints and just return successfully when interface
number 1 is probed.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/usb/serial/xsens_mt.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
index d500ccd..3837d51 100644
--- a/drivers/usb/serial/xsens_mt.c
+++ b/drivers/usb/serial/xsens_mt.c
@@ -41,28 +41,13 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
-static int has_required_endpoints(const struct usb_host_interface *interface)
-{
- __u8 i;
- int has_bulk_in = 0;
- int has_bulk_out = 0;
-
- for (i = 0; i interface-desc.bNumEndpoints; ++i) {
- if (usb_endpoint_is_bulk_in(interface-endpoint[i].desc))
- has_bulk_in = 1;
- else if (usb_endpoint_is_bulk_out(interface-endpoint[i].desc))
- has_bulk_out = 1;
- }
-
- return has_bulk_in has_bulk_out;
-}
-
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial-interface-cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial-interface-cur_altsetting-desc.bInterfaceNumber == 1)
+ return 0;
+
+ return -ENODEV;
}
static struct usb_serial_driver xsens_mt_device = {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: EHCI Isochronous schedule full?
Hi Alan. The machine has only two cameras inserted (no hids, nothing else). While the cameras have an interrupt endpoint, I disabled it in uvc_video. Still I don't get more than two cameras into the schedule. So there are no interrupt endpoints besides the one used for the internal hubs. They are 2 and their schedule is 4bytes per 256ms. Hardly a large load. With the interrupt endpoints on the camera, usage was 98%, now it's 93% with them disabled. T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc=744/800 us (93%), #Int= 2, #Iso= 10 The only reason I can come up with to make this happen is that the driver does not send 3 packets per microframe worth of isoc-data or that the scheduler does not account for that capacity, ie only 8 microframes * 1024 bytes. Something along that path. Or the scheduler is really, really broken. :) That would probably give me 80%+ usage when it should not be more than 30-35%. Searching the net for it yields approx. the same information. People are lucky to be able to run two cameras with Linux. Regards, Christian From: Alan Stern [st...@rowland.harvard.edu] Sent: Wednesday, 03 September 2014 6:16 PM To: Christian Melki Cc: linux-usb@vger.kernel.org Subject: Re: EHCI Isochronous schedule full? On Wed, 3 Sep 2014, Christian Melki wrote: I've probably got this wrong... I try to run several cameras with compressed streams (MJPEG) using maxpacket 3*1024 isoc-endpoints. EHCI should be able to transmit 8 microframes * 1024 bytes * 3 packets of data per frame (approx 24MB/sec). Two cameras work fine, but when I connect a third camera I get -ENOSPC from the scheduler. I don't get how the schedule can be full. One camera should be able to fit within one microframe. (3 * 1024b). That leaves atleast 7 microframes available if 100% of bandwith is used for isochronous transfers (not likely, but anyway). Debugfs lists the periodic schedule as (two cameras connected): /sys/kernel/debug/usb/ehci/fsl-ehci.0 cat periodic size = 512 1: qh256-0001/c3b0bd40 (h2 ep1in [1/0] q1 p1) 6: qh16-0001/c301d080 (h7 ep3in [1/0] q1 p8) 7: qh256-0001/c3b72180 (h8 ep1in [1/0] q1 p1) 9: qh16-0001/c30dd100 (h10 ep7in [1/0] q1 p16) 22: qh16-0001/c301d080 25: qh16-0001/c30dd100 38: qh16-0001/c301d080 41: qh16-0001/c30dd100 54: qh16-0001/c301d080 57: qh16-0001/c30dd100 70: qh16-0001/c301d080 73: qh16-0001/c30dd100 86: qh16-0001/c301d080 89: qh16-0001/c30dd100 102: qh16-0001/c301d080 105: qh16-0001/c30dd100 118: qh16-0001/c301d080 121: qh16-0001/c30dd100 134: qh16-0001/c301d080 137: qh16-0001/c30dd100 150: qh16-0001/c301d080 153: qh16-0001/c30dd100 166: qh16-0001/c301d080 169: qh16-0001/c30dd100 182: qh16-0001/c301d080 185: qh16-0001/c30dd100 198: qh16-0001/c301d080 201: qh16-0001/c30dd100 214: qh16-0001/c301d080 217: qh16-0001/c30dd100 230: qh16-0001/c301d080 233: qh16-0001/c30dd100 246: qh16-0001/c301d080 249: qh16-0001/c30dd100 257: qh256-0001/c3b0bd40 262: qh16-0001/c301d080 263: qh256-0001/c3b72180 265: qh16-0001/c30dd100 278: qh16-0001/c301d080 281: qh16-0001/c30dd100 294: qh16-0001/c301d080 297: qh16-0001/c30dd100 310: qh16-0001/c301d080 313: qh16-0001/c30dd100 326: qh16-0001/c301d080 329: qh16-0001/c30dd100 342: qh16-0001/c301d080 345: qh16-0001/c30dd100 358: qh16-0001/c301d080 361: qh16-0001/c30dd100 374: qh16-0001/c301d080 377: qh16-0001/c30dd100 390: qh16-0001/c301d080 393: qh16-0001/c30dd100 406: qh16-0001/c301d080 409: qh16-0001/c30dd100 422: qh16-0001/c301d080 425: qh16-0001/c30dd100 438: qh16-0001/c301d080 441: qh16-0001/c30dd100 453: itd/c32901e0 itd/c3290500 454: itd/c33c1d20 itd/c20ec000 qh16-0001/c301d080 455: itd/c20eca00 itd/c20d5320 456: itd/c32d08c0 itd/c32d05a0 457: itd/c20e83c0 itd/c20e86e0 qh16-0001/c30dd100 458: itd/c20e8460 itd/c20e8780 459: itd/c20ecaa0 itd/c20ec6e0 460: itd/c33c16e0 itd/c20ece60 461: itd/c33c1aa0 itd/c20ec140 462: itd/c21eaaa0 itd/c21eadc0 463: itd/c32900a0 itd/c32903c0 464: itd/c33c1960 itd/c20ecf00 465: itd/c3155dc0 itd/c3155aa0 466: itd/c20ec320 itd/c33cc0a0 467: itd/c3155c80 itd/c3155960 468: itd/c3155e60 itd/c3155b40 469: itd/c21ea1e0 itd/c21ea500 470: itd/c20ec780 itd/c33c1780 qh16-0001/c301d080 471: itd/c21eabe0 itd/c21ea8c0 472: itd/c21ea140 itd/c21ea460 473: qh16-0001/c30dd100 486: qh16-0001/c301d080 489: qh16-0001/c30dd100 502: qh16-0001/c301d080 505: qh16-0001/c30dd100 which is ~90 entries out of the 512 uframe schedule size. So why do I get -ENOSPC? This is probably a result of the interrupt transfers using up space in the schedule. If you can get rid of them (by unplugging the devices that require them, or plugging the devices into a different USB bus), leaving only the isochronous
[PATCH net-next v3 1/2] r8152: change the location of rtl8152_set_mac_address
Exchange the location of rtl8152_set_mac_address() and
set_ethernet_addr(). Then, the set_ethernet_addr() could
set the MAC address by calling rtl8152_set_mac_address()
later.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 80b0179..b5ff933 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -975,6 +975,23 @@ void write_mii_word(struct net_device *netdev, int phy_id,
int reg, int val)
static int
r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
+static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
+{
+ struct r8152 *tp = netdev_priv(netdev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+
+ memcpy(netdev-dev_addr, addr-sa_data, netdev-addr_len);
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
+ pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr-sa_data);
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+
+ return 0;
+}
+
static inline void set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp-netdev;
@@ -1003,23 +1020,6 @@ static inline void set_ethernet_addr(struct r8152 *tp)
}
}
-static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
-{
- struct r8152 *tp = netdev_priv(netdev);
- struct sockaddr *addr = p;
-
- if (!is_valid_ether_addr(addr-sa_data))
- return -EADDRNOTAVAIL;
-
- memcpy(netdev-dev_addr, addr-sa_data, netdev-addr_len);
-
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
- pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr-sa_data);
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
-
- return 0;
-}
-
static void read_bulk_callback(struct urb *urb)
{
struct net_device *netdev;
--
1.9.3
--
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 resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial-interface-cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial-interface-cur_altsetting.desc.bInterfaceNumber == 1)
This should be
if (serial-interface-cur_altsetting-desc.bInterfaceNumber == 1)
So this wasn't even compile tested. Always test your patches before
submission, including trivial ones.
Is the new version tested on actual hardware?
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB-serial fixes for v3.17-rc4
Hi Greg, Here's a few device id updates for v3.17-rc4. I added the zte_ev one to my tree when it missed rc3, but didn't ask you to drop it from your queue so you have already applied that one. Thanks, Johan The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.17-rc4 for you to fetch changes up to 5b3da69285c143b7ea76b3b9f73099ff1093ab73: USB: sierra: add 1199:68AA device ID (2014-09-01 11:55:30 +0200) USB-serial fixes for v3.17-rc4 These updates add back some PIDs that were lost in a recent revert and add a couple of new ones. Included is also an update to how the sierra driver binds its interfaces in order to avoid binding CDC interfaces. Signed-off-by: Johan Hovold jo...@kernel.org Bjørn Mork (2): USB: sierra: avoid CDC class functions on 68A3 devices USB: sierra: add 1199:68AA device ID Johan Hovold (2): USB: zte_ev: fix removed PIDs USB: ftdi_sio: add support for NOVITUS Bono E thermal printer drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 6 ++ drivers/usb/serial/sierra.c | 9 +++-- drivers/usb/serial/zte_ev.c | 8 4 files changed, 22 insertions(+), 2 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] usb: usbip: fix usbip.h path in userspace tool
On Thu, Sep 4, 2014 at 2:41 AM, Greg KH gre...@linuxfoundation.org wrote: Shouldn't you be able to use the same path as ch9.h uses? It's a uapi .h file, no relative paths should be needed. For the userspace tool, the build system only looks for headers in the system default locations, such as /usr/include. Hence, this won't work for systems that don't have kernel 3.17 headers. This patch is a pretty nasty hack to get it to compile within the kernel tree. I wonder whether we can make this self-contained by duplicating the header's content inside usbip_common.h. Greg, Shuah, what do you think? Thanks, Valentina -- 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-next v3 0/2] r8152: random MAC address
If the interface has invalid MAC address, it couldn't be used. In order to let it work normally, give a random one. v3: Remove ether_addr_copy(dev-perm_addr, dev-dev_addr); v2: Use %pM format specifier for printing a MAC address. Hayes Wang (2): r8152: change the location of rtl8152_set_mac_address r8152: use eth_hw_addr_random drivers/net/usb/r8152.c | 65 - 1 file changed, 37 insertions(+), 28 deletions(-) -- 1.9.3 -- 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 resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
On Thu, Sep 04, 2014 at 10:15:22AM +0200, Johan Hovold wrote:
On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial-interface-cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial-interface-cur_altsetting.desc.bInterfaceNumber == 1)
This should be
if (serial-interface-cur_altsetting-desc.bInterfaceNumber == 1)
So this wasn't even compile tested. Always test your patches before
submission, including trivial ones.
Is the new version tested on actual hardware?
The implementation was tested (also fixed) before the first submission.
Not the patches. Looks like I've got a step to add.
The new version is applied, built and tested with some actual hardware
on 3.17-rc3.
Frans
--
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-next v3 2/2] r8152: use eth_hw_addr_random
If the hw doesn't have a valid MAC address, give a random one and
set it to the hw.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b5ff933..f95e678 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -992,32 +992,35 @@ static int rtl8152_set_mac_address(struct net_device
*netdev, void *p)
return 0;
}
-static inline void set_ethernet_addr(struct r8152 *tp)
+static int set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp-netdev;
+ struct sockaddr sa;
int ret;
- u8 node_id[8] = {0};
if (tp-version == RTL_VER_01)
- ret = pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id);
+ ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
else
- ret = pla_ocp_read(tp, PLA_BACKUP, sizeof(node_id), node_id);
+ ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
if (ret 0) {
- netif_notice(tp, probe, dev, inet addr fail\n);
+ netif_err(tp, probe, dev, Get ether addr fail\n);
+ } else if (!is_valid_ether_addr(sa.sa_data)) {
+ netif_err(tp, probe, dev, Invalid ether addr %pM\n,
+ sa.sa_data);
+ eth_hw_addr_random(dev);
+ ether_addr_copy(sa.sa_data, dev-dev_addr);
+ ret = rtl8152_set_mac_address(dev, sa);
+ netif_info(tp, probe, dev, Random ether addr %pM\n,
+ sa.sa_data);
} else {
- if (tp-version != RTL_VER_01) {
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
- CRWECR_CONFIG);
- pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES,
- sizeof(node_id), node_id);
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
- CRWECR_NORAML);
- }
-
- memcpy(dev-dev_addr, node_id, dev-addr_len);
- memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
+ if (tp-version == RTL_VER_01)
+ ether_addr_copy(dev-dev_addr, sa.sa_data);
+ else
+ ret = rtl8152_set_mac_address(dev, sa);
}
+
+ return ret;
}
static void read_bulk_callback(struct urb *urb)
--
1.9.3
--
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 resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
On Thu, Sep 04, 2014 at 11:05:47AM +0200, Frans Klaver wrote:
On Thu, Sep 04, 2014 at 10:15:22AM +0200, Johan Hovold wrote:
On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial-interface-cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial-interface-cur_altsetting.desc.bInterfaceNumber ==
1)
This should be
if (serial-interface-cur_altsetting-desc.bInterfaceNumber == 1)
So this wasn't even compile tested. Always test your patches before
submission, including trivial ones.
Is the new version tested on actual hardware?
The implementation was tested (also fixed) before the first submission.
Not the patches. Looks like I've got a step to add.
The new version is applied, built and tested with some actual hardware
on 3.17-rc3.
Good. Both patches applied now.
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
On Thu, Sep 04, 2014 at 11:22:26AM +0200, Johan Hovold wrote: On Thu, Sep 04, 2014 at 11:05:47AM +0200, Frans Klaver wrote: The new version is applied, built and tested with some actual hardware on 3.17-rc3. Good. Both patches applied now. Thanks again, Frans -- 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]your patch to deal with devices that need continous data traffic
Hi,
I also got a problem with such a device and I took your patch
and applied it to this device. What do you think? The only
substantial change I made was not counting unrequested input
for autosuspend.
Regards
Oliver
From 7babd79010390e9bee19cf2ac2a0f374a59b1bed Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Wed, 3 Sep 2014 15:26:39 +0200
Subject: [PATCH] usbhid: Johan's patch for devices that need constant polling
Some devices need constant polling or they crash.
So move the start of IO from open() to start()
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-core.c | 31 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 25cd674..b303a62 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -733,6 +733,7 @@
#define USB_DEVICE_ID_PI_ENGINEERING_VEC_USB_FOOTPEDAL 0xff
#define USB_VENDOR_ID_PIXART 0x093a
+#define USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE 0x2510
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN 0x8001
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1 0x8002
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2 0x8003
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 79cf503..4507987 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid-driver_data;
spin_lock_irqsave(usbhid-lock, flags);
- if (hid-open 0
+ if ((hid-open 0 || hid-quirks HID_QUIRK_ALWAYS_POLL)
!test_bit(HID_DISCONNECTED, usbhid-iofl)
!test_bit(HID_SUSPENDED, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
@@ -290,8 +290,14 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
- usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
+ /*
+* do not not report unrequested data
+* neither should it count for autosuspend
+*/
+ if ((hid-quirks HID_QUIRK_ALWAYS_POLL) !hid-open)
+ break;
+ usbhid_mark_busy(usbhid);
hid_input_report(urb-context, HID_INPUT_REPORT,
urb-transfer_buffer,
urb-actual_length, 1);
@@ -735,8 +741,10 @@ void usbhid_close(struct hid_device *hid)
if (!--hid-open) {
spin_unlock_irq(usbhid-lock);
hid_cancel_delayed_stuff(usbhid);
- usb_kill_urb(usbhid-urbin);
- usbhid-intf-needs_remote_wakeup = 0;
+ if (!(hid-quirks HID_QUIRK_ALWAYS_POLL)) {
+ usb_kill_urb(usbhid-urbin);
+ usbhid-intf-needs_remote_wakeup = 0;
+ }
} else {
spin_unlock_irq(usbhid-lock);
}
@@ -1134,6 +1142,19 @@ static int usbhid_start(struct hid_device *hid)
set_bit(HID_STARTED, usbhid-iofl);
+ if (hid-quirks HID_QUIRK_ALWAYS_POLL) {
+ ret = usb_autopm_get_interface(usbhid-intf);
+ if (ret)
+ goto fail;
+ usbhid-intf-needs_remote_wakeup = 1;
+ ret = hid_start_in(hid);
+ if (ret) {
+ dev_err(hid-dev,
+ failed to start in urb: %d\n, ret);
+ }
+ usb_autopm_put_interface(usbhid-intf);
+ }
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
@@ -1166,6 +1187,8 @@ static void usbhid_stop(struct hid_device *hid)
if (WARN_ON(!usbhid))
return;
+ usbhid-intf-needs_remote_wakeup = 0;
+
clear_bit(HID_STARTED, usbhid-iofl);
spin_lock_irq(usbhid-lock); /* Sync with error and led handlers */
set_bit(HID_DISCONNECTED, usbhid-iofl);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 15225f3..8a8c667 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -79,6 +79,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET
},
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_ALWAYS_POLL },
{
[PATCH] usb: gadget: midi: Fix ignored index and id module parameters
The MIDI USB gadget driver has index and id parameters which should determine the alsa sound card index and id to use when registering the card. Those parameters had no effect, as the relevant information is only set on the midi structure after f_midi_register_card is called. This patch moves the two initialisation statements before the function call. Signed-off-by: Marcus Weseloh mar...@weseloh.cc --- drivers/usb/gadget/function/f_midi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c index 807b31c..674ba06 100644 --- a/drivers/usb/gadget/function/f_midi.c +++ b/drivers/usb/gadget/function/f_midi.c @@ -954,6 +954,8 @@ int __init f_midi_bind_config(struct usb_configuration *c, /* set up ALSA midi devices */ midi-in_ports = in_ports; midi-out_ports = out_ports; + midi-id = kstrdup(id, GFP_KERNEL); + midi-index = index; status = f_midi_register_card(midi); if (status 0) goto setup_fail; @@ -965,8 +967,6 @@ int __init f_midi_bind_config(struct usb_configuration *c, midi-func.set_alt = f_midi_set_alt; midi-func.disable = f_midi_disable; - midi-id = kstrdup(id, GFP_KERNEL); - midi-index = index; midi-buflen = buflen; midi-qlen = qlen; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: gadget: How should an udc handle reception of more data than req.length?
On 2014-09-03 18:07, Alan Stern wrote: On Wed, 3 Sep 2014, Andreas Larsson wrote: Hi! In short: How should a udc driver handle a situation when the host sends more data than req.length in the receiving OUT request? What should be reported to the gadget driver? What should be done with the excess data? It depends. If req.length is a multiple of the endpoint's maxpacket size then any excess must take the form of extra packets. The UDC should NAK these packets or apply them toward the next request on the endpoint's queue, if there is one. If req.length is not a multiple of the maxpacket size then an excess could take the form of a packet that's too long. The UDC should store as much of the data as possible (i.e., to up req.length) in the request's buffer and drop the rest, and the request should complete with a status code of -EOVERFLOW. Thanks a lot! This case was the one I was unsure of. Cheers, Andreas Larsson -- 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: [rfc]your patch to deal with devices that need continous data traffic
On Thu, Sep 04, 2014 at 12:44:37PM +0200, Oliver Neukum wrote:
Hi,
I also got a problem with such a device and I took your patch
and applied it to this device. What do you think? The only
substantial change I made was not counting unrequested input
for autosuspend.
Ah, good to know there are more devices that need this quirk.
I got side-tracked with other stuff, but I should be able to submit the
patch this week (just want to look through it once more first).
Not sure the mark-last-busy needs to be moved, though. The device has
already been woken up, and might as well stay unsuspended for a while
longer should further events occur.
From 7babd79010390e9bee19cf2ac2a0f374a59b1bed Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Wed, 3 Sep 2014 15:26:39 +0200
Subject: [PATCH] usbhid: Johan's patch for devices that need constant polling
Some devices need constant polling or they crash.
So move the start of IO from open() to start()
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-core.c | 31 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 25cd674..b303a62 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -733,6 +733,7 @@
#define USB_DEVICE_ID_PI_ENGINEERING_VEC_USB_FOOTPEDAL 0xff
#define USB_VENDOR_ID_PIXART 0x093a
+#define USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE 0x2510
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN0x8001
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1 0x8002
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2 0x8003
snip
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 15225f3..8a8c667 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -79,6 +79,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET
},
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_ALWAYS_POLL },
You'd want to use USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE here, or?
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2,
HID_QUIRK_NO_INIT_REPORTS },
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: usbip: fix usbip.h path in userspace tool
On Thu, Sep 04, 2014 at 11:59:40AM +0300, Valentina Manea wrote: On Thu, Sep 4, 2014 at 2:41 AM, Greg KH gre...@linuxfoundation.org wrote: Shouldn't you be able to use the same path as ch9.h uses? It's a uapi .h file, no relative paths should be needed. For the userspace tool, the build system only looks for headers in the system default locations, such as /usr/include. Hence, this won't work for systems that don't have kernel 3.17 headers. That's fine to depend on. This patch is a pretty nasty hack to get it to compile within the kernel tree. I wonder whether we can make this self-contained by duplicating the header's content inside usbip_common.h. Ick, no, don't do that, use the .h file, that is what it is there for. 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] usb: usbip: fix usbip.h path in userspace tool
Hello. On 9/4/2014 3:31 AM, Piotr Król wrote: Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- tools/usb/usbip/libsrc/usbip_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..a80e73d4f11e 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include ../../../include/uapi/linux/usbip.h I wonder why you use for the current-dir-relative path, not ? 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
How to control charging on USB OTG port
Hi all, I've got an ARM development board with Allwinner A20 SoC and AXP209 charging controller for the attached battery. I'm using the USB OTG port for a MIDI USB gadget and would like to control how and when my board tries to charge the battery via the OTG USB connection. When attached to a USB wall plug it should charge at high speed, to a normal USB port at slower speed and when attached to an iPad (via camera connection kit) it should not charge at all. I think I found the relevant registers on the AXP209 chip that control the charging current, but I don't know how to detect how much power the USB connection can supply, and whether or not I'm connected to the iPad (to disable charging altogether). Do I even need to poke the AXP directly, or is there some kind of kernel device that I can control, maybe even from userland? I'm currently running a linux-sunxi 3.4 kernel. All the best, Marcus -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rfc]your patch to deal with devices that need continous data traffic
On Thu, 2014-09-04 at 13:36 +0200, Johan Hovold wrote:
On Thu, Sep 04, 2014 at 12:44:37PM +0200, Oliver Neukum wrote:
Hi,
I also got a problem with such a device and I took your patch
and applied it to this device. What do you think? The only
substantial change I made was not counting unrequested input
for autosuspend.
Ah, good to know there are more devices that need this quirk.
Actually, I'd prefer you to be the only one. ;-)
But shared misery is better than single misery.
I got side-tracked with other stuff, but I should be able to submit the
patch this week (just want to look through it once more first).
Good.
Not sure the mark-last-busy needs to be moved, though. The device has
already been woken up, and might as well stay unsuspended for a while
longer should further events occur.
Why? Remote wakeup will be disabled. It would be a waste of power.
[..]
@@ -79,6 +79,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET
},
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_ALWAYS_POLL },
You'd want to use USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE here, or?
Yes. Thank you.
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 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
Hi Tony, On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote: We don't need twl4030_phy_power() any longer now that we have the runtime PM calls. Let's get rid of it as it's confusing. No functional changes, just move the code and use res instead of ret as we are not returning that value. Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it power on the phy even before initializing it (since runtime_resume will be invoked even before doing phy_init)? Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core itself does pm_runtime_get_sync in phy_init(). Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB-serial fixes for v3.17-rc4
On Thu, Sep 04, 2014 at 10:40:40AM +0200, Johan Hovold wrote: Hi Greg, Here's a few device id updates for v3.17-rc4. I added the zte_ev one to my tree when it missed rc3, but didn't ask you to drop it from your queue so you have already applied that one. Thanks, Johan The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.17-rc4 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gadget serial driver - configuration value
On Thu, 4 Sep 2014, Anjana V Kumar wrote: We see that, the three configurations listed in serial driver (CDC ACM, CDC OBEX, generic serial) cannot be present together as per the current implementation. Is there a specific reason why the configuration values were set as 1, 2 and 3 instead of setting all to 1? well, setting configuration 0 means that you're not selecting any configuration. Basically you go back to Addressed state, so you can't use configuration 0 for anything, really. Sorry for not being clear, I am not setting the configuration to 0. The question was, can we set all the three configuration values of CDC ACM, CDC OBEX, and generic serial to 1? Was there any specific reason as to why the configuration values were set as 1,2 and 3. We cannot have all three at the same time according to the current if, elseif, else implementation, No two configurations can have the same bConfigurationValue. If the gadget has three different configs then it must have three different config values. 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: EHCI Isochronous schedule full?
On Thu, 4 Sep 2014, Christian Melki wrote: Hi Alan. The machine has only two cameras inserted (no hids, nothing else). While the cameras have an interrupt endpoint, I disabled it in uvc_video. Still I don't get more than two cameras into the schedule. So there are no interrupt endpoints besides the one used for the internal hubs. They are 2 and their schedule is 4bytes per 256ms. Hardly a large load. The total load isn't what matters; it's more a question of what slots in the schedule get used up. The periodic scheduler in ehci-hcd isn't capable of moving things around if the schedule is fragmented and a large contiguous reservation is needed. With the interrupt endpoints on the camera, usage was 98%, now it's 93% with them disabled. With two cameras you get 93% usage? And you wonder why you can't get three cameras to fit in the schedule? T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc=744/800 us (93%), #Int= 2, #Iso= 10 The only reason I can come up with to make this happen is that the driver does not send 3 packets per microframe worth of isoc-data or that the scheduler does not account for that capacity, ie only 8 microframes * 1024 bytes. Something along that path. Or the scheduler is really, really broken. :) The scheduler isn't really broken, but it definitely is not as capable as it ought to be. That would probably give me 80%+ usage when it should not be more than 30-35%. Searching the net for it yields approx. the same information. People are lucky to be able to run two cameras with Linux. I can't tell what's going on without a lot more detailed information. To start with, I'd need the contents of /sys/kernel/debug/usb/devices for all devices on the bus (not just one or two lines) -- that's while the cameras are both running. And it wouldn't hurt to have the dmesg log for the period when you start using the cameras, with debugging enabled for ehci-hcd. Also, recent kernels (try for 3.16) have more detailed scheduling info in ehci-hcd's debugfs directories. There's a new file named bandwidth that would be highly relevant. 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: Fwd: Status of chipidea msm USB reset patch
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in someone's
tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back in
May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Please let me know.
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, 4 Sep 2014, Peter Chen wrote: Hi Felipe Alan, how about using below steps for this reset/vbus/pullup changes? It mainly uses Alan's suggestion. Step 1: The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. the -reset is mandatory for all gadget drivers (currently, only four, they are composite, configfs, gadgetfs , dbgp. Step 2: Add routines to udc-core to handle Vbus changes, function activation changes, and resets. It will include three sub-steps, from easy to hard: reset handler, vbus handler, and activation handler. Perhaps the activation handler can be delayed until step 4. It won't get used until composite.c is modified to call it. Step 3: Modify all UDCs to call udc-core's reset and vbus handler, delete usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers, and delete invoking usb_gadget_connect unconditional at udc_bind_to_driver Step 4: Modify the composite.c to disable pullup for adding every function, and enable pullup when necessary. Actually, composite.c should be modified to call the activation handler in udc-core, and then _that_ routine would adjust the pullup as necessary. This plan is okay with me. 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 v3 0/6] usb: host: change TPL support behaviour
On Thu, 4 Sep 2014, Peter Chen wrote: On Wed, Sep 03, 2014 at 09:48:15PM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. But usb_enumerate_device_otg() gets called for all types of host, right? At least, it gets called whenever usb_enumerate_device() runs. Yes, it contains #ifdef CONFIG_USB_OTG. But your patch has if (... IS_ENABLED(CONFIG_USB_OTG)), so the behavior is the same. Why move the code if there's no change in behavior? At former code, the tpl support judgement (in function is_targeted) will only be called if CONFIG_USB_OTG is defined, but now, we need tpl support for all targeted hosts. Why we need IS_ENABLED(CONFIG_USB_OTG) as last conditions at if conditions, the reason is the operation which the B-device may want switch to host even if it is not at A's TPL is only for OTG host. The only side effect in is_targeted() is the dev_err() message. Are you saying that this dev_err() message needs to appear even when CONFIG_USB_OTG is disabled? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Sat, Aug 30, 2014 at 12:00 AM, Octavian Purdila octavian.purd...@intel.com wrote: From: Daniel Baluta daniel.bal...@intel.com This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 2.9 for the GPIO module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Daniel Baluta daniel.bal...@intel.com Signed-off-by: Octavian Purdila octavian.purd...@intel.com I like this version. I assume you need to funnel it with the rest of the patches through the MFD tree so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Sun, Aug 31, 2014 at 5:24 PM, Wang YanQing udkni...@gmail.com wrote: PL2303 USB Serial devices may has GPIOs, this patch add basic PL2303 gpio support. Known issue: If gpios are in use(export to userspace through sysfs interface, etc), then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc), will cause trouble, so we need to make sure there is no gpio user before call pl2303_release. Signed-off-by: Wang YanQing udkni...@gmail.com --- Note: I sniffed office HXD gpio test program to get gpios control protocol with PL2303 RA, so I only test it with PL2303 RA and HXA, I don't have HXD, but because it is *office* HXD gpio test program, so if it doesn't work with HXD, I will feel surprise. Changes v7-v8: 1: add support for four dedicated gpios on HXD and RA 2: fix problem reported by Johan Hovold in v7 3: fix checkpatch.pl's warning This has been looking nice from the GPIO side of things for a while so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
* Kishon Vijay Abraham I kis...@ti.com [140904 06:51]: Hi Tony, On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote: We don't need twl4030_phy_power() any longer now that we have the runtime PM calls. Let's get rid of it as it's confusing. No functional changes, just move the code and use res instead of ret as we are not returning that value. Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it power on the phy even before initializing it (since runtime_resume will be invoked even before doing phy_init)? Yes. The logic being that it should not matter as we are not configuring the phy until in twl4030_phy_power_on(). Maybe we should add code to make sure the phy is deconfigured initially though :) In twl4030_phy_init() we just want to check the ID pin state to get things right initially. In the twl4030-usb case the I2C chip is always on, but let's try to get the runtime PM set up like any standard Linux driver would do it to avoid confusion. Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core itself does pm_runtime_get_sync in phy_init(). Hmm OK. Looking at that, looks like we don't neeed any of these custom exports though: $ git grep phy_pm_runtime | grep EXPORT_SYMBOL drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_allow); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid); The reasons why I think we don't need the above at all is: 1. We already have a framework for that in Linux runtime PM and we can follow the standard Linux runtime PM calls and not proxy them in phy-core.c 2. We can allow idling the phy properly on the bus it's connected to, in this case I2C, even if USB driver is not loaded. We eventually should idle the phy even if usb_add_phy_dev() failed 3. There's no actual need for phy-core.c to proxy the runtime PM calls So we can and should just let the phy drivers do their own runtime PM as needed based on just the phy init, power_on and power_off calls. Probably the same goes for the regulator_enable in phy-core.c. That should be handled in the phy driver as phy-core is already unable to handle it properly. For example, for phy-twl4030-usb.c we have three regulators to deal with and the phy framework won't have any idea how to deal with those. And the phy-core won't be able to deal with the phy driver interrupts anyways, so any attempt of doing finer grained runtime PM in phy-core or handling of separate wake-up interrupts will be doomed to fail. I think the changes above would simplify the phy handling quite a bit, what do you think? Regards, Tony -- 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Sun, Aug 31, 2014 at 11:24:56PM +0800, Wang YanQing wrote:
PL2303 USB Serial devices may has GPIOs, this patch add
basic PL2303 gpio support.
Known issue:
If gpios are in use(export to userspace through sysfs interface, etc),
then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc),
will cause trouble, so we need to make sure there is no gpio user before
call pl2303_release.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
Note: I sniffed office HXD gpio test program to get
gpios control protocol with PL2303 RA, so I only
test it with PL2303 RA and HXA, I don't have HXD,
but because it is *office* HXD gpio test program,
so if it doesn't work with HXD, I will feel surprise.
Changes
v7-v8:
1: add support for four dedicated gpios on HXD and RA
2: fix problem reported by Johan Hovold in v7
3: fix checkpatch.pl's warning
v6-v7:
1: add generic gpio support interfaces for pl2303 USB Serial devices
in pl2303_type_data and pl2303_serial_private suggested by Andreas Mohr.
2: drop different label names for different pl2303 instance suggested by
Johan Hovold.
3: fix missing lock corrected by Johan Hovold.
4: use prefix pl2303hx_gpio instead pl2303_gpio, pl2303_gpio is over generic
for current code,
and now we move gpio_startup|gpio_release into type-specified data
structure, so pl2303hx_gpio
is a better prefix.
5: make words in Kconfig a little more useful and clarified.
6: many misc code quality enhancement suggested by Johan Hovold.
v5-v6:
1: fix typo error in Kconfig reported by Andreas Mohr
2: add const qulification to gpio_dir_mask and gpio_value_mask suggested by
Andreas Mohr
v4-v5:
1: fix gpio_chip.lable been overwrited by template_chip.
2: use idr to manage minor instead of crude monotonous atomic increment.
v3-v4:
1: fix missing static for gpio_dir_mask and gpio_value_mask
2: reduce unneeded compile macro defined suggested by
gno...@lxorguk.ukuu.org.uk
3: use true instead of 1 corrected by Linus Walleij
4: ignore return value of gpiochip_remove suggested by Linus Walleij
5: fix multi gpio_chips registered by pl2303 can't be distinguished in
kernel space.
v2-v3:
1: fix errors and warnings reported by Daniele Forsi checked with
checkpatch.pl
2: fix missing GPIOLIB dependence in Kconfig
3: fix pl2303_gpio_get can't work
v1-v2:
1:drop gpio-pl2303.c and relation stuff
2:hang gpio stuff off of pl2303.c
drivers/usb/serial/Kconfig | 11 ++
drivers/usb/serial/pl2303.c | 250
2 files changed, 261 insertions(+)
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 3ce5c74..b4e0cf9 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -516,6 +516,17 @@ config USB_SERIAL_PL2303
To compile this driver as a module, choose M here: the
module will be called pl2303.
+config USB_SERIAL_PL2303_GPIO
+ bool USB Prolific 2303 Single Port GPIOs support
+ depends on USB_SERIAL_PL2303 GPIOLIB
+ ---help---
+ Say Y here if you want to use GPIOs on PL2303 USB Serial single port
+ adapter from Prolific.
+
+ It supports 2 dedicated GPIOs on PL2303HXA, 4 dedicated GPIOs on
+ PL2303HXD and PL2303RA currently.
+ If unsure, say N.
+
config USB_SERIAL_OTI6858
tristate USB Ours Technology Inc. OTi-6858 USB To RS232 Bridge
Controller
help
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index e9bad92..a3f8411 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -28,6 +28,8 @@
#include linux/usb.h
#include linux/usb/serial.h
#include asm/unaligned.h
+#include linux/gpio.h
+#include linux/mutex.h
#include pl2303.h
@@ -132,6 +134,22 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define UART_OVERRUN_ERROR 0x40
#define UART_CTS 0x80
+#define HXD_GPIO_01_CTRL 0x0001
+#define HXD_GPIO_01_VALUE0x0081
+#define HXD_GPIO_23_DIR_CTRL 0x0c0c
+#define HXD_GPIO_23_VALUE_CTRL 0x0d0d
+#define HXD_GPIO_23_VALUE0x8d8d
+
+#define HXD_GPIO0_DIR_MASK 0x10
+#define HXD_GPIO1_DIR_MASK 0x20
+#define HXD_GPIO2_DIR_MASK 0x03
+#define HXD_GPIO3_DIR_MASK 0x0c
+
+#define HXD_GPIO0_VALUE_MASK 0x40
+#define HXD_GPIO1_VALUE_MASK 0x80
+#define HXD_GPIO2_VALUE_MASK 0x01
+#define HXD_GPIO3_VALUE_MASK 0x02
+
enum pl2303_type {
TYPE_01,/* Type 0 and 1 (difference unknown) */
@@ -144,9 +162,12 @@ struct pl2303_type_data {
unsigned long quirks;
};
+struct pl2303_gpio;
struct pl2303_serial_private {
const struct pl2303_type_data *type;
unsigned long quirks;
+ u8 ngpio;
+ struct pl2303_gpio *gpio;
};
RCU bug with v3.17-rc3 ?
Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: | # modprobe g_mass_storage stall=0 removable=1 file=/dev/sda | [ 44.883554] Number of LUNs=8 | [ 44.886709] Mass Storage Function, version: 2009/09/11 | [ 44.892303] LUN: removable file: (no medium) | [ 44.896916] Number of LUNs=1 | [ 44.901198] LUN: removable file: /dev/sda | [ 44.905410] Number of LUNs=1 | [ 44.917706] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 | [ 44.925018] g_mass_storage gadget: userspace failed to provide iSerialNumber | [ 44.932489] g_mass_storage gadget: g_mass_storage ready | [ 52.583773] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage | # [ 98.270585] Unable to handle kernel paging request at virtual address | [ 98.278198] pgd = c0004000 | [ 98.281027] [] *pgd=ae7f6821, *pte=, *ppte= | [ 98.287648] Internal error: Oops: 17 [#1] SMP ARM | [ 98.292559] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs usb_storage xhci_hcd dwc3 udc_core matrix_keypad lis3lv02d_i2c dwc3_omap lis3lv02d input_polldev | [ 98.309721] CPU: 0 PID: 1820 Comm: file-storage Not tainted 3.17.0-rc3-00013-gc6b1a7d #806 | [ 98.318346] task: ec356040 ti: ec378000 task.ti: ec378000 | [ 98.324000] PC is at find_get_entry+0x7c/0x128 | [ 98.328640] LR is at 0xfffa | [ 98.331912] pc : [c011394c]lr : [fffa]psr: a013 | [ 98.331912] sp : ec379b50 ip : fp : ec379b84 | [ 98.343888] r10: c0c81243 r9 : 0001 r8 : ea123d28 | [ 98.349352] r7 : ec378010 r6 : 0001 r5 : r4 : 000f | [ 98.356181] r3 : ec379b3c r2 : r1 : 0001 r0 : | [ 98.363006] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel | [ 98.370646] Control: 10c5387d Table: ac2b0059 DAC: 0015 | [ 98.376641] Process file-storage (pid: 1820, stack limit = 0xec378248) | [ 98.383454] Stack: (0xec379b50 to 0xec37a000) | [ 98.388003] 9b40: c01138d0 c002aa3c | [ 98.396560] 9b60: 000f ea123d24 000200d0 0001 00d0 ec379bbc ec379b88 | [ 98.405100] 9b80: c0114360 c01138dc c1486a00 6013 ec379bc4 1400 ea123d24 | [ 98.413635] 9ba0: 0c00 0400 ec378010 c06dea0c ec379bdc ec379bc0 c011478c c0114330 | [ 98.422183] 9bc0: 00d0 c00904f8 c1486a00 1400 ec379c04 ec379be0 c019cd68 c0114760 | [ 98.430732] 9be0: c0090808 c0090590 ec379c34 0001 0c00 ea123d24 ec379c2c ec379c08 | [ 98.439300] 9c00: c019ecbc c019cd44 0c00 0001 ec379c58 c019eb9c 0c00 ec379d54 | [ 98.447860] 9c20: ec379c8c ec379c30 c0113f14 c019ec8c 0c00 0001 ec379c58 ec379c5c | [ 98.456414] 9c40: ec378030 0001 ec250cc0 1400 c018195c c00acd08 | [ 98.464974] 9c60: 5408b05a 1000 ec250cc0 ec379d68 ea123d24 ec378010 | [ 98.473533] 9c80: ec379cf4 ec379c90 c0115ed4 c0113e6c 0001 c019f2b0 c0090590 | [ 98.482071] 9ca0: ec379cc4 ec378010 c06c3df4 1000 ea123c64 c019f2b0 ec379d54 ec379cc8 | [ 98.490607] 9cc0: 1400 0001 ec379d68 ec379d54 ec379e30 ec250cc0 ec356040 | [ 98.499178] 9ce0: ed7ab800 ec30d800 ec379d3c ec379cf8 c019f2b0 c0115c8c c06be3b8 c006dcec | [ 98.507741] 9d00: ec1b0010 ec30d800 ec379d08 ec379d08 ec379d10 ec379d10 ec379d18 ec379d18 | [ 98.516288] 9d20: 1400 ec379e30 ec250cc0 ec379dc4 ec379d40 c016618c c019f284 | [ 98.524833] 9d40: 1000 c0317b78 ec379d7c ec394000 1000 0003 1000 | [ 98.533385] 9d60: ec379d4c 0001 ec250cc0 ec356040 | [ 98.541946] 9d80: 1400 1000 | [ 98.550482] 9da0: ec394000 ec250cc0 ec394000 ec379e30 1000 1000 ec379df4 ec379dc8 | [ 98.559023] 9dc0: c0166a3c c01660f4 0002 ec0ace20 1000 000e ec0ace00 | [ 98.567567] 9de0: 1000 ed7ab800 ec379e64 ec379df8 bf0bc3b4 c0166994 006f 1000 | [ 98.576112] 9e00: bf0bc7a4 6013 e8156000 000e 3930343d bf0bc7a4 ec0ace00 | [ 98.584660] 9e20: 2400 1400 1400 ec379e64 | [ 98.593193] 9e40: ed36ddc0 ec378018 ec30d894 ec0ace00 ec30d800 ec30d840 ec379ed4 ec379e68 | [ 98.601754] 9e60: bf0bd1c8 bf0bc08c bf0bf6ec ec378010 c06c3df4 ec356040 0001 | [ 98.610305] 9e80: ec379eac ec379e90 c00906b0 c00904f8 ec30d894 ed36ddc0 ec378018 ec30d894 | [ 98.618857] 9ea0: ec379ebc ec379eb0 c0090808 ec30d800 ed36ddc0 ec378018 ec30d894 | [ 98.627405] 9ec0: 0200 ec0ace00 ec379f14 ec379ed8 bf0bdbe8 bf0bc74c c06c3d94 ec0acc80 | [ 98.635942] 9ee0: ec394000 ec30d800 bf0bd8cc ec0acc80 ec30d800 bf0bd8cc | [ 98.644465] 9f00: ec379fac ec379f18 c0066ac4
Re: [PATCH] usb: usbip: fix usbip.h path in userspace tool
On Thu, Sep 4, 2014 at 5:14 AM, Greg KH gre...@linuxfoundation.org wrote: This patch is a pretty nasty hack to get it to compile within the kernel tree. I wonder whether we can make this self-contained by duplicating the header's content inside usbip_common.h. Ick, no, don't do that, use the .h file, that is what it is there for. This leaves 2 options: a. include the file the way this patch did it b. include as linux/usbip.h and add the relative path in the kernel tree to include/uapi as include path. the problem with this is that the previous header, ch9.h, eventually includes other kernel headers and a path to include/ would also be necessary. plus, there's a warning about using kernel headers from user space, which is legit. For the time being, I suppose the first option will do. Thanks, Valentina -- 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 RESEND v3 00/12] usb: dwc2/gadget: fix series (for v3.18)
From: Robert Baldyga r.bald...@samsung.com I'm resending this patchset rebased on linux-next. Now it should apply. Thanks, Robert Baldyga Changelog: v3: https://lkml.org/lkml/2014/8/4/617 - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series, Acked-by: Paul Zimmerman pa...@synopsys.com Greg, Can you apply this for 3.18 please? Thanks. -- 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
[PATCH RESEND v3 01/12] usb: dwc2/gadget: fix phy disable sequence
From: Kamil Debski k.deb...@samsung.com When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/usb/dwc2/gadget.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 7c9618e..505d56e 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2897,8 +2897,6 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget, spin_lock_irqsave(hsotg-lock, flags); - s3c_hsotg_phy_disable(hsotg); - if (!driver) hsotg-driver = NULL; @@ -3582,7 +3580,6 @@ static int s3c_hsotg_remove(struct platform_device *pdev) usb_gadget_unregister_driver(hsotg-driver); } - s3c_hsotg_phy_disable(hsotg); if (hsotg-phy) phy_exit(hsotg-phy); clk_disable_unprepare(hsotg-clk); -- 2.1.0.24.g4109c28 -- 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 RESEND v3 02/12] usb: dwc2/gadget: fix phy initialization sequence
From: Kamil Debski k.deb...@samsung.com
In the Generic PHY Framework a NULL phy is considered to be a valid phy
thus the if (hsotg-phy) check does not give us the information whether
the Generic PHY Framework is used.
In addition to the above this patch also removes phy_init from probe and
phy_exit from remove. This is not necessary when init/exit is done in the
s3c_hsotg_phy_enable/disable functions.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 505d56e..fd556e0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2747,13 +2747,14 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
*hsotg)
dev_dbg(hsotg-dev, pdev 0x%p\n, pdev);
- if (hsotg-phy) {
- phy_init(hsotg-phy);
- phy_power_on(hsotg-phy);
- } else if (hsotg-uphy)
+ if (hsotg-uphy)
usb_phy_init(hsotg-uphy);
- else if (hsotg-plat-phy_init)
+ else if (hsotg-plat hsotg-plat-phy_init)
hsotg-plat-phy_init(pdev, hsotg-plat-phy_type);
+ else {
+ phy_init(hsotg-phy);
+ phy_power_on(hsotg-phy);
+ }
}
/**
@@ -2767,13 +2768,14 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg
*hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg-dev);
- if (hsotg-phy) {
- phy_power_off(hsotg-phy);
- phy_exit(hsotg-phy);
- } else if (hsotg-uphy)
+ if (hsotg-uphy)
usb_phy_shutdown(hsotg-uphy);
- else if (hsotg-plat-phy_exit)
+ else if (hsotg-plat hsotg-plat-phy_exit)
hsotg-plat-phy_exit(pdev, hsotg-plat-phy_type);
+ else {
+ phy_power_off(hsotg-phy);
+ phy_exit(hsotg-phy);
+ }
}
/**
@@ -3486,9 +3488,6 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
if (hsotg-phy (phy_get_bus_width(phy) == 8))
hsotg-phyif = GUSBCFG_PHYIF8;
- if (hsotg-phy)
- phy_init(hsotg-phy);
-
/* usb phy enable */
s3c_hsotg_phy_enable(hsotg);
@@ -3580,8 +3579,6 @@ static int s3c_hsotg_remove(struct platform_device *pdev)
usb_gadget_unregister_driver(hsotg-driver);
}
- if (hsotg-phy)
- phy_exit(hsotg-phy);
clk_disable_unprepare(hsotg-clk);
return 0;
--
2.1.0.24.g4109c28
--
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 RESEND v3 03/12] usb: dwc2/gadget: move phy bus length initialization
From: Kamil Debski k.deb...@samsung.com
This patch moves the part of code that initializes the PHY bus width.
This results in simpler code and removes the need to check whether
the Generic PHY Framework is used.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fd556e0..4382f83 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3392,6 +3392,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
if (!hsotg)
return -ENOMEM;
+ /* Set default UTMI width */
+ hsotg-phyif = GUSBCFG_PHYIF16;
+
/*
* Attempt to find a generic PHY, then look for an old style
* USB PHY, finally fall back to pdata
@@ -3410,8 +3413,15 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
hsotg-plat = plat;
} else
hsotg-uphy = uphy;
- } else
+ } else {
hsotg-phy = phy;
+ /*
+* If using the generic PHY framework, check if the PHY bus
+* width is 8-bit and set the phyif appropriately.
+*/
+ if (phy_get_bus_width(phy) == 8)
+ hsotg-phyif = GUSBCFG_PHYIF8;
+ }
hsotg-dev = dev;
@@ -3478,16 +3488,6 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
goto err_supplies;
}
- /* Set default UTMI width */
- hsotg-phyif = GUSBCFG_PHYIF16;
-
- /*
-* If using the generic PHY framework, check if the PHY bus
-* width is 8-bit and set the phyif appropriately.
-*/
- if (hsotg-phy (phy_get_bus_width(phy) == 8))
- hsotg-phyif = GUSBCFG_PHYIF8;
-
/* usb phy enable */
s3c_hsotg_phy_enable(hsotg);
--
2.1.0.24.g4109c28
--
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 RESEND v3 04/12] usb: dwc2/gadget: Fix comment text
From: Andrzej Pietrasiewicz andrze...@samsung.com
Adjust the debug text to the name of the printed variable.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4382f83..08f6557 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2934,7 +2934,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
struct s3c_hsotg *hsotg = to_hsotg(gadget);
unsigned long flags = 0;
- dev_dbg(hsotg-dev, %s: is_in: %d\n, __func__, is_on);
+ dev_dbg(hsotg-dev, %s: is_on: %d\n, __func__, is_on);
spin_lock_irqsave(hsotg-lock, flags);
if (is_on) {
--
2.1.0.24.g4109c28
--
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 RESEND v3 07/12] usb: dwc2/gadget: break infinite loop in endpoint disable code
From: Marek Szyprowski m.szyprow...@samsung.com This patch fixes possible freeze caused by infinite loop in interrupt context. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/usb/dwc2/gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 86e4fd9..97368c4c 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -1651,6 +1651,7 @@ static void s3c_hsotg_txfifo_flush(struct s3c_hsotg *hsotg, unsigned int idx) dev_err(hsotg-dev, %s: timeout flushing fifo (GRSTCTL=%08x)\n, __func__, val); + break; } udelay(1); -- 2.1.0.24.g4109c28 -- 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 RESEND v3 09/12] usb: dwc2/gadget: delay enabling irq once hardware is configured properly
From: Marek Szyprowski m.szyprow...@samsung.com
This patch fixes kernel panic/interrupt storm/etc issues if bootloader
left s3c-hsotg module in enabled state. Now interrupt handler is enabled
only after proper configuration of hardware registers.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 55238b0..2c9f0f5 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3456,13 +3456,6 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
hsotg-irq = ret;
- ret = devm_request_irq(pdev-dev, hsotg-irq, s3c_hsotg_irq, 0,
- dev_name(dev), hsotg);
- if (ret 0) {
- dev_err(dev, cannot claim IRQ\n);
- goto err_clk;
- }
-
dev_info(dev, regs %p, irq %d\n, hsotg-regs, hsotg-irq);
hsotg-gadget.max_speed = USB_SPEED_HIGH;
@@ -3500,6 +3493,17 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
s3c_hsotg_hw_cfg(hsotg);
s3c_hsotg_init(hsotg);
+ ret = devm_request_irq(pdev-dev, hsotg-irq, s3c_hsotg_irq, 0,
+ dev_name(dev), hsotg);
+ if (ret 0) {
+ s3c_hsotg_phy_disable(hsotg);
+ clk_disable_unprepare(hsotg-clk);
+ regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies),
+ hsotg-supplies);
+ dev_err(dev, cannot claim IRQ\n);
+ goto err_clk;
+ }
+
/* hsotg-num_of_eps holds number of EPs other than ep0 */
if (hsotg-num_of_eps == 0) {
--
2.1.0.24.g4109c28
--
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 RESEND v3 06/12] usb: dwc2/gadget: ensure that all fifos have correct memory buffers
From: Marek Szyprowski m.szyprow...@samsung.com
Print warning if FIFOs are configured in such a way that they don't fit
into the SPRAM available on the s3c hsotg module.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 15 ++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..067390e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -194,6 +194,7 @@ struct s3c_hsotg {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
u32 phyif;
+ int fifo_mem;
unsigned intdedicated_fifos:1;
unsigned char num_of_eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d737192..86e4fd9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -192,6 +192,8 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
for (ep = 1; ep = 15; ep++) {
val = addr;
val |= size FIFOSIZE_DEPTH_SHIFT;
+ WARN_ONCE(addr + size hsotg-fifo_mem,
+ insufficient fifo memory);
addr += size;
writel(val, hsotg-regs + DPTXFSIZN(ep));
@@ -3029,19 +3031,22 @@ static void s3c_hsotg_initep(struct s3c_hsotg *hsotg,
*/
static void s3c_hsotg_hw_cfg(struct s3c_hsotg *hsotg)
{
- u32 cfg2, cfg4;
+ u32 cfg2, cfg3, cfg4;
/* check hardware configuration */
cfg2 = readl(hsotg-regs + 0x48);
hsotg-num_of_eps = (cfg2 10) 0xF;
- dev_info(hsotg-dev, EPs:%d\n, hsotg-num_of_eps);
+ cfg3 = readl(hsotg-regs + 0x4C);
+ hsotg-fifo_mem = (cfg3 16);
cfg4 = readl(hsotg-regs + 0x50);
hsotg-dedicated_fifos = (cfg4 25) 1;
- dev_info(hsotg-dev, %s fifos\n,
-hsotg-dedicated_fifos ? dedicated : shared);
+ dev_info(hsotg-dev, EPs: %d, %s fifos, %d entries in SPRAM\n,
+hsotg-num_of_eps,
+hsotg-dedicated_fifos ? dedicated : shared,
+hsotg-fifo_mem);
}
/**
@@ -3492,8 +3497,8 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
s3c_hsotg_phy_enable(hsotg);
s3c_hsotg_corereset(hsotg);
- s3c_hsotg_init(hsotg);
s3c_hsotg_hw_cfg(hsotg);
+ s3c_hsotg_init(hsotg);
/* hsotg-num_of_eps holds number of EPs other than ep0 */
--
2.1.0.24.g4109c28
--
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 RESEND v3 05/12] usb: dwc2/gadget: hide some not really needed debug messages
From: Marek Szyprowski m.szyprow...@samsung.com
Some DWC2/s3c-hsotg debug messages are really useless for typical user,
so hide them behind dev_dbg().
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 08f6557..d737192 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2567,7 +2567,7 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
u32 epctrl_reg;
u32 ctrl;
- dev_info(hsotg-dev, %s(ep %p)\n, __func__, ep);
+ dev_dbg(hsotg-dev, %s(ep %p)\n, __func__, ep);
if (ep == hsotg-eps[0].ep) {
dev_err(hsotg-dev, %s: called for ep0\n, __func__);
@@ -2625,7 +2625,7 @@ static int s3c_hsotg_ep_dequeue(struct usb_ep *ep, struct
usb_request *req)
struct s3c_hsotg *hs = hs_ep-parent;
unsigned long flags;
- dev_info(hs-dev, ep_dequeue(%p,%p)\n, ep, req);
+ dev_dbg(hs-dev, ep_dequeue(%p,%p)\n, ep, req);
spin_lock_irqsave(hs-lock, flags);
--
2.1.0.24.g4109c28
--
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 RESEND v3 11/12] usb: dwc2/gadget: disable clock when it's not needed
From: Robert Baldyga r.bald...@samsung.com
When device is stopped or suspended clock is not needed so we
can disable it for this time.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 662ab4c..32af626 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2893,6 +2893,8 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
hsotg-gadget.dev.of_node = hsotg-dev-of_node;
hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ clk_enable(hsotg-clk);
+
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg-supplies),
hsotg-supplies);
if (ret) {
@@ -2941,6 +2943,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies), hsotg-supplies);
+ clk_disable(hsotg-clk);
+
return 0;
}
@@ -2972,8 +2976,10 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
spin_lock_irqsave(hsotg-lock, flags);
if (is_on) {
s3c_hsotg_phy_enable(hsotg);
+ clk_enable(hsotg-clk);
s3c_hsotg_core_init(hsotg);
} else {
+ clk_disable(hsotg-clk);
s3c_hsotg_phy_disable(hsotg);
}
@@ -3636,6 +3642,7 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t state)
ret = regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies),
hsotg-supplies);
+ clk_disable(hsotg-clk);
}
return ret;
@@ -3650,6 +3657,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
if (hsotg-driver) {
dev_info(hsotg-dev, resuming usb gadget %s\n,
hsotg-driver-driver.name);
+
+ clk_enable(hsotg-clk);
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg-supplies),
hsotg-supplies);
}
--
2.1.0.24.g4109c28
--
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 RESEND v3 08/12] usb: dwc2/gadget: do not call disconnect method in pullup
From: Marek Szyprowski m.szyprow...@samsung.com
This leads to potential spinlock recursion in composite framework, other
udc drivers also don't call it directly from pullup method.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/gadget.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 97368c4c..55238b0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2944,7 +2944,6 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
s3c_hsotg_phy_enable(hsotg);
s3c_hsotg_core_init(hsotg);
} else {
- s3c_hsotg_disconnect(hsotg);
s3c_hsotg_phy_disable(hsotg);
}
--
2.1.0.24.g4109c28
--
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 RESEND v3 12/12] usb: dwc2/gadget: avoid disabling ep0
From: Robert Baldyga r.bald...@samsung.com Endpoint 0 should not be disabled, so we start loop counter from number 1. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/usb/dwc2/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 32af626..94f7a3f 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2929,7 +2929,7 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget, return -ENODEV; /* all endpoints should be shutdown */ - for (ep = 0; ep hsotg-num_of_eps; ep++) + for (ep = 1; ep hsotg-num_of_eps; ep++) s3c_hsotg_ep_disable(hsotg-eps[ep].ep); spin_lock_irqsave(hsotg-lock, flags); -- 2.1.0.24.g4109c28 -- 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 RESEND v3 10/12] usb: dwc2/gadget: assign TX FIFO dynamically
From: Robert Baldyga r.bald...@samsung.com
Because we have not enough memory to have each TX FIFO of size at least
3072 bytes (the maximum single packet size with 3 transactions per
microframe), we create four FIFOs of lenght 1024, and four of length
3072 bytes, and assing them to endpoints dynamically according to
maxpacket size value of given endpoint.
Up to now there were initialized 16 TX FIFOs, but we use only 8 IN
endpoints, so we can split available memory for 8 FIFOs to have more
memory for each one.
It needed to do some small modifications in few places in code, because
there was assumption that TX FIFO numbers assigned to endpoints are the
same as the endpoint numbers, which is not true since we have dynamic
FIFO assigning.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/core.h | 2 ++
drivers/usb/dwc2/gadget.c | 80 +--
2 files changed, 52 insertions(+), 30 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 067390e..3b4bd4c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -139,6 +139,7 @@ struct s3c_hsotg_ep {
unsigned intlast_load;
unsigned intfifo_load;
unsigned short fifo_size;
+ unsigned short fifo_index;
unsigned char dir_in;
unsigned char index;
@@ -197,6 +198,7 @@ struct s3c_hsotg {
int fifo_mem;
unsigned intdedicated_fifos:1;
unsigned char num_of_eps;
+ u32 fifo_map;
struct dentry *debug_root;
struct dentry *debug_file;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 2c9f0f5..662ab4c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -182,14 +182,29 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
/* start at the end of the GNPTXFSIZ, rounded up */
addr = 2048 + 1024;
- size = 768;
/*
-* currently we allocate TX FIFOs for all possible endpoints,
-* and assume that they are all the same size.
+* Because we have not enough memory to have each TX FIFO of size at
+* least 3072 bytes (the maximum single packet size), we create four
+* FIFOs of lenght 1024, and four of length 3072 bytes, and assing
+* them to endpoints dynamically according to maxpacket size value of
+* given endpoint.
*/
- for (ep = 1; ep = 15; ep++) {
+ /* 256*4=1024 bytes FIFO length */
+ size = 256;
+ for (ep = 1; ep = 4; ep++) {
+ val = addr;
+ val |= size FIFOSIZE_DEPTH_SHIFT;
+ WARN_ONCE(addr + size hsotg-fifo_mem,
+ insufficient fifo memory);
+ addr += size;
+
+ writel(val, hsotg-regs + DPTXFSIZN(ep));
+ }
+ /* 768*4=3072 bytes FIFO length */
+ size = 768;
+ for (ep = 5; ep = 8; ep++) {
val = addr;
val |= size FIFOSIZE_DEPTH_SHIFT;
WARN_ONCE(addr + size hsotg-fifo_mem,
@@ -1834,7 +1849,7 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg,
unsigned int idx,
if (dir_in) {
int epctl = readl(hsotg-regs + epctl_reg);
- s3c_hsotg_txfifo_flush(hsotg, idx);
+ s3c_hsotg_txfifo_flush(hsotg, hs_ep-fifo_index);
if ((epctl DXEPCTL_STALL)
(epctl DXEPCTL_EPTYPE_BULK)) {
@@ -1983,6 +1998,7 @@ static void kill_all_requests(struct s3c_hsotg *hsotg,
int result, bool force)
{
struct s3c_hsotg_req *req, *treq;
+ unsigned size;
list_for_each_entry_safe(req, treq, ep-queue, queue) {
/*
@@ -1996,9 +2012,11 @@ static void kill_all_requests(struct s3c_hsotg *hsotg,
s3c_hsotg_complete_request(hsotg, ep, req,
result);
}
- if (hsotg-dedicated_fifos)
- if ((readl(hsotg-regs + DTXFSTS(ep-index)) 0x) * 4
3072)
- s3c_hsotg_txfifo_flush(hsotg, ep-index);
+ if (!hsotg-dedicated_fifos)
+ return;
+ size = (readl(hsotg-regs + DTXFSTS(ep-index)) 0x) * 4;
+ if (size ep-fifo_size)
+ s3c_hsotg_txfifo_flush(hsotg, ep-fifo_index);
}
/**
@@ -2439,6 +2457,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
u32 epctrl;
u32 mps;
int dir_in;
+ int i, val, size;
int ret = 0;
dev_dbg(hsotg-dev,
@@ -2511,17 +2530,8 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
break;
case USB_ENDPOINT_XFER_INT:
- if (dir_in) {
-
Re: RCU bug with v3.17-rc3 ?
On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote: Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: v3.17-rc3, correct? I take it that the test passes on some earlier version? Thanx, Paul | # modprobe g_mass_storage stall=0 removable=1 file=/dev/sda | [ 44.883554] Number of LUNs=8 | [ 44.886709] Mass Storage Function, version: 2009/09/11 | [ 44.892303] LUN: removable file: (no medium) | [ 44.896916] Number of LUNs=1 | [ 44.901198] LUN: removable file: /dev/sda | [ 44.905410] Number of LUNs=1 | [ 44.917706] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 | [ 44.925018] g_mass_storage gadget: userspace failed to provide iSerialNumber | [ 44.932489] g_mass_storage gadget: g_mass_storage ready | [ 52.583773] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage | # [ 98.270585] Unable to handle kernel paging request at virtual address | [ 98.278198] pgd = c0004000 | [ 98.281027] [] *pgd=ae7f6821, *pte=, *ppte= | [ 98.287648] Internal error: Oops: 17 [#1] SMP ARM | [ 98.292559] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs usb_storage xhci_hcd dwc3 udc_core matrix_keypad lis3lv02d_i2c dwc3_omap lis3lv02d input_polldev | [ 98.309721] CPU: 0 PID: 1820 Comm: file-storage Not tainted 3.17.0-rc3-00013-gc6b1a7d #806 | [ 98.318346] task: ec356040 ti: ec378000 task.ti: ec378000 | [ 98.324000] PC is at find_get_entry+0x7c/0x128 | [ 98.328640] LR is at 0xfffa | [ 98.331912] pc : [c011394c]lr : [fffa]psr: a013 | [ 98.331912] sp : ec379b50 ip : fp : ec379b84 | [ 98.343888] r10: c0c81243 r9 : 0001 r8 : ea123d28 | [ 98.349352] r7 : ec378010 r6 : 0001 r5 : r4 : 000f | [ 98.356181] r3 : ec379b3c r2 : r1 : 0001 r0 : | [ 98.363006] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel | [ 98.370646] Control: 10c5387d Table: ac2b0059 DAC: 0015 | [ 98.376641] Process file-storage (pid: 1820, stack limit = 0xec378248) | [ 98.383454] Stack: (0xec379b50 to 0xec37a000) | [ 98.388003] 9b40: c01138d0 c002aa3c | [ 98.396560] 9b60: 000f ea123d24 000200d0 0001 00d0 ec379bbc ec379b88 | [ 98.405100] 9b80: c0114360 c01138dc c1486a00 6013 ec379bc4 1400 ea123d24 | [ 98.413635] 9ba0: 0c00 0400 ec378010 c06dea0c ec379bdc ec379bc0 c011478c c0114330 | [ 98.422183] 9bc0: 00d0 c00904f8 c1486a00 1400 ec379c04 ec379be0 c019cd68 c0114760 | [ 98.430732] 9be0: c0090808 c0090590 ec379c34 0001 0c00 ea123d24 ec379c2c ec379c08 | [ 98.439300] 9c00: c019ecbc c019cd44 0c00 0001 ec379c58 c019eb9c 0c00 ec379d54 | [ 98.447860] 9c20: ec379c8c ec379c30 c0113f14 c019ec8c 0c00 0001 ec379c58 ec379c5c | [ 98.456414] 9c40: ec378030 0001 ec250cc0 1400 c018195c c00acd08 | [ 98.464974] 9c60: 5408b05a 1000 ec250cc0 ec379d68 ea123d24 ec378010 | [ 98.473533] 9c80: ec379cf4 ec379c90 c0115ed4 c0113e6c 0001 c019f2b0 c0090590 | [ 98.482071] 9ca0: ec379cc4 ec378010 c06c3df4 1000 ea123c64 c019f2b0 ec379d54 ec379cc8 | [ 98.490607] 9cc0: 1400 0001 ec379d68 ec379d54 ec379e30 ec250cc0 ec356040 | [ 98.499178] 9ce0: ed7ab800 ec30d800 ec379d3c ec379cf8 c019f2b0 c0115c8c c06be3b8 c006dcec | [ 98.507741] 9d00: ec1b0010 ec30d800 ec379d08 ec379d08 ec379d10 ec379d10 ec379d18 ec379d18 | [ 98.516288] 9d20: 1400 ec379e30 ec250cc0 ec379dc4 ec379d40 c016618c c019f284 | [ 98.524833] 9d40: 1000 c0317b78 ec379d7c ec394000 1000 0003 1000 | [ 98.533385] 9d60: ec379d4c 0001 ec250cc0 ec356040 | [ 98.541946] 9d80: 1400 1000 | [ 98.550482] 9da0: ec394000 ec250cc0 ec394000 ec379e30 1000 1000 ec379df4 ec379dc8 | [ 98.559023] 9dc0: c0166a3c c01660f4 0002 ec0ace20 1000 000e ec0ace00 | [ 98.567567] 9de0: 1000 ed7ab800 ec379e64 ec379df8 bf0bc3b4 c0166994 006f 1000 | [ 98.576112] 9e00: bf0bc7a4 6013 e8156000 000e 3930343d bf0bc7a4 ec0ace00 | [ 98.584660] 9e20: 2400 1400 1400 ec379e64 | [ 98.593193] 9e40: ed36ddc0 ec378018 ec30d894 ec0ace00 ec30d800 ec30d840 ec379ed4 ec379e68 | [ 98.601754] 9e60: bf0bd1c8 bf0bc08c bf0bf6ec ec378010 c06c3df4 ec356040 0001 | [ 98.610305] 9e80: ec379eac ec379e90 c00906b0 c00904f8 ec30d894 ed36ddc0 ec378018 ec30d894 | [ 98.618857] 9ea0: ec379ebc ec379eb0 c0090808
Re: [PATCH RESEND v3 01/12] usb: dwc2/gadget: fix phy disable sequence
On Thu, Sep 04, 2014 at 12:04:23PM -0700, Paul Zimmerman wrote: From: Kamil Debski k.deb...@samsung.com When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com looks like this one deserves a Cc: stable ? FWIW Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND v3 02/12] usb: dwc2/gadget: fix phy initialization sequence
On Thu, Sep 04, 2014 at 12:04:24PM -0700, Paul Zimmerman wrote:
From: Kamil Debski k.deb...@samsung.com
In the Generic PHY Framework a NULL phy is considered to be a valid phy
thus the if (hsotg-phy) check does not give us the information whether
the Generic PHY Framework is used.
In addition to the above this patch also removes phy_init from probe and
phy_exit from remove. This is not necessary when init/exit is done in the
s3c_hsotg_phy_enable/disable functions.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
this too, looks like it deserves Cc: stable
FWIW
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc2/gadget.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 505d56e..fd556e0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2747,13 +2747,14 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
*hsotg)
dev_dbg(hsotg-dev, pdev 0x%p\n, pdev);
- if (hsotg-phy) {
- phy_init(hsotg-phy);
- phy_power_on(hsotg-phy);
- } else if (hsotg-uphy)
+ if (hsotg-uphy)
usb_phy_init(hsotg-uphy);
- else if (hsotg-plat-phy_init)
+ else if (hsotg-plat hsotg-plat-phy_init)
hsotg-plat-phy_init(pdev, hsotg-plat-phy_type);
+ else {
+ phy_init(hsotg-phy);
+ phy_power_on(hsotg-phy);
+ }
coding style, placement of braces.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND v3 07/12] usb: dwc2/gadget: break infinite loop in endpoint disable code
On Thu, Sep 04, 2014 at 12:04:29PM -0700, Paul Zimmerman wrote: From: Marek Szyprowski m.szyprow...@samsung.com This patch fixes possible freeze caused by infinite loop in interrupt context. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com Cc stable ? Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc2/gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 86e4fd9..97368c4c 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -1651,6 +1651,7 @@ static void s3c_hsotg_txfifo_flush(struct s3c_hsotg *hsotg, unsigned int idx) dev_err(hsotg-dev, %s: timeout flushing fifo (GRSTCTL=%08x)\n, __func__, val); + break; } udelay(1); -- 2.1.0.24.g4109c28 -- 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 -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND v3 08/12] usb: dwc2/gadget: do not call disconnect method in pullup
On Thu, Sep 04, 2014 at 12:04:30PM -0700, Paul Zimmerman wrote:
From: Marek Szyprowski m.szyprow...@samsung.com
This leads to potential spinlock recursion in composite framework, other
udc drivers also don't call it directly from pullup method.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Cc stable ?
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc2/gadget.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 97368c4c..55238b0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2944,7 +2944,6 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
s3c_hsotg_phy_enable(hsotg);
s3c_hsotg_core_init(hsotg);
} else {
- s3c_hsotg_disconnect(hsotg);
s3c_hsotg_phy_disable(hsotg);
}
--
2.1.0.24.g4109c28
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND v3 09/12] usb: dwc2/gadget: delay enabling irq once hardware is configured properly
On Thu, Sep 04, 2014 at 12:04:31PM -0700, Paul Zimmerman wrote:
From: Marek Szyprowski m.szyprow...@samsung.com
This patch fixes kernel panic/interrupt storm/etc issues if bootloader
left s3c-hsotg module in enabled state. Now interrupt handler is enabled
only after proper configuration of hardware registers.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Makes sense, Cc stable ?
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc2/gadget.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 55238b0..2c9f0f5 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3456,13 +3456,6 @@ static int s3c_hsotg_probe(struct platform_device
*pdev)
hsotg-irq = ret;
- ret = devm_request_irq(pdev-dev, hsotg-irq, s3c_hsotg_irq, 0,
- dev_name(dev), hsotg);
- if (ret 0) {
- dev_err(dev, cannot claim IRQ\n);
- goto err_clk;
- }
-
dev_info(dev, regs %p, irq %d\n, hsotg-regs, hsotg-irq);
hsotg-gadget.max_speed = USB_SPEED_HIGH;
@@ -3500,6 +3493,17 @@ static int s3c_hsotg_probe(struct platform_device
*pdev)
s3c_hsotg_hw_cfg(hsotg);
s3c_hsotg_init(hsotg);
+ ret = devm_request_irq(pdev-dev, hsotg-irq, s3c_hsotg_irq, 0,
+ dev_name(dev), hsotg);
+ if (ret 0) {
+ s3c_hsotg_phy_disable(hsotg);
+ clk_disable_unprepare(hsotg-clk);
+ regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies),
+hsotg-supplies);
+ dev_err(dev, cannot claim IRQ\n);
+ goto err_clk;
+ }
+
/* hsotg-num_of_eps holds number of EPs other than ep0 */
if (hsotg-num_of_eps == 0) {
--
2.1.0.24.g4109c28
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND v3 12/12] usb: dwc2/gadget: avoid disabling ep0
On Thu, Sep 04, 2014 at 12:04:34PM -0700, Paul Zimmerman wrote: From: Robert Baldyga r.bald...@samsung.com Endpoint 0 should not be disabled, so we start loop counter from number 1. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com Looks like this would fix a modprobe -r followed by modprobe of dwc2 ? In that case, should you Cc stable ? Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc2/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 32af626..94f7a3f 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2929,7 +2929,7 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget, return -ENODEV; /* all endpoints should be shutdown */ - for (ep = 0; ep hsotg-num_of_eps; ep++) + for (ep = 1; ep hsotg-num_of_eps; ep++) s3c_hsotg_ep_disable(hsotg-eps[ep].ep); spin_lock_irqsave(hsotg-lock, flags); -- 2.1.0.24.g4109c28 -- 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 -- balbi signature.asc Description: Digital signature
Re: RCU bug with v3.17-rc3 ?
On Thu, Sep 04, 2014 at 12:16:42PM -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote: Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: v3.17-rc3, correct? yup, as in subject ;-) I take it that the test passes on some earlier version? about to test v3.14.17. -- balbi signature.asc Description: Digital signature
RE: [PATCH RESEND v3 01/12] usb: dwc2/gadget: fix phy disable sequence
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, September 04, 2014 12:18 PM On Thu, Sep 04, 2014 at 12:04:23PM -0700, Paul Zimmerman wrote: From: Kamil Debski k.deb...@samsung.com When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com looks like this one deserves a Cc: stable ? Good point. Robert, what do you think? Only problem is, this file moved from drivers/usb/gadget/ to here in 3.16, so earlier stable versions would require some additional backporting. -- Paul FWIW Reviewed-by: Felipe Balbi ba...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v3 01/12] usb: dwc2/gadget: fix phy disable sequence
Hi, On Thu, Sep 04, 2014 at 07:37:20PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, September 04, 2014 12:18 PM On Thu, Sep 04, 2014 at 12:04:23PM -0700, Paul Zimmerman wrote: From: Kamil Debski k.deb...@samsung.com When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Paul Zimmerman pa...@synopsys.com looks like this one deserves a Cc: stable ? Good point. Robert, what do you think? Only problem is, this file moved from drivers/usb/gadget/ to here in 3.16, so earlier stable versions would require some additional backporting. Right, you'll receive a notification from Greg that the patch FAILED to apply and all you gotta do is provide a modified patch which, in this case, is just a path modification. -- balbi signature.asc Description: Digital signature
Re: RCU bug with v3.17-rc3 ?
Hi, On Thu, Sep 04, 2014 at 02:25:35PM -0500, Felipe Balbi wrote: On Thu, Sep 04, 2014 at 12:16:42PM -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote: Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: v3.17-rc3, correct? yup, as in subject ;-) I take it that the test passes on some earlier version? about to test v3.14.17. coudln't get v3.14 working on this board but at least v3.16 is also affected except that on now it happened during boot, I didn't even need to run my test: [ 17.438195] Unable to handle kernel paging request at virtual address [ 17.446109] pgd = ec36 [ 17.448947] [] *pgd=ae7f6821, *pte=, *ppte= [ 17.455639] Internal error: Oops: 17 [#1] SMP ARM [ 17.460578] Modules linked in: dwc3(+) udc_core lis3lv02d_i2c lis3lv02d input_polldev dwc3_omap matrix_keypad [ 17.471060] CPU: 0 PID: 1381 Comm: accounts-daemon Tainted: G W 3.16.0-5-g8a6cdb4 #811 [ 17.480735] task: ed716040 ti: ec026000 task.ti: ec026000 [ 17.486405] PC is at find_get_entry+0x7c/0x128 [ 17.491070] LR is at 0xfffa [ 17.494364] pc : [c0110b4c]lr : [fffa]psr: a013 [ 17.494364] sp : ec027dc8 ip : fp : ec027dfc [ 17.506384] r10: c0c6f6bc r9 : 0005 r8 : ecdf22f8 [ 17.511860] r7 : ec026008 r6 : 0001 r5 : r4 : [ 17.518705] r3 : ec027db4 r2 : r1 : 0005 r0 : [ 17.525526] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 17.533007] Control: 10c5387d Table: ac360059 DAC: 0015 [ 17.539020] Process accounts-daemon (pid: 1381, stack limit = 0xec026248) [ 17.546151] Stack: (0xec027dc8 to 0xec028000) [ 17.550710] 7dc0: c0110ad0 ecdf0b80 ecdf22f4 [ 17.559259] 7de0: ecdf22f4 0005 ec027e34 ec027e00 c0111874 c0110adc [ 17.567824] 7e00: ecdf0b80 c03565b4 ed7165f8 ec3dddf0 ecdf22f4 0005 ec3ddd00 0001 [ 17.576385] 7e20: ecdf21a0 ec027ebc ec027e38 c0112978 c0111844 c06af938 [ 17.584950] 7e40: ecdf0b70 ecdf0b70 ec027e6c ec027e58 0005 0006 0b80 ecdf0b70 [ 17.593514] 7e60: c0163264 ec3dddf0 ec027ee8 ec027ed4 0b80 ec027eac ec027e88 [ 17.602087] 7e80: c0178d98 c0356590 0002 5b80 ec027f78 [ 17.610653] 7ea0: ec3ddd00 ed716040 b6cab018 ec027f44 ec027ec0 c0163264 c0112780 [ 17.619202] 7ec0: 0180 0180 ec027efc b6cab018 0180 0180 [ 17.627772] 7ee0: ec027ecc 0001 ec3ddd00 ed716040 [ 17.636371] 7f00: 5b80 0180 [ 17.644946] 7f20: b6cab018 ec3ddd00 b6cab018 ec027f78 ec3ddd00 0180 ec027f74 ec027f48 [ 17.653524] 7f40: c0163a6c c01631cc b6cab018 5b80 ec3ddd03 ec3ddd00 [ 17.662085] 7f60: 0180 b6cab018 ec027fa4 ec027f78 c0164198 c01639e0 5b80 [ 17.670658] 7f80: be91badc be91ba50 00044a00 0003 c000f044 ec026000 ec027fa8 [ 17.679222] 7fa0: c000edc0 c0164158 be91badc be91ba50 0008 b6cab018 0180 be91ba38 [ 17.687794] 7fc0: be91badc be91ba50 00044a00 0003 be91bbac b6cab008 [ 17.696370] 7fe0: 0020 be91ba40 b6c78e8c b6c78ea8 6010 0008 ae7f6821 ae7f6c21 [ 17.704956] [c0110b4c] (find_get_entry) from [c0111874] (pagecache_get_page+0x3c/0x1f4) [ 17.713687] [c0111874] (pagecache_get_page) from [c0112978] (generic_file_read_iter+0x204/0x794) [ 17.723259] [c0112978] (generic_file_read_iter) from [c0163264] (new_sync_read+0xa4/0xcc) [ 17.732185] [c0163264] (new_sync_read) from [c0163a6c] (vfs_read+0x98/0x158) [ 17.739945] [c0163a6c] (vfs_read) from [c0164198] (SyS_read+0x4c/0xa0) [ 17.747149] [c0164198] (SyS_read) from [c000edc0] (ret_fast_syscall+0x0/0x48) [ 17.754994] Code: e1a01009 eb08ffa9 e350 0a1f (e5904000) [ 17.761476] ---[ end trace 49c4ed35a1c01157 ]--- It seems to be a difficult-to-reproduce race though. On a second boot it didn't die during boot, but died with my USB test case. Unfortunately, the platform I'm using is pretty new and only goes as far back as v3.16 (which I had to backport 11 patches to get it to boot good enough for this test). I wonder if a corrupt file system could cause such problems... I keep seeing EXT4 errors every now and again; considering that this dies in a path through VFS, I wonder... cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: usbip: fix usbip.h path in userspace tool
On Thu, Sep 04, 2014 at 09:58:11PM +0300, Valentina Manea wrote: On Thu, Sep 4, 2014 at 5:14 AM, Greg KH gre...@linuxfoundation.org wrote: This patch is a pretty nasty hack to get it to compile within the kernel tree. I wonder whether we can make this self-contained by duplicating the header's content inside usbip_common.h. Ick, no, don't do that, use the .h file, that is what it is there for. This leaves 2 options: a. include the file the way this patch did it No. b. include as linux/usbip.h and add the relative path in the kernel tree to include/uapi as include path. the problem with this is that the previous header, ch9.h, eventually includes other kernel headers and a path to include/ would also be necessary. plus, there's a warning about using kernel headers from user space, which is legit. If you get a warning, then you are doing something wrong. Just use the header file that the kernel installs (it is a uapi/ file, right?) Then all should be fine. For the time being, I suppose the first option will do. No, relative paths for user tools to kernel header files isn't ok. 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
From: James Bottomley james.bottom...@hansenpartnership.com Before we embark on elaborate hacks, why don't we just make the capacity writeable (by root) in sysfs from userspace (will require block change)? We can then encode all the nasty heuristics (including gpt reading) in userspace as a udev rule. Looking in from the outside, this makes sense to me. All the nasty hueristics can be put in userspace -- perhaps as even a special-purpose program, where we can directly warn the user as to what he's getting himself into. (I do not demand that this all work automatically.) And the hueristics can be improved easily, without kernel changes. The only gotcha that I see is that once the recorded device size is changed, the kernel may now consider the partition table to be valid, and should now parse it and set up the special device numbers for the partitions. So that needs to get triggered properly. I suppose there is some complexity if the block-handling layer already has blocks cached and the device size is reduced below the addresses of the cached blocks. But as long as the kernel doesn't crash or write blocks in incorrect places, I don't see that as a problem -- if you set the device size as less than the block numbers you've already written to, that's your problem. Dale -- 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: Similar Elan Touchscreen reset behaviour
On Sat, Aug 16, 2014 at 12:37:19AM -0700, Eric Decker wrote: Hi Sarah, I talked to you a while back about the ELAN touchscreen in my ASUS laptop doing a repeated disconnect. It just came back. So you are probably right about it being flakey h/w. Returning it at this point probably isn't an option. Now if the ELAN touchscreen is a problem, is there a way to blacklist it so it doesn't get turned on? I don't even use the touchscreen. You could blacklist the driver, e.g. put the module name in /etc/modprobe.d/blacklist-whatever.conf That will at least stop the module from being loaded, but won't stop it from being enumerated. I think there's a way for userspace to claim a particular port so that the kernel doesn't even do enumeration, but I can't remember the interface. Maybe Mathias or Alan knows? Sarah Sharp -- 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: ax88179_178a hang over xhci
Hi Andrea, I'm no longer the xHCI driver maintainer. Please work with Mathias, and Cc the linux-usb mailing list. Sarah Sharp On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: Hi Sarah, just a short followup on this. I still had 1gbps hangs with the 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now stable for the last 12 hours under heavy load after I removed all powersaving features. Earlier I had these two command run at boot time: for i in /sys/bus/usb/devices/*/power/autosuspend_delay_ms; do echo 2000 $i; done for i in /sys/bus/*/devices/*/power/control; do echo auto $i; done Removing these two and leaving all the power tweaks at their default setting may have made a difference (even though I expect powertop will now complain but I don't mind the battery life too much on the laptop so this is ok for now if I can get it stable at least). Potentially it could be an hardware issue too related to suspending some pci or usb2 device conflicting with xhci usb3. More likely there's some software screwup in the powersave code that conflicts with xhci runtime. The powersaving being the culprit didn't cross my mind earlier because while there's a constant flood at 2gigabit through the usb3 network card, I would never expect powersaving to potentially kick in. On Thu, Jul 03, 2014 at 02:30:17AM +0200, Andrea Arcangeli wrote: Hello Sarah, last year I bought this device: Bus 004 Device 002: ID 0b95:1790 ASIX Electronics Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0b95 ASIX Electronics Corp. idProduct 0x1790 bcdDevice1.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 57 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 124mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 11 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Unless the hardware is broken there's something wrong in xhci or the usbnet driver that makes it hang with my usual stress test I do to check if the networks is reliable. The device driver is ax88179_178a.c This is the USB host side on the laptop: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) In normal usage it practically actually happens, it happened once but it's definitely not reproducible without the stress test. So I guess nobody has noticed this because it's kind of desktop hardware that is used without much QA. I never reported this because I never bothered to collect
[PATCH v5 0/2] Add generic PHY support to USB HCD
Hello. This patchset is against the usb-next' branch of Greg KH's 'usb.git' repo. Here I add support for the generic PHY to the 'struct usb_hcd' (having to rename the existing 'phy' field to 'usb_phy' beforehand). This was mainly intended to be used with the PCI OHCI/EHCI drivers and also xHCI driver; however there are several more dependent patchsets now posted to 'linux-usb'. Greg, if you want links to these patchsets and the device tree patches using this patchset in order to link the PCI OHCI/EHCI devices to the PHY, just ask (I have already posted the previously but will probably have to repost them again)... [1/2] usb: rename phy to usb_phy in HCD [2/2] usb: hcd: add generic PHY support 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 v5 1/2] usb: rename phy to usb_phy in HCD
From: Antoine Tenart antoine.ten...@free-electrons.com
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.
drivers/usb/chipidea/host.c |2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c|8
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c |2 +-
drivers/usb/host/ehci-msm.c |4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
drivers/usb/misc/lvstest.c|8
include/linux/usb/hcd.h |2 +-
10 files changed, 49 insertions(+), 49 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
hcd-power_budget = ci-platdata-power_budget;
- hcd-phy = ci-transceiver;
+ hcd-usb_phy = ci-transceiver;
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2627,7 +2627,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) !hcd-phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
if (IS_ERR(phy)) {
@@ -2640,7 +2640,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd-phy = phy;
+ hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2788,10 +2788,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
return retval;
}
@@ -2864,10 +2864,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
usb_put_invalidate_rhdev(hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4461,8 +4461,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd-phy !hdev-parent)
- usb_phy_notify_connect(hcd-phy, udev-speed);
+ if (hcd-usb_phy !hdev-parent)
+ usb_phy_notify_connect(hcd-usb_phy, udev-speed);
/*
* Some superspeed devices have finished the link training process
@@ -4617,9 +4617,9 @@ static void hub_port_connect(struct usb_
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd-phy !hdev-parent
+ if (hcd-usb_phy !hdev-parent
!(portstatus USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd-phy, udev-speed);
+ usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct
[PATCH v5 2/2] usb: hcd: add generic PHY support
Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
Changes in version 5:
- renamed the new 'gen_phy' field of 'struct usb_phy' back to 'phy';
- resolved rejects occured due to a newly added patch.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- refreshed the patch.
Changes in version 2:
- renamed the new 'phy' field of 'struct usb_phy' to 'gen_phy';
- resolved rejects due to removal of the first patch in the series.
drivers/usb/core/hcd.c | 42 --
include/linux/usb/hcd.h |1 +
2 files changed, 41 insertions(+), 2 deletions(-)
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -42,6 +42,7 @@
#include linux/pm_runtime.h
#include linux/types.h
+#include linux/phy/phy.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/phy.h
@@ -2645,6 +2646,29 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
}
+ if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
+ struct phy *phy = phy_get(hcd-self.controller, usb);
+
+ if (IS_ERR(phy)) {
+ retval = PTR_ERR(phy);
+ if (retval == -EPROBE_DEFER)
+ goto err_phy;
+ } else {
+ retval = phy_init(phy);
+ if (retval) {
+ phy_put(phy);
+ goto err_phy;
+ }
+ retval = phy_power_on(phy);
+ if (retval) {
+ phy_exit(phy);
+ phy_put(phy);
+ goto err_phy;
+ }
+ hcd-phy = phy;
+ }
+ }
+
dev_info(hcd-self.controller, %s\n, hcd-product_desc);
/* Keep old behaviour if authorized_default is not in [0, 1]. */
@@ -2660,7 +2684,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
*/
if ((retval = hcd_buffer_create(hcd)) != 0) {
dev_dbg(hcd-self.controller, pool alloc failed\n);
- goto err_remove_phy;
+ goto err_create_buf;
}
if ((retval = usb_register_bus(hcd-self)) 0)
@@ -2787,7 +2811,14 @@ err_allocate_root_hub:
usb_deregister_bus(hcd-self);
err_register_bus:
hcd_buffer_destroy(hcd);
-err_remove_phy:
+err_create_buf:
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-phy) {
+ phy_power_off(hcd-phy);
+ phy_exit(hcd-phy);
+ phy_put(hcd-phy);
+ hcd-phy = NULL;
+ }
+err_phy:
if (hcd-remove_phy hcd-usb_phy) {
usb_phy_shutdown(hcd-usb_phy);
usb_put_phy(hcd-usb_phy);
@@ -2864,6 +2895,13 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
+
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-phy) {
+ phy_power_off(hcd-phy);
+ phy_exit(hcd-phy);
+ phy_put(hcd-phy);
+ hcd-phy = NULL;
+ }
if (hcd-remove_phy hcd-usb_phy) {
usb_phy_shutdown(hcd-usb_phy);
usb_put_phy(hcd-usb_phy);
Index: usb/include/linux/usb/hcd.h
===
--- usb.orig/include/linux/usb/hcd.h
+++ usb/include/linux/usb/hcd.h
@@ -107,6 +107,7 @@ struct usb_hcd {
* other external phys should be software-transparent
*/
struct usb_phy *usb_phy;
+ struct phy *phy;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
--
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: Similar Elan Touchscreen reset behaviour
On Thu, Sep 04, 2014 at 02:30:40PM -0700, Sarah Sharp wrote: On Sat, Aug 16, 2014 at 12:37:19AM -0700, Eric Decker wrote: Hi Sarah, I talked to you a while back about the ELAN touchscreen in my ASUS laptop doing a repeated disconnect. It just came back. So you are probably right about it being flakey h/w. Returning it at this point probably isn't an option. Now if the ELAN touchscreen is a problem, is there a way to blacklist it so it doesn't get turned on? I don't even use the touchscreen. You could blacklist the driver, e.g. put the module name in /etc/modprobe.d/blacklist-whatever.conf That will at least stop the module from being loaded, but won't stop it from being enumerated. I think there's a way for userspace to claim a particular port so that the kernel doesn't even do enumeration, but I can't remember the interface. Maybe Mathias or Alan knows? You might want to look at Johan's patches on the list, they address a known problem with ELAN touchscreens of being flakey that solves the issue with my laptop, and should be merged soon. The problem is the hardware goes crazy if it doesn't see USB traffic very quickly after booting, and constantly. So switching to console mode, or booting to console mode can cause problems. I'd be interested to see if those patches solve your issue as well. 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Thu, Sep 4, 2014 at 7:35 PM, Wang YanQing udkni...@gmail.com wrote: On Sun, Aug 31, 2014 at 11:24:56PM +0800, Wang YanQing wrote: PL2303 USB Serial devices may has GPIOs, this patch add basic PL2303 gpio support. Known issue: If gpios are in use(export to userspace through sysfs interface, etc), then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc), will cause trouble, so we need to make sure there is no gpio user before call pl2303_release. Signed-off-by: Wang YanQing udkni...@gmail.com --- Note: I sniffed office HXD gpio test program to get gpios control protocol with PL2303 RA, so I only test it with PL2303 RA and HXA, I don't have HXD, but because it is *office* HXD gpio test program, so if it doesn't work with HXD, I will feel surprise. I can confirm your patch is working fine on the HXD: http://www.zoobab.com/pl2303hxd-gpio I am still hunting for a simple C program to test the speed of the GPIOs and sysfs, if you have a good reference. Best, -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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: usbip: fix usbip.h path in userspace tool
Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- tools/usb/usbip/libsrc/usbip_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..a80e73d4f11e 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include ../../../include/uapi/linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: usbip: fix usbip.h path in userspace tool
Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- include/uapi/linux/Kbuild | 1 + tools/usb/usbip/libsrc/usbip_common.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 24e9033f8b3f..9955c3b0ef93 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -395,6 +395,7 @@ header-y += un.h header-y += unistd.h header-y += unix_diag.h header-y += usbdevice_fs.h +header-y += usbip.h header-y += utime.h header-y += utsname.h header-y += uuid.h diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..15fe792e1e96 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: usbip: fix usbip.h path in userspace tool
On Fri, Sep 05, 2014 at 12:55:39AM +0200, Piotr Król wrote: Sorry for that I send second time the same patch. Please ignore it. Thanks, Piotr Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- tools/usb/usbip/libsrc/usbip_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..a80e73d4f11e 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include ../../../include/uapi/linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: usbip: fix usbip.h path in userspace tool
On Fri, Sep 05, 2014 at 12:58:02AM +0200, Piotr Król wrote: Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- include/uapi/linux/Kbuild | 1 + tools/usb/usbip/libsrc/usbip_common.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 24e9033f8b3f..9955c3b0ef93 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -395,6 +395,7 @@ header-y += un.h header-y += unistd.h header-y += unix_diag.h header-y += usbdevice_fs.h +header-y += usbip.h header-y += utime.h header-y += utsname.h header-y += uuid.h diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..15fe792e1e96 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 Much nicer, thanks. I'll queue this up in a bit. 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 v3 0/6] usb: host: change TPL support behaviour
On Thu, Sep 04, 2014 at 11:12:42AM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: On Wed, Sep 03, 2014 at 09:48:15PM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. But usb_enumerate_device_otg() gets called for all types of host, right? At least, it gets called whenever usb_enumerate_device() runs. Yes, it contains #ifdef CONFIG_USB_OTG. But your patch has if (... IS_ENABLED(CONFIG_USB_OTG)), so the behavior is the same. Why move the code if there's no change in behavior? At former code, the tpl support judgement (in function is_targeted) will only be called if CONFIG_USB_OTG is defined, but now, we need tpl support for all targeted hosts. Why we need IS_ENABLED(CONFIG_USB_OTG) as last conditions at if conditions, the reason is the operation which the B-device may want switch to host even if it is not at A's TPL is only for OTG host. The only side effect in is_targeted() is the dev_err() message. Are you saying that this dev_err() message needs to appear even when CONFIG_USB_OTG is disabled? Yes, both embedded host and otg host CAN support TPL, if the embedded host SHOULD support TPL, it should show an err message if the unsupported device is on the port. At OTG EH compliance test plan, (http://www.usb.org/developers/onthego/otgeh_compliance_plan_1_2.pdf) page 124, the chapter 7.3.6 A-UUT Unsupported device Message test, it needs host prints Unsupported Device if the attaching device is not supported (without at Targeted Peripheral List). -- Best Regards, Peter Chen -- 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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, Sep 04, 2014 at 11:04:38AM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Felipe Alan, how about using below steps for this reset/vbus/pullup changes? It mainly uses Alan's suggestion. Step 1: The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. the -reset is mandatory for all gadget drivers (currently, only four, they are composite, configfs, gadgetfs , dbgp. Step 2: Add routines to udc-core to handle Vbus changes, function activation changes, and resets. It will include three sub-steps, from easy to hard: reset handler, vbus handler, and activation handler. Perhaps the activation handler can be delayed until step 4. It won't get used until composite.c is modified to call it. Step 3: Modify all UDCs to call udc-core's reset and vbus handler, delete usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers, and delete invoking usb_gadget_connect unconditional at udc_bind_to_driver Step 4: Modify the composite.c to disable pullup for adding every function, and enable pullup when necessary. Actually, composite.c should be modified to call the activation handler in udc-core, and then _that_ routine would adjust the pullup as necessary. This plan is okay with me. OK, let's put the function activation change to the last. If the Felipe has no other comments, I will send the patch for step one next Monday. -- Best Regards, Peter Chen -- 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: Fwd: Status of chipidea msm USB reset patch
On Thu, Sep 04, 2014 at 07:47:40AM -0700, Tim Bird wrote:
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in
someone's tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back
in May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Please let me know.
OK, in fact, this patch is in my next chipidea next tree, and will be in
3.18-rc1.
(From the commit log, it doesn't show it is a bugfix:))
If it is a bugfix for you, I will send it go Greg.
Peter
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: usbip: fix usbip.h path in userspace tool
On Fri, Sep 5, 2014 at 1:58 AM, Piotr Król piotr.k...@3mdeb.com wrote: Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- include/uapi/linux/Kbuild | 1 + tools/usb/usbip/libsrc/usbip_common.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 24e9033f8b3f..9955c3b0ef93 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -395,6 +395,7 @@ header-y += un.h header-y += unistd.h header-y += unix_diag.h header-y += usbdevice_fs.h +header-y += usbip.h header-y += utime.h header-y += utsname.h header-y += uuid.h diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..15fe792e1e96 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 Looks good. 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Thu, Sep 04, 2014 at 06:44:31PM +0200, Benjamin Henrion wrote: On Thu, Sep 4, 2014 at 6:14 PM, Benjamin Henrion zoo...@gmail.com wrote: I have subscribed to the lkml. Can you make me a favour, send me your email as you posted on the LKML in mbox format attached to an email? I am trying to reply to it, but I cannot find an mbox archive, outside of gmane which rewrites all the email addresses. Otherwise, I made a page here: http://www.zoobab.com/pl2303hxd-gpio I will also try with other adapters to see if the 2 GPIOs show up. Any idea how to test the GPIO sysfs speed? Also tested with an HXA laying around, I could export the 2 GPIOS in /sys/class/gpio, but I could not change the status of the pins via echo. Any idea why? It is strange, I have tested again with my two HXA adapters, they work well. How do you test? check cat value or check voltage change? I check cat value, and they work good. -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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: Fwd: Status of chipidea msm USB reset patch
On Thu, Sep 04, 2014 at 07:47:40AM -0700, Tim Bird wrote:
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in
someone's tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back
in May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Wait, the below patch was not exactly the Ivan sent to me, it has no below
change at Ivan's recent patch
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
https://github.com/hzpeterchen/linux-usb/commit/be3473c05639dc84696c5e66e524ca22180cbe88
https://github.com/hzpeterchen/linux-usb/commit/b59838118bcc14a6a4ea1efec85c3452a705bfe0
Peter
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
Best Regards,
Peter Chen
--
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] SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices
Thanks, applied. -- 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
