Re: [PATCH] Add support for usbfs zerocopy.
Steinar H. Gunderson wrote: > > Our interface for zero copy reads/writes is O_DIRECT, and that requires > > not special memory allocation, just proper alignment. > > But that assumes you are using I/O using read()/write(). There's no way you > can shoehorn USB isochronous reads into the read() interface, O_DIRECT or not. How about aio? //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for usbfs zerocopy.
Steinar H. Gunderson wrote: > > Our interface for zero copy reads/writes is O_DIRECT, and that requires > > not special memory allocation, just proper alignment. > > But that assumes you are using I/O using read()/write(). There's no way you > can shoehorn USB isochronous reads into the read() interface, O_DIRECT or not. How about aio? //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
> + struct timespec64 tv;
tv is very often used for timeval structs.
I suggest also changing the variable name, for example to ts, to
avoid some possible confusion.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
> + struct timespec64 tv;
tv is very often used for timeval structs.
I suggest also changing the variable name, for example to ts, to
avoid some possible confusion.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote:
> > I started in the morning to build the driver from the source provided
> > by the vendor, but it was written in the times of kernel-version 2.4,
> > and I got hopelessly stuck.
>
> The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177
The vendor driver version 1.2 readme.txt from 2014-10-10 says:
Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.
> > Also, as per
> > http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
> > the particular serial-USB-adapter device is added into the id_table,
> > so seems supported as per say.
>
> That id was added by 82078234d402 ("USB: serial: ch341: New VID/PID for
> CH341 USB-serial") in 2008, which claims that the driver supports both
> old and new devices.
My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.
> > ###
> > usb 2-2: device not accepting address 8, error -71
> > ###
>
> This still looks like a hardware issue to me. Specifically, this happens
> before the ch341 driver is even involved.
I haven't seen any messages like this with my hardware.
//Peter
--- ch34x.c.orig2014-04-14 10:38:44.0 +0200
+++ ch34x.c 2015-06-15 19:26:39.0 +0200
@@ -10,11 +10,7 @@
// Support linux kernel version 2.6.25 and later
//
-#include
-#ifndef KERNEL_VERSION
-#defineKERNEL_VERSION(ver, rel, seq) ((ver << 16) | (rel << 8) |
(seq))
-#endif
-
+#include
#include
#include
#include
@@ -380,7 +376,7 @@
unsigned char reg_value = 0;
unsigned short value = 0;
unsigned short index = 0;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -405,7 +401,7 @@
return;
cflag = termios->c_cflag;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->number, cflag);
#else
dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->port_number, cflag);
@@ -515,7 +511,7 @@
/*unsigned int msr;*/
unsigned int retval;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -561,7 +557,7 @@
long timeout;
wait_queue_t wait;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -636,7 +632,7 @@
struct usb_serial *serial = port->serial;
int retval;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number );
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number );
@@ -710,7 +706,7 @@
/*unsigned int mcr = priv->line_control;*/
u8 control;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -743,7 +739,7 @@
unsigned int status;
unsigned int changed;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s -port:%d", __func__, port->number);
#else
dbg_ch34x("%s -port:%d", __func__, port->port_number);
@@ -793,7 +789,7 @@
{
//struct usb_serial_port *port = tty->driver_data;
#endif
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->number, cmd);
#else
dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->port_number, cmd);
@@ -802,7 +798,7 @@
{
// Note here
case TIOCMIWAIT:
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote:
I started in the morning to build the driver from the source provided
by the vendor, but it was written in the times of kernel-version 2.4,
and I got hopelessly stuck.
The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177
The vendor driver version 1.2 readme.txt from 2014-10-10 says:
Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.
Also, as per
http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
the particular serial-USB-adapter device is added into the id_table,
so seems supported as per say.
That id was added by 82078234d402 (USB: serial: ch341: New VID/PID for
CH341 USB-serial) in 2008, which claims that the driver supports both
old and new devices.
My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.
###
usb 2-2: device not accepting address 8, error -71
###
This still looks like a hardware issue to me. Specifically, this happens
before the ch341 driver is even involved.
I haven't seen any messages like this with my hardware.
//Peter
--- ch34x.c.orig2014-04-14 10:38:44.0 +0200
+++ ch34x.c 2015-06-15 19:26:39.0 +0200
@@ -10,11 +10,7 @@
// Support linux kernel version 2.6.25 and later
//
-#include linux/version.h
-#ifndef KERNEL_VERSION
-#defineKERNEL_VERSION(ver, rel, seq) ((ver 16) | (rel 8) |
(seq))
-#endif
-
+#include generated/uapi/linux/version.h
#include linux/kernel.h
#include linux/errno.h
#include linux/init.h
@@ -380,7 +376,7 @@
unsigned char reg_value = 0;
unsigned short value = 0;
unsigned short index = 0;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -405,7 +401,7 @@
return;
cflag = termios-c_cflag;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-number, cflag);
#else
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-port_number, cflag);
@@ -515,7 +511,7 @@
/*unsigned int msr;*/
unsigned int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -561,7 +557,7 @@
long timeout;
wait_queue_t wait;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -636,7 +632,7 @@
struct usb_serial *serial = port-serial;
int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number );
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number );
@@ -710,7 +706,7 @@
/*unsigned int mcr = priv-line_control;*/
u8 control;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -743,7 +739,7 @@
unsigned int status;
unsigned int changed;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s -port:%d, __func__, port-number);
#else
dbg_ch34x(%s -port:%d, __func__, port-port_number);
@@ -793,7 +789,7 @@
{
//struct usb_serial_port *port = tty-driver_data;
#endif
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-number, cmd);
#else
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-port_number, cmd);
@@ -802,7 +798,7 @@
{
// Note here
case TIOCMIWAIT:
-#if(LINUX_VERSION_CODE
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote: > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. > > garbage characters transmitted from embedded-device .. > > It seems that there is some issue with the driver. > > Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. > > Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. > > Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. > Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote: On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. garbage characters transmitted from embedded-device .. It seems that there is some issue with the driver. Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix data loss in cdc-acm
Sven Brauch wrote: > I don't make any other changes to the default settings. To be honest, > I'm not sure in which mode it is operating then (I was assuming raw, but > I might be wrong?). You should explicitly set a mode if you need a particular mode, otherwise the port might be in another mode. This sets raw. Add error checking. struct termios t; tcgetattr(fd, ); cfmakeraw(); cfsetspeed(, B115200); tcsetattr(fd, 0, ); //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix data loss in cdc-acm
Sven Brauch wrote: I don't make any other changes to the default settings. To be honest, I'm not sure in which mode it is operating then (I was assuming raw, but I might be wrong?). You should explicitly set a mode if you need a particular mode, otherwise the port might be in another mode. This sets raw. Add error checking. struct termios t; tcgetattr(fd, t); cfmakeraw(t); cfsetspeed(t, B115200); tcsetattr(fd, 0, t); //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
Mathias Nyman wrote: > +++ b/drivers/usb/host/xhci-ring.c > @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, > return 0; > /* offset in TRBs */ > segment_offset = trb - seg->trbs; > - if (segment_offset > TRBS_PER_SEGMENT) > + if (segment_offset > TRBS_PER_SEGMENT - 1) Maybe change the > comparison to >= rather than add the extra "- 1"? //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
Mathias Nyman wrote: +++ b/drivers/usb/host/xhci-ring.c @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, return 0; /* offset in TRBs */ segment_offset = trb - seg-trbs; - if (segment_offset TRBS_PER_SEGMENT) + if (segment_offset TRBS_PER_SEGMENT - 1) Maybe change the comparison to = rather than add the extra - 1? //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] FTDI CBUS GPIO support
Stefan Agner wrote: > libftdi requires to detach the kernel driver to get access to the device Control transfers ought to be possible without a detach. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] FTDI CBUS GPIO support
Stefan Agner wrote: libftdi requires to detach the kernel driver to get access to the device Control transfers ought to be possible without a detach. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
Juergen Gross wrote: > Do you have another feeling about the probability of a need to do usb 3? > If it is already on the horizon I wouldn't want to do the user space > backend now and the kernel one next year. :-) One year is pretty long in kernel time. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
Juergen Gross wrote: Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) One year is pretty long in kernel time. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Added PIDs for Actisense USB Devices
Mark Glover wrote: > From: Mark Glover > > Signed-off-by: Mark Glover There's an extraneous leading whitespace on the Signed-off-by line. > +#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */ The typo remains. "Apadter" here ^ //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Added PIDs for Actisense USB Devices Signed-off-by: Mark Glover
Please update your commit message to leave one blank line between the commit message summary and the rest of the message. (This avoids your signed-off-by ending up in the email subject.) Mark Glover wrote: > +++ b/drivers/usb/serial/ftdi_sio_ids.h .. > +#define CHETCO_SEAGAUGE_PID 0xA548 /* SeaGauge USB Adapter */ > +#define CHETCO_SEAGAUGE__PID 0xA549 /* SeaSwitch USG Apadter */ Please make the macro name match the product name. Also note typo^ here. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Added PIDs for Actisense USB Devices
Mark Glover wrote: From: Mark Glover m...@actisense.com Signed-off-by: Mark Glover m...@actisense.com There's an extraneous leading whitespace on the Signed-off-by line. +#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */ The typo remains. Apadter here ^ //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Added PIDs for Actisense USB Devices Signed-off-by: Mark Glover m...@actisense.com
Please update your commit message to leave one blank line between the commit message summary and the rest of the message. (This avoids your signed-off-by ending up in the email subject.) Mark Glover wrote: +++ b/drivers/usb/serial/ftdi_sio_ids.h .. +#define CHETCO_SEAGAUGE_PID 0xA548 /* SeaGauge USB Adapter */ +#define CHETCO_SEAGAUGE__PID 0xA549 /* SeaSwitch USG Apadter */ Please make the macro name match the product name. Also note typo^ here. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB driver fixes for 3.18-rc7
Linus Torvalds wrote: > I seem to get this problem possibly more commonly at boot these days: > usb 1-6: device descriptor read/64, error -71 > xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. > usb 1-6: hub failed to enable device, error -22 Since my upgrade to 98e8d2e0 from something a bit older I also get -71 error messages on boot and on resume, however this is older hardware with only ehci-pci. In my case some of the descriptors coming back from the device are bogus when the device is first seen. The device then disconnects, and when it is seen again by the kernel, nearly one second later, the descriptors are fine and there are no errors. vid/pid change from hardware ODM to OEM, suggesting that my device simply isn't ready when Linux first talks with it. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB driver fixes for 3.18-rc7
Linus Torvalds wrote: I seem to get this problem possibly more commonly at boot these days: usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 Since my upgrade to 98e8d2e0 from something a bit older I also get -71 error messages on boot and on resume, however this is older hardware with only ehci-pci. In my case some of the descriptors coming back from the device are bogus when the device is first seen. The device then disconnects, and when it is seen again by the kernel, nearly one second later, the descriptors are fine and there are no errors. vid/pid change from hardware ODM to OEM, suggesting that my device simply isn't ready when Linux first talks with it. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Felipe Balbi wrote: > > > A babble only occurs when > > > the device side tries to move data without the host asking for anything. > > > > It also occurs if the device moves more than packet_size bytes. Not > > really helping, I know… > > hmm, why would the device move more than wMaxPacketSize at a time ? Some devices are buggy. > That's certainly babble :-) Certainly! But musb shouldn't fall over or lock up because of it, should it? //Peter pgpf6s9Dswz1i.pgp Description: PGP signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Felipe Balbi wrote: A babble only occurs when the device side tries to move data without the host asking for anything. It also occurs if the device moves more than packet_size bytes. Not really helping, I know… hmm, why would the device move more than wMaxPacketSize at a time ? Some devices are buggy. That's certainly babble :-) Certainly! But musb shouldn't fall over or lock up because of it, should it? //Peter pgpf6s9Dswz1i.pgp Description: PGP signature
Re: [PATCH][RFC] USB: zerocopy support for usbfs
Alan Stern wrote: > > > Also, many host controllers cannot handle arbitrary alignment. > > > It would be best to require that the buffer start at a page boundary. > > > > This requires a bit of negotiation with userspace, maybe per-URB but > > I don't follow. What negotiation is needed? All that needs to happen > is the user program submits a transfer where the buffer is aligned on a > page boundary. The negotiation needed would be for userspace to learn what alignment is required, so that it can make sure to provide only such buffers. But see below on mmap.. > > it seems better to negotiate per-claim or even per-open. What about > > large control transfers? > > The kernel doesn't support scatter-gather for control transfers, only > bulk. That could possibly change, right, and then it would be nice to have zerocopy for free there as well? > > It's important that the kernel gives userspace enough information > > about the constraints, if userspace wants zerocopy. > > I don't know of any way for the kernel to give userspace any > information about constraints of this sort. Do you? I don't know of any at the moment, no. It might be done through an ioctl into usbfs, but if sysfs already has all neccessary information then no ioctl is needed. Anyway... > > Indeed I think userspace wants to be involved in choosing memory also > > with bulk, in order to ensure that zerocopy will always work when > > userspace cares about that. > > > > Is it enough to expose the DMA mask of the host controller? > > It doesn't need to be exposed, since the mmap(2) call would be handled > by the kernel's USB stack (and besides, the user program can't request > that the mapped memory be located in any particular physical address > region). Since alignment isn't the only issue I don't think there's a way to avoid it. I was just hoping to be able to avoid allocating zerocopy buffers with mmap(). > Furthermore, the DMA mask already is exposed in sysfs. > For example, the DMA mask for the host controller on bus 2 is > given in /sys/bus/usb/devices/usb2/../dma_mask_bits. I realize that this doesn't help much, since userspace can't get the physical address for its virtual addresses anyway. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] USB: zerocopy support for usbfs
Thank you very much for working on this, Stefan. Alan Stern wrote: > Also, many host controllers cannot handle arbitrary alignment. > It would be best to require that the buffer start at a page boundary. This requires a bit of negotiation with userspace, maybe per-URB but it seems better to negotiate per-claim or even per-open. What about large control transfers? > Using a global module parameter to control the use of zerocopy (for > anything other than debugging or testing) is a bad idea. I agree. > If you think people will have a reason for avoiding zerocopy then > you should make it possible to decide for each URB, by adding a new > flag to struct usbdevfs_urb. People might want to use zerocopy always, but have buffers in userspace which make that impossible with the given hardware. It's important that the kernel gives userspace enough information about the constraints, if userspace wants zerocopy. > People will want to use zerocopy with isochronous transfers as well as > bulk. Implementing that isn't going to be quite so easy; it will be > necessary for the user to set up a memory mapping. In fact, once > that's done the same mechanism could be used for bulk transfers too. Indeed I think userspace wants to be involved in choosing memory also with bulk, in order to ensure that zerocopy will always work when userspace cares about that. Is it enough to expose the DMA mask of the host controller? //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] USB: zerocopy support for usbfs
Thank you very much for working on this, Stefan. Alan Stern wrote: Also, many host controllers cannot handle arbitrary alignment. It would be best to require that the buffer start at a page boundary. This requires a bit of negotiation with userspace, maybe per-URB but it seems better to negotiate per-claim or even per-open. What about large control transfers? Using a global module parameter to control the use of zerocopy (for anything other than debugging or testing) is a bad idea. I agree. If you think people will have a reason for avoiding zerocopy then you should make it possible to decide for each URB, by adding a new flag to struct usbdevfs_urb. People might want to use zerocopy always, but have buffers in userspace which make that impossible with the given hardware. It's important that the kernel gives userspace enough information about the constraints, if userspace wants zerocopy. People will want to use zerocopy with isochronous transfers as well as bulk. Implementing that isn't going to be quite so easy; it will be necessary for the user to set up a memory mapping. In fact, once that's done the same mechanism could be used for bulk transfers too. Indeed I think userspace wants to be involved in choosing memory also with bulk, in order to ensure that zerocopy will always work when userspace cares about that. Is it enough to expose the DMA mask of the host controller? //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] USB: zerocopy support for usbfs
Alan Stern wrote: Also, many host controllers cannot handle arbitrary alignment. It would be best to require that the buffer start at a page boundary. This requires a bit of negotiation with userspace, maybe per-URB but I don't follow. What negotiation is needed? All that needs to happen is the user program submits a transfer where the buffer is aligned on a page boundary. The negotiation needed would be for userspace to learn what alignment is required, so that it can make sure to provide only such buffers. But see below on mmap.. it seems better to negotiate per-claim or even per-open. What about large control transfers? The kernel doesn't support scatter-gather for control transfers, only bulk. That could possibly change, right, and then it would be nice to have zerocopy for free there as well? It's important that the kernel gives userspace enough information about the constraints, if userspace wants zerocopy. I don't know of any way for the kernel to give userspace any information about constraints of this sort. Do you? I don't know of any at the moment, no. It might be done through an ioctl into usbfs, but if sysfs already has all neccessary information then no ioctl is needed. Anyway... Indeed I think userspace wants to be involved in choosing memory also with bulk, in order to ensure that zerocopy will always work when userspace cares about that. Is it enough to expose the DMA mask of the host controller? It doesn't need to be exposed, since the mmap(2) call would be handled by the kernel's USB stack (and besides, the user program can't request that the mapped memory be located in any particular physical address region). Since alignment isn't the only issue I don't think there's a way to avoid it. I was just hoping to be able to avoid allocating zerocopy buffers with mmap(). Furthermore, the DMA mask already is exposed in sysfs. For example, the DMA mask for the host controller on bus 2 is given in /sys/bus/usb/devices/usb2/../dma_mask_bits. I realize that this doesn't help much, since userspace can't get the physical address for its virtual addresses anyway. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
Philipp Hachtmann wrote: > This patch adds a sysfs attribute "cbus" which allows to set the > four CBUS pins on the FT232H. I think this should be implemented with the gpio subsystem instead. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
Philipp Hachtmann wrote: This patch adds a sysfs attribute cbus which allows to set the four CBUS pins on the FT232H. I think this should be implemented with the gpio subsystem instead. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ath9k-devel] [PATCH] net: wireless: wcn36xx: fix potential NULL pointer dereference
Michal Nazarewicz wrote:
> + wcn36xx_err("Run out of memory while hnadling SMD_EVENT
> (%d)\n",
> + msg_header->msg_type);
Typo hnadling.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ath9k-devel] [PATCH] net: wireless: wcn36xx: fix potential NULL pointer dereference
Michal Nazarewicz wrote: + wcn36xx_err(Run out of memory while hnadling SMD_EVENT (%d)\n, + msg_header-msg_type); Typo hnadling. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Finally eradicate CONFIG_HOTPLUG
Are you changing the code to have HOTPLUG always -on- or -off- ? From the commit message I had expected always -on-. Stephen Rothwell wrote: > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -68,14 +68,6 @@ > * are handled as text/data or they can be discarded (which > * often happens at runtime) > */ > -#ifdef CONFIG_HOTPLUG > -#define DEV_KEEP(sec)*(.dev##sec) > -#define DEV_DISCARD(sec) > -#else > -#define DEV_KEEP(sec) > -#define DEV_DISCARD(sec) *(.dev##sec) > -#endif > - > #ifdef CONFIG_HOTPLUG_CPU > #define CPU_KEEP(sec)*(.cpu##sec) > #define CPU_DISCARD(sec) > @@ -182,8 +174,6 @@ > *(.data)\ > *(.ref.data)\ > *(.data..shared_aligned) /* percpu related */ \ > - DEV_KEEP(init.data) \ > - DEV_KEEP(exit.data) \ .. > @@ -503,7 +489,6 @@ > /* init and exit section handling */ > #define INIT_DATA\ > *(.init.data) \ > - DEV_DISCARD(init.data) \ Shouldn't the effect of one of the above remain? //Peter pgp2JVo9aO0rd.pgp Description: PGP signature
Re: [PATCH] Finally eradicate CONFIG_HOTPLUG
Are you changing the code to have HOTPLUG always -on- or -off- ? From the commit message I had expected always -on-. Stephen Rothwell wrote: --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -68,14 +68,6 @@ * are handled as text/data or they can be discarded (which * often happens at runtime) */ -#ifdef CONFIG_HOTPLUG -#define DEV_KEEP(sec)*(.dev##sec) -#define DEV_DISCARD(sec) -#else -#define DEV_KEEP(sec) -#define DEV_DISCARD(sec) *(.dev##sec) -#endif - #ifdef CONFIG_HOTPLUG_CPU #define CPU_KEEP(sec)*(.cpu##sec) #define CPU_DISCARD(sec) @@ -182,8 +174,6 @@ *(.data)\ *(.ref.data)\ *(.data..shared_aligned) /* percpu related */ \ - DEV_KEEP(init.data) \ - DEV_KEEP(exit.data) \ .. @@ -503,7 +489,6 @@ /* init and exit section handling */ #define INIT_DATA\ *(.init.data) \ - DEV_DISCARD(init.data) \ Shouldn't the effect of one of the above remain? //Peter pgp2JVo9aO0rd.pgp Description: PGP signature
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Henrik Rydberg wrote: > Hi Hans, > > > Oh what fun (not). The best way to figure out what really is going > > on is to get some usb level traces. Note my first hunch is that what > > you're seeing is a device firmware bug, as this patch together with > > a new libusb (which you seem to also have) will make bulk transfers > > run slightly faster, which might be just enough to overwhelm your > > device ... > > Or, the large bulk transfer actually never worked in the first place. > The list you gave me seemed boringly long, so I read the patch more > closely instead. The fix below is the result. Greg, will you please > take it through your tree? > > Thanks, > Henrik > > From 40b70394747eea51fdd07cc8213dd6afd24b1b30 Mon Sep 17 00:00:00 2001 > From: Henrik Rydberg > Date: Thu, 11 Oct 2012 23:27:04 +0200 > Subject: [PATCH] usbdevfs: Fix broken scatter-gather transfer > > The recently introduced handling of large bulk transfers is completely > broken; the same user page is read over and over again. Fixed with > this patch. > > Cc: sta...@kernel.org > Signed-off-by: Henrik Rydberg Acked-by: Peter Stuge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Xiaofan Chen wrote: > On Thu, Oct 11, 2012 at 2:50 PM, Peter Stuge wrote: > > But it isn't certain that is is involved at all. If your impact > > version uses libusb.so like in ISE 11.1 then it will not be. One way > > to test is by trying to generate a libusb debug log. See > > https://libusb.org/wiki/debug for instructions which are for libusb, > > but which work also for libusbx since the code is nearly the same. > > (Just replace the repository to clone from.) > > Actually this is not that correct. For libusbx, you do not need > to rebuild libusbx to get the debug log at all, just need to > set environment variable LIBUSB_DEBUG=4 to get the > debug log. The configure option to completely disable logging is still present in libusbx, and I do not know which distributions use that, if any, so I prefer to recommend the method that is guaranteed to work. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Henrik Rydberg wrote: > > What is the programming cable and software that uses it? > > The programmer is impact, using libusbx-1.0.14-1. Do you know for a fact that your version calls libusb-1.0? Did you establish this with e.g. strace? ISE 11.1 impact uses only libusb.so, ie. libusb-0.1. Depending on what distribution you are using you may or may not have libusb-compat-0.1, without which the libusbx package isn't involved at all. Many distributions still ship libusb-0.1.12 or some patched variant thereof, which of course knows nothing about the kernel changes. > The patch is pretty generic, so I am suprised the problem has not > shown up earlier. There are several explanations. There is clearly a problem with Hans' patch(es) for some cases, but those are perhaps not so common. I've reviewed Hans' patch that he added to libusbx and which is in libusbx-1.0.14, but I am not sure that it is correct, which is why I haven't included it in libusb yet. But it isn't certain that is is involved at all. If your impact version uses libusb.so like in ISE 11.1 then it will not be. One way to test is by trying to generate a libusb debug log. See https://libusb.org/wiki/debug for instructions which are for libusb, but which work also for libusbx since the code is nearly the same. (Just replace the repository to clone from.) Another factor is the host controller. Is the device connected to a USB 3.0 port or a USB 2.0 port? USB 3.0 still has some gotchas which may or may not be what you are seeing. Looking forward to more information //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Henrik Rydberg wrote: What is the programming cable and software that uses it? The programmer is impact, using libusbx-1.0.14-1. Do you know for a fact that your version calls libusb-1.0? Did you establish this with e.g. strace? ISE 11.1 impact uses only libusb.so, ie. libusb-0.1. Depending on what distribution you are using you may or may not have libusb-compat-0.1, without which the libusbx package isn't involved at all. Many distributions still ship libusb-0.1.12 or some patched variant thereof, which of course knows nothing about the kernel changes. The patch is pretty generic, so I am suprised the problem has not shown up earlier. There are several explanations. There is clearly a problem with Hans' patch(es) for some cases, but those are perhaps not so common. I've reviewed Hans' patch that he added to libusbx and which is in libusbx-1.0.14, but I am not sure that it is correct, which is why I haven't included it in libusb yet. But it isn't certain that is is involved at all. If your impact version uses libusb.so like in ISE 11.1 then it will not be. One way to test is by trying to generate a libusb debug log. See https://libusb.org/wiki/debug for instructions which are for libusb, but which work also for libusbx since the code is nearly the same. (Just replace the repository to clone from.) Another factor is the host controller. Is the device connected to a USB 3.0 port or a USB 2.0 port? USB 3.0 still has some gotchas which may or may not be what you are seeing. Looking forward to more information //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Xiaofan Chen wrote: On Thu, Oct 11, 2012 at 2:50 PM, Peter Stuge pe...@stuge.se wrote: But it isn't certain that is is involved at all. If your impact version uses libusb.so like in ISE 11.1 then it will not be. One way to test is by trying to generate a libusb debug log. See https://libusb.org/wiki/debug for instructions which are for libusb, but which work also for libusbx since the code is nearly the same. (Just replace the repository to clone from.) Actually this is not that correct. For libusbx, you do not need to rebuild libusbx to get the debug log at all, just need to set environment variable LIBUSB_DEBUG=4 to get the debug log. The configure option to completely disable logging is still present in libusbx, and I do not know which distributions use that, if any, so I prefer to recommend the method that is guaranteed to work. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Henrik Rydberg wrote: Hi Hans, Oh what fun (not). The best way to figure out what really is going on is to get some usb level traces. Note my first hunch is that what you're seeing is a device firmware bug, as this patch together with a new libusb (which you seem to also have) will make bulk transfers run slightly faster, which might be just enough to overwhelm your device ... Or, the large bulk transfer actually never worked in the first place. The list you gave me seemed boringly long, so I read the patch more closely instead. The fix below is the result. Greg, will you please take it through your tree? Thanks, Henrik From 40b70394747eea51fdd07cc8213dd6afd24b1b30 Mon Sep 17 00:00:00 2001 From: Henrik Rydberg rydb...@euromail.se Date: Thu, 11 Oct 2012 23:27:04 +0200 Subject: [PATCH] usbdevfs: Fix broken scatter-gather transfer The recently introduced handling of large bulk transfers is completely broken; the same user page is read over and over again. Fixed with this patch. Cc: sta...@kernel.org Signed-off-by: Henrik Rydberg rydb...@euromail.se Acked-by: Peter Stuge pe...@stuge.se -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Hej Henrik, Henrik Rydberg wrote: > commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a > Author: Hans de Goede > Date: Wed Jul 4 09:18:03 2012 +0200 > > usbdevfs: Use scatter-gather lists for large bulk transfers > > breaks an usb programming cable over here. The problem is reported as > "bulk tranfer failed" [sic] by the tool, and bisection leads to this > commit. Reverting on top of 3.6 solves it for me. > > I am happy to test alternatives. In order to make full use of the new kernel commit you also need changes in libusb, if the tool uses libusb, but I agree that the kernel change must under no circumstance cause existing userland software to regress. What is the programming cable and software that uses it? //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers
Hej Henrik, Henrik Rydberg wrote: commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a Author: Hans de Goede hdego...@redhat.com Date: Wed Jul 4 09:18:03 2012 +0200 usbdevfs: Use scatter-gather lists for large bulk transfers breaks an usb programming cable over here. The problem is reported as bulk tranfer failed [sic] by the tool, and bisection leads to this commit. Reverting on top of 3.6 solves it for me. I am happy to test alternatives. In order to make full use of the new kernel commit you also need changes in libusb, if the tool uses libusb, but I agree that the kernel change must under no circumstance cause existing userland software to regress. What is the programming cable and software that uses it? //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
Rene Buergel wrote: > - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors Is this really the reason for the build error? I doubt it. Also, does the code in fact support only FX2, neither older chips nor newer FX3? > diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig > index 1bfcd02..bf7dc43 100644 > --- a/drivers/usb/misc/Kconfig > +++ b/drivers/usb/misc/Kconfig > @@ -244,3 +244,8 @@ config USB_YUREX > To compile this driver as a module, choose M here: the > module will be called yurex. > > +config USB_EZUSB_FX2 > + tristate "Functions for loading firmware on EZUSB chips" If only FX2 then I suggest mentioning that also in the immediately user-visible option description, not only in the help. > + help > + Say Y here if you need EZUSB device support. > + (Cypress FX/FX2/FX2LP microcontrollers) If FX is also supported then perhaps still rename the option, although I think renaming is unrelated to the build problems. I think it makes sense to call the option after the "highest" supported chip. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
Rene Buergel wrote: - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors Is this really the reason for the build error? I doubt it. Also, does the code in fact support only FX2, neither older chips nor newer FX3? diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig index 1bfcd02..bf7dc43 100644 --- a/drivers/usb/misc/Kconfig +++ b/drivers/usb/misc/Kconfig @@ -244,3 +244,8 @@ config USB_YUREX To compile this driver as a module, choose M here: the module will be called yurex. +config USB_EZUSB_FX2 + tristate Functions for loading firmware on EZUSB chips If only FX2 then I suggest mentioning that also in the immediately user-visible option description, not only in the help. + help + Say Y here if you need EZUSB device support. + (Cypress FX/FX2/FX2LP microcontrollers) If FX is also supported then perhaps still rename the option, although I think renaming is unrelated to the build problems. I think it makes sense to call the option after the highest supported chip. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter in Compliance Mode as per xHCI Spec, thus causing
> the port to become Unusable. This patch creates a timer which polls
> every 2 seconds the link state of each host controller's port (this
> by reading the PORTSC register) and recovers the port by issuing a
> Warm reset every time Compliance mode is detected. Since the issue
> is being caused by a pice of hardware, the timer will be enabled
Typo, insert an 'e' here ^
> +++ b/drivers/usb/host/xhci.c
..
> @@ -420,6 +477,12 @@ int xhci_init(struct usb_hcd *hcd)
> retval = xhci_mem_init(xhci, GFP_KERNEL);
> xhci_dbg(xhci, "Finished xhci_init\n");
>
> + /* Initializing Compliance Mode Recovery Data If Needed */
> + if (compliance_mode_recovery_timer_quirk_check()) {
> + xhci->quirks |= XHCI_COMP_MODE_QUIRK;
> + compliance_mode_recovery_timer_init(xhci);
> + }
> +
> return retval;
> }
Maybe add the code just *before* the "Finished" debug message rather
than after.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Hi Alexis,
Did you run the patch through checkpatch.pl before submitting it?
I think you will get a bunch of important and completely automatic
feedback when you do that. Please fix everything that the script
mentions.
Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter in Compliance Mode as per xHCI Spec. The patch
> creates a timer which polls every 2 seconds the link state of each
> host controller's port (this by reading the PORTSC register) and
> recovers the port by issuing a Warm reset every time Compliance mode
> is detected.
This is a pretty awful workaround for a teeny tiny hardware error.
You're making systems wake up every two seconds. I don't want that on
my system. I think making the timer settable would be nice.
Also, the patch does more things than what you describe. It adds a
new quirk, and it adds checks to set said quirk for various different
laptop models. Each of those changes (add timer+quirk, and add checks
to set quirk for laptops) should rather be a separate commit.
> @@ -645,6 +657,22 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
> u16 wValue,
> /* Update Port Link State for super speed ports*/
> if (hcd->speed == HCD_USB3) {
> xhci_hub_report_link_state(, temp);
> + /*
> + * Verify if all USB3 Ports Have entered U0. Delete
> compliance
> + * mode timer if so.
> + */
> + if (xhci->quirks & XHCI_COMP_MODE_QUIRK) {
> + if (xhci->port_status_u0 != ((1 <<
> xhci->num_usb3_ports)-1)) {
> + if ((temp & PORT_PLS_MASK) == XDEV_U0) {
> + xhci->port_status_u0 |= 1 <<
> wIndex;
> + if (xhci->port_status_u0 == ((1
> << xhci->num_usb3_ports)-1)) {
> +
> del_timer_sync(>comp_mode_recovery_timer);
> + xhci_dbg(xhci,
> "Compliance Mode Recovery Timer Deleted. "
> + "All
> USB3 ports have entered U0 at least once.\n");
> + }
> + }
> + }
> + }
> }
Is this style consistent with the surrounding code? I would be
surprised. The kernel frequently uses the "early exits" concept.
Please try to embrace it, I think it makes for lovely readable code.
A quote from
http://www.cranked.me/2008/07/spartan-programming-real-man-way-to-do.html
--8<--
Spartan programming strives for simultaneous minimization of all of
the following measures of code complexity:
1. horizontal complexity, that is, the depth of nesting of control
structures, just as the total line length.
..
8. conditionals, that is the number of if and multiple branch
switch statements.
-->8--
This may not be in http://kernel.org/doc/Documentation/CodingStyle
per se, but Chapter 7: Centralized exiting of functions touches on
the issue, includes an example, and I've found it used a lot in the
kernel code. It's a very good idea.
> +++ b/drivers/usb/host/xhci.h
> @@ -1494,6 +1494,7 @@ struct xhci_hcd {
> #define XHCI_TRUST_TX_LENGTH (1 << 10)
> #define XHCI_LPM_SUPPORT (1 << 11)
> #define XHCI_INTEL_HOST (1 << 12)
> +#define XHCI_COMP_MODE_QUIRK (1 << 13)
> unsigned intnum_active_eps;
> unsigned intlimit_active_eps;
> /* There are two roothubs to keep track of bus suspend info for */
> @@ -1510,6 +1511,11 @@ struct xhci_hcd {
> unsignedsw_lpm_support:1;
> /* support xHCI 1.0 spec USB2 hardware LPM */
> unsignedhw_lpm_support:1;
> + /* Compliance Mode Recovery Data */
> + struct timer_list comp_mode_recovery_timer;
> + u32 port_status_u0;
> +/* Compliance Mode Timer Triggered every 2 seconds */
> +#define COMP_MODE_RCVRY_MSECS 2000
I'm surprised how this get hardcoded from a header file.
I for one would like it to be settable.
Thanks
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Hi Alexis,
Did you run the patch through checkpatch.pl before submitting it?
I think you will get a bunch of important and completely automatic
feedback when you do that. Please fix everything that the script
mentions.
Alexis R. Cortes wrote:
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout,
and if that happens on the first insertion, the host controller
port will enter in Compliance Mode as per xHCI Spec. The patch
creates a timer which polls every 2 seconds the link state of each
host controller's port (this by reading the PORTSC register) and
recovers the port by issuing a Warm reset every time Compliance mode
is detected.
This is a pretty awful workaround for a teeny tiny hardware error.
You're making systems wake up every two seconds. I don't want that on
my system. I think making the timer settable would be nice.
Also, the patch does more things than what you describe. It adds a
new quirk, and it adds checks to set said quirk for various different
laptop models. Each of those changes (add timer+quirk, and add checks
to set quirk for laptops) should rather be a separate commit.
@@ -645,6 +657,22 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
/* Update Port Link State for super speed ports*/
if (hcd-speed == HCD_USB3) {
xhci_hub_report_link_state(status, temp);
+ /*
+ * Verify if all USB3 Ports Have entered U0. Delete
compliance
+ * mode timer if so.
+ */
+ if (xhci-quirks XHCI_COMP_MODE_QUIRK) {
+ if (xhci-port_status_u0 != ((1
xhci-num_usb3_ports)-1)) {
+ if ((temp PORT_PLS_MASK) == XDEV_U0) {
+ xhci-port_status_u0 |= 1
wIndex;
+ if (xhci-port_status_u0 == ((1
xhci-num_usb3_ports)-1)) {
+
del_timer_sync(xhci-comp_mode_recovery_timer);
+ xhci_dbg(xhci,
Compliance Mode Recovery Timer Deleted.
+ All
USB3 ports have entered U0 at least once.\n);
+ }
+ }
+ }
+ }
}
Is this style consistent with the surrounding code? I would be
surprised. The kernel frequently uses the early exits concept.
Please try to embrace it, I think it makes for lovely readable code.
A quote from
http://www.cranked.me/2008/07/spartan-programming-real-man-way-to-do.html
--8--
Spartan programming strives for simultaneous minimization of all of
the following measures of code complexity:
1. horizontal complexity, that is, the depth of nesting of control
structures, just as the total line length.
..
8. conditionals, that is the number of if and multiple branch
switch statements.
--8--
This may not be in http://kernel.org/doc/Documentation/CodingStyle
per se, but Chapter 7: Centralized exiting of functions touches on
the issue, includes an example, and I've found it used a lot in the
kernel code. It's a very good idea.
+++ b/drivers/usb/host/xhci.h
@@ -1494,6 +1494,7 @@ struct xhci_hcd {
#define XHCI_TRUST_TX_LENGTH (1 10)
#define XHCI_LPM_SUPPORT (1 11)
#define XHCI_INTEL_HOST (1 12)
+#define XHCI_COMP_MODE_QUIRK (1 13)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
@@ -1510,6 +1511,11 @@ struct xhci_hcd {
unsignedsw_lpm_support:1;
/* support xHCI 1.0 spec USB2 hardware LPM */
unsignedhw_lpm_support:1;
+ /* Compliance Mode Recovery Data */
+ struct timer_list comp_mode_recovery_timer;
+ u32 port_status_u0;
+/* Compliance Mode Timer Triggered every 2 seconds */
+#define COMP_MODE_RCVRY_MSECS 2000
I'm surprised how this get hardcoded from a header file.
I for one would like it to be settable.
Thanks
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Alexis R. Cortes wrote:
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout,
and if that happens on the first insertion, the host controller
port will enter in Compliance Mode as per xHCI Spec, thus causing
the port to become Unusable. This patch creates a timer which polls
every 2 seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected. Since the issue
is being caused by a pice of hardware, the timer will be enabled
Typo, insert an 'e' here ^
+++ b/drivers/usb/host/xhci.c
..
@@ -420,6 +477,12 @@ int xhci_init(struct usb_hcd *hcd)
retval = xhci_mem_init(xhci, GFP_KERNEL);
xhci_dbg(xhci, Finished xhci_init\n);
+ /* Initializing Compliance Mode Recovery Data If Needed */
+ if (compliance_mode_recovery_timer_quirk_check()) {
+ xhci-quirks |= XHCI_COMP_MODE_QUIRK;
+ compliance_mode_recovery_timer_init(xhci);
+ }
+
return retval;
}
Maybe add the code just *before* the Finished debug message rather
than after.
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Fri, Jan 11, 2008 at 12:42:40PM +0900, Paul Mundt wrote: > How about throwing out hand-rolled debug printk wrappers for the > brain-damage they are and using the ones the kernel provides > instead? Sounds great! //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> +#define DEBUG(x, args...)printk("%s: ", __func__, x, ##args)
Can this really be expected to work when x contains conversions?
How about:
#define DEBUG(x, args...) printk("%s: " x, __func__, ##args)
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote: -#define DEBUG(x,args...) printk(__FUNCTION__ : x,##args) +#define DEBUG(x, args...)printk(%s: , __func__, x, ##args) Can this really be expected to work when x contains conversions? How about: #define DEBUG(x, args...) printk(%s: x, __func__, ##args) //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Fri, Jan 11, 2008 at 12:42:40PM +0900, Paul Mundt wrote: How about throwing out hand-rolled debug printk wrappers for the brain-damage they are and using the ones the kernel provides instead? Sounds great! //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
Please stop cross-posting this thread at least to linux-pcmcia until your post is relevant to PCMCIA. Sorry for being a bore. (Not that I don't love reading LKML discussions, but I found that it took too much time, and now they're over at linux-pcmcia too! :) Thank you in advance. //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
Please stop cross-posting this thread at least to linux-pcmcia until your post is relevant to PCMCIA. Sorry for being a bore. (Not that I don't love reading LKML discussions, but I found that it took too much time, and now they're over at linux-pcmcia too! :) Thank you in advance. //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote: > > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 > > As of 2.6.23-rc2, we should have: > - probes for 8250 legacy devices (as in 2.6.21 and previous) > - smsc PNP probes turned off by default (2.6.21 and previous had > no PNP probes for smsc at all) > - some complicated PNP quirks for SMCf010 devices > > In other words, I think we're basically back where we started. The > 8250 driver should find a ttyS3 device at 0x2e8, and it should > claim those ports, which will prevent smsc from claiming them. I use 8250.nr_uarts=1 appended to my kernel parameters on my laptop. Perfectly reliable workaround, but if it is possible to detect, then all the better! //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote: [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 As of 2.6.23-rc2, we should have: - probes for 8250 legacy devices (as in 2.6.21 and previous) - smsc PNP probes turned off by default (2.6.21 and previous had no PNP probes for smsc at all) - some complicated PNP quirks for SMCf010 devices In other words, I think we're basically back where we started. The 8250 driver should find a ttyS3 device at 0x2e8, and it should claim those ports, which will prevent smsc from claiming them. I use 8250.nr_uarts=1 appended to my kernel parameters on my laptop. Perfectly reliable workaround, but if it is possible to detect, then all the better! //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Fri, Apr 27, 2007 at 07:01:43PM -0700, Andrew Morton wrote:
> This one-liner is turning into a fiasco.
> diff -puN
> drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend
> drivers/ide/legacy/ide-cs.c
> ---
> a/drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend
> +++ a/drivers/ide/legacy/ide-cs.c
> @@ -401,6 +401,8 @@ static struct pcmcia_device_id ide_ids[]
> PCMCIA_DEVICE_PROD_ID12("TOSHIBA", "MK2001MPL", 0xb4585a1a, 0x3489e003),
> PCMCIA_DEVICE_PROD_ID1("TRANSCEND512M ", 0xd0909443),
> PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS1GCF80", 0x709b1bf1,
> 0x2a54d4b1),
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0xf54a91c8),
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0x969aa4f2),
> PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS4GCF120", 0x709b1bf1,
> 0xf54a91c8),
> PCMCIA_DEVICE_PROD_ID12("WIT", "IDE16", 0x244e5994, 0x3e232852),
> PCMCIA_DEVICE_PROD_ID12("WEIDA", "TWTTI", 0xcc7cf69c, 0x212bb918),
> _
>
>
> Is this really supposed to add a TS2GCF120 entry with the same IDs
> as TS4GCF120?
That's probably a copy and paste error. 0x969aa4f2 is the correct ID.
> And pata_pcmcia-recognize-2gb-compactflash-from-transcend.patch:
This one is all right so for what it's worth, it gets:
Acked-by: Peter Stuge <[EMAIL PROTECTED]>
//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Fri, Apr 27, 2007 at 07:01:43PM -0700, Andrew Morton wrote: This one-liner is turning into a fiasco. diff -puN drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend drivers/ide/legacy/ide-cs.c --- a/drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend +++ a/drivers/ide/legacy/ide-cs.c @@ -401,6 +401,8 @@ static struct pcmcia_device_id ide_ids[] PCMCIA_DEVICE_PROD_ID12(TOSHIBA, MK2001MPL, 0xb4585a1a, 0x3489e003), PCMCIA_DEVICE_PROD_ID1(TRANSCEND512M , 0xd0909443), PCMCIA_DEVICE_PROD_ID12(TRANSCEND, TS1GCF80, 0x709b1bf1, 0x2a54d4b1), + PCMCIA_DEVICE_PROD_ID12(TRANSCEND, TS2GCF120, 0x709b1bf1, 0xf54a91c8), + PCMCIA_DEVICE_PROD_ID12(TRANSCEND, TS2GCF120, 0x709b1bf1, 0x969aa4f2), PCMCIA_DEVICE_PROD_ID12(TRANSCEND, TS4GCF120, 0x709b1bf1, 0xf54a91c8), PCMCIA_DEVICE_PROD_ID12(WIT, IDE16, 0x244e5994, 0x3e232852), PCMCIA_DEVICE_PROD_ID12(WEIDA, TWTTI, 0xcc7cf69c, 0x212bb918), _ Is this really supposed to add a TS2GCF120 entry with the same IDs as TS4GCF120? That's probably a copy and paste error. 0x969aa4f2 is the correct ID. And pata_pcmcia-recognize-2gb-compactflash-from-transcend.patch: This one is all right so for what it's worth, it gets: Acked-by: Peter Stuge [EMAIL PROTECTED] //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Wed, Apr 25, 2007 at 11:27:09AM +0200, Aeschbacher, Fabrice wrote:
> I'm not sure which correct values must be assigned to the 3th and
> 4th parameters (here: 0x709b1bf1, 0xf54a91c8). Anyway, the patch is
> working with these values. Tested on arch=mips.
>
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0xf54a91c8),
According to /usr/src/linux/Documentation/pcmcia/devicetable.txt and
crc32hash.c the 4th parameter should be 0x969aa4f2.
//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Wed, Apr 25, 2007 at 11:27:09AM +0200, Aeschbacher, Fabrice wrote: I'm not sure which correct values must be assigned to the 3th and 4th parameters (here: 0x709b1bf1, 0xf54a91c8). Anyway, the patch is working with these values. Tested on arch=mips. + PCMCIA_DEVICE_PROD_ID12(TRANSCEND, TS2GCF120, 0x709b1bf1, 0xf54a91c8), According to /usr/src/linux/Documentation/pcmcia/devicetable.txt and crc32hash.c the 4th parameter should be 0x969aa4f2. //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote: > It works in LinuxBIOS now. Cool, can't wait to try it out. Good work! //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote: It works in LinuxBIOS now. Cool, can't wait to try it out. Good work! //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote: > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 06, 2006 12:59 PM > > >I haven't looked how the other usb_debug works -- if it's polled > >too then it wouldn't have much advantage. > > Need to verify if the two sides of debug cable are identical. I got my device yesterday and after a small plugfest I can confirm that only one end of the device enumerates when connected to an ICH7 EHCI driven by 2.6.19. --8<-- Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x127a bcdDevice1.01 iManufacturer 1 NetChip iProduct2 NetChip TurboCONNECT 2.0 iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Debug descriptor: bLength 4 bDescriptorType10 bDebugInEndpoint 0x82 bDebugOutEndpoint0x01 -->8-- The device is in fact not self-powered. My theory is that the same set of descriptors are used for both ends, but one end has been locked to address 127 in order to work with simpler debug port drivers that assume it will be there. I guess that the self-powered error is also to simplify life for debug port drivers. IIRC most if not all USB power management concerns are noops for debug ports. //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote: -Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 12:59 PM I haven't looked how the other usb_debug works -- if it's polled too then it wouldn't have much advantage. Need to verify if the two sides of debug cable are identical. I got my device yesterday and after a small plugfest I can confirm that only one end of the device enumerates when connected to an ICH7 EHCI driven by 2.6.19. --8-- Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x127a bcdDevice1.01 iManufacturer 1 NetChip iProduct2 NetChip TurboCONNECT 2.0 iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Debug descriptor: bLength 4 bDescriptorType10 bDebugInEndpoint 0x82 bDebugOutEndpoint0x01 --8-- The device is in fact not self-powered. My theory is that the same set of descriptors are used for both ends, but one end has been locked to address 127 in order to work with simpler debug port drivers that assume it will be there. I guess that the self-powered error is also to simplify life for debug port drivers. IIRC most if not all USB power management concerns are noops for debug ports. //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote: > >> Sure, I will send it out shortly. I currently have a working > >> user space libusb thing (easy, but useful for my debug) > > > > Hm - for driving which end? > > Either. The specific device we are talking about doesn't care. Which device do you have? > > The debug port isn't really supposed to be used with anything but > > a debug device - which can't be enumerated normally anyway. > > It depends. If you have a debug cable with magic ends and a > hardcoded address of 127 the normal enumeration doesn't work. I > don't think anyone actually makes one of those. Only one of the ports on Stefan's PLX NET20DC that I had a look at during the LinuxBIOS symposium enumerated for me. > Debug devices are also allowed to be normal devices that just > support the debug descriptor. Which is what I'm working with. Aye. I would be happy if we could get something out, as you have done! :) Looking forward to trying it, I hope I get my device soon. //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote: Sure, I will send it out shortly. I currently have a working user space libusb thing (easy, but useful for my debug) Hm - for driving which end? Either. The specific device we are talking about doesn't care. Which device do you have? The debug port isn't really supposed to be used with anything but a debug device - which can't be enumerated normally anyway. It depends. If you have a debug cable with magic ends and a hardcoded address of 127 the normal enumeration doesn't work. I don't think anyone actually makes one of those. Only one of the ports on Stefan's PLX NET20DC that I had a look at during the LinuxBIOS symposium enumerated for me. Debug devices are also allowed to be normal devices that just support the debug descriptor. Which is what I'm working with. Aye. I would be happy if we could get something out, as you have done! :) Looking forward to trying it, I hope I get my device soon. //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
> Right. For LinuxBIOS not a problem for earlyprintk in the kernel
> somethings might need to be refactored. The challenge in the
> kernel is we don't know at build to how to do a pci_read_config...
>
> The other hard part early in the kernel is the fact that the
> bar is memory mapped I/O. Which means it will need to get mapped
> into the kernels page tables.
I see.
> >> And I have some code that barely works for this already, perhaps
> >> Eric and I should work together on this :)
> >
> > I would be interested in having a look at any code for it too.
>
> Sure, I will send it out shortly. I currently have a working
> user space libusb thing (easy, but useful for my debug)
Hm - for driving which end?
> and a rude read/write to the bar from user space program that
How does that work? /dev/{port,mem}?
> allowed me to debug the worst of the state machine from user
> space. I don't think I have the state setup logic correct yet
> but that is minor in comparison.
>
> I really wish the EHCI spec had made that stupid interface 16 bytes
> instead of 8 or had a way to chain multiple access together. The
> we could have used a normal usb cable. As it is most descriptors
> are 1 byte to big to read.
Which descriptors are you reading?
The debug port isn't really supposed to be used with anything but a
debug device - which can't be enumerated normally anyway.
//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote: > Well, earlyprintk will not work, as you need PCI up and running. Not all of it though. LinuxBIOS will probably do just enough PCI setup to talk to the EHCI controller and use the debug port _very_ soon after power on. > And I have some code that barely works for this already, perhaps > Eric and I should work together on this :) I would be interested in having a look at any code for it too. > Yes, that will work just fine today using the usb-serial generic > driver. Ugh. I did not know it was that generic. The irony is that I always ask other libusb users to check the kernel drivers to see if they really need to write a libusb app. > I'll knock up a "real" driver for the device later today and send > it to Linus, as it's trivial to do so, and will make it simpler > than using the module parameters. Awesome. Thanks! //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 10:41:23AM -0800, Greg KH wrote: > On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote: > > Anyone is working on creating one usb_serial_driver for USB debug > > device without using host debug port? > > I can do that in about 15 minutes if you give me the device ids for > the usb debug device that you wish to have. The host (aka remote) end of the NET20DC debug device has vid 0x0525 and pid 0x127a. > Or you can also use the generic usb-serial driver today just fine > with no modification. Have you had a problem with using that > option? Does it check for a debug descriptor and attach to the device if one is found? Neat! //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 10:41:23AM -0800, Greg KH wrote: On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote: Anyone is working on creating one usb_serial_driver for USB debug device without using host debug port? I can do that in about 15 minutes if you give me the device ids for the usb debug device that you wish to have. The host (aka remote) end of the NET20DC debug device has vid 0x0525 and pid 0x127a. Or you can also use the generic usb-serial driver today just fine with no modification. Have you had a problem with using that option? Does it check for a debug descriptor and attach to the device if one is found? Neat! //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote: Well, earlyprintk will not work, as you need PCI up and running. Not all of it though. LinuxBIOS will probably do just enough PCI setup to talk to the EHCI controller and use the debug port _very_ soon after power on. And I have some code that barely works for this already, perhaps Eric and I should work together on this :) I would be interested in having a look at any code for it too. Yes, that will work just fine today using the usb-serial generic driver. Ugh. I did not know it was that generic. The irony is that I always ask other libusb users to check the kernel drivers to see if they really need to write a libusb app. I'll knock up a real driver for the device later today and send it to Linus, as it's trivial to do so, and will make it simpler than using the module parameters. Awesome. Thanks! //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
Right. For LinuxBIOS not a problem for earlyprintk in the kernel
somethings might need to be refactored. The challenge in the
kernel is we don't know at build to how to do a pci_read_config...
The other hard part early in the kernel is the fact that the
bar is memory mapped I/O. Which means it will need to get mapped
into the kernels page tables.
I see.
And I have some code that barely works for this already, perhaps
Eric and I should work together on this :)
I would be interested in having a look at any code for it too.
Sure, I will send it out shortly. I currently have a working
user space libusb thing (easy, but useful for my debug)
Hm - for driving which end?
and a rude read/write to the bar from user space program that
How does that work? /dev/{port,mem}?
allowed me to debug the worst of the state machine from user
space. I don't think I have the state setup logic correct yet
but that is minor in comparison.
I really wish the EHCI spec had made that stupid interface 16 bytes
instead of 8 or had a way to chain multiple access together. The
we could have used a normal usb cable. As it is most descriptors
are 1 byte to big to read.
Which descriptors are you reading?
The debug port isn't really supposed to be used with anything but a
debug device - which can't be enumerated normally anyway.
//Peter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
