RE: [PATCH] usb-storage: scsiglue: Changing the command result
Hi, Attaching the new patch which will replace all the occurrences of DID_ABORT with DID_TIMOUT in USB Storage whenever it sees US_FLIDX_TIMED_OUT bit is set. Regards, Vishal -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, October 18, 2013 4:10 PM To: Vishal Annapurve Cc: Ming Lei; Linux Kernel Mailing List; linux-usb Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result On Fri, 18 Oct 2013, Vishal Annapurve wrote: > Hi Alan, > > What I wanted to say was If the bit US_FLIDX_TIMED_OUT can have more > meanings than timed out then maybe it would be best to override the > results after usb-storage is done with the command maybe in scsi layer > itself who aborted it in the first place. US_FLIDX_TIMED_OUT has one very specific meaning: command_abort() was called. Since command_abort() is the .eh_abort_handler routine, US_FLIDX_TIMED_OUT means that the SCSI layer decided to abort the command. Does the SCSI layer ever abort a command for any reason other than a timeout? If not, you may conclude that US_FLIDX_TIMED_OUT indicates a timeout. But if it does, you should not make this conclusion. > My concern was that overriding the result in usb storage or scsi > layers will have more side effects than doing it in scsiglue.c. > And by scsi-usb storage bridge what I meant was specifically the code > in scsiglue. > > Question about your last mail, do you want to change all the > occurrences of DID_ABORT from usb-storage to DID_TIMEOUT? Put it this way: There's no good reason for changing some of them but not all of them. And if you're going to change them at all, it makes no sense to first set the result to DID_ABORT and then change it to DID_TIMEOUT. You should simply set it to DID_TIMEOUT in the first place. Alan Stern usb_storage_change_abort_to_timeout.patch Description: usb_storage_change_abort_to_timeout.patch
Re: xhci-hcd wakeup settings
On Fri, 18 Oct 2013, Andiry Xu wrote: > Interesting. I used the following commands: > > #echo disabled > /sys/bus/pci/devices/:00:14.0/power/wakeup > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb3/power/wakeup > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb4/power/wakeup > > And a device plugging to xHCI port does wakeup the system from S3. > The test is performed on a Intel HM76 chipset. > > So it means xHCI driver should clear wakeup flags for suspended ports > in this case, just like ehci driver does. Correct? Yes, I agree. Sarah, is this worth reporting to the Intel chipset engineers as a bug? 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: [Pull Request] xhci: Final patches for 3.13
On Thu, Oct 17, 2013 at 05:29:15PM -0700, Sarah Sharp wrote: > The following changes since commit c00809d330cfe42469fcd1cfd63f0690b47ea9bb: > > USB: ohci-exynos: Remove non-DT support (2013-10-14 11:09:13 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > tags/for-usb-next-2013-10-17 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] USB: OHCI: Properly handle OHCI controller suspend
On Fri, Oct 18, 2013 at 04:36:11PM +0530, Majunath Goudar wrote: > Suspend scenario in case of OHCI was not properly > handled in ochi_suspend()routine. Alan Stern > suggested, properly handle OHCI suspend scenario. > > This does generic proper handling of suspend > scenario to all OHCI SOC. > > Signed-off-by: Manjunath Goudar > Acked-by: Alan Stern > Cc: Greg KH > Cc: linux-usb@vger.kernel.org > --- > V2->V3 : You sent 2 copies of "V3", yet there should have been some changes in this series based on prior review comments. Please try this again... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: gadget: s3c-hsotg: Include linux/of.h header
On Thu, Oct 17, 2013 at 01:55:02PM +0530, Sachin Kamat wrote: > 'of_match_ptr' is defined in linux/of.h. Include it explicitly to > avoid build breakage in the future. Why, what is going to happen in the "future"? Kernel development is almost always about the "now", who knows what is going to happen later. If you want to make a change that will require this type of file to be included, then do it, and fix things up. Otherwise I'm not going to take this series for things that are not a real problem/issue, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v4] usb: ohci: remove ep93xx bus glue platform driver
On Thu, Oct 17, 2013 at 05:11:54PM -0400, Alan Stern wrote: > On Thu, 17 Oct 2013, H Hartley Sweeten wrote: > > > Convert ep93xx to use the OHCI platform driver and remove the > > ohci-ep93xx bus glue driver. > > > > Enable CONFIG_OHCI_HCD_PLATFORM in the ep93xx_defconfig so that USB > > is still enabled by default on the EP93xx platform. > > > > Signed-off-by: H Hartley Sweeten > > Acked-by: Alan Stern > > Cc: Ryan Mallon > > Cc: Lennert Buytenhek > > Cc: Greg Kroah-Hartman > > Cc: Olof Johansson > > Cc: Russell King > > Good work; thanks a lot for doing this. > > Greg, please merge both of these v4 patches. Will do, thanks for reviewing them. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v4] usb: ohci: remove ep93xx bus glue platform driver
On Thu, Oct 17, 2013 at 01:29:11PM -0700, H Hartley Sweeten wrote: > Convert ep93xx to use the OHCI platform driver and remove the > ohci-ep93xx bus glue driver. > > Enable CONFIG_OHCI_HCD_PLATFORM in the ep93xx_defconfig so that USB > is still enabled by default on the EP93xx platform. > > Signed-off-by: H Hartley Sweeten > Acked-by: Alan Stern > Cc: Ryan Mallon > Cc: Lennert Buytenhek > Cc: Greg Kroah-Hartman > Cc: Olof Johansson > Cc: Russell King > --- > arch/arm/configs/ep93xx_defconfig | 1 + > arch/arm/mach-ep93xx/clock.c | 2 +- > arch/arm/mach-ep93xx/core.c | 38 +++- > drivers/usb/host/ohci-ep93xx.c| 184 > -- > drivers/usb/host/ohci-hcd.c | 18 > 5 files changed, 36 insertions(+), 207 deletions(-) > delete mode 100644 drivers/usb/host/ohci-ep93xx.c This patch doesn't apply to my usb-next branch of usb.git at all, what happened? Did Alan's other recent changes interfere with this? Can you refresh this against my tree and resend it so that I can apply it? I've applied the 1/2 patch already. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci-hcd wakeup settings
On Sat, Oct 19, 2013 at 03:36:58PM -0400, Alan Stern wrote: > On Fri, 18 Oct 2013, Andiry Xu wrote: > > > Interesting. I used the following commands: > > > > #echo disabled > /sys/bus/pci/devices/:00:14.0/power/wakeup > > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb3/power/wakeup > > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb4/power/wakeup > > > > And a device plugging to xHCI port does wakeup the system from S3. > > The test is performed on a Intel HM76 chipset. > > > > So it means xHCI driver should clear wakeup flags for suspended ports > > in this case, just like ehci driver does. Correct? > > Yes, I agree. > > Sarah, is this worth reporting to the Intel chipset engineers as a bug? I'm not sure. I'll have to take a closer look at it after I get back from LinuxCon/Kernel Summit and vacation (which won't be until after Nov 6th, FYI). I do agree that it should be fixed. I've stared at that code a couple times and tired to figure out why it unconditionally sets the wake on flags. I suppose it might even explain some of the spurious wakeups we've seen on xHCI host controllers, although those systems seem to reboot on shutdown even if there's no port changes. Also, hi Andiry! I haven't seen you on the mailing list in a while. :) Are you working for another company on the kernel again? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci-hcd wakeup settings
On Sat, Oct 19, 2013 at 9:45 PM, Sarah Sharp wrote: > On Sat, Oct 19, 2013 at 03:36:58PM -0400, Alan Stern wrote: >> On Fri, 18 Oct 2013, Andiry Xu wrote: >> >> > Interesting. I used the following commands: >> > >> > #echo disabled > /sys/bus/pci/devices/:00:14.0/power/wakeup >> > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb3/power/wakeup >> > #echo enabled > /sys/bus/pci/devices/:00:14.0/usb4/power/wakeup >> > >> > And a device plugging to xHCI port does wakeup the system from S3. >> > The test is performed on a Intel HM76 chipset. >> > >> > So it means xHCI driver should clear wakeup flags for suspended ports >> > in this case, just like ehci driver does. Correct? >> >> Yes, I agree. >> >> Sarah, is this worth reporting to the Intel chipset engineers as a bug? > > I'm not sure. I'll have to take a closer look at it after I get back > from LinuxCon/Kernel Summit and vacation (which won't be until after Nov > 6th, FYI). > > I do agree that it should be fixed. I've stared at that code a couple > times and tired to figure out why it unconditionally sets the wake on > flags. I suppose it might even explain some of the spurious wakeups > we've seen on xHCI host controllers, although those systems seem to > reboot on shutdown even if there's no port changes. > > Also, hi Andiry! I haven't seen you on the mailing list in a while. :) > Are you working for another company on the kernel again? > Hi Sarah, nice to see you again:) I'm still working on my PhD degree at UC San Diego. I'm working with storage devices on Linux, but not on driver. With fast non-volatile storage - perhaps as fast as DRAM, all the software overhead is significant, including the kernel switch, file system and interrupt handler, etc. So I'm trying to "bypass" the kernel entirely rather than working on it. I'm quite busy with my study so I only look at LKML occasionally. That's why it looks like I disappeared. Thanks for all the work you've done to fix my code. Thanks, Andiry -- 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
