Re: [PATCH v8] usb_8dev: Add support for USB2CAN interface from 8 devices
On 15.12.2012 07:53, Bernd Krumboeck wrote: > +++ b/Documentation/ABI/testing/sysfs-driver-usb_8dev > @@ -0,0 +1,13 @@ > +What:/sys/bus/usb/devices/-: num>./firmware > +Date:December 2012 > +Contact: Bernd Krumboeck > +Description: > + Returns the firmware version in the form ".". > + This file is readonly. > + > +What:/sys/bus/usb/devices/-: num>./hardware > +Date:December 2012 > +Contact: Bernd Krumboeck > +Description: > + Returns the hardware version in the form ".". > + This file is readonly. Hello Bernd, sorry but probably i missed the discussion about this point: Why do your create some extra sysfs entries for plain static information that could be retrieved from the syslog too? E.g. when attaching the PCAN USB, i get this: usb 2-1.3: new full-speed USB device number 6 using ehci-pci usb 2-1.3: New USB device found, idVendor=0c72, idProduct=000c usb 2-1.3: New USB device strings: Mfr=0, Product=3, SerialNumber=0 usb 2-1.3: Product: VER1:PEAK VER2:02.8.01 DAT :06.05.2004 TIME:09:35:37 ... peak_usb 2-1.3:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial (1 channel) peak_usb 2-1.3:1.0 can2: attached to PCAN-USB channel 0 (device 67) usbcore: registered new interface driver peak_usb Don't you think it's a better idea to add an additional line to the syslog telling about this *static* hw/sw information than adding the extra complexity and documentation for the sysfs handling? 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
[Suggestion] drivers/usb/host/ohci* : not setting urb->hcpriv = NULL after kfree it.
Hello Alan Stern:
in drivers/usb/host/ohci-q.c, function finish_urb:
when we finish call urb_free_priv, we not set urb->hcpriv = NULL (line 46)
urb_free_priv call kfree for urb_priv (which is urb->hcpriv, line 29)
within finish_urb, we not set urb->hcpriv = NULL (line 43..81)
in drivers/usb/host/ohci-hdc.c, function ohci_urb_dequeue:
it judges urb->hcpriv == NULL to decide whether call finish_urb (line
317..322)
within ohci_urb_dequeue, we not set urb->hcpriv = NULL (line 321..326)
another functions (finish_unlinks, takeback_td...), can call finish_urb,
too.
they do not set urb->hcpriv = NULL, either.
they do not judge urb->hcpriv == NULL before calling finish_urb.
although I can not say it is surely a bug.
I still suggest:
in finish_urb, set urb->hcpriv = NULL, after finish calling urb_free_priv.
in urb_free_priv, better to judge whether urb_priv == NULL, firstly.
thanks.
gchen.
drivers/usb/host/ohci-q.c:
13 static void urb_free_priv (struct ohci_hcd *hc, urb_priv_t *urb_priv)
14 {
15 int last = urb_priv->length - 1;
16
17 if (last >= 0) {
18 int i;
19 struct td *td;
20
21 for (i = 0; i <= last; i++) {
22 td = urb_priv->td [i];
23 if (td)
24 td_free (hc, td);
25 }
26 }
27
28 list_del (&urb_priv->pending);
29 kfree (urb_priv);
30 }
31
32
/*-*/
33
34 /*
35 * URB goes back to driver, and isn't reissued.
36 * It's completely gone from HC data structures.
37 * PRECONDITION: ohci lock held, irqs blocked.
38 */
39 static void
40 finish_urb(struct ohci_hcd *ohci, struct urb *urb, int status)
41 __releases(ohci->lock)
42 __acquires(ohci->lock)
43 {
44 // ASSERT (urb->hcpriv != 0);
45
46 urb_free_priv (ohci, urb->hcpriv);
47 if (likely(status == -EINPROGRESS))
48 status = 0;
49
50 switch (usb_pipetype (urb->pipe)) {
51 case PIPE_ISOCHRONOUS:
52 ohci_to_hcd(ohci)->self.bandwidth_isoc_reqs--;
53 if (ohci_to_hcd(ohci)->self.bandwidth_isoc_reqs == 0) {
54 if (quirk_amdiso(ohci))
55 usb_amd_quirk_pll_enable();
56 if (quirk_amdprefetch(ohci))
57 sb800_prefetch(ohci, 0);
58 }
59 break;
60 case PIPE_INTERRUPT:
61 ohci_to_hcd(ohci)->self.bandwidth_int_reqs--;
62 break;
63 }
64
65 #ifdef OHCI_VERBOSE_DEBUG
66 urb_print(urb, "RET", usb_pipeout (urb->pipe), status);
67 #endif
68
69 /* urb->complete() can reenter this HCD */
70 usb_hcd_unlink_urb_from_ep(ohci_to_hcd(ohci), urb);
71 spin_unlock (&ohci->lock);
72 usb_hcd_giveback_urb(ohci_to_hcd(ohci), urb, status);
73 spin_lock (&ohci->lock);
74
75 /* stop periodic dma if it's not needed */
76 if (ohci_to_hcd(ohci)->self.bandwidth_isoc_reqs == 0
77 && ohci_to_hcd(ohci)->self.bandwidth_int_reqs ==
0) {
78 ohci->hc_control &= ~(OHCI_CTRL_PLE|OHCI_CTRL_IE);
79 ohci_writel (ohci, ohci->hc_control, &ohci->regs->control);
80 }
81 }
...
in drivers/usb/host/ohci-hcd.c
290 static int ohci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int
status)
291 {
292 struct ohci_hcd *ohci = hcd_to_ohci (hcd);
293 unsigned long flags;
294 int rc;
295
296 #ifdef OHCI_VERBOSE_DEBUG
297 urb_print(urb, "UNLINK", 1, status);
298 #endif
299
300 spin_lock_irqsave (&ohci->lock, flags);
301 rc = usb_hcd_check_unlink_urb(hcd, urb, status);
302 if (rc) {
303 ; /* Do nothing */
304 } else if (ohci->rh_state == OHCI_RH_RUNNING) {
305 urb_priv_t *urb_priv;
306
307 /* Unless an IRQ completed the unlink while it was being
308 * handed to us, flag it for unlink and giveback, and force
309 * some upcoming INTR_SF to call finish_unlinks()
310 */
311 urb_priv = urb->hcpriv;
312 if (urb_priv) {
313 if (urb_priv->ed->state == ED_OPER)
314 start_ed_unlink (ohci, urb_priv->ed);
315 }
316 } else {
317 /*
318 * with HC dead, we won't respect hc queue pointers
319 * any more ... just clean up every urb's memory.
320
Re: [PATCH v8] usb_8dev: Add support for USB2CAN interface from 8 devices
This informations could be useful for configuration scripts. Various drivers do the same. regards, Bernd 2012/12/15 Oliver Hartkopp On 15.12.2012 07:53, Bernd Krumboeck wrote: > +++ b/Documentation/ABI/testing/sysfs-driver-usb_8dev > @@ -0,0 +1,13 @@ > +What:/sys/bus/usb/devices/-:./firmware > +Date:December 2012 > +Contact: Bernd Krumboeck > +Description: > + Returns the firmware version in the form ".". > + This file is readonly. > + > +What:/sys/bus/usb/devices/-:./hardware > +Date:December 2012 > +Contact: Bernd Krumboeck > +Description: > + Returns the hardware version in the form ".". > + This file is readonly. Hello Bernd, sorry but probably i missed the discussion about this point: Why do your create some extra sysfs entries for plain static information that could be retrieved from the syslog too? E.g. when attaching the PCAN USB, i get this: usb 2-1.3: new full-speed USB device number 6 using ehci-pci usb 2-1.3: New USB device found, idVendor=0c72, idProduct=000c usb 2-1.3: New USB device strings: Mfr=0, Product=3, SerialNumber=0 usb 2-1.3: Product: VER1:PEAK VER2:02.8.01 DAT :06.05.2004 TIME:09:35:37 ... peak_usb 2-1.3:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial (1 channel) peak_usb 2-1.3:1.0 can2: attached to PCAN-USB channel 0 (device 67) usbcore: registered new interface driver peak_usb Don't you think it's a better idea to add an additional line to the syslog telling about this *static* hw/sw information than adding the extra complexity and documentation for the sysfs handling? 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 v8] usb_8dev: Add support for USB2CAN interface from 8 devices
On 12/15/2012 11:12 AM, "Bernd Krumböck" wrote: > This informations could be useful for configuration scripts. Various > drivers do the same. Well, "could be" is not a strong argument. Is there a real use-case? If not I'm also in favor of removing these entries, as I already said. Wolfgang. -- 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_8dev: Add support for USB2CAN interface from 8 devices
> On 12/15/2012 11:12 AM, "Bernd Krumböck" wrote: >> This informations could be useful for configuration scripts. Various >> drivers do the same. > > Well, "could be" is not a strong argument. Is there a real use-case? If > not I'm also in favor of removing these entries, as I already said. > Ok, I'll remove... regards, Bernd -- 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 4/4] regulator: fixed: Properly use input_supply parameter from device tree
On Fri, Nov 16, 2012 at 12:23:43PM +0200, Roger Quadros wrote: > How is this supposed to work? How does phandle supplied in vin-supply > map to config->input_supply? You should provide a separate property to name the supply, or just pick a fixed name in the fixed voltage driver. signature.asc Description: Digital signature
Re: USB issue with kernel 3.6
On Fri, Dec 14, 2012 at 11:02:07AM -0500, Alan Stern wrote:
> On Mon, 10 Dec 2012, Piergiorgio Sartor wrote:
>
> > > Here's an idea. This just occurred to me. Maybe when the driver is
> > > waiting for the async schedule to turn off, new QH's should not be
> > > added to the schedule. The driver could wait and add them after the
> > > schedule was off. I didn't do it that way because it would slow things
> > > down and add complexity, but maybe that's what the nVidia hardware
> > > needs.
> >
> > How difficult is it?
> > Would it be possible to have as a patch I could try?
>
> Instead of doing this, I wrote a simpler patch that removes the limit
> on the number of polls. It also writes a debugging message whenever
> more than 20 ms of polling is needed, so we can see what your
> controller is actually doing.
Hi Alan,
thanks for the patch, I applied it and tested.
I've bad news...
Unless I made some mistake (which can always be), I did not
see any of the logs of this patch in the output, despite
having seen the problem occuring (this time I used "cpuburn"
to overload the system).
The only reasonable log was like the previous one:
[ 248.833978] ehci_hcd :00:0b.1: alan start cur time 4294916032 last scan
4294885464
[ 248.833991] ehci_hcd :00:0b.1: command 10035 cmd reg 10075 io watchdog 1
async count 10
[ 248.833998] ehci_hcd :00:0b.1: async list:
[ 248.834006] ehci_hcd :00:0b.1: qh 880149fcfe00 hw 8800af80
dma af80 next 880146d70380 hw_next af8009c2
[ 248.834013] ehci_hcd :00:0b.1: qh 880146d70380 hw 8800af8009c0
dma af8009c0 next 880146c95b00 hw_next af800a82
[ 248.834020] ehci_hcd :00:0b.1: qh 880146c95b00 hw 8800af800a80
dma af800a80 next 880149b51f00 hw_next af800cc2
[ 248.834027] ehci_hcd :00:0b.1: qh 880149b51f00 hw 8800af800cc0
dma af800cc0 next 880145d17e80 hw_next af800f02
[ 248.834033] ehci_hcd :00:0b.1: qh 880145d17e80 hw 8800af800f00
dma af800f00 next 88013d137180 hw_next af800c02
[ 248.834040] ehci_hcd :00:0b.1: qh 88013d137180 hw 8800af800c00
dma af800c00 next 880148bc hw_next af800d82
[ 248.834046] ehci_hcd :00:0b.1: qh 880148bc hw 8800af800d80
dma af800d80 next 8801410f9f00 hw_next af800b42
[ 248.834053] ehci_hcd :00:0b.1: qh 8801410f9f00 hw 8800af800b40
dma af800b40 next 880147b8bc80 hw_next af8007e2
[ 248.834060] ehci_hcd :00:0b.1: qh 880147b8bc80 hw 8800af8007e0
dma af8007e0 next 880140b49180 hw_next af800e42
[ 248.834066] ehci_hcd :00:0b.1: qh 880140b49180 hw 8800af800e40
dma af800e40 next 880141f8ac00 hw_next af8008a2
[ 248.834073] ehci_hcd :00:0b.1: qh 880141f8ac00 hw 8800af8008a0
dma af8008a0 next (null) hw_next af82
[ 248.834080] ehci_hcd :00:0b.1: This qh link time 4294885466 enqueue time
4294885466 td token 1f8c80 ov token 0
[ 248.834087] ehci_hcd :00:0b.1: qh 880146d70380 naf800a82 info
42002210 4000 qtd af81ccc0
[ 248.834095] ehci_hcd :00:0b.1: overlay td 8800af8009d0 nae2531e0
0001 t p0=af87fa9f
[ 248.834103] ehci_hcd :00:0b.1: dma ae2531e0 td 8800ae2531e0
naf81ef60 0001 t001f8c80 p0=af87fa80
[ 248.834111] ehci_hcd :00:0b.1: dummy af81ef60 td 8800af81ef60
n0001 0001 t0040 p0=
[ 248.845154] ehci_hcd :00:0b.1: giveback urb 88014980dcc0 actual 0
[ 248.845162] ehci_hcd :00:0b.1: alan end
Note that there was not anymore the log line before "alan start".
I suspect the previous error was something else, maybe something
it happens seldom, since sometimes I saw some timeout errors, but
they were almost always not a problem.
Any ideas?
Thanks again,
bye,
pg
>
> Alan Stern
>
>
>
>
> Index: usb-3.7/drivers/usb/host/ehci-timer.c
> ===
> --- usb-3.7.orig/drivers/usb/host/ehci-timer.c
> +++ usb-3.7/drivers/usb/host/ehci-timer.c
> @@ -113,14 +113,15 @@ static void ehci_poll_ASS(struct ehci_hc
>
> if (want != actual) {
>
> - /* Poll again later, but give up after about 20 ms */
> - if (ehci->ASS_poll_count++ < 20) {
> - ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true);
> - return;
> - }
> - ehci_dbg(ehci, "Waited too long for the async schedule status
> (%x/%x), giving up\n",
> - want, actual);
> + /* Poll again later */
> + ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true);
> + ++ehci->ASS_poll_count;
> + return;
> }
> +
> + if (ehci->ASS_poll_count > 20)
> + ehci_dbg(ehci, "ASS poll count reached %d\n",
> + ehci->ASS_poll_count);
> ehci->ASS_poll_count = 0;
>
> /* The status is up-to-date; restart or stop the sch
Re: [Suggestion] drivers/usb/host/uhci* : sprintf, need check len when use buf
On Sat, 15 Dec 2012, Chen Gang wrote: > 于 2012年12月14日 23:46, Alan Stern 写道: > > > > The easiest fix is to increase MAX_OUTPUT. Can you figure out how > > large it needs to be? > > > for me, it seems only increasing MAX_OUTPUT is not a good idea. > > maybe we can reference usb_device_dump: > it processes the same thing in a simple way. > it is in drivers/usb/core/devices.c > function usb_device_dump calls function usb_dump_desc > and function usb_dump_desc calls another dump functions. > usb_device_dump also has to recuse call itself to process a tree. > > > > I'm not concerned with making this code absolutely 100% reliable. It > > is used only for debugging; in almost all kernel builds it will not be > > compiled. > > > > if it is useless: > I suggest to delete it (which is better that fix it) > else > we need be sure that it is correct (or it can cause issue). It is _almost_ uesless. I don't know of anybody who has had to use it for quite a few years. But I still don't want to get rid of it, because it might possibly become useful in the future and it doesn't add any runtime overhead. > I feel: > we provide 20% can finish 80%. > but the left 20%, need us to provide 80%. > if we are focus on quality, we have to provide 80% for the left 20%. In my opinion this problem is not serious enough to spend much time on, and I have lots of other, more important things, to do. If you want to fix it, go ahead and send in a patch. 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: [Suggestion] drivers/usb/host/ohci* : not setting urb->hcpriv = NULL after kfree it.
On Sat, 15 Dec 2012, Chen Gang wrote: > Hello Alan Stern: > > in drivers/usb/host/ohci-q.c, function finish_urb: > when we finish call urb_free_priv, we not set urb->hcpriv = NULL (line 46) > urb_free_priv call kfree for urb_priv (which is urb->hcpriv, line 29) > within finish_urb, we not set urb->hcpriv = NULL (line 43..81) > > in drivers/usb/host/ohci-hdc.c, function ohci_urb_dequeue: > it judges urb->hcpriv == NULL to decide whether call finish_urb (line > 317..322) > within ohci_urb_dequeue, we not set urb->hcpriv = NULL (line 321..326) > another functions (finish_unlinks, takeback_td...), can call finish_urb, > too. > they do not set urb->hcpriv = NULL, either. > they do not judge urb->hcpriv == NULL before calling finish_urb. > > although I can not say it is surely a bug. It isn't. ohci_urb_dequeue calls usb_hcd_check_unlink_urb before looking at urb->hcpriv. If urb_free_priv has been called already then usb_hcd_check_unlink_urb will return a non-zero value. This is because finish_urb calls usb_hcd_unlink_urb_from_ep. Also, don't forget that the first think usb_hcd_giveback_urb does is set urb->hcpriv to NULL. > I still suggest: > in finish_urb, set urb->hcpriv = NULL, after finish calling urb_free_priv. > in urb_free_priv, better to judge whether urb_priv == NULL, firstly. If you want to send in a patch to do this, go ahead. 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: USB issue with kernel 3.6
On Sat, 15 Dec 2012, Piergiorgio Sartor wrote:
> Hi Alan,
>
> thanks for the patch, I applied it and tested.
>
> I've bad news...
> Unless I made some mistake (which can always be), I did not
> see any of the logs of this patch in the output, despite
> having seen the problem occuring (this time I used "cpuburn"
> to overload the system).
That's disappointing.
> The only reasonable log was like the previous one:
>
> [ 248.833978] ehci_hcd :00:0b.1: alan start cur time 4294916032 last
> scan 4294885464
> [ 248.833991] ehci_hcd :00:0b.1: command 10035 cmd reg 10075 io watchdog
> 1 async count 10
> [ 248.833998] ehci_hcd :00:0b.1: async list:
> [ 248.834006] ehci_hcd :00:0b.1: qh 880149fcfe00 hw
> 8800af80 dma af80 next 880146d70380 hw_next af8009c2
> [ 248.834013] ehci_hcd :00:0b.1: qh 880146d70380 hw
> 8800af8009c0 dma af8009c0 next 880146c95b00 hw_next af800a82
> [ 248.834020] ehci_hcd :00:0b.1: qh 880146c95b00 hw
> 8800af800a80 dma af800a80 next 880149b51f00 hw_next af800cc2
> [ 248.834027] ehci_hcd :00:0b.1: qh 880149b51f00 hw
> 8800af800cc0 dma af800cc0 next 880145d17e80 hw_next af800f02
> [ 248.834033] ehci_hcd :00:0b.1: qh 880145d17e80 hw
> 8800af800f00 dma af800f00 next 88013d137180 hw_next af800c02
> [ 248.834040] ehci_hcd :00:0b.1: qh 88013d137180 hw
> 8800af800c00 dma af800c00 next 880148bc hw_next af800d82
> [ 248.834046] ehci_hcd :00:0b.1: qh 880148bc hw
> 8800af800d80 dma af800d80 next 8801410f9f00 hw_next af800b42
> [ 248.834053] ehci_hcd :00:0b.1: qh 8801410f9f00 hw
> 8800af800b40 dma af800b40 next 880147b8bc80 hw_next af8007e2
> [ 248.834060] ehci_hcd :00:0b.1: qh 880147b8bc80 hw
> 8800af8007e0 dma af8007e0 next 880140b49180 hw_next af800e42
> [ 248.834066] ehci_hcd :00:0b.1: qh 880140b49180 hw
> 8800af800e40 dma af800e40 next 880141f8ac00 hw_next af8008a2
> [ 248.834073] ehci_hcd :00:0b.1: qh 880141f8ac00 hw
> 8800af8008a0 dma af8008a0 next (null) hw_next af82
> [ 248.834080] ehci_hcd :00:0b.1: This qh link time 4294885466 enqueue
> time 4294885466 td token 1f8c80 ov token 0
> [ 248.834087] ehci_hcd :00:0b.1: qh 880146d70380 naf800a82 info
> 42002210 4000 qtd af81ccc0
> [ 248.834095] ehci_hcd :00:0b.1: overlay td 8800af8009d0 nae2531e0
> 0001 t p0=af87fa9f
> [ 248.834103] ehci_hcd :00:0b.1: dma ae2531e0 td 8800ae2531e0
> naf81ef60 0001 t001f8c80 p0=af87fa80
> [ 248.834111] ehci_hcd :00:0b.1: dummy af81ef60 td 8800af81ef60
> n0001 0001 t0040 p0=
> [ 248.845154] ehci_hcd :00:0b.1: giveback urb 88014980dcc0 actual 0
> [ 248.845162] ehci_hcd :00:0b.1: alan end
This says that everything is correct, but the async schedule isn't
running even though it is supposedly turned on. Goodness knows why
not.
> Note that there was not anymore the log line before "alan start".
>
> I suspect the previous error was something else, maybe something
> it happens seldom, since sometimes I saw some timeout errors, but
> they were almost always not a problem.
Maybe. We need more debugging. Two changes:
Firstly, in the code added by the earlier, larger patch, edit the
alan_debug() function in ehci-hcd.c. Change the lines that say:
ehci_dbg(ehci, "command %x cmd reg %x io watchdog %d async count %d\n",
ehci->command, ehci_readl(ehci, &ehci->regs->command),
ehci->need_io_watchdog, ehci->async_count);
to this instead:
ehci_dbg(ehci, "command %x cmd reg %x status reg %x\n",
ehci->command, ehci_readl(ehci, &ehci->regs->command),
ehci_readl(ehci, &ehci->regs->status));
Secondly, apply the patch below on top of the last patch. It will
tell us when the async schedule gets turned on and off.
Alan Stern
Index: usb-3.7/drivers/usb/host/ehci-timer.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-timer.c
+++ usb-3.7/drivers/usb/host/ehci-timer.c
@@ -126,9 +126,10 @@ static void ehci_poll_ASS(struct ehci_hc
/* The status is up-to-date; restart or stop the schedule as needed */
if (want == 0) {/* Stopped */
- if (ehci->async_count > 0)
+ if (ehci->async_count > 0) {
ehci_set_command_bit(ehci, CMD_ASE);
-
+ ehci_dbg(ehci, "async on\n");
+ }
} else {/* Running */
if (ehci->async_count == 0) {
@@ -143,6 +144,7 @@ static void ehci_poll_ASS(struct ehci_hc
static void ehci_disable_ASE(struct ehci_hcd *ehci)
{
ehci_clear_command_bit(ehci, CMD_ASE);
+ ehci_dbg(ehci, "async off\n");
}
--
To unsubscribe from this list: send the line "unsubscribe linu
xHCI immediately wakes up Asus P8Z68-V LX in S5
Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard always wakes up a few seconds after I shutdown. I then have to switch it off a second time. This still occurs in Linux 3.6.9 (haven't tried 3.7 yet). I initially bisected this to: commit 13a307e1a4a10502d688ce058141bc503933214e Author: Lin Ming Date: Mon Nov 28 09:46:02 2011 +0800 ACPICA: Fix to allow region arguments to reference other scopes commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream. However, that seems to be a perfectly good bug fix (the error mentioned in the commit message did previously appear on this system). I therefore tried cherry-picking it onto earlier versions, and bisected to: commit 9777e3ce907d4cb5a513902a87ecd03b52499569 Author: Andiry Xu Date: Thu Oct 14 07:23:03 2010 -0700 USB: xHCI: bus power management implementation That is, this is the first commit for which cherry-picking commit 13a307e1a4a1 on top results in the problem. lspci -vvnn says: 04:00.0 USB Controller [0c03]: Device [1b21:1042] (prog-if 30) Subsystem: ASUSTeK Computer Inc. Device [1043:8488] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. I can try updating the BIOS if you think this might help (the description of changes is very vague). Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
[PATCH 1/1] usb: host: xhci: remove unused trb var in xhci_irq()
The union xhci_trb *trb variable is defined and assigned
inside the xHCI IRQ handler function but is never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/usb/host/xhci-ring.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index cbb44b7..b1b6abb 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2697,13 +2697,11 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
u32 status;
- union xhci_trb *trb;
u64 temp_64;
union xhci_trb *event_ring_deq;
dma_addr_t deq;
spin_lock(&xhci->lock);
- trb = xhci->event_ring->dequeue;
/* Check if the xHC generated the interrupt, or the irq is shared */
status = xhci_readl(xhci, &xhci->op_regs->status);
if (status == 0x)
--
1.7.7.6
--
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 v9] usb_8dev: Add support for USB2CAN interface from 8 devices
Add device driver for USB2CAN interface from "8 devices"
(http://www.8devices.com).
changes since v8:
* remove all sysfs files
changes since v7:
* add sysfs documentation
* fix minor styling issue
* fixed can state for passive mode
* changed handling for crc errors
changes since v6:
* changed some variable types to big endian equivalent
* small cleanups
changes since v5:
* unlock mutex on error
changes since v4:
* removed FSF address
* renamed struct usb_8dev
* removed unused variable free_slots
* replaced some _to_cpu functions with pointer equivalent
* fix return value for usb_8dev_set_mode
* handle can errors with separate function
* fix overrun error handling
* rewrite error handling for usb_8dev_start_xmit
* fix urb submit in usb_8dev_start
* various small fixes
Signed-off-by: Bernd Krumboeck
Acked-by: Wolfgang Grandegger
---
drivers/net/can/usb/Kconfig|6 +
drivers/net/can/usb/Makefile |1 +
drivers/net/can/usb/usb_8dev.c | 1034
3 files changed, 1041 insertions(+)
create mode 100644 drivers/net/can/usb/usb_8dev.c
diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
index a4e4bee..2162233 100644
--- a/drivers/net/can/usb/Kconfig
+++ b/drivers/net/can/usb/Kconfig
@@ -48,4 +48,10 @@ config CAN_PEAK_USB
This driver supports the PCAN-USB and PCAN-USB Pro adapters
from PEAK-System Technik (http://www.peak-system.com).
+config CAN_8DEV_USB
+ tristate "8 devices USB2CAN interface"
+ ---help---
+ This driver supports the USB2CAN interface
+ from 8 devices (http://www.8devices.com).
+
endmenu
diff --git a/drivers/net/can/usb/Makefile b/drivers/net/can/usb/Makefile
index 80a2ee4..becef46 100644
--- a/drivers/net/can/usb/Makefile
+++ b/drivers/net/can/usb/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_CAN_EMS_USB) += ems_usb.o
obj-$(CONFIG_CAN_ESD_USB2) += esd_usb2.o
obj-$(CONFIG_CAN_KVASER_USB) += kvaser_usb.o
obj-$(CONFIG_CAN_PEAK_USB) += peak_usb/
+obj-$(CONFIG_CAN_8DEV_USB) += usb_8dev.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
new file mode 100644
index 000..660b4f87
--- /dev/null
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -0,0 +1,1034 @@
+/*
+ * CAN driver for "8 devices" USB2CAN converter
+ *
+ * Copyright (C) 2012 Bernd Krumboeck (krumbo...@universalnet.at)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.
+ *
+ * This driver is inspired by the 3.2.0 version of
drivers/net/can/usb/ems_usb.c
+ * and drivers/net/can/usb/esd_usb2.c
+ *
+ * Many thanks to Gerhard Bertelsmann (i...@gerhard-bertelsmann.de)
+ * for testing and fixing this driver. Also many thanks to "8 devices",
+ * who were very cooperative and answered my questions.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* driver constants */
+#define MAX_RX_URBS10
+#define MAX_TX_URBS10
+#define RX_BUFFER_SIZE 64
+
+/* vendor and product id */
+#define USB_8DEV_VENDOR_ID 0x0483
+#define USB_8DEV_PRODUCT_ID0x1234
+
+/* endpoints */
+enum usb_8dev_endpoint {
+ USB_8DEV_ENDP_DATA_RX = 1,
+ USB_8DEV_ENDP_DATA_TX,
+ USB_8DEV_ENDP_CMD_RX,
+ USB_8DEV_ENDP_CMD_TX
+};
+
+/* bittiming constants */
+#define USB_8DEV_ABP_CLOCK 3200
+#define USB_8DEV_BAUD_MANUAL 0x09
+#define USB_8DEV_TSEG1_MIN 1
+#define USB_8DEV_TSEG1_MAX 16
+#define USB_8DEV_TSEG2_MIN 1
+#define USB_8DEV_TSEG2_MAX 8
+#define USB_8DEV_SJW_MAX 4
+#define USB_8DEV_BRP_MIN 1
+#define USB_8DEV_BRP_MAX 1024
+#define USB_8DEV_BRP_INC 1
+
+/* setup flags */
+#define USB_8DEV_SILENT0x01
+#define USB_8DEV_LOOPBACK 0x02
+#define USB_8DEV_DISABLE_AUTO_RESTRANS 0x04
+#define USB_8DEV_STATUS_FRAME 0x08
+
+/* commands */
+enum usb_8dev_cmd {
+ USB_8DEV_RESET = 1,
+ USB_8DEV_OPEN,
+ USB_8DEV_CLOSE,
+ USB_8DEV_SET_SPEED,
+ USB_8DEV_SET_MASK_FILTER,
+ USB_8DEV_GET_STATUS,
+ USB_8DEV_GET_STATISTICS,
+ USB_8DEV_GET_SERIAL,
+ USB_8DEV_GET_SOFTW_VER,
+ USB_8DEV_GET_HARDW_VER,
+ USB_8DEV_RESET_TIMESTAMP,
+ USB_8DEV_GET_SOFTW_HARDW_VER
+};
+
+#define USB_8DEV_CMD_START 0x11
