On Fri, 13 Nov 2015, Lu, Baolu wrote:
> On 11/13/2015 12:20 AM, Alan Stern wrote:
> > On Thu, 12 Nov 2015, Lu Baolu wrote:
> >
> >> Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3
> >> hardware LPM") introduced usb3_hardware_lpm sysfs node
warn(&udev->dev, "Could not disable xHCI %s timeout, "
> "bus schedule bandwidth may be impacted.\n",
> usb3_lpm_names[state]);
> +
> + if (state == USB3_LPM_U1)
> + udev->usb3_lpm_u1_enabl
On Thu, 15 Oct 2015, Jassi Brar wrote:
> On Thu, Oct 15, 2015 at 7:59 PM, Alan Stern wrote:
> > On Thu, 15 Oct 2015, Jassi Brar wrote:
> >
> >> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern
> >> wrote:
> >> > On Wed, 14 Oct 2015, Jassi Brar wrote
On Thu, 15 Oct 2015, Jassi Brar wrote:
> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern
> wrote:
> > On Wed, 14 Oct 2015, Jassi Brar wrote:
> >
> >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some
> >> setup request that has USB_DIR_IN not
On Wed, 14 Oct 2015, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Wed, 14 Oct 2015, Jassi Brar wrote:
> >
> >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some
> >> setup request that has USB_DIR_IN not set?
> >
> &
e problem you're seeing? The host tries to send
more data than the gadget is ready to receive? (Although then the
error code on the gadget side should be -75, not -71.)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to
/?l=linux-scsi&m=144185206825609&w=2). We
ought to hold off putting it into the -stable kernels.
Alan Stern
> --
>
> From: Alan Stern
>
> commit 49718f0fb8c9af192b33d8af3a2826db04025371 upstream.
>
> The routines in scsi_rpm.c assume that if a runtim
->uframe_periodic_max);
> return n;
> }
> @@ -101,7 +101,7 @@ static ssize_t store_uframe_periodic_max(struct device
> *dev,
> unsigned long flags;
> ssize_t ret;
>
> - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
> +
notification for the transfer. This can result
in a hang or a segmentation error, depending on how the userspace
program tries to cope.
The patch may require some context adjustment before it will apply to
the longterm -stable trees, but I think it should be added.
Alan Stern
--
To
packet size should be 384 bytes, not 96.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nter at the same time.
> Cc: Jun Li
> Cc:
> Cc: Alan Stern
> Signed-off-by: Peter Chen
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
platform_unregister_driver(&ci_hdrc_driver);
}
module_exit(ci_hdrc_driver_cleanup);
Then in host.c, make ci_hdrc_host_driver_init non-static.
This should work, because the core's probe routine can't be called
before it is registered as a platform driver, and that doesn't happen
until
On Mon, 20 Jul 2015, Peter Chen wrote:
> On Fri, Jul 17, 2015 at 09:52:26AM -0400, Alan Stern wrote:
> > On Fri, 17 Jul 2015, Peter Chen wrote:
> >
> > > There are several benefits for doing like this:
> > >
> > > - hc_driver can be customized
ller is initialized; rather, it should be called just once when
the driver is initialized. This means the call should be in a
module_init routine in host.c, not in ci_hdrc_host_init.
If you need to customize the hc_driver structure for each host
controller then yes, a separate copy is needed. But
themselves in
> the foot if they want to, especially as letting them to that is less
> code. ;)
How about logging a warning message if the LUNs aren't contiguous but
then continuing on? Like we do if the serial number string isn't
provided.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
tected flags, and use this in the uas driver.
>
> Cc: stable@vger.kernel.org # 3.16
> Signed-off-by: Hans de Goede
For this whole series:
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.ke
ecause the transfer data
generally isn't contiguous in memory.
It would be okay to do this for other transfer types, though.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Sun, 8 Mar 2015, Lu, Baolu wrote:
> Hi Alan,
>
> Do you have any comments for this patch?
No comments.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
wever, I also believe that it is important to fix the bugs revealed
by the API change.
> FWIW we have a large number of systems here that are broken
> without this change.
For all you know, they will still be broken even after the change is
applied. The breakage may become less obvious,
ect other people
to figure out where it is with no help from you?
I looked briefly at the xhci-hcd DMA allocation code. It does not
contain any obvious mistakes.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
? I haven't seen fixes from the
> XHCI folks yet. This is breaking many of our systems.
Have you tried doing the experiments I suggested in
http://marc.info/?l=linux-usb&m=142272448620716&w=2
to determine where the problem occurs?
Alan Stern
--
To unsubscribe from this list:
in D3
> Here for JMicron chip 363/361, we need forcedly to disable the async method.
You know, this is exactly why device_pm_wait_for_dev() exists -- so
that asynchronous power-management operations can wait for other
devices even when there's no parent-child relation.
You should try to
oesn't really say anywhere. I'm pretty sure the intention was that
the endpoint_reset callback is always called in process context. It
wouldn't hurt to add a comment to usb_hcd_reset_endpoint() documenting
this.
Alan Stern
--
To unsubscribe from this list: send the line "
inter before giving back the URB (so there's no need to save a
"stopped TD" value). Otherwise there will be TDs in the endpoint ring
containing stale DMA pointers to buffers that have already been
unmapped.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscrib
course, if the queue is empty then
there's no harm in leaving the ep in EP_STATE_HALTED until another URB
is submitted.
By the same reasoning, when the state is changed to EP_STATE_STOPPED,
the doorbell should be rung.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 12 Nov 2014, Felipe Balbi wrote:
> Hi,
>
> On Wed, Nov 12, 2014 at 03:03:10PM -0500, Alan Stern wrote:
> > On Wed, 12 Nov 2014, Felipe Balbi wrote:
> >
> > > If class driver wants to SetFeature(ENDPOINT_HALT) and
> > > later tries to talk to the
bout moving the dequeue pointer past
the STALLed TD and then clearing the halt condition. Moving the
dequeue pointer is fine -- there's no other way to take control of the
TD back from the hardware -- but why would you want to clear the halt?
The HCD isn't supposed to do that; the cla
L;
> if (dev->speed != USB_SPEED_SUPER)
> return -EINVAL;
> + if (dev->state < USB_STATE_CONFIGURED)
> + return -ENODEV;
>
> for (i = 0; i < num_eps; i++) {
> /* Streams only apply to bulk endpoints. */
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_reset_and_verify_device fails,
Not so. The state is changed by:
usb_reset_and_verify_device -> hub_port_logical_disconnect ->
hub_port_disable -> usb_set_device_state.
This takes place without involving khubd.
> and khubd may not yet have a chance to
> run wh
t;
> This commit adds a check for this condition to xhci_check_args(), which should
> cover all public entry points into the xhci driver.
Wouldn't it be better to make usbcore check that the device state is
CONFIGURED (or at least, isn't NOTATTACHED) before asking the HCD to
allocate or
On Mon, 15 Sep 2014, Oliver Neukum wrote:
> On Mon, 2014-09-15 at 08:42 +, David Laight wrote:
> > From: Alan Stern
> >
> > > You must not add an aditional value for a module parameter without
> > > documenting it in Documentation/kernel-parameters.txt
break;
> + case 't':
> + f |= US_FL_NO_ATA_1X;
> + break;
> case 'u':
> f |= US_FL_IGNORE_UAS;
> break;
You must not add an aditional value for a module parame
ORE_UAS;
> + }
> + }
> +
> + usb_stor_adjust_quirks(udev, &flags);
This won't work. usb_stor_adjust_quirks masks out all the quirks that
it handles before applying the user-specified quirks. Therefore it
will erase your US_FL_IGNORE_UAS flag.
You might
error:
>
> drivers/usb/host/ohci-spear.c: In function ‘ohci_spear_start’:
> drivers/usb/host/ohci-spear.c:56:2: error: too many arguments to function
> ‘ohci_dump’
>
> Signed-off-by: Vincent Stehlé
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
>
l behaivour
> and stopped respecting the usbcore.autosuspend parameter for hubs.
>
> Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0"
>
> Cc: [3.8+]
> Signed-off-by: Roger Quadros
Acked-by: Alan Stern
--
To unsubscribe from this list: send
olumn rule, you should reduce the
excessive indentation on the continued line.
Apart from that,
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 1 Aug 2014, Oliver Neukum wrote:
> On Fri, 2014-08-01 at 10:24 -0400, Alan Stern wrote:
> > On Fri, 1 Aug 2014, Oliver Neukum wrote:
> >
> > > usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
> > > for output URBs. That causes usbc
RB_DIR_OUT);
> if (uurb->flags & USBDEVFS_URB_ISO_ASAP)
> u |= URB_ISO_ASAP;
> - if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
> + if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)
> u |= URB_SHORT_NOT_OK;
>
ep, then the penalty would be the timeout ie
> 2000 ms.
>
> Results:
>
> Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
> Kernel resumes in 461 msecs without this patch, but hard disk is
> assigned a new device address. Same system resumes in
On Fri, 30 May 2014, Huang Rui wrote:
> On Fri, May 30, 2014 at 10:25:40AM -0400, Alan Stern wrote:
> > On Fri, 30 May 2014, Huang Rui wrote:
> >
> >
> > Ugh, don't make a copy of the existing code. Use the facilities the
> > way they are m
;entries;
> + long timeleft;
...
Ugh, don't make a copy of the existing code. Use the facilities the
way they are meant to be used. Like the patch below.
Alan Stern
Index: usb-3.15/drivers/usb/misc/usbtest.c
===
--- u
should do it in special class driver, not in core level,
> right?
Right. In this case, the class driver is usbtest.c.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 29 May 2014, Huang Rui wrote:
> On Thu, May 29, 2014 at 10:50:03AM -0400, Alan Stern wrote:
> > On Thu, 29 May 2014, Huang Rui wrote:
> >
> > > Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> > > completion signal. When
imeout value you specify has to
work for _all_ places that call this routine. 10 minutes might be
okay.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
iv(hcd);
>
> usb_remove_hcd(hcd);
> usb_put_hcd(hcd);
>
> - clk = devm_clk_get(&pdev->dev, NULL);
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + if (!IS_ERR(priv->clk))
> + clk_disable_unprepare(pr
p.
>
> These values are recommended practice for all Tegra chips. However,
> I've only noticed practical problems when not setting them this way on
> systems using Tegra124. Hence, CC: stable only for recent kernels which
> actually support Tegra124.
>
> Cc: # 3.14+
&g
On Fri, 7 Mar 2014, David Laight wrote:
> From: Alan Stern
> > On Fri, 7 Mar 2014, David Laight wrote:
> >
> > > From: Mathias Nyman
> > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8.
> > >
ork most of the time.
If hcd->self.no_sg_constraint wasn't sent, then certain commands would
fail always, instead of failing occasionally.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majo
lse)
> the ax88179_178a driver won't request transmits that need fragmenting.
True. But xhci-hcd _will_ set the flag, because of patch 1 in this
series. In other words, patch 1 makes patch 2 necessary.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable&
On Wed, 5 Mar 2014, Dan Williams wrote:
> On Mon, Mar 3, 2014 at 1:25 PM, Daniel Mack wrote:
> > From: Alan Stern
> >
> > Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE
> > CACHE command, as shown in this email thread:
> >
> >
B and get back an -EPIPE
> response.
In theory, errors caused by the device sending a STALL should be
handled just like other sorts of errors. After the URB which got the
STALL has been given back, the HCD should automatically restart the
endpoint ring. It should not wait for usb_clear_halt.
Al
On Tue, 21 Jan 2014, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jan 21, 2014 at 01:06:19PM -0500, Alan Stern wrote:
> > > You could try to differentiate between an endpoint halt that requires a
> > > manual cleanup, and ones that the upper layer should handle, pe
CD should always accept URB
submissions. Nothing will get sent to the device until the HCD clears
any host-side halts, but the upper layers don't worry about that
because the HCD takes care of it automatically.
Contrariwise, the upper layers are responsible for clearing device-side
halts. Th
; issues than new code.
Reverting Ksenia's patch from the stable kernels is okay with me.
Strictly speaking, I guess this means you have to revert it from the
current kernel as well, and then write your new patch to go on top of
the reversion.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
a transaction. A single
TRB can encompass a single transaction or multiple transactions, and a
single transfer can involve more than one TRB.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 8 Jan 2014, David Laight wrote:
> > From: Alan Stern
> >
> > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > the first place?
>
> Because it can't write in a link TRB because other parts of the
> code use link TRBs t
tart the ring
againk, just tell the host controller to move the dequeue pointer up to
the start of the next surviving URB. (You'll also have to adjust the
CYCLE bits of the TRBs that get skipped over, but that's trivial.)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ems completely wrong. Why do you want
to reset the port? What happens if you don't reset the port?
Wouldn't it be simpler to disable the port? Then usbcore would do the
reset for you. That certainly is safer than a reset.
Instead of doing this always for all mice, wouldn't it be better to
test first and see whether it really is needed?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
igned-off-by: Martin K. Petersen
> Acked-by: Alan Stern
> Tested-by: Stuart Foster
> Cc: stable@vger.kernel.org
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 3b1ea34..eaa808e 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -1031,6 +1
On Mon, 29 Jul 2013, Stuart Foster wrote:
> > Stuart and Ed, does Martin's patch fix your problem?
> >
> > Alan Stern
> >
> >
> Hi Alan,
>
> The patch is good for me.
>
> thanks
There also have been positive reports from Marc Meledandri and Ph
On Mon, 29 Jul 2013, Martin K. Petersen wrote:
> >>>>> "Alan" == Alan Stern writes:
>
> Alan,
>
> Alan> It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE
> Alan> SAME heuristics). This commit adds a call to scsi_get_vpd_pag
On Sat, 27 Jul 2013, Stuart Foster wrote:
> On 07/27/13 20:34, Alan Stern wrote:
> > On Sat, 27 Jul 2013, Stuart Foster wrote:
> >
> >> On 07/27/13 15:58, Alan Stern wrote:
> >>> On Sat, 27 Jul 2013, Stuart Foster wrote:
> >>>
> >>&g
);
This code cries out for refactoring. Why test pdev->class and
pdev->vendor in the same way in three different places? Those two
tests should be moved directly into usb_is_intel_switchable_xhci().
The other helper functions then become simple comparisons. As far as
I'm c
> May 8 17:01:56 richardiv kernel: [ 1680.924472] cannot submit urb (err = -18)
>
> real 0m10.023s
> user 0m0.008s
> sys 0m0.004s
I don't know if you want to investigate this in any detail. If you do,
please post a usbmon trace of a failed playback.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
?p=linux/kernel/git/stable/stable-queue.git;a=summary
This patch should not be applied to this kernel, as per the
instructions:
> This should be applied to -stable kernels going back to 3.6.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable&q
l.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
This patch should not be applied to this kernel, as per the
instructions:
> This should be applied to -stable kernels going back to 3.6.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stabl
On Wed, 27 Mar 2013, Felipe Balbi wrote:
> From: Alan Stern
>
> This patch (as1666) fixes a regression in the UDC core. The core
> takes care of unbinding gadget drivers, and it does the unbinding
> before telling the UDC driver to turn off the controller hardware.
> Wh
On Wed, 20 Mar 2013, Greg Kroah-Hartman wrote:
> On Wed, Mar 20, 2013 at 04:41:21PM -0400, Alan Stern wrote:
> > On Wed, 20 Mar 2013, Greg Kroah-Hartman wrote:
> >
> > > > > Ok, I'll postpone this patch for the next stable release, in time for
> > &g
the time, but
it shouldn't be in any kernel earlier than 3.6. I guess the best thing
to do is queue up a reversion for those two series.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Mar 2013, Sven Joachim wrote:
> On 2013-03-19 21:10 +0100, Alan Stern wrote:
>
> > On Tue, 19 Mar 2013, Sven Joachim wrote:
> >
> >> > In what way is resume broken?
> >>
> >> The kernel comes back, but the screen is black. Manuall
ed?
There was another report on the linux-usb mailing list today of this
same patch causing the khubd task to hang. I'm thinking that you might
be facing a similar problem.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to m
ide more information
> if needed.
In what way is resume broken?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Mar 2013, Ben Hutchings wrote:
> On Mon, 2013-03-18 at 04:22 +, Ben Hutchings wrote:
> > 3.2-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Alan Stern
> >
> > co
ither one of them would have sufficed. I
simply submitted both patches.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ers
> bf79379 USB: EHCI: fix timer bug affecting port resume
> d01875f USB: EHCI: unlink one async QH at a time
> 269ef9f USB: EHCI: remove ASS/PSS polling timeout
>
> Alan, any ideas?
A lot of people have reported problems caused by the last one
(269ef9f). I haven't had time to
scan ended.
Not doing this properly can result in memory leaks and failures to
complete isochronous URBs.
This patch is meant for the 3.7 and earlier stable kernels. It was
back-ported from upstream commit
b09a61cc0bc2a7151f4ab652489e85253d5d0175.
Signed-off-by: Alan Stern
Reported-and-tested
what is
going wrong. Please ask the reporter to post usbmon traces showing
what happens in both a failed and a successful recording attempt.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
Mor
On Mon, 26 Nov 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 26 Nov 2012, Oliver Neukum wrote:
> >> On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
> >>> usb_autopm_get_interface() cannot be called from the USB probe c
> >
> > usb_autopm_get_interface() cannot be called from the USB probe callback.
>
> You can use usb_autopm_get_interface_no_resume()
> During probe() the device is known to not be suspended.
In fact, as far as I know you _can_ use usb_autopm_get_interface() from
within a prob
really an improvement over nobbling the IDENTIFY results to
> force SCSI_2?
Yes. There was a good reason for getting rid of that change to the
INQUIRY result (some devices don't like it when the LUN bits are
stuffed into the second byte of each CDB), and I don't want to go back.
Alan
irst and it indicates a capacity
below 2 TB.
In the end, usb-storage may be forced to use the NO_READ_CAPACITY_16
flag with all devices except those we can positively identify as a
USB-(S)ATA bridge.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the bod
ice(dev))
err = scsi_dev_type_resume(dev);
if (err == 0) {
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
}
pm_runtime_put_sync(dev->parent);
Alan Stern
--
To unsubscribe from this list: send the line "u
all the fields
in the RC16 response if the RC16 capacity disagrees with the RC10
capacity and the RC10 capacity is under 2 TB.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 3 Jul 2012, Matthew Wilcox wrote:
> On Tue, Jul 03, 2012 at 11:49:00AM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2012, James Bottomley wrote:
> >
> > > > What happened is that T10
> > > > in their infinite wisdom decided to put things like "
r level when in fact they support some but not
all of the required commands. Then what do you do? Put them on the
whitelist because of the commands they support, or leave them off
because of the other ones? What happens later on when you decide to
use more of the required commands?
Alan St
l.
>
> OK, I will submit a new patch which just holds device lock.
>
> Alan, do you have objections on the new one?
No objections. It should end up being pretty much like one of the
patches you posted earlier.
Should there be an option for a debug log of each device name just
befor
On Mon, 11 Jun 2012, Ming Lei wrote:
> On Mon, Jun 11, 2012 at 10:16 PM, Alan Stern
> wrote:
>
> >> +
> >> + � � � � � � if (nonlocked)
> >> + � � � � � � � � � � dev_err(dev, "can't hold %slock for shutdown\n",
> >> + � � �
(nonlocked)
> + dev_err(dev, "can't hold %slock for shutdown\n",
> + nonlocked == 1 ? "" : "parent ");
Even if the parent can't be locked, you should still try to lock the
device.
Al
fter it is checked in
> device_shutdown().
>
> So just hold device lock and its parent lock if it has to fix the
> races.
>
> Cc: Alan Stern
> Cc: stable@vger.kernel.org
> Signed-off-by: Ming Lei
> ---
> drivers/base/core.c |8
> 1 file changed, 8 insertions(+
> This was experienced when we share the same IRQ line between OHCI and EHCI
> controllers.
>
> Signed-off-by: Nicolas Ferre
> Tested-by: Christian Eggers
> Cc: stable
Acked-by: Alan Stern
> ---
> drivers/usb/host/ohci-at91.c | 11 ++-
> 1 file chan
rb *urb);
> extern void usb_poison_urb(struct urb *urb);
> extern void usb_unpoison_urb(struct urb *urb);
> +extern void usb_block_urb(struct urb *urb);
> +extern void usb_unblock_urb(struct urb *urb);
changing this to
#define usb_unblock_urb usb_unpoison_urb
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sically the URB state is maintained by device driver, so looks
> better to add the state into specific device driver instead of struct URB to
> save each URB storage, but if so, the solution will become more
> complicated than the way of adding lock.
Why? In one case you add a stat
On Tue, 24 Apr 2012, Oliver Neukum wrote:
> Am Montag, 23. April 2012, 17:42:11 schrieb Alan Stern:
> > I don't like the idea of changing the status codes. It would mean
> > changing usb_kill_urb too.
>
> Why?
Okay, maybe it wouldn't. If usb_unlink_urb retu
On Sun, 22 Apr 2012, Ming Lei wrote:
> On Sun, Apr 22, 2012 at 8:50 PM, Alan Stern wrote:
> > On Sun, 22 Apr 2012, Ming Lei wrote:
> >
> >> > Although the kerneldoc doesn't actually say so, it should be safe to
> >> > assume that usb_unlink_urb
On Sun, 22 Apr 2012, Ming Lei wrote:
> On Sun, Apr 22, 2012 at 1:31 AM, Alan Stern wrote:
> > On Sat, 21 Apr 2012, Ming Lei wrote:
> >> How about always scheduling a tasklet to run what usb_unlink_urb does?
> >> just implement usb_unlink_urb as something like
> >
r will access some global data.
That would be a completely separate race, right? So maybe it can use a
different lock for protection -- and this other lock could be dropped
before usb_unlink_urb is called.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable&qu
ke the lock for resubmission. If the URB completes
with status == -ECONNRESET then you know it was unlinked, so you don't
need to take the lock -- the race has already been lost.
Does that solve your problem?
Alan Stern
--
To unsubscribe from this list: send the line "uns
tasklet to run what usb_unlink_urb does?
> just implement usb_unlink_urb as something like
> tasklet_schedule(unlink_tasklet).
>
> Then we can have a uniform lock requirement and no changes are involved
> on host controller drivers.
The return values would not be correct.
On the oth
re's no natural time to give it back later.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; return 0;
On the other hand, it certainly seems like a good idea to move this
usb_set_intfdata() call above the loop where the ports are registered.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.k
1 - 100 of 101 matches
Mail list logo
