With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream
ids, and those go from 1 - qdepth.
Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would
only get cmnd->request->tag from 0 - (qdepth - 1), and we used those as
uas-tags / stream-ids.
With blk-mq
Hi,
This one seems to have fallen through the cracks.
Regards,
Hans
--
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 help debugging xhci problems.
Signed-off-by: Hans de Goede
---
drivers/usb/host/xhci.c | 4
drivers/usb/host/xhci.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..36e3493 100644
--- a/drivers/usb/host/xhci.c
+++ b/d
Hi Greg,
You probably already have this one queued up for merging once 3.18-rc1 is out,
just resending it to make sure, as this fixes a nasty oops which may trigger
when uas devices get unplugged.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body o
This commit fixes the following oops:
[10238.622067] scsi host3: uas_eh_bus_reset_handler start
[10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
[10245.779365] usb 3-4: device descriptor read/8, error -110
[10245.883331] usb 3-4: reset SuperSpeed USB device number 3 usin
Hi,
Some mass storage devices return a bogus value in response to a Get Max LUN
request. The Iomega Jaz USB Adapter responds with 0x10, hence my recent patch
to use the US_FL_SINGLE_LUN quirk for it.
The USB MSC Bulk Only Transport document says "The device shall return one byte
of data that c
On Wed, Oct 08, 2014 at 02:12:18PM -0700, David Cohen wrote:
> use_mm(io_data->mm);
> for (i = 0; i < io_data->nr_segs; i++) {
> + size_t len = min_t(size_t, ret - pos,
> + io_data->iovec[i].iov_len);
> +
On Sun, Oct 12, 2014 at 08:12:28PM +0100, Al Viro wrote:
> On Wed, Oct 08, 2014 at 02:12:18PM -0700, David Cohen wrote:
> > use_mm(io_data->mm);
> > for (i = 0; i < io_data->nr_segs; i++) {
> > + size_t len = min_t(size_t, ret - pos,
> > +
On Sun, 12 Oct 2014, Mark Knibbs wrote:
> --- linux-3.17/drivers/usb/storage/transport.c.orig 2014-10-05
> 20:12:36.0 +0100
> +++ linux-3.17/drivers/usb/storage/transport.c2014-10-12
> 13:11:38.0 +0100
> @@ -1035,9 +1035,20 @@ int usb_stor_Bulk_max_lun(struct us_data
>
On Sun, Oct 12, 2014 at 12:33:28PM +0200, Hans de Goede wrote:
> Hi Greg,
>
> You probably already have this one queued up for merging once 3.18-rc1 is out,
> just resending it to make sure, as this fixes a nasty oops which may trigger
> when uas devices get unplugged.
I have to wait for 3.18-rc1
On Sat, Oct 11, 2014 at 11:40:54PM +0200, Jonas Brunsgaard wrote:
> Signed-off-by: Jonas Brunsgaard
_what_ "style" issues did you fix?
How did you fix them?
Why did you fix them?
Please, you have to provide something in the changelog here, it can't
just be blank.
Also, make sure you aren't do
From: Michael Grzeschik
The current EHCI implementation is prepared to toggle the
PORT_POWER bit to enable or disable a USB-Port. In some
cases this port power can not be just toggled by the PORT_POWER
bit, and the gpio-regulator is needed to be toggled too.
This patch defines a port power contr
From: Michael Grzeschik
This patch adds an external portpower override callback, only single
port regulator control is supported now.
Signed-off-by: Michael Grzeschik
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/host.c | 67 +--
1 file changed,
Changes for v3:
- Using struct ehci_hcd * instead of struct usb_hcd * for ehci_port_power
's the 1st parameter
- Call ehci_port_power at every places which port power needs to be
changed.
- Call platform defined hcd->driver->port_power at ehci_port_power
if it is defined
- Clear PORT_RWC bits befor
From: Fabio Estevam
MM core code already complains when devm_kzalloc() fails, so no need to print
the error locally.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/ci_hdrc_imx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/
From: Fabio Estevam
MM core code already complains when devm_kzalloc() fails, so no need to print
the error locally.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chi
On 10 October 2014 20:50, Felipe Balbi wrote:
> Hi,
>
> On Fri, Oct 10, 2014 at 11:37:31AM +0530, Kiran Raparthy wrote:
>> Hi Felipe,
>> Thank you very much for taking time in reviewing the patch.
>> I will try to improve the patch as per your suggestions.
>> however,i have few queries which i wan
Hi Vivek,
> Exynos7 also has a separate special gate clock going to the IP
> apart from the usual AHB clock. So add support for the same.
As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
by the driver. Adding only sclk is not enough.
>
> Signed-off-by: Vivek Gautam
> ---
>
Hi Vivek,
> Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
> clock, as well as 60MHz utmi phy clock.
> So get the same and control in the phy-exynos5-usbdrd driver.
In case of the PHY the situation is pretty much the same as with
DWC3 core. Here we should control 6 clocks to make
Hi Vivek,
> Some Exynos SoCs have a separate regulator controlling a
I guess you meant the Exynos based *boards* instead of SoCs,
since Exynos SoCs don't have any boost regulators.
> Boost 5V supply which goes as input for VBUS regulator.
> So adding a control for the same in driver, to enable
>
On Mon, Oct 13, 2014 at 10:36 AM, Anton Tikhomirov
wrote:
> Hi Vivek,
>
>> Some Exynos SoCs have a separate regulator controlling a
>
> I guess you meant the Exynos based *boards* instead of SoCs,
> since Exynos SoCs don't have any boost regulators.
Right, should be boards instead. Thanks for poi
On Sun, Oct 12, 2014 at 11:26:33PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> MM core code already complains when devm_kzalloc() fails, so no need to print
> the error locally.
>
For the title: you may need to add "usb" first. "usb: chipdea: xxx".
Besides, would you show me where the
The individual PHY driver should take this responsibility if it
needs to delay between clear portsc.phcd and let the phy leave
low power mode.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/ch
The phy needs some delay to output the stable status from low
power mode. And for OTGSC, the status inputs are debounced
using a 1 ms time constant, so, delay 2ms for controller to get
the stable status(like vbus and id) when the phy leaves low power.
Signed-off-by: Peter Chen
---
drivers/usb/ch
Add system power management support
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 6cbfeb5..5b3e771 100644
--- a/drivers/u
Add basic system power management support
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 74b5b09..aa66199 1
This patch set adds the basic system power management. For glue layer,
I only add it for imx which I am familar with it and have hardware for it.
For msm, it has pm management at its phy driver, zevio and pci has no
pm (clock & phy) information for its driver, so I leave these three
glue layer driv
27 matches
Mail list logo
