a,has-utmi-pad-registers")) {
> + if (has_utmi_pad_registers) {
But down here the sense of the test is reversed. Now the conditional
block gets executed if the property is true, whereas the original code
executed it if the property was false.
> reset_control_asse
a
> SIM card with existing Linux tools, I would search for it in India and
> buy it.
Maybe your device can be used with existing Linux tools. Have you
tried asking Google? There is a program called monosim that might do
what you want.
Alan Stern
--
To unsubscribe from this list: send t
gt; MUSB. It also seems that Synopsys' XHCI (part of dwc3 when configured as
> dual-role) is immune to this link TRB alignment limitation because I was
> running hcd-tests.sh also on a daily basis on TI's AM437x SK and IDK
> boards (one as host, one as peripheral).
If creating boun
pwrseq_pre_power_on(hub->ports[i]->pwrseq);
> + */
> +
> + for (i = 0; i < maxchild; i++)
> + pwrseq_post_power_on(hub->ports[i]->pwrseq);
This is patch 10/13. hub->ports[i]->pwrseq doesn't get added until
11/13. Obviously you never tried compiling each patch in the
ago which Dave wrote. At [1] you can find Dave's usbtest page on
> linux-usb.org and at [2] you can find a direct link to test.sh.
Okay. Still, the fact remains that I haven't tried test.sh. Only
testusb run directly from the command line.
Alan Stern
--
To unsubscribe from this l
re knows. It doesn't use the information for a whole lot of
things, but it does use it in a couple of places. Search for
"companion" in core/hcd-pci.c and you'll see.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mes
/kernel/debug/usb/devices
Or just copy the file directly into an email message.
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
=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=83(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
...
That doesn't say very much, but at least it proves that no other driver
has claimed the interface.
The next thing you can try is to run the Gebabbel program under strace
and send the output to a file. That sho
rts = board->ports;
> +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable)
> +{
> + u32 regval;
> + int ret;
> +
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, SFR_OHCIICR, ®val);
And
d by
> non-PCI devices.
> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
That's right.
> So, I will try to add such a code if needed.
The main thing to watch out for is during system resume. The EHCI
controller must not be resumed until
values for the bus and device numbers)?
> Sadly moving from text based line commands to a GUI has not in this
> case improved ease of use on this installation.
You may get better help from an Ubuntu support forum or mailing list.
Alan Stern
> Stephen
>
> 0.00 restart_syscall(<
t root 80 May 12 21:04 003
> drwxr-xr-x 2 root root 60 May 11 14:39 004
> drwxr-xr-x 2 root root 60 May 11 14:39 005
What about the permissions for the files inside those directories?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
ow whether the host sent more data than
expected. All you know is that the host sent more data than the user
asked the kernel for -- but maybe the user didn't ask for all the data
that he expected. Maybe the user wanted to retrieve the full set of
data using two read() system calls.
Alan Stern
On Thu, 12 May 2016, Stephen Furner wrote:
> I apologise if this is a duplicate I had a bounce back from the list
> due to it since I had inadvertently included HTML. So I am resending.
>
> To: Alan Stern
> Cc: USB list
>
> Alan,
>
> I have looked through the
e. But
there may be other reasons why it doesn't show up. For example, the
program may fork some child processes and one of these children might
be the source of the error.
Anyway, fixing the file permissions is probably the right approach.
Alan Stern
--
To unsubscribe from this list:
001
> crw-rw-r-- 1 root root 189, 131 May 13 19:03 004
There it is: write permission only for root. Have you tried installing
the udev rule recommended on the Ubuntu forum?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mess
etdents(3, /* 0 entries */, 32768) = 0
> close(3)= 0
> openat(AT_FDCWD, "/dev/bus/usb/005",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission
> denied)
> write(2, "Found no Garmin USB devices.\n", 29Found no Garmin US
very intelligible. You had too
many debug options turned on, which is almost as bad as not having
enough.
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
y to hassle you guys.
Don't worry about it; that's part of why we're here.
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
element of the array object, the evaluation
> >> shall not produce an overflow;
> >> otherwise, the behavior is undefined."
> >
> > But we do not care whether the calculation overflows. We don't use it
> > at all in those cases.
> >
>
> This
return;
> +
> spin_lock_irq(&ehci->lock);
> ehci->shutdown = true;
> ehci->rh_state = EHCI_RH_STOPPING;
This doesn't seem like the right place. What you really should do is
skip calling ehci_silence_controller() if the hardware isn't
accessible. That
iver_info = USB_QUIRK_NO_LPM },
> +
> { } /* terminating entry must be last */
> };
Please keep the entries sorted by Vendor and Product ID. In fact, if
you wouldn't mind, it would be good to submit an additional patch that
rearranges the existing out-of-order entries.
Alan
On Wed, 18 May 2016, Andrey Ryabinin wrote:
> 2016-05-18 17:40 GMT+03:00 Alan Stern :
>
> > All right, I'm getting very tired of all these bug reports. Besides,
> > Andrey has a point: Unless you're Linus, arguing against the C standard
> > is futile. (Even t
On Wed, 18 May 2016, Srinivas Kandagatla wrote:
> On 18/05/16 15:56, Alan Stern wrote:
> > On Wed, 18 May 2016, Srinivas Kandagatla wrote:
> >
> >> This patch adds a check in ehci_shutdown(), to make sure
> >> that the register access is available before acces
; issue. (Sorry I think I mentioned just pm_runtime_put_sync()
> earlier..)
Actually it may be the other way around.
pm_runtime_put_sync_suspend() will do an immediate suspend regardless
of the autosuspend timer, whereas pm_runtime_put_sync() will not
suspend the device until the autosuspend timer expires.
On Wed, 18 May 2016, Srinivas Kandagatla wrote:
> On 18/05/16 15:56, Alan Stern wrote:
> > This doesn't seem like the right place. What you really should do is
> > skip calling ehci_silence_controller() if the hardware isn't
> > accessible. That's whe
On Wed, 18 May 2016, Andrey Ryabinin wrote:
> 2016-05-18 19:09 GMT+03:00 Alan Stern :
> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
> >
> >> 2016-05-18 17:40 GMT+03:00 Alan Stern :
> >>
> >> > All right, I'm getting very tired of all thes
registers or
> + * variables initialized in ehci_setup()
> + */
> + if (!ehci->sbrn)
> + return;
> +
> spin_lock_irq(&ehci->lock);
> ehci->shutdown = true;
> ehci->rh_state = EHCI_RH_STOPPING;
Acked-by: Alan S
On Thu, 19 May 2016, Andrey Ryabinin wrote:
> 2016-05-18 22:28 GMT+03:00 Alan Stern :
> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
> >
> >> 2016-05-18 19:09 GMT+03:00 Alan Stern :
> >> > On Wed, 18 May 2016, Andrey Ryabinin wrote:
> >> &g
d, it's not clear
what the compiler is really allowed to do.)
At any rate, we can avoid all these difficulties, at the cost of
making the code slightly longer, by not decrementing the index when it
is equal to 0. The runtime effect is minimal, and anyway
ehci_hub_control() is not on a hot pat
ze the ehci-hcd parts.
Neither ehci_suspend nor ehci_resume is called directly by the driver
core; the calls all have to pass through the glue code. So maybe the
glue layer needs to be careful about invoking these routines in
ehci-hcd before ehci-hcd has been initialized.
Alan Stern
--
To uns
RAID of several USB
> sticks (same machine has host and peripheral controllers).
How about setting up USBIP, using the same machine as both the server
and the client?
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
ell, UBSAN doesn't complain about the *other* use of the same exact index,
> apparently because 'u32 port_status[0]' tells it to shut up we know what we're
> doing.
>
> And I'm pretty sure that if hostpc was supposed to be exactly one u32 rather
> than an ar
* USBMODE_EX: offset 0xc8 */
> u32 usbmode_ex; /* USB Device mode extension */
Is this problem still present with my latest patch
(http://marc.info/?l=linux-usb&m=146368979514228&w=2)?
I agree that this is a reasonable change to make in any case.
Alan Ster
On Fri, 20 May 2016, Andy Gross wrote:
> On 20 May 2016 at 09:31, Alan Stern wrote:
> > On Thu, 19 May 2016, Andy Gross wrote:
> >
> >> On 19 May 2016 at 05:12, Srinivas Kandagatla
> >> wrote:
> >>
> >>
> >>
> >> > +
me(hcd, false);
> +
> + /* Only call ehci_resume if ehci_setup has been done */
> + if (ehci->sbrn)
> + ehci_resume(hcd, false);
>
> return 0;
> }
> +
> #else
> #define ehci_msm_pm_suspend NULL
> #define ehci_msm_pm_resume NULL
Ac
_submit_urb(urb, mem_flags);
> + ret = debug_urb_activate(urb);
> + if (ret)
> + return ret;
> + ret = usb_hcd_submit_urb(urb, mem_flags);
> + if (ret)
> + debug_urb_deactivate(urb);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(usb_submit_u
ould normally be available.
If you can acquire a usbmon trace showing what happens when the flash
drive is plugged in and the reset occurs, that would help.
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
spin_lock_irq (&dev->lock);
Since you are enabling IRQs around this call to usb_ep_queue(), the
last argument should be changed to GFP_KERNEL.
> dev->state = STATE_DEV_CONNECTED;
>
> /* assume that was SET_CONFIGURAT
7;t a generic way of doing it, but you could such a thing to
the ohci-platform driver. That would be preferable to adding a new,
separate platform driver.
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
On Thu, 26 May 2016, Martin Townsend wrote:
> On Thu, May 26, 2016 at 4:24 PM, Alan Stern wrote:
> > On Thu, 26 May 2016, Martin Townsend wrote:
> >
> >> Hi,
> >>
> >> I'm currently trying to get the USB Host working on the SH7760. I
> >
s plugged in? It sounds like the driver is not accessing
the right registers.
> Also
> any ideas on where to start with debugging this would be appreciated.
What do you see in /sys/kernel/debug/usb/ohci/*/registers?
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
cates that an OverCurrent
condition was present at some point.
The CCS bit in roothub.portstats[0] indicates that something
is plugged into port 1. If there really is nothing plugged
into that port then this is a hardware failure.
The reason for the ENOMEM e
ce condition !hcd->primary_hcd is met.
>
> int usb_hcd_is_primary_hcd(struct usb_hcd *hcd)
> {
> if (!hcd->primary_hcd)
> return 1;
> return hcd == hcd->primary_hcd;
> }
That's just a symptom, not the real cause of the bug. You need to fix
the real cause: the shared_hcd has to be released _before_ the
primary_hcd.
The right way to do this is to make the shared_hcd take a reference to
the primary_hcd. This reference should be dropped when hcd_release()
is called for the shared_hcd.
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
to get a connect-change event even though the cable has remained
plugged into the port the whole time.
So the question is, how do we prevent the port from re-enabling itself
until the cable has been unplugged? Maybe the port should not be in
RX_DETECT at all? But then how do we tell when the cabl
not syncing: Attempted to kill the idle task!
> [ 161.599219] Kernel Offset: disabled
> [ 161.599778] ---[ end Kernel panic - not syncing: Attempted to kill the
> idle task!
What happens if you do (as root):
echo 2-2:1.0 >/sys/bus/usb/drivers/usbhid/unbind
before unplugging the device?
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
howing what happens when you plug in the
drive.
Alan Stern
> On Wed, May 18, 2016 at 3:41 PM, Michael Schaller wrote:
> > [1.] One line summary of the problem:
> > Slow writes with dd on Lexar JumpDrive P20 64GB flash drives connected
> > via Intel USB 3.0 host control
ep1out: 31/1024 --> 0
The CBW is received by get_next_command(), which runs in the fsg
thread. Therefore the thread is already running; the question is why
doesn't it continue?
You might want to add some debugging to fsg_main_thread() to see what
happens with the return codes from get_ne
On Tue, 31 May 2016, Mathias Nyman wrote:
> On 30.05.2016 19:39, Alan Stern wrote:
> > On Sun, 29 May 2016, Marco Chiappero wrote:
> >
> >> Hello,
> >>
> >> I'm experiencing a problem I'm not able to troubleshoot.
> >>
> >>
c->pullup)
return -EINVAL;
Or maybe (I'm not familiar with the driver so I don't know the best
approach) changes the test to:
if (!udc->driver || !udc->pullup)
After all, there's no reason to check !udc if it is known beforehand
that udc will n
|
> |bandXX_mutex(free) |<-(Link)-bandXX_mutex |
> |___| |__|
>
> --
That's the same as what I said. In your diagram, vold releases the
shared_hcd (in <5>) after dwc3_otg_sm_work releases the primary_hcd
(in <4>).
If you change the code so that the shared_hcd takes a reference to the
primary_hcd and drops that reference when the shared_hcd is released,
this will never occur.
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
/* MCP89 chips on the MacBookAir3,1 give EPROTO when
Please merge the PCI_VENDOR_ID_AMD case with the PCI_VENDOR_ID_INTEL
case.
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
t; anymore, it's just so much simpler to change hardware.
As Greg says, changing hardware would be much less effort and cost a
lot less than trying to fix up the software. Of course, if you want to
work on the driver software, you are free to do so -- I'll be willing
to help.
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
m. ed->in_use_list gets modified in only
two places: in ohci_urb_enqueue() in ohci-hcd.c and in finish_unlinks()
in ohci-q.c. Just before each of those lines, you could write out the
value of ed to the kernel log. That would tell us if the ED really is
being removed before it is added to the list.
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
> The failing EP 0x88 is 1kB isochronous, btw, so it all looks plausible.
Yes, you spotted it. The problem is indeed in ed_schedule().
Try moving the first executable line:
ed->state = ED_OPER;
to the end of the routine, just before the "return 0;". That should
fix the pro
many urbs it has outstanding and
> call the reap ioctl (with some msleep after failure) until it
> has reaped all urbs ?
We already have POLLOUT to indicate when a completed URB is available
for reaping. Can libusb use that?
Strictly speaking, POLLERR just indicates an error condition, of any
kind.
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
Lee Jones
For this andd the 10/10 patch:
Acked-by: 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
On Sat, 4 Jun 2016, Marco Chiappero wrote:
> On 31/05/2016 16:34, Alan Stern wrote:
> > On Tue, 31 May 2016, Mathias Nyman wrote:
> >
> >>
> >> xhci specs say that port will move from Disconnected (PLS = RX_DETECT) to
> >> Polling if "SuperS
eed
> keyboard and a 192kB/s audio stream, all at the same time and with no
> errors whatsoever :) Only it takes pppd a few minutes to even establish
> the ppp session.
I don't think there were any significant changes to the bandwidth
allocation routines in ohci-hcd between those ke
the branch
> 'if (ed->state==ED_IDLE)' is taken and ed_schedule() called. Despite
> this, however, the modem starts to work once I disconnect other stuff.
It sounds like the ueagle-atm driver ought to be more careful about
resubmitting URBs after an ENOSPC error. Regardless, the
= NULL;
> ed->hwNextED = 0;
> @@ -259,6 +258,8 @@ static int ed_schedule (struct ohci_hcd *ohci, struct ed
> *ed)
> /* the HC may not see the schedule updates yet, but if it does
>* then they'll be properly ordered.
>*/
> +
> + ed->s
I feel like pppd
> takes unusually long to start.
Periodic scheduling is "pessimistic"; it uses worst-case values. So if
the driver over-commits, things will still work okay most of the time.
> This is 3.14.25 and I'm almost sure *every* current kernel allows that.
No doubt.
b.c is now part of the kernel source:
tools/usb/usb.c
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
_primary_ hcd
is released.
Can you please test the patch below?
By the way, a good change (if you want to do it) would be to rename the
"shared_hcd" field to "other_hcd" or "peer_hcd". This is because it
always points to the other hcd in the peer set: In the primary
s
On Tue, 7 Jun 2016, Hans de Goede wrote:
> Hi,
>
> On 06-06-16 19:03, Alan Stern wrote:
> > On Mon, 6 Jun 2016, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 06-06-16 16:48, Greg Kroah-Hartman wrote:
> >>> On Mon, Jun 06,
t
wouldn't hurt anything. That will make it easier for the fix to get
into the -stable kernels.
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
is also leads
> to a nice cleanup of the cleanup code.
>
> This brings the ehci-platform reset handling code inline
> with ohci-platform.
>
> Signed-off-by: Hans de Goede
> ---
This is just the difference between what Greg has merged and what you
wanted to add, right? I
port suspend?
If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case in ohci_hub_control() already take care of this?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vg
one too.
If I want to refer to a Host Controller Device, I would write either
"HC" or "host controller".
Admittedly, this means that struct usb_hcd has a slightly illogical
name.
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
e a bug in the memory management subsystem. It should be
reported on the linux-mm mailing list (CC'ed).
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
rn.
Well, there haven't been any complaints about this until you reported
the problem. If anybody else was relying on the driver exceeding the
maximum allowed bandwidth, wouldn't they run across the same BUG as you
did?
In which case there wouldn't be any downside to put
unt -t debugfs none /sys/kernel/debug
In fact, maybe you can run the same test and capture the contents of
/sys/bus/kernel/debug/usb/ehci/:00:1a.0/periodic with the devices
plugged into the docking station. It would be interesting to compare
the two results.
Oh yes, and you should also capture
standing URBs have completed. That's what
this patch does; it uses the fact that ps->list is always on the
dev->filelist list until usbdev_remove() takes it off, which happens
after all the outstanding URBs have been cancelled.
Signed-off-by: Alan Stern
Reported-by: Hans de Goede
---
is
written in such a way that it now thinks the shared hcd _is_ the
primary.
Is the patch below a good way to fix the problem? There doesn't _seem_
to be any harm in making this change. At least, I don't think it will
confuse drivers any more than they are already.
Than
On Fri, 10 Jun 2016, Sean M. Pappalardo wrote:
>
>
> On 06/10/2016 11:06 AM, Alan Stern wrote:
> > Have you tried plugging the audio
> > devices into a USB-2 hub and plugging the hub into bus 2?
>
> That works!! (I forgot, my monitor has a built-in 2-port USB2.0
On Fri, 10 Jun 2016, Alan Stern wrote:
> On Fri, 10 Jun 2016, Sean M. Pappalardo wrote:
>
> >
> >
> > On 06/10/2016 11:06 AM, Alan Stern wrote:
> > > Have you tried plugging the audio
> > > devices into a USB-2 hub and plugging the hub into bus 2?
&
On Sat, 11 Jun 2016, Sean M. Pappalardo wrote:
>
>
> On 06/10/2016 02:18 PM, Alan Stern wrote:
> > Actually, after reviewing the data files you sent I did have a thought.
> > Can you try out the patch below and see if it makes any difference?
>
> It did not, sor
24] perf pmu: Fix misleadingly
> indented assignment (whitespace)
> git bisect bad d85ce830eef6c10d1e9617172dea4681f02b8424
> # first bad commit: [d85ce830eef6c10d1e9617172dea4681f02b8424] perf pmu: Fix
> misleadingly indented assignment (whitespace)
> [13/511]mh@fan:~/lin
On Sun, 12 Jun 2016, Sean M. Pappalardo wrote:
> Hello again.
>
> On 06/12/2016 07:57 AM, Alan Stern wrote:
> > Would you mind posting the contents of
> > /sys/kernel/debug/usb/ehci/:00:1d.0/periodic, for the patched
> > kernel, while the test is running?
&
On Sun, 12 Jun 2016, Sean M. Pappalardo wrote:
>
>
> On 06/12/2016 06:05 PM, Alan Stern wrote:
> > Okay, thanks. I just wanted to be sure the patch was behaving as
> > intended. It was, but since it didn't fix your problem the whole
> > thing's a moot po
r {
> >
> > };
> >
> > +/**
> > + * struct otg_hcd_ops - Interface between OTG core and HCD
> > + *
> > + * Provided by the HCD core to allow the OTG core to interface with the HCD
Add: * in case the OTG core is built-in and the HCD core is built as
ll three /dev/ttyUSB[0-2] ?
>
> $ sudo ./usbreset $DEVFN
> Usage: usbreset device-filename
>
> If you need more informations if my attached linux-config,
> dmesg-output and 'lsusb -vvv' outputs don't help, please let me know.
sudo ./usbreset /dev/bus/usb/001/005
device. Or it will give you an error
message.
Besides, you can try those experiments yourself and see what happens.
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
uct usb_hub *hub = usb_get_intfdata(intf);
It would be easier to pass hub as the argument instead of intf.
Otherwise this looks okay to me.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-115 13 <
> 88042981bc00 588213441 C Bi:2:003:1 0 13 = 55534253 ba00 00
This required only 486 us to send the data (250 MB/s), but the status
reply added an additional 2038 us, driving the total rate way down to
48 MB/s.
The timings in the trace file vary, but these two see
those operating systems and post the results. (And even if Wireshark
can't do this, there are publicly available programs that can.)
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
t have dependency on the at91 material
> anymore.
Sorry, I will not accept this patch until Wenyou Yang answers the
questions I raised in
http://marc.info/?l=linux-usb&m=146307669102601&w=2
and
http://marc.info/?l=linux-usb&m=146541324027407&w=2
Alan Stern
-
t last splat persists until at least linux-next-20160622.
>
> Is there anything else you need?
Please try 4.7-rc4.
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
itional data will help diagnose this issue,
> or would it be best to submit a revert request?
Another option is to add a NO_LPM quirks entry for the troublesome
device.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mess
sable */
#define HOSTPC_PSPD(3<<25) /* Port speed detection */
- u32 reserved5[16];
+ u32 reserved5[17];
/* USBMODE_EX: offset 0xc8 */
u32 usbmode_ex; /* USB Device mode extension */
By coincidenc
-off-by: Alan Stern
Reported-by: Wilfried Klaebe
Tested-by: Wilfried Klaebe
CC:
---
[as1803]
include/linux/usb/ehci_def.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: usb-4.x/include/linux/usb/ehci_def.h
Greg:
Sorry, the Subject line of the original email left out "[PATCH]" at the
beginning. Will it still work with your scripts?
Alan Stern
On Thu, 23 Jun 2016, Alan Stern wrote:
> The HOSTPC extension registers found in some EHCI implementations form
> a variable-length
ructure
referencing it is released. The patch also removes an unnecessary
test, so that when an hcd is released, both the shared_hcd and
primary_hcd pointers in the hcd's peer will be cleared.
Signed-off-by: Alan Stern
Reported-by: Chung-Geol Kim
Tested-by: Chung-Geol Kim
CC:
---
[as
ou provide a usbmon trace for bus 6 showing what happens when this
problem occurs?
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
ructure
referencing it is released. The patch also removes an unnecessary
test, so that when an hcd is released, both the shared_hcd and
primary_hcd pointers in the hcd's peer will be cleared.
Signed-off-by: Alan Stern
Reported-by: Chung-Geol Kim
Tested-by: Chung-Geol Kim
CC:
-
ime it was
used (not shown above).
The last line shows that the port's link state changed to Recovery.
I don't know exactly what that indicates, but apparently something went
wrong with the connection between the device and host controller.
Later parts of the trace show the link state gettin
t; >> 4.2 is pretty old and obsolete you know :)
> >>
> >> thanks,
> >>
> >> greg k-h
> > The regression does exist in 4.6-rc2. I'll have the latest mainline
> > 4.7-rc4 kernel tested.
> The 4.7-rc4 kernel still exhibits the bug.
Have you t
show_bug.cgi?id=120701
What do you get from "lspci -vv -s 00:14.0"?
And what shows up in the /sys/bus/pci/device/:00:14.0/power/wakeup
file?
You can also try enabling usbcore dynamic debugging:
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
and then s
them. But external hubs are either self-powered or bus-powered;
there's no need and no way for the hub driver to turn the hub power on
or off. Therefore it doesn't try, not even for root hubs.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
On Wed, 21 Nov 2012, Sachin Kamat wrote:
> 'new_interfaces' should be freed to avoid memory leak.
>
> Cc: Sarah Sharp
> Cc: Alan Stern
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/core/message.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletion
1 - 100 of 7023 matches
Mail list logo
