Tascam US-122L - Corrupt USB descriptor
Hi all, I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working. I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but then describes 3 separate with the same interface number for the last 2... could it be that this is confusing the Linux USB stack? I have attached a copy of the descriptor and an annotated 'lsusb -vv'. >From my experience with the HID subsystem, they have a mechanism for patching HID descriptors, is the same possible for the base USB descriptor? Trolling through 'drivers/usb' I didn't see anything... any suggestions? If this is possible I can try to increase the interface count and renumber the last one. Cheers, Simon. PS. For reference the device is: Model No: US-122L Serial: (21)0120xxx Other barcode: 043774021628 12 01 00 02 00 00 00 40 44 06 0e 80 00 01 01 02 |...@D...| 0010 03 01 09 02 48 00 02 01 00 80 f0 09 04 00 00 00 |H...| 0020 ff 00 00 00 09 04 01 00 00 ff 00 00 00 09 04 01 || 0030 01 04 ff 00 00 00 09 05 81 05 4e 00 01 00 00 09 |..N.| 0040 05 02 05 4e 00 01 00 00 09 05 83 02 09 00 04 00 |...N| 0050 00 09 05 04 02 00 02 04 00 00|..| 005a Bus 001 Device 042: ID 0644:800e TEAC Corp. TASCAM US-122L -- 12 01 00 02 00 00 00 40 44 06 0e 80 00 01 01 02 |...@D...| 0010 03 01 __ |H...| -- Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0644 TEAC Corp. idProduct 0x800e TASCAM US-122L bcdDevice1.00 iManufacturer 1 (error) <-- Here be Errors! iProduct2 (error) iSerial 3 (error) bNumConfigurations 1 Configuration Descriptor: -- 0010 _ 09 02 48 00 02 01 00 80 f0 __ |H...| -- bLength 9 bDescriptorType 2 wTotalLength 72 bNumInterfaces 2 <--- 2 interfaces bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 480mA Interface Descriptor: <-- that's 1 -- 0010 _ 09 04 00 00 00 |H...| 0020 ff 00 00 00 || -- bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: <-- that's 2 -- 0020 ___ 09 04 01 00 00 ff 00 00 00 || -- bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: <-- that's 3, err wait... -- 0020 ___ 09 04 01 || 0030 01 04 ff 00 00 00 __ |..N.| -- bLength 9 bDescriptorType 4 bInterfaceNumber1 <-- interface duplicate!! bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: -- 0030 _ 09 05 81 05 4e 00 01 00 00 __ |..N.| -- bLength 9 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes5 Transfer TypeIsochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes bInterval 1 bRefresh0 bSynchAddress 0 Endpoint Descriptor: -- 0030 _ 09 |..N.| 0040 05 02 05 4e 00 01 00 00 ___ |...
[PATCH 1/1] doc: usb: chipidea: update the doc for OTG FSM
Since we have added otg version and HNP polling support, update related documentation. Signed-off-by: Peter Chen --- Documentation/usb/chipidea.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt index 678741b..edf7cdf 100644 --- a/Documentation/usb/chipidea.txt +++ b/Documentation/usb/chipidea.txt @@ -3,14 +3,17 @@ To show how to demo OTG HNP and SRP functions via sys input files with 2 Freescale i.MX6Q sabre SD boards. -1.1 How to enable OTG FSM in menuconfig +1.1 How to enable OTG FSM --- -Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules. -If you want to check some internal variables for otg fsm, -mount debugfs, there are 2 files which can show otg fsm -variables and some controller registers value: +1.1.1 Select CONFIG_USB_OTG_FSM in menuconfig, rebuild kernel +Image and modules. If you want to check some internal +variables for otg fsm, mount debugfs, there are 2 files +which can show otg fsm variables and some controller registers value: cat /sys/kernel/debug/ci_hdrc.0/otg cat /sys/kernel/debug/ci_hdrc.0/registers +1.1.2 Add below entries in your dts file for your controller node + otg-rev = <0x0200>; + adp-disable; 1.2 Test operations --- -- 1.9.1 -- 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: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
On Wed, 2016-04-13 at 08:42 +0300, Felipe Balbi wrote:
> USB3 devices, because they are much newer, have much
> less chance of having issues with larger transfers.
>
> We still keep a limit because anything above 2048
> sectors really rendered negligible speed
> improvements, so we will simply ignore
> that. Transferring 1MiB should already give us
> pretty good performance.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/storage/scsiglue.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index 9da1fb3d0ff4..2bb6a88858ea 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
> if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
> blk_queue_max_hw_sectors(sdev->request_queue,
> max_sectors);
> + } else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
> + /* USB3 devices will be limited to 2048 sectors. This gives us
> + * better throughput on most devices.
> + */
> + blk_queue_max_hw_sectors(sdev->request_queue, 2048);
Should we really test for speed rather than USB version?
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: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
Hi,
Oliver Neukum writes:
> On Wed, 2016-04-13 at 08:42 +0300, Felipe Balbi wrote:
>> USB3 devices, because they are much newer, have much
>> less chance of having issues with larger transfers.
>>
>> We still keep a limit because anything above 2048
>> sectors really rendered negligible speed
>> improvements, so we will simply ignore
>> that. Transferring 1MiB should already give us
>> pretty good performance.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> drivers/usb/storage/scsiglue.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
>> index 9da1fb3d0ff4..2bb6a88858ea 100644
>> --- a/drivers/usb/storage/scsiglue.c
>> +++ b/drivers/usb/storage/scsiglue.c
>> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
>> if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
>> blk_queue_max_hw_sectors(sdev->request_queue,
>>max_sectors);
>> +} else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
>> +/* USB3 devices will be limited to 2048 sectors. This gives us
>> + * better throughput on most devices.
>> + */
>> +blk_queue_max_hw_sectors(sdev->request_queue, 2048);
>
> Should we really test for speed rather than USB version?
bcdUSB >= 0x0300 ? Sure, why not...
--
balbi
signature.asc
Description: PGP signature
Re: [-next] BUG_ON in scsi_target_destroy()
Hi Sergey, Xiong,
Can you try below patch?
On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
> Hello,
>
> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
> Author: Johannes Thumshirn
> Date: Tue Apr 5 11:50:44 2016 +0200
>
> scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
>
>
> BUG_ON()s (next-20160411) each time I remove a usb flash
>
> [ 49.561600] [] scsi_target_destroy+0x5a/0xcb [scsi_mod]
> [ 49.561607] [] scsi_target_reap+0x4a/0x4f [scsi_mod]
> [ 49.561613] [] __scsi_remove_device+0xc3/0xd0 [scsi_mod]
> [ 49.561619] [] scsi_forget_host+0x52/0x63 [scsi_mod]
> [ 49.561623] [] scsi_remove_host+0x8c/0x102 [scsi_mod]
> [ 49.561627] [] usb_stor_disconnect+0x6b/0xab
> [usb_storage]
> [ 49.561634] [] usb_unbind_interface+0x77/0x1ca [usbcore]
> [ 49.561636] [] __device_release_driver+0x9d/0x121
> [ 49.561638] [] device_release_driver+0x23/0x30
> [ 49.561639] [] bus_remove_device+0xfb/0x10e
> [ 49.561641] [] device_del+0x164/0x1e6
> [ 49.561648] [] ? remove_intf_ep_devs+0x3b/0x48 [usbcore]
> [ 49.561655] [] usb_disable_device+0x84/0x1a5 [usbcore]
> [ 49.561661] [] usb_disconnect+0x94/0x19f [usbcore]
> [ 49.561667] [] hub_event+0x5c1/0xdea [usbcore]
> [ 49.561670] [] process_one_work+0x1dc/0x37f
> [ 49.561672] [] worker_thread+0x282/0x36d
> [ 49.561673] [] ? rescuer_thread+0x2ae/0x2ae
> [ 49.561675] [] kthread+0xd2/0xda
> [ 49.561678] [] ret_from_fork+0x22/0x40
> [ 49.561679] [] ? kthread_worker_fn+0x13e/0x13e
>
> -ss
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0734927..0c00928 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
void __scsi_remove_device(struct scsi_device *sdev)
{
struct device *dev = &sdev->sdev_gendev;
+ struct scsi_target *starget;
/*
* This cleanup path is not reentrant and while it is impossible
@@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
* remoed sysfs visibility from the device, so make the target
* invisible if this was the last device underneath it.
*/
- scsi_target_reap(scsi_target(sdev));
+ starget = scsi_target(sdev);
+ starget->state = STARGET_REMOVE;
+ scsi_target_reap(starget);
put_device(dev);
}
--
Johannes Thumshirn
Storage
jthumsh...@suse.de
+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: Tascam US-122L - Corrupt USB descriptor
Simon Wood wrote: > I have been struggling for the past few days to get a Tascam US-122L (USB > sound-card/midi interface) working, despite reading numerous forum > postings I have only been able to get the midi portion working. Does it show up with "aplay -l"? > I note that the USB descriptor seems to be corrupt. It declares 2 > interfaces, but then describes 3 separate with the same interface number > for the last 2. The descriptors describe two alternate settings for the same interface. This is a feature, which is required for audio devices. > iManufacturer 1 (error) <-- Here be > Errors! > iProduct2 (error) > iSerial 3 (error) It's possible that lsusb does not have the permissions needed to send the messages to ask for the strings. Try running it as root. Regards, Clemens -- 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 v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform
On 11/04/16 09:41, Chunfeng Yun wrote: A new compatible string, "mediatek,mt2701-u3phy", is added. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/phy/phy-mt65xx-usb.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Matthias Brugger diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt index 00100cf..33a2b1e 100644 --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt @@ -4,7 +4,9 @@ mt65xx USB3.0 PHY binding This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. Required properties (controller (parent) node): - - compatible : should be "mediatek,mt8173-u3phy" + - compatible : should be one of + "mediatek,mt2701-u3phy" + "mediatek,mt8173-u3phy" - reg: offset and length of register for phy, exclude port's register. - clocks : a list of phandle + clock-specifier pairs, one for each -- 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 09/16] phy: da8xx-usb: new driver for DA8xx SoC USB PHY
Hi,
On Friday 25 March 2016 05:21 AM, David Lechner wrote:
> This is a new phy driver for the SoC USB controllers on the TI DA8xx
> family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
> The USB 2.0 PHY also allows overriding the VBUS and ID pins.
>
> Signed-off-by: David Lechner
> ---
>
> v3 changes:
>
> * Uses syscon device for CFGCHIP2 instead of using it directly.
> * Got rid of nop inline funtions
> * Correct suffix on funtions to match ops.*
> * Added header file for extern method.
>
>
> drivers/phy/Kconfig | 10 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-da8xx-usb.c | 249
> ++
> include/linux/phy/phy-da8xx-usb.h | 19 +++
> 4 files changed, 279 insertions(+)
> create mode 100644 drivers/phy/phy-da8xx-usb.c
> create mode 100644 include/linux/phy/phy-da8xx-usb.h
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..c1d315f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -35,6 +35,16 @@ config ARMADA375_USBCLUSTER_PHY
> depends on OF && HAS_IOMEM
> select GENERIC_PHY
>
> +config PHY_DA8XX_USB
> + tristate "TI DA8xx USB PHY Driver"
> + depends on ARCH_DAVINCI_DA8XX
> + select GENERIC_PHY
> + select MFD_SYSCON
> + help
> + Enable this to support the USB PHY on DA8xx SoCs.
> +
> + This driver controls both the USB 1.1 PHY and the USB 2.0 PHY.
> +
> config PHY_DM816X_USB
> tristate "TI dm816x USB PHY driver"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..722e01c 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -5,6 +5,7 @@
> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
> +obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
> obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
> obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
> obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> new file mode 100644
> index 000..687d9a0
> --- /dev/null
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -0,0 +1,249 @@
> +/*
> + * phy-da8xx-usb - TI DaVinci DA8xx USB PHY driver
> + *
> + * Copyright (C) 2016 David Lechner
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct da8xx_usbphy {
> + struct phy_provider *phy_provider;
> + struct phy *usb11_phy;
> + struct phy *usb20_phy;
> + struct clk *usb11_clk;
> + struct clk *usb20_clk;
> + struct regmap *regmap;
> +};
> +
> +static int da8xx_usb11_phy_power_on(struct phy *phy)
> +{
> + struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(d_phy->usb11_clk);
> + if (ret)
> + return ret;
> +
> + regmap_write_bits(d_phy->regmap, CFGCHIP2_REG, CFGCHIP2_USB1SUSPENDM,
> + CFGCHIP2_USB1SUSPENDM);
> +
> + return 0;
> +}
> +
> +static int da8xx_usb11_phy_power_off(struct phy *phy)
> +{
> + struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
> +
> + regmap_write_bits(d_phy->regmap, CFGCHIP2_REG, CFGCHIP2_USB1SUSPENDM,
> 0);
> +
> + clk_disable_unprepare(d_phy->usb11_clk);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops da8xx_usb11_phy_ops = {
> + .power_on = da8xx_usb11_phy_power_on,
> + .power_off = da8xx_usb11_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int da8xx_usb20_phy_init(struct phy *phy)
> +{
> + struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(d_phy->usb20_clk);
> + if (ret)
> + return ret;
> +
> + regmap_write_bits(d_phy->regmap, CFGCHIP2_REG, CFGCHIP2_OTGPWRDN, 0);
> +
> + return 0;
> +}
> +
> +static int da8xx_usb20_phy_shutdown(struct phy *phy)
> +{
> + struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
> +
> + regmap_write_bits(d_phy->regmap, CFGCHIP2_REG, CFGCHIP2_OTGPWRDN,
> + CFGCHIP2_OTGPWRDN);
> +
> + cl
Re: [PATCH v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform
Hi, On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > A new compatible string, "mediatek,mt2701-u3phy", is added. how about changing the commit log to something like below? Add a new compatible string for "mt2701" Thanks Kishon > > Signed-off-by: Chunfeng Yun > --- > .../devicetree/bindings/phy/phy-mt65xx-usb.txt |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > index 00100cf..33a2b1e 100644 > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > @@ -4,7 +4,9 @@ mt65xx USB3.0 PHY binding > This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. > > Required properties (controller (parent) node): > - - compatible: should be "mediatek,mt8173-u3phy" > + - compatible: should be one of > + "mediatek,mt2701-u3phy" > + "mediatek,mt8173-u3phy" > - reg : offset and length of register for phy, exclude port's > register. > - clocks: a list of phandle + clock-specifier pairs, one for each > -- 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 v2 2/2] phy: phy-mt65xx-usb3: add support for mt2701 platform
Hi, On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > A new compatible string, "mediatek,mt2701-u3phy", is added. > > Some register settings to avoid RX sensitivity level degradation > which may arise on mt8173 platform are separated from other > platforms. > > Signed-off-by: Chunfeng Yun > --- > drivers/phy/Kconfig |5 ++- > drivers/phy/phy-mt65xx-usb3.c | 77 > - > 2 files changed, 54 insertions(+), 28 deletions(-) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 26566db..3037f28 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -218,9 +218,8 @@ config PHY_MT65XX_USB3 > depends on ARCH_MEDIATEK && OF > select GENERIC_PHY > help > - Say 'Y' here to add support for Mediatek USB3.0 PHY driver > - for mt65xx SoCs. it supports two usb2.0 ports and > - one usb3.0 port. > + Say 'Y' here to add support for Mediatek USB3.0 PHY driver, > + it supports multiple usb2.0 and usb3.0 ports. Do you mean this PHY driver support both USB2 and USB3? Then it's not really a USB3 PHY driver right? Thanks Kishon -- 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: [-next] BUG_ON in scsi_target_destroy()
Hi, On (04/13/16 10:41), Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? it panics my system. first it warn_on-s in lib/kobject.c:244 then NULL dereferences do_scan_async __scsi_remove_device scsi_target_reap device_del dpm_sysfs_remove sysfs_unmerge_group kernfs_find_and_get_ns kernfs_find_ns -ss -- 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] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar
Hi,
On Monday 11 April 2016 03:13 PM, Rafał Miłecki wrote:
> Northstar is a family of SoCs used in home routers. They have USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can be bound
> with an EHCI controller driver.
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Support reg-names and clock-names. As you can see PHY PLL is
> controlled over DMU, not a separated PHY registers range. This may
> be a bit confusing and even less clear if we happen to support more
> complex hardware in the future. Using a clear name should make code
> cleaner.
> Also use struct device *dev helpers to make code simpler.
> V3: Update Kconfig entry fixing 2.0 vs. 3.0 typo and removing info about
> bcma (this driver is not bcma specific).
> ---
> .../devicetree/bindings/phy/bcm-ns-usb2-phy.txt| 22
> drivers/phy/Kconfig| 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-bcm-ns-usb2.c | 139
> +
> include/linux/bcma/bcma.h | 1 +
> include/linux/bcma/bcma_driver_arm_c9.h| 15 +++
> 6 files changed, 187 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> create mode 100644 drivers/phy/phy-bcm-ns-usb2.c
> create mode 100644 include/linux/bcma/bcma_driver_arm_c9.h
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> new file mode 100644
> index 000..161ff76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> @@ -0,0 +1,22 @@
> +Driver for Broadcom Northstar USB 2.0 PHY
> +
> +Required properties:
> +- compatible: brcm,ns-usb2-phy
> +- reg: iomem address range of DMU (Device Management Unit)
> +- reg-names: "dmu", the only needed & supported reg right now
> +- clocks: USB PHY reference clock
> +- clock-names: "phy-ref-clk", the only needed & supported clock right now
> +
> +To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
> +requires passing phandle to the USB PHY reference clock.
> +
> +Example:
> + usb2-phy {
> + compatible = "brcm,ns-usb2-phy";
> + reg = <0x1800c000 0x1000>;
> + reg-names = "dmu";
> + #phy-cells = <0>;
> + #clock-cells = <0>;
Is clock-cells required here? It's generally added for clock providers right?
> + clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
> + clock-names = "phy-ref-clk";
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..3292502 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,6 +15,15 @@ config GENERIC_PHY
> phy users can obtain reference to the PHY. All the users of this
> framework should select this config.
>
> +config PHY_BCM_NS_USB2
> + tristate "Broadcom Northstar USB 2.0 PHY Driver
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + select GENERIC_PHY
> + help
> + Enable this to support Broadcom USB 2.0 PHY connected to the USB
> + controller on Northstar family.
> +
> config PHY_BERLIN_USB
> tristate "Marvell Berlin USB PHY Driver"
> depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..9c8f08d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,6 +3,7 @@
> #
>
> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> +obj-$(CONFIG_PHY_BCM_NS_USB2)+= phy-bcm-ns-usb2.o
> obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
> obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
> diff --git a/drivers/phy/phy-bcm-ns-usb2.c b/drivers/phy/phy-bcm-ns-usb2.c
> new file mode 100644
> index 000..ed92419
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-ns-usb2.c
> @@ -0,0 +1,139 @@
> +/*
> + * Broadcom Northstar USB 2.0 PHY Driver
> + *
> + * Copyright (C) 2016 Rafał Miłecki
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct bcm_ns_usb2 {
> + struct device *dev;
> + struct clk *ref_clk;
> + struct phy *phy;
> +};
> +
> +static int bcm_ns_usb2_phy_init(struct phy *phy)
> +{
> + struct bcm_ns_usb2 *usb2 = phy_get_drvdata(phy);
> + struct device *dev = usb2->dev;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct resource *res;
> + void __iomem *d
Re: [-next] BUG_ON in scsi_target_destroy()
On Mittwoch, 13. April 2016 23:47:04 CEST Sergey Senozhatsky wrote: > Hi, > > On (04/13/16 10:41), Johannes Thumshirn wrote: > > Hi Sergey, Xiong, > > > > Can you try below patch? > > it panics my system. > first it warn_on-s in lib/kobject.c:244 > > then NULL dereferences > do_scan_async > __scsi_remove_device > scsi_target_reap >device_del > dpm_sysfs_remove > sysfs_unmerge_group > kernfs_find_and_get_ns >kernfs_find_ns > > -ss > Thanks for the update, I'll have a look into the callchain -- Johannes Thumshirn Storage jthumsh...@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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: ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)
On Wed, Apr 13, 2016 at 08:44:25AM +0200, Rafał Miłecki wrote: > Hi, > > I'm trying to debug some EHCI issue so I enabled debugging by adding > ccflags-y := -DDEBUG > to the drivers/usb/host/Makefile > > Some of debugging lines contain random memory, e.g.: > ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o > > It's caused by dbg_status, dbg_cmd and dbg_port calling ehci_dbg even with: > # CONFIG_DYNAMIC_DEBUG > > The lack of above config implies using dummy dbg_status_buf, > dbg_command_buf and dbg_port_buf. They don't print anything to the > buffer and it stays uninitialized. > > Can you give me a hint how to solve this (apart from enabling > CONFIG_DYNAMIC_DEBUG for my debugging which I did)? Should dbg_*_buf > functions return some error instead of 0? We could check for that in > dbg_* functions then. Unfortunately I'm not sure how it's going to > affect other places, e.g. fill_registers_buffer. Please just enable CONFIG_DYNAMIC_DEBUG, as you did, that's the correct thing to do here, don't try to hack up Makefiles by hand. 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: Tascam US-122L - Corrupt USB descriptor
On Wed, April 13, 2016 3:01 am, Clemens Ladisch wrote: > Simon Wood wrote: > >> I have been struggling for the past few days to get a Tascam US-122L >> (USB >> sound-card/midi interface) working, despite reading numerous forum >> postings I have only been able to get the midi portion working. > > Does it show up with "aplay -l"? The card shows up under '/proc/asound/cards', but only as Midi. See attached for full listing. >> I note that the USB descriptor seems to be corrupt. It declares 2 >> interfaces, but then describes 3 separate with the same interface number >> for the last 2. > > The descriptors describe two alternate settings for the same interface. > This is a feature, which is required for audio devices. > > >> iManufacturer 1 (error)<-- Here be >> Errors! iProduct >> 2 (error) >> iSerial 3 (error) > > It's possible that lsusb does not have the permissions needed to send > the messages to ask for the strings. Try running it as root. Was running as root (on Xubuntu, 2 different machines, different installs). I note that sometimes this is OK, ie when I do '# echo 0 > /sys/bus/usb/devices/1-2/bConfigurationValue', but then I have no interfaces at all (no midi, no listing). Can anyone confirm they have a US-122L working on a new kernel. Is the USB descriptor the same as what I'm seeing, perhaps hardware changed at some point. Cheers, Simon# cat /proc/asound/cards > aplay_l.txt 0 [Audigy2]: Audigy2 - SB Audigy 2 ZS [SB0350] SB Audigy 2 ZS [SB0350] (rev.4, serial:0x20021102) at 0xccc0, irq 27 1 [US122L ]: USB US-122L - TASCAM US-122L TASCAM US-122L (644:800e if 0 at 001/005) # aplaymidi -l >> aplay_l.txt PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0SB Audigy 2 ZS [SB0350] Audigy MPU-401 (UART) 16:32 SB Audigy 2 ZS [SB0350] Audigy MPU-401 #2 17:0Emu10k1 WaveTableEmu10k1 Port 0 17:1Emu10k1 WaveTableEmu10k1 Port 1 17:2Emu10k1 WaveTableEmu10k1 Port 2 17:3Emu10k1 WaveTableEmu10k1 Port 3 20:0TASCAM US-122L TASCAM US-122L MIDI 1 # aplay -l >> aplay_l.txt List of PLAYBACK Hardware Devices card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 0: emu10k1 [ADC Capture/Standard PCM Playback] Subdevices: 32/32 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 Subdevice #8: subdevice #8 Subdevice #9: subdevice #9 Subdevice #10: subdevice #10 Subdevice #11: subdevice #11 Subdevice #12: subdevice #12 Subdevice #13: subdevice #13 Subdevice #14: subdevice #14 Subdevice #15: subdevice #15 Subdevice #16: subdevice #16 Subdevice #17: subdevice #17 Subdevice #18: subdevice #18 Subdevice #19: subdevice #19 Subdevice #20: subdevice #20 Subdevice #21: subdevice #21 Subdevice #22: subdevice #22 Subdevice #23: subdevice #23 Subdevice #24: subdevice #24 Subdevice #25: subdevice #25 Subdevice #26: subdevice #26 Subdevice #27: subdevice #27 Subdevice #28: subdevice #28 Subdevice #29: subdevice #29 Subdevice #30: subdevice #30 Subdevice #31: subdevice #31 card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 2: emu10k1 efx [Multichannel Capture/PT Playback] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 3: emu10k1 [Multichannel Playback] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 4: p16v [p16v] Subdevices: 1/1 Subdevice #0: subdevice #0
Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
On Tue, 12 Apr 2016, John Youn wrote: > > Wait, even SuperSpeed GEN1-only devices *must* set bcdUSB to 0x0310 ? Do > > you have a reference to that ? I find that pretty odd because this means > > that if I take any of my USB3 devices that I already have today, and run > > them against latest USBCV, they'll all fail and that's not very nice. > > Yup, that is exactly what happens. See 9.6.1 in the USB 3.1 > specification. Also the CV tool and compliance test specification from > USB IF say this as well. If you test with any existing SuperSpeed > device it will fail. I have the definite impression that the USB IF is getting more and more careless as it gets older. The first two paragraphs of 9.6.1 are actually contradictory! A device descriptor describes general information about a device. It includes information that applies globally to the device and all of the device’s configurations. A device has only one device descriptor. The device descriptor of an Enhanced SuperSpeed device shall have a version number of 3.1 (0310H). The device descriptor of an Enhanced SuperSpeed device operating in one of the USB 2.0 modes shall have a version number of 2.1 (0210H). If a device has only one device descriptor, how can it have different version numbers at different speeds? Besides, this doesn't say what the version number of a non-Enhanced SuperSpeed device should be. I don't see why the USBCV would conclude that a non-Enhanced device needs to set the version to 0x0310. 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: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
On Wed, 13 Apr 2016, Felipe Balbi wrote:
> USB3 devices, because they are much newer, have much
> less chance of having issues with larger transfers.
>
> We still keep a limit because anything above 2048
> sectors really rendered negligible speed
> improvements, so we will simply ignore
> that. Transferring 1MiB should already give us
> pretty good performance.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/storage/scsiglue.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index 9da1fb3d0ff4..2bb6a88858ea 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
> if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
> blk_queue_max_hw_sectors(sdev->request_queue,
> max_sectors);
> + } else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
> + /* USB3 devices will be limited to 2048 sectors. This gives us
> + * better throughput on most devices.
> + */
> + blk_queue_max_hw_sectors(sdev->request_queue, 2048);
> } else if (sdev->type == TYPE_TAPE) {
> /* Tapes need much higher max_sector limits, so just
>* raise it to the maximum possible (4 GB / 512) and
Argh! This has the same kind of problem as before. What will happen
when somebody has a USB-3 tape drive?
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: ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)
On Wed, 13 Apr 2016, Rafał Miłecki wrote:
> Hi,
>
> I'm trying to debug some EHCI issue so I enabled debugging by adding
> ccflags-y := -DDEBUG
> to the drivers/usb/host/Makefile
>
> Some of debugging lines contain random memory, e.g.:
> ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o
>
> It's caused by dbg_status, dbg_cmd and dbg_port calling ehci_dbg even with:
> # CONFIG_DYNAMIC_DEBUG
>
> The lack of above config implies using dummy dbg_status_buf,
> dbg_command_buf and dbg_port_buf. They don't print anything to the
> buffer and it stays uninitialized.
>
> Can you give me a hint how to solve this (apart from enabling
> CONFIG_DYNAMIC_DEBUG for my debugging which I did)? Should dbg_*_buf
> functions return some error instead of 0? We could check for that in
> dbg_* functions then. Unfortunately I'm not sure how it's going to
> affect other places, e.g. fill_registers_buffer.
That's a real problem. The whole ehci-dbg.c file needs to be cleaned
up -- we should just remove all the debugging when CONFIG_DYNAMIC_DEBUG
isn't enabled.
See if the patch below fixes the problem.
Alan Stern
Index: usb-4.4/drivers/usb/host/ehci-dbg.c
===
--- usb-4.4.orig/drivers/usb/host/ehci-dbg.c
+++ usb-4.4/drivers/usb/host/ehci-dbg.c
@@ -56,13 +56,6 @@ static void dbg_hcs_params (struct ehci_
label, buf);
}
}
-#else
-
-static inline void dbg_hcs_params (struct ehci_hcd *ehci, char *label) {}
-
-#endif
-
-#ifdef CONFIG_DYNAMIC_DEBUG
/* check the values in the HCCPARAMS register
* (host controller _Capability_ parameters)
@@ -95,13 +88,6 @@ static void dbg_hcc_params (struct ehci_
" 32 periodic list" : "");
}
}
-#else
-
-static inline void dbg_hcc_params (struct ehci_hcd *ehci, char *label) {}
-
-#endif
-
-#ifdef CONFIG_DYNAMIC_DEBUG
static void __maybe_unused
dbg_qtd (const char *label, struct ehci_hcd *ehci, struct ehci_qtd *qtd)
@@ -280,29 +266,6 @@ dbg_port_buf (char *buf, unsigned len, c
(status & PORT_CONNECT) ? " CONNECT" : "");
}
-#else
-static inline void __maybe_unused
-dbg_qh (char *label, struct ehci_hcd *ehci, struct ehci_qh *qh)
-{}
-
-static inline int __maybe_unused
-dbg_status_buf (char *buf, unsigned len, const char *label, u32 status)
-{ return 0; }
-
-static inline int __maybe_unused
-dbg_command_buf (char *buf, unsigned len, const char *label, u32 command)
-{ return 0; }
-
-static inline int __maybe_unused
-dbg_intr_buf (char *buf, unsigned len, const char *label, u32 enable)
-{ return 0; }
-
-static inline int __maybe_unused
-dbg_port_buf (char *buf, unsigned len, const char *label, int port, u32 status)
-{ return 0; }
-
-#endif /* CONFIG_DYNAMIC_DEBUG */
-
/* functions have the "wrong" filename when they're output... */
#define dbg_status(ehci, label, status) { \
char _buf [80]; \
@@ -324,13 +287,6 @@ dbg_port_buf (char *buf, unsigned len, c
/*-*/
-#ifdef STUB_DEBUG_FILES
-
-static inline void create_debug_files (struct ehci_hcd *bus) { }
-static inline void remove_debug_files (struct ehci_hcd *bus) { }
-
-#else
-
/* troubleshooting help: expose state in debugfs */
static int debug_async_open(struct inode *, struct file *);
@@ -1089,4 +1045,38 @@ static inline void remove_debug_files (s
debugfs_remove_recursive(ehci->debug_dir);
}
-#endif /* STUB_DEBUG_FILES */
+#else /* CONFIG_DYNAMIC_DEBUG */
+
+static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label) { }
+static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label) { }
+
+static inline void __maybe_unused dbg_qh(const char *label,
+ struct ehci_hcd *ehci, struct ehci_qh *qh) { }
+
+static inline int __maybe_unused dbg_status_buf(const char *buf,
+ unsigned len, const char *label, u32 status)
+{ return 0; }
+
+static inline int __maybe_unused dbg_command_buf(const char *buf,
+ unsigned len, const char *label, u32 command)
+{ return 0; }
+
+static inline int __maybe_unused dbg_intr_buf(const char *buf,
+ unsigned len, const char *label, u32 enable)
+{ return 0; }
+
+static inline int __maybe_unused dbg_port_buf(char *buf,
+ unsigned len, const char *label, int port, u32 status)
+{ return 0; }
+
+static inline void dbg_status(struct ehci_hcd *ehci, const char *label,
+ u32 status) { }
+static inline void dbg_cmd(struct ehci_hcd *ehci, const char *label,
+ u32 command) { }
+static inline void dbg_port(struct ehci_hcd *ehci, const char *label,
+ int port, u32 status) { }
+
+static inline void create_debug_files(struct ehci_hcd *bus) { }
+static inline void remove_debug_files(struct ehci_hcd *bus) { }
+
+#endif /* CONFIG_DYNAMIC_DEBUG */
Index: usb-4.4/drivers/usb/host/ehci.h
===
Re: [-next] BUG_ON in scsi_target_destroy()
On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote:
> Hi Sergey, Xiong,
>
> Can you try below patch?
>
> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
> > Hello,
> >
> > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
> > Author: Johannes Thumshirn
> > Date: Tue Apr 5 11:50:44 2016 +0200
> >
> > scsi: Add intermediate STARGET_REMOVE state to
> > scsi_target_state
> >
> >
> > BUG_ON()s (next-20160411) each time I remove a usb flash
> >
> > [ 49.561600] [] scsi_target_destroy+0x5a/0xcb
> > [scsi_mod]
> > [ 49.561607] [] scsi_target_reap+0x4a/0x4f
> > [scsi_mod]
> > [ 49.561613] [] __scsi_remove_device+0xc3/0xd0
> > [scsi_mod]
> > [ 49.561619] [] scsi_forget_host+0x52/0x63
> > [scsi_mod]
> > [ 49.561623] [] scsi_remove_host+0x8c/0x102
> > [scsi_mod]
> > [ 49.561627] [] usb_stor_disconnect+0x6b/0xab
> > [usb_storage]
> > [ 49.561634] []
> > usb_unbind_interface+0x77/0x1ca [usbcore]
> > [ 49.561636] []
> > __device_release_driver+0x9d/0x121
> > [ 49.561638] []
> > device_release_driver+0x23/0x30
> > [ 49.561639] [] bus_remove_device+0xfb/0x10e
> > [ 49.561641] [] device_del+0x164/0x1e6
> > [ 49.561648] [] ?
> > remove_intf_ep_devs+0x3b/0x48 [usbcore]
> > [ 49.561655] [] usb_disable_device+0x84/0x1a5
> > [usbcore]
> > [ 49.561661] [] usb_disconnect+0x94/0x19f
> > [usbcore]
> > [ 49.561667] [] hub_event+0x5c1/0xdea
> > [usbcore]
> > [ 49.561670] [] process_one_work+0x1dc/0x37f
> > [ 49.561672] [] worker_thread+0x282/0x36d
> > [ 49.561673] [] ? rescuer_thread+0x2ae/0x2ae
> > [ 49.561675] [] kthread+0xd2/0xda
> > [ 49.561678] [] ret_from_fork+0x22/0x40
> > [ 49.561679] [] ?
> > kthread_worker_fn+0x13e/0x13e
> >
> > -ss
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux
> > -scsi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..0c00928 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
> *sdev)
> void __scsi_remove_device(struct scsi_device *sdev)
> {
> struct device *dev = &sdev->sdev_gendev;
> + struct scsi_target *starget;
>
> /*
>* This cleanup path is not reentrant and while it is
> impossible
> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
> *sdev)
>* remoed sysfs visibility from the device, so make the
> target
>* invisible if this was the last device underneath it.
>*/
> - scsi_target_reap(scsi_target(sdev));
> + starget = scsi_target(sdev);
> + starget->state = STARGET_REMOVE;
> + scsi_target_reap(starget);
How about good grief no! A device with multiple targets will get it's
lists screwed with this
The STARGET_REMOVE state you added only applies to the case we're
trying to kill a target. In the natural operation case, which is what
everyone else is running into, we will try to remove a running target
when it has no more scsi devices left on it. So the correct patch
should be to make the BUG_ON see this:
James
---
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 27df7e7..e0a78f5 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target *starget)
struct Scsi_Host *shost = dev_to_shost(dev->parent);
unsigned long flags;
- BUG_ON(starget->state != STARGET_REMOVE &&
- starget->state != STARGET_CREATED);
+ BUG_ON(starget->state == STARGET_DEL);
starget->state = STARGET_DEL;
transport_destroy_device(dev);
spin_lock_irqsave(shost->host_lock, flags);
--
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: [PATCHv3] usb: dwc2: Add reset control to dwc2
Hi Dinh,
> From: Dinh Nguyen
>
> Allow for platforms that have a reset controller driver in place to bring the
> USB IP out of reset.
>
> Signed-off-by: Dinh Nguyen
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 88629be..6987ef3 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -45,6 +45,7 @@
> #include
> #include
> #include
>+#include
>
> #include
>
> @@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
> *hsotg)
> {
> int i, ret;
>
> + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
shouldn't this be documented in Documentation/devicetree/bindings/usb/dwc2.txt ?
> + if (IS_ERR(hsotg->reset)) {
> + dev_info(hsotg->dev, "Could not get reset control!\n");
> + if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
If this log message is really necessary, please move it down here and add the
error code into the message.
Thanks
Stefan
> + hsotg->reset = NULL;
> + }
--
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 xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]
One more question: this issue does not occur if I intentionally do not
claim the interface via libusb_claim_interface() before requesting
streaming image data from the camera. Does this make any sense? It's to
my understanding I should always claim the interface before issuing r/w
calls to the camera.
Thanks.
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail: matt...@giassa.net
website: www.giassa.net
> Original Message
> Subject: Re: USB xHCI regression after upgrading from kernel 3.19.0-51
> to 4.2.0-34.]
> From: Felipe Balbi
> Date: Sun, April 10, 2016 10:28 pm
> To: Matthew Giassa , linux-usb@vger.kernel.org,
> Mathias Nyman
>
>
> Hi,
>
> Matthew Giassa writes:
> > *Migrating from linux-media mailing list.
> >
> > Good day,
> >
> > I maintain an SDK for USB2.0 and USB3.0 U3V machine vision cameras, and
> > several of our customers have reported severe issues since upgrading
> > from
> > kernel 3.19.0-51 (Ubuntu 14.04.3 LTS) to kernel 4.2.0-34 (Ubuntu 14.04.4
> > LTS). I've received helpful advice from members of the libusb and
> > linux-usb mailing lists on how to generate useful logs to help diagnose
> > the issue, and have filed a bug to track this issue at:
> >
> >https://bugzilla.kernel.org/show_bug.cgi?id=115961
> >
> > It seems that with kernels newer than the 3.19 series (I've tested on
> > 4.2.0-34, and just repeated the tests on the latest 4.5.0 vanilla
> > release),
> > the cameras lock up, and cannot stream image data to the user
> > application. I
> > am able to resolve the issue on 4.2.0-34 by disabling USB power
> > management by adding "usbcore.autosuspend=-1". On the 4.5 kernel, this
> > "trick" doesn't work at all, and I have no way to get the cameras to
> > stream data. I can do simple USB control requests to query things like
> > register values and serial numbers, but that's it. Asynchronous bulk
> > transfers never succeed.
> >
> > I am using the libusb library to communicate with the cameras, and have
> > a fairly simple minimal working example to test the cameras, which:
> > * Creates a default libusb context.
> > * Enumerates available USB devices.
> > * Filters out a select device based on the vendor/product ID values.
> > * Opens the device, claims the bulk interface, and starts requesting
> > frames of image data via async bulk transfer requests.
> >
> > There are select cases where the issue does not arise:
> >
> > Special Cases:
> > * The issue does not occur when using USB2.0 cameras on a USB2.0 port,
> > regardless of the kernel in use.
> > * The issues occur only on Intel 8 Series and Intel 9 Series USB3.0
> > host controllers with 4.x kernels.
> > * Intel 10 Series host controllers have not yet been tested.
> > * The issues never occur on Fresco or Renesas host controllers,
> > regardless of the kernel in use.
> > * From visual inspection of lsusb output, the issue only appears to
> > happen when the U1 and U2 options are available to the device.
>
> okay, this is probably what's happening. Intel hosts are the only ones
> actively doing LPM, for all other hosts we don't have support.
>
> Here are a few question:
>
> a) Are you sure your cameras implement proper LPM ?
> b) I'm assuming the following makes the problem go away, can you test ?
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index f0640b7a1c42..9c3ead114ad5 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -127,8 +127,8 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> - xhci->quirks |= XHCI_LPM_SUPPORT;
> - xhci->quirks |= XHCI_INTEL_HOST;
> + /* xhci->quirks |= XHCI_LPM_SUPPORT; */
> + /* xhci->quirks |= XHCI_INTEL_HOST; */
> xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>
> c) I remember that I mentioned to Mathias that I'd seen XHCI LPM go a
> bit crazy and trigger constant LPM transactions; maybe you're just the
> first one to notice an actual functional breakage due to that.
>
> --
> balbi
--
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 0/1] xhci fix for usb-linus
Hi Greg One tiny fix to 4.6 to make sure xhci platform devices without a platform type don't get identified as XHCI_PLAT_TYPE_MARVELL_ARMADA (0) Peter Griffin (1): usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value drivers/usb/host/xhci-plat.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 -- 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 1/1] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
From: Peter Griffin
Otherwise generic-xhci and xhci-platform which have no data get wrongly
detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().
This fixes a regression in v4.5 for STiH407 family SoC's which use the
synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never
gets added.
I suspect this will also fix other dwc3 DT platforms such as Exynos,
although I've only tested on STih410 SoC.
Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
Cc: sta...@vger.kernel.org
Cc: gregory.clem...@free-electrons.com
Cc: yoshihiro.shimoda...@renesas.com
Signed-off-by: Peter Griffin
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-plat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
index 5a2e2e3..529c3c4 100644
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -14,7 +14,7 @@
#include "xhci.h" /* for hcd_to_xhci() */
enum xhci_plat_type {
- XHCI_PLAT_TYPE_MARVELL_ARMADA,
+ XHCI_PLAT_TYPE_MARVELL_ARMADA = 1,
XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
};
--
1.9.1
--
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] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
On 11.04.2016 18:44, Peter Griffin wrote:
Hi Mathias,
On Fri, 25 Mar 2016, Peter Griffin wrote:
Otherwise generic-xhci and xhci-platform which have no data get wrongly
detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().
This fixes a regression in v4.5 for STiH407 family SoC's which use the
synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never
gets added.
I suspect this will also fix other dwc3 DT platforms such as Exynos,
although I've only tested on STih410 SoC.
Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
Can you take this 1 charcter fix for the next -rc?
added to my tree and sent forward to Greg
-Mathias
--
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 xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]
Hi Felipe, Mathias;
I pulled a clean copy of v4.5 and applied the patch suggested by Felipe,
and the issue is no longer present. I would like to disable this
behavior via changes to my software instead of requiring customers to
build a custom kernel. What would be the ideal solution to this issue?
Would it be acceptable to wrap the lines of code with an if-else using a
new kernel boot parameter?
Mathias also provided a suggestion that I could put in to my code:
> If that is the issue then adding pm_runtime_get_xxx() will increase the device
> usage count before you know you are going to use a device. It prevents
> runtime suspend.
> Then once you know the device is going to be idle, decrease the referece cound
> with a pm_runtime_put().
May I please request a short code snippet on how I could get the `struct
device*' handle, assuming I have a libusb_device_handle and the bus/dev
number of the camera in use? I'm not very familiar with the core USB
API, and would just need to know how to do the set/reset logic to
prevent runtime suspend.
Thank you all for your time and assistance.
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail: matt...@giassa.net
website: www.giassa.net
> Original Message
> Subject: Re: USB xHCI regression after upgrading from kernel 3.19.0-51
> to 4.2.0-34.]
> From: Felipe Balbi
> Date: Sun, April 10, 2016 10:28 pm
> To: Matthew Giassa , linux-usb@vger.kernel.org,
> Mathias Nyman
>
>
> Hi,
>
> Matthew Giassa writes:
> > *Migrating from linux-media mailing list.
> >
> > Good day,
> >
> > I maintain an SDK for USB2.0 and USB3.0 U3V machine vision cameras, and
> > several of our customers have reported severe issues since upgrading
> > from
> > kernel 3.19.0-51 (Ubuntu 14.04.3 LTS) to kernel 4.2.0-34 (Ubuntu 14.04.4
> > LTS). I've received helpful advice from members of the libusb and
> > linux-usb mailing lists on how to generate useful logs to help diagnose
> > the issue, and have filed a bug to track this issue at:
> >
> >https://bugzilla.kernel.org/show_bug.cgi?id=115961
> >
> > It seems that with kernels newer than the 3.19 series (I've tested on
> > 4.2.0-34, and just repeated the tests on the latest 4.5.0 vanilla
> > release),
> > the cameras lock up, and cannot stream image data to the user
> > application. I
> > am able to resolve the issue on 4.2.0-34 by disabling USB power
> > management by adding "usbcore.autosuspend=-1". On the 4.5 kernel, this
> > "trick" doesn't work at all, and I have no way to get the cameras to
> > stream data. I can do simple USB control requests to query things like
> > register values and serial numbers, but that's it. Asynchronous bulk
> > transfers never succeed.
> >
> > I am using the libusb library to communicate with the cameras, and have
> > a fairly simple minimal working example to test the cameras, which:
> > * Creates a default libusb context.
> > * Enumerates available USB devices.
> > * Filters out a select device based on the vendor/product ID values.
> > * Opens the device, claims the bulk interface, and starts requesting
> > frames of image data via async bulk transfer requests.
> >
> > There are select cases where the issue does not arise:
> >
> > Special Cases:
> > * The issue does not occur when using USB2.0 cameras on a USB2.0 port,
> > regardless of the kernel in use.
> > * The issues occur only on Intel 8 Series and Intel 9 Series USB3.0
> > host controllers with 4.x kernels.
> > * Intel 10 Series host controllers have not yet been tested.
> > * The issues never occur on Fresco or Renesas host controllers,
> > regardless of the kernel in use.
> > * From visual inspection of lsusb output, the issue only appears to
> > happen when the U1 and U2 options are available to the device.
>
> okay, this is probably what's happening. Intel hosts are the only ones
> actively doing LPM, for all other hosts we don't have support.
>
> Here are a few question:
>
> a) Are you sure your cameras implement proper LPM ?
> b) I'm assuming the following makes the problem go away, can you test ?
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index f0640b7a1c42..9c3ead114ad5 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -127,8 +127,8 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> - xhci->quirks |= XHCI_LPM_SUPPORT;
> - xhci->quirks |= XHCI_INTEL_HOST;
> + /* xhci->quirks |= XHCI_LPM_SUPPORT; */
> + /* xhci->quirks |= XHCI_INTEL_HOST; */
> xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>
> c) I remember that I mentioned to Mathias that I'd seen XHCI L
RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]
On Wed, 13 Apr 2016, Matthew Giassa wrote: > Hi Felipe, Mathias; > > I pulled a clean copy of v4.5 and applied the patch suggested by Felipe, > and the issue is no longer present. I would like to disable this > behavior via changes to my software instead of requiring customers to > build a custom kernel. What would be the ideal solution to this issue? > Would it be acceptable to wrap the lines of code with an if-else using a > new kernel boot parameter? > > Mathias also provided a suggestion that I could put in to my code: > > If that is the issue then adding pm_runtime_get_xxx() will increase the > > device > > usage count before you know you are going to use a device. It prevents > > runtime suspend. > > Then once you know the device is going to be idle, decrease the referece > > cound > > with a pm_runtime_put(). > > May I please request a short code snippet on how I could get the `struct > device*' handle, assuming I have a libusb_device_handle and the bus/dev > number of the camera in use? I'm not very familiar with the core USB > API, and would just need to know how to do the set/reset logic to > prevent runtime suspend. It is possible to disable LPM for one particular device, based on the vendor and product IDs. To do so would require a kernel patch, but this patch would be accepted for the mainline kernel and therefore would be available to everyone using these devices, not just the people running your software. To write such a patch yourself, edit the drivers/core/usb/quirks.c file and copy one of the entries for the Blackmagic Design devices, changing the ID numbers as appropriate. The USB_QUIRK_NO_LPM flag is the important factor. 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 xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]
I will look into doing that. I think it would be preferable to add some functionality to mark all devices matching a certain VendorID rather than dumping the entire device table into `quirks.c', as I'd have to routinely update it every time we release a new product. In the meantime, if there's a way to disable LPM from within my software, I'd prefer to take that route as I could build, test, and ship a new version of my software to customers before end-of-week and not require them to build/use a custom kernel until the patch finds its way into production Ubuntu kernels. Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matt...@giassa.net website: www.giassa.net > Original Message > Subject: RE: USB xHCI regression after upgrading from kernel 3.19.0-51 > to 4.2.0-34.] > From: Alan Stern > Date: Wed, April 13, 2016 10:55 am > To: Matthew Giassa > Cc: Felipe Balbi , Mathias Nyman > , > > > On Wed, 13 Apr 2016, Matthew Giassa wrote: > > > Hi Felipe, Mathias; > > > > I pulled a clean copy of v4.5 and applied the patch suggested by Felipe, > > and the issue is no longer present. I would like to disable this > > behavior via changes to my software instead of requiring customers to > > build a custom kernel. What would be the ideal solution to this issue? > > Would it be acceptable to wrap the lines of code with an if-else using a > > new kernel boot parameter? > > > > Mathias also provided a suggestion that I could put in to my code: > > > If that is the issue then adding pm_runtime_get_xxx() will increase the > > > device > > > usage count before you know you are going to use a device. It prevents > > > runtime suspend. > > > Then once you know the device is going to be idle, decrease the referece > > > cound > > > with a pm_runtime_put(). > > > > May I please request a short code snippet on how I could get the `struct > > device*' handle, assuming I have a libusb_device_handle and the bus/dev > > number of the camera in use? I'm not very familiar with the core USB > > API, and would just need to know how to do the set/reset logic to > > prevent runtime suspend. > > It is possible to disable LPM for one particular device, based on the > vendor and product IDs. To do so would require a kernel patch, but > this patch would be accepted for the mainline kernel and therefore > would be available to everyone using these devices, not just the people > running your software. > > To write such a patch yourself, edit the drivers/core/usb/quirks.c > file and copy one of the entries for the Blackmagic Design devices, > changing the ID numbers as appropriate. The USB_QUIRK_NO_LPM flag is > the important factor. > > 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: [PATCHv3] usb: dwc2: Add reset control to dwc2
On 04/13/2016 11:23 AM, Stefan Wahren wrote:
>> +hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
>
> shouldn't this be documented in
> Documentation/devicetree/bindings/usb/dwc2.txt ?
>
Sure, I can document it.
>> +if (IS_ERR(hsotg->reset)) {
>> +dev_info(hsotg->dev, "Could not get reset control!\n");
>> +if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>
> If this log message is really necessary, please move it down here and add the
> error code into the message.
>
Will do. Thanks for the review.
Dinh
--
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 xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]
On Wed, 13 Apr 2016, Matthew Giassa wrote: > I will look into doing that. I think it would be preferable to add some > functionality to mark all devices matching a certain VendorID rather > than dumping the entire device table into `quirks.c', as I'd have to > routinely update it every time we release a new product. > > In the meantime, if there's a way to disable LPM from within my > software, I'd prefer to take that route as I could build, test, and ship > a new version of my software to customers before end-of-week and not > require them to build/use a custom kernel until the patch finds its way > into production Ubuntu kernels. As far as I know, there's no way to do it. Maybe we should add one. 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: [PATCHv3] usb: dwc2: Add reset control to dwc2
On 4/13/2016 11:52 AM, Dinh Nguyen wrote:
> On 04/13/2016 11:23 AM, Stefan Wahren wrote:
>
>>> + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
>>
>> shouldn't this be documented in
>> Documentation/devicetree/bindings/usb/dwc2.txt ?
>>
>
> Sure, I can document it.
>
>>> + if (IS_ERR(hsotg->reset)) {
>>> + dev_info(hsotg->dev, "Could not get reset control!\n");
>>> + if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>
>> If this log message is really necessary, please move it down here and add
>> the error code into the message.
>>
>
> Will do. Thanks for the review.
Also could you downgrade it to dev_dbg() and remove the "!".
Thanks,
John
--
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: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
On 4/13/2016 7:58 AM, Alan Stern wrote: > On Tue, 12 Apr 2016, John Youn wrote: > >>> Wait, even SuperSpeed GEN1-only devices *must* set bcdUSB to 0x0310 ? Do >>> you have a reference to that ? I find that pretty odd because this means >>> that if I take any of my USB3 devices that I already have today, and run >>> them against latest USBCV, they'll all fail and that's not very nice. >> >> Yup, that is exactly what happens. See 9.6.1 in the USB 3.1 >> specification. Also the CV tool and compliance test specification from >> USB IF say this as well. If you test with any existing SuperSpeed >> device it will fail. > > I have the definite impression that the USB IF is getting more and > more careless as it gets older. The first two paragraphs of 9.6.1 are > actually contradictory! > > A device descriptor describes general information about a > device. It includes information that applies globally to the > device and all of the device’s configurations. A device has > only one device descriptor. > > The device descriptor of an Enhanced SuperSpeed device shall > have a version number of 3.1 (0310H). The device descriptor of > an Enhanced SuperSpeed device operating in one of the USB 2.0 > modes shall have a version number of 2.1 (0210H). > > If a device has only one device descriptor, how can it have different > version numbers at different speeds? > > Besides, this doesn't say what the version number of a non-Enhanced > SuperSpeed device should be. I don't see why the USBCV would conclude > that a non-Enhanced device needs to set the version to 0x0310. Non-Enhanced SuperSpeed (i.e. HS and lower) devices follow the USB 2.0 spec. Or do you mean SuperSpeed-only devices? In the 3.1 spec, "Enhanced SuperSpeed" means either SuperSpeed (Gen 1) or SuperSpeedPlus (Gen 2). So they should set bcdUSB to 0x0310 as well. John -- 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: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
On Wed, 13 Apr 2016, John Youn wrote: > > Besides, this doesn't say what the version number of a non-Enhanced > > SuperSpeed device should be. I don't see why the USBCV would conclude > > that a non-Enhanced device needs to set the version to 0x0310. > > Non-Enhanced SuperSpeed (i.e. HS and lower) devices follow the USB 2.0 > spec. > > Or do you mean SuperSpeed-only devices? > > In the 3.1 spec, "Enhanced SuperSpeed" means either SuperSpeed (Gen 1) > or SuperSpeedPlus (Gen 2). So they should set bcdUSB to 0x0310 as > well. Yes, all right, I misunderstood. So the USB-IF really did invalidate all the existing 3.0 devices when the 3.1 spec was released. That doesn't make much sense. 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: [PATCH v3 09/16] phy: da8xx-usb: new driver for DA8xx SoC USB PHY
On 04/13/2016 08:20 AM, Kishon Vijay Abraham I wrote: Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. To see how to fix it, please see my comment for the previous version of your patch. Thanks Kishon What is the proper way to give you credit for the changes you suggested? -- 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 v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY
On 04/01/2016 08:16 AM, Kishon Vijay Abraham I wrote:
+EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode);
Don't prefer export symbols from PHY driver. That'll create unnecessary
dependencies between the controller and the PHY.
I think it'll be better to create a new attribute and use it?
Just having an attribute that keeps track of state does not work. I need
a callback to poke registers. Would this be acceptable instead?
-8<--
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index e7e574d..a13c7e4 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -342,6 +342,36 @@ int phy_power_off(struct phy *phy)
}
EXPORT_SYMBOL_GPL(phy_power_off);
+int phy_get_mode(struct phy *phy, enum phy_mode *mode)
+{
+ int ret;
+
+ if (!phy || !phy->ops->get_mode)
+ return 0;
+
+ mutex_lock(&phy->mutex);
+ ret = phy->ops->get_mode(phy, mode);
+ mutex_unlock(&phy->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_get_mode);
+
+int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ int ret;
+
+ if (!phy || !phy->ops->set_mode)
+ return 0;
+
+ mutex_lock(&phy->mutex);
+ ret = phy->ops->set_mode(phy, mode);
+ mutex_unlock(&phy->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_mode);
+
/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cf05e3..12c1986 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -22,12 +22,21 @@
struct phy;
+enum phy_mode {
+ PHY_MODE_INVALID,
+ PHY_MODE_USB_HOST,
+ PHY_MODE_USB_DEVICE,
+ PHY_MODE_USB_OTG,
+};
+
/**
* struct phy_ops - set of function pointers for performing phy operations
* @init: operation to be performed for initializing phy
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @get_mode: get the current mode of the phy
+ * @set_mode: set the mode of the phy
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -35,6 +44,8 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*get_mode)(struct phy *phy, enum phy_mode *mode);
+ int (*set_mode)(struct phy *phy, enum phy_mode mode);
struct module *owner;
};
@@ -119,6 +130,8 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_get_mode(struct phy *phy, enum phy_mode *mode);
+int phy_set_mode(struct phy *phy, enum phy_mode mode);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy->attrs.bus_width;
@@ -224,6 +237,16 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_get_mode(struct phy *phy, enum phy_mode *mode)
+{
+ return 0;
+}
+
+static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ return 0;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
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 1/1] usb: lpm: add boot flag to disable lpm
commit 4e8998d462ab06900949a3099706a19177484c09
Author: Matthew
Date: Wed Apr 13 13:37:21 2016 -0700
Adding new kernel parameter that allows users to skip the check
for whether or not LPM is supported. This resolves erratic power
state changes with certain U3V machine vision cameras.
Signed-off-by: Matthew Giassa
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index df0e3b9..ab6eb62 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -118,6 +118,12 @@ static inline int is_root_hub(struct usb_device
*udev)
return (udev->parent == NULL);
}
+/* allow LPM to be disabled */
+static bool usb_hcd_lpm_disable = false;
+module_param(usb_hcd_lpm_disable, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(usb_hcd_lpm_disable, "true to disable link power
management");
+
+
/*-*/
/*
@@ -1054,6 +1060,7 @@ static int register_root_hub(struct usb_hcd *hcd)
struct device *parent_dev = hcd->self.controller;
struct usb_device *usb_dev = hcd->self.root_hub;
const int devnum = 1;
+ bool disable_lpm;
int retval;
usb_dev->devnum = devnum;
@@ -1074,15 +1081,18 @@ static int register_root_hub(struct usb_hcd
*hcd)
return (retval < 0) ? retval : -EMSGSIZE;
}
- if (le16_to_cpu(usb_dev->descriptor.bcdUSB) >= 0x0201) {
- retval = usb_get_bos_descriptor(usb_dev);
- if (!retval) {
- usb_dev->lpm_capable = usb_device_supports_lpm(usb_dev);
- } else if (usb_dev->speed == USB_SPEED_SUPER) {
- mutex_unlock(&usb_bus_list_lock);
- dev_dbg(parent_dev, "can't read %s bos descriptor %d\n",
- dev_name(&usb_dev->dev), retval);
- return retval;
+ disable_lpm = ACCESS_ONCE(usb_hcd_lpm_disable);
+ if (!disable_lpm) {
+ if (le16_to_cpu(usb_dev->descriptor.bcdUSB) >= 0x0201) {
+ retval = usb_get_bos_descriptor(usb_dev);
+ if (!retval) {
+ usb_dev->lpm_capable =
usb_device_supports_lpm(usb_dev);
+ } else if (usb_dev->speed >= USB_SPEED_SUPER) {
+ mutex_unlock(&usb_bus_list_lock);
+ dev_dbg(parent_dev, "can't read %s bos
descriptor %d\n",
+ dev_name(&usb_dev->dev),
retval);
+ return retval;
+ }
}
}
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail: matt...@giassa.net
website: www.giassa.net
--
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/1] usb: lpm: add boot flag to disable lpm
On Wed, Apr 13, 2016 at 02:25:08PM -0700, Matthew Giassa wrote: > commit 4e8998d462ab06900949a3099706a19177484c09 > Author: Matthew > Date: Wed Apr 13 13:37:21 2016 -0700 Why is this here? > > Adding new kernel parameter that allows users to skip the check > for whether or not LPM is supported. This resolves erratic power > state changes with certain U3V machine vision cameras. > > Signed-off-by: Matthew Giassa > Why is this oddly indented? Please use git send-email to send a patch. > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index df0e3b9..ab6eb62 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -118,6 +118,12 @@ static inline int is_root_hub(struct usb_device > *udev) > return (udev->parent == NULL); > } > > +/* allow LPM to be disabled */ > +static bool usb_hcd_lpm_disable = false; > +module_param(usb_hcd_lpm_disable, bool, S_IRUGO | S_IWUSR); > +MODULE_PARM_DESC(usb_hcd_lpm_disable, "true to disable link power > management"); Patch is line-wrapped :( But larger issue, no new module parameters for things like this. No one will use them and they aren't device or bus specific. It's a huge hammer that isn't nice to use. 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 1/1] usb: lpm: add boot flag to disable lpm
Thank you for the feedback Greg. This is my first attempt to submit a kernel patch. Is there a better approach to this? The only other option at my disposal is to add about 200 products to the quirks.c file, and routinely update that list as new products are released. I need to implement some means of disabling LPM, ideally on a per-device basis. > Original Message > Subject: Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: Greg KH > Date: Wed, April 13, 2016 2:33 pm > To: Matthew Giassa > Cc: Mathias Nyman , > linux-usb@vger.kernel.org > > > On Wed, Apr 13, 2016 at 02:25:08PM -0700, Matthew Giassa wrote: > > commit 4e8998d462ab06900949a3099706a19177484c09 > > Author: Matthew > > Date: Wed Apr 13 13:37:21 2016 -0700 > > Why is this here? > > > > > Adding new kernel parameter that allows users to skip the check > > for whether or not LPM is supported. This resolves erratic power > > state changes with certain U3V machine vision cameras. > > > > Signed-off-by: Matthew Giassa > > > > Why is this oddly indented? > > Please use git send-email to send a patch. > > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > > index df0e3b9..ab6eb62 100644 > > --- a/drivers/usb/core/hcd.c > > +++ b/drivers/usb/core/hcd.c > > @@ -118,6 +118,12 @@ static inline int is_root_hub(struct usb_device > > *udev) > > return (udev->parent == NULL); > > } > > > > +/* allow LPM to be disabled */ > > +static bool usb_hcd_lpm_disable = false; > > +module_param(usb_hcd_lpm_disable, bool, S_IRUGO | S_IWUSR); > > +MODULE_PARM_DESC(usb_hcd_lpm_disable, "true to disable link power > > management"); > > Patch is line-wrapped :( > > But larger issue, no new module parameters for things like this. No one > will use them and they aren't device or bus specific. It's a huge > hammer that isn't nice to use. > > 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 1/1] usb: lpm: add boot flag to disable lpm
On Wed, Apr 13, 2016 at 02:37:35PM -0700, Matthew Giassa wrote: > Thank you for the feedback Greg. This is my first attempt to submit a > kernel patch. > > Is there a better approach to this? The only other option at my disposal > is to add about 200 products to the quirks.c file, and routinely update > that list as new products are released. I need to implement some means > of disabling LPM, ideally on a per-device basis. Why are these devices say they support LPM yet they do not? -- 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/1] usb: lpm: add boot flag to disable lpm
The devices support LPM and are USB3.0 certified, and they work fine in Windows using the same Intel 8/9/10 Series USB host controllers, along with Renesas and Fresco controllers. On Linux the devices either seize up or slow down dramatically ever since LPM support was enabled. I could always just build a custom kernel ".deb" package for customers for now, as some of them are migrating from Ubuntu 14.04.3 LTS (kernel 3.19.0-51) to Ubuntu 14.04.4 LTS (kernel 4.2.x) or Ubuntu 16.04 LTS (kernel 4.4.x), but I'd like to avoid that solution. Ideally, disabling LPM on a per-device basis would be better than the solution I proposed, but I'm not familiar enough with the usbcore code to implement such a feature at this time. I'd also prefer customers go with an official kernel release and just add a custom boot parameter. Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matt...@giassa.net website: www.giassa.net > Original Message > Subject: Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: Greg KH > Date: Wed, April 13, 2016 3:11 pm > To: Matthew Giassa > Cc: Mathias Nyman , > linux-usb@vger.kernel.org > > > On Wed, Apr 13, 2016 at 02:37:35PM -0700, Matthew Giassa wrote: > > Thank you for the feedback Greg. This is my first attempt to submit a > > kernel patch. > > > > Is there a better approach to this? The only other option at my disposal > > is to add about 200 products to the quirks.c file, and routinely update > > that list as new products are released. I need to implement some means > > of disabling LPM, ideally on a per-device basis. > > Why are these devices say they support LPM yet they do not? > > -- > 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 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/1] usb: lpm: add boot flag to disable lpm
On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote: > The devices support LPM and are USB3.0 certified, and they work fine in > Windows using the same Intel 8/9/10 Series USB host controllers, along > with Renesas and Fresco controllers. On Linux the devices either seize > up or slow down dramatically ever since LPM support was enabled. Then we need to fix Linux, as it must be our bug. Mathias, any ideas? 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/1] usb: lpm: add boot flag to disable lpm
Mathias provided me with some usb device calls I could use to resolve this in software (pm_runtime_get_xxx(), pm_runtime_put()), but I'm not familiar with the API, so I'd need some help figure out how to get the `struct device*' handle for my current device and issuing those calls within my application. I have the bus/dev pair and a libusb_device_handle to it. This would at least allow me to patch my software in the meantime. Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matt...@giassa.net website: www.giassa.net > Original Message > Subject: Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: Greg KH > Date: Wed, April 13, 2016 3:36 pm > To: Matthew Giassa > Cc: Mathias Nyman , > linux-usb@vger.kernel.org > > > On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote: > > The devices support LPM and are USB3.0 certified, and they work fine in > > Windows using the same Intel 8/9/10 Series USB host controllers, along > > with Renesas and Fresco controllers. On Linux the devices either seize > > up or slow down dramatically ever since LPM support was enabled. > > Then we need to fix Linux, as it must be our bug. > > Mathias, any ideas? > > 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
[PATCHv3 2/2] usb: dwc2: Add reset control to dwc2
From: Dinh Nguyen
Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.
Signed-off-by: Dinh Nguyen
---
v4: use dev_dbg() if not a -EPROBE_DEFER
v3: fix compile error
v2: move to lowlevel_hw_init()
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/platform.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3c58d63..f748132 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -837,6 +837,7 @@ struct dwc2_hsotg {
void *priv;
int irq;
struct clk *clk;
+ struct reset_control *reset;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 88629be..5e89af1 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
@@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
int i, ret;
+ hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
+ if (IS_ERR(hsotg->reset)) {
+ if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_dbg(hsotg->dev, "Could not get reset control.\n");
+ hsotg->reset = NULL;
+ }
+
+ if(hsotg->reset)
+ reset_control_deassert(hsotg->reset);
+
/* Set default UTMI width */
hsotg->phyif = GUSBCFG_PHYIF16;
@@ -434,6 +446,9 @@ static int dwc2_driver_remove(struct platform_device *dev)
if (hsotg->ll_hw_enabled)
dwc2_lowlevel_hw_disable(hsotg);
+ if (hsotg->reset)
+ reset_control_assert(hsotg->reset);
+
return 0;
}
--
2.6.2
--
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 1/2] Documentation: dt-bindings: dwc2: add the resets and reset-names property
From: Dinh Nguyen Document the optional 'resets' and 'reset-names' property for the DWC2 usb core. Signed-off-by: Dinh Nguyen --- Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala --- Documentation/devicetree/bindings/usb/dwc2.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 20a68bf..c9ccea6 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -27,6 +27,9 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties - g-rx-fifo-size: size of rx fifo size in gadget mode. - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode. - g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode. +- resets: list of phandle and reset specifier pairs. The should be one entry for + softreset line of the USB IP. +- reset-names: Should be "dwc2". Example: -- 2.6.2 -- 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 v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform
Hi, On Wed, 2016-04-13 at 12:00 +0200, Matthias Brugger wrote: > > On 11/04/16 09:41, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/phy/phy-mt65xx-usb.txt |4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Reviewed-by: Matthias Brugger > Thanks > > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > index 00100cf..33a2b1e 100644 > > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > @@ -4,7 +4,9 @@ mt65xx USB3.0 PHY binding > > This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. > > > > Required properties (controller (parent) node): > > - - compatible : should be "mediatek,mt8173-u3phy" > > + - compatible : should be one of > > + "mediatek,mt2701-u3phy" > > + "mediatek,mt8173-u3phy" > >- reg: offset and length of register for phy, exclude port's > > register. > >- clocks : a list of phandle + clock-specifier pairs, one for each > > -- 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 v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform
Hi, On Wed, 2016-04-13 at 18:56 +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > how about changing the commit log to something like below? > Add a new compatible string for "mt2701" > OK thanks > Thanks > Kishon > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/phy/phy-mt65xx-usb.txt |4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > index 00100cf..33a2b1e 100644 > > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt > > @@ -4,7 +4,9 @@ mt65xx USB3.0 PHY binding > > This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. > > > > Required properties (controller (parent) node): > > - - compatible : should be "mediatek,mt8173-u3phy" > > + - compatible : should be one of > > + "mediatek,mt2701-u3phy" > > + "mediatek,mt8173-u3phy" > > - reg : offset and length of register for phy, exclude port's > > register. > > - clocks : a list of phandle + clock-specifier pairs, one for each > > -- 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 v2 2/2] phy: phy-mt65xx-usb3: add support for mt2701 platform
Hi, On Wed, 2016-04-13 at 19:01 +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > > > Some register settings to avoid RX sensitivity level degradation > > which may arise on mt8173 platform are separated from other > > platforms. > > > > Signed-off-by: Chunfeng Yun > > --- > > drivers/phy/Kconfig |5 ++- > > drivers/phy/phy-mt65xx-usb3.c | 77 > > - > > 2 files changed, 54 insertions(+), 28 deletions(-) > > > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > > index 26566db..3037f28 100644 > > --- a/drivers/phy/Kconfig > > +++ b/drivers/phy/Kconfig > > @@ -218,9 +218,8 @@ config PHY_MT65XX_USB3 > > depends on ARCH_MEDIATEK && OF > > select GENERIC_PHY > > help > > - Say 'Y' here to add support for Mediatek USB3.0 PHY driver > > - for mt65xx SoCs. it supports two usb2.0 ports and > > - one usb3.0 port. > > + Say 'Y' here to add support for Mediatek USB3.0 PHY driver, > > + it supports multiple usb2.0 and usb3.0 ports. > > Do you mean this PHY driver support both USB2 and USB3? Then it's not really a > USB3 PHY driver right? > Sorry for my unclear description. It supports USB3 PHY, and each USB3 PHY in fact includes a USB2 PHY and a SuperSpeed PHY. Thanks a lot > Thanks > Kishon -- 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: [PATCHv3 2/2] usb: dwc2: Add reset control to dwc2
On Thursday 14 April 2016, dingu...@opensource.altera.com wrote:
> @@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
> *hsotg)
> {
> int i, ret;
>
> + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
> + if (IS_ERR(hsotg->reset)) {
> + if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_dbg(hsotg->dev, "Could not get reset control.\n");
> + hsotg->reset = NULL;
> + }
> +
> + if(hsotg->reset)
> + reset_control_deassert(hsotg->reset);
The error handling seems a bit odd here. If there is a failure to get the
reset control and it's actually needed, I would argue the init function should
not continue. Conversely, if there was no reset line specified in the
device, why even print a message about it?
Arnd
--
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: [-next] BUG_ON in scsi_target_destroy()
Hello, On (04/13/16 08:14), James Bottomley wrote: [..] > How about good grief no! A device with multiple targets will get it's > lists screwed with this > > The STARGET_REMOVE state you added only applies to the case we're > trying to kill a target. In the natural operation case, which is what > everyone else is running into, we will try to remove a running target > when it has no more scsi devices left on it. So the correct patch > should be to make the BUG_ON see this: works for me. Reported-and-tested-by: Sergey Senozhatsky -ss > James > > --- > > diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c > index 27df7e7..e0a78f5 100644 > --- a/drivers/scsi/scsi_scan.c > +++ b/drivers/scsi/scsi_scan.c > @@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target > *starget) > struct Scsi_Host *shost = dev_to_shost(dev->parent); > unsigned long flags; > > - BUG_ON(starget->state != STARGET_REMOVE && > -starget->state != STARGET_CREATED); > + BUG_ON(starget->state == STARGET_DEL); > starget->state = STARGET_DEL; > transport_destroy_device(dev); > spin_lock_irqsave(shost->host_lock, flags); > -- 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 v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space
Hello, Sergei,
> > From: "Du, Changbin"
> >
> > For DWC3 USB controller, the Global Debug Queue/FIFO Space Available
> > Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available
> space.
>
> Space needed before (.
Okay.
>
> > This can be used to check some special issues, like whether data is
> > successfully copied from memory to fifo when a trb is blocked.
> >
> > Signed-off-by: Du, Changbin
> > ---
> > v4:
> >Do not fail silently, but print error.
> [...]
> > diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> > index 615d4dc..83e5bc1 100644
> > --- a/drivers/usb/dwc3/debugfs.c
> > +++ b/drivers/usb/dwc3/debugfs.c
> [...]
> > @@ -642,10 +681,15 @@ void dwc3_debugfs_init(struct dwc3 *dwc)
> > dwc->regset->nregs = ARRAY_SIZE(dwc3_regs);
> > dwc->regset->base = dwc->regs;
> >
> > +
>
> Why?
Thanks for point out, I will remove this additional line.
>
> > file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc-
> >regset);
> > if (!file)
> > dev_err(dwc->dev, "Can't create debugfs regdump\n");
> >
> > + file = debugfs_create_file("fifo", S_IRUGO, root, dwc,
> &dwc3_fifo_fops);
> > + if (!file)
> > + dev_err(dwc->dev, "Can't create debugfs fifo\n");
> > +
> > if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
> > file = debugfs_create_file("mode", S_IRUGO | S_IWUSR,
> root,
> > dwc, &dwc3_mode_fops);
>
> MBR, Sergei
--
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
我的信息在:
你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速
Re: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
Hi,
Alan Stern writes:
> On Wed, 13 Apr 2016, Felipe Balbi wrote:
>
>> USB3 devices, because they are much newer, have much
>> less chance of having issues with larger transfers.
>>
>> We still keep a limit because anything above 2048
>> sectors really rendered negligible speed
>> improvements, so we will simply ignore
>> that. Transferring 1MiB should already give us
>> pretty good performance.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> drivers/usb/storage/scsiglue.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
>> index 9da1fb3d0ff4..2bb6a88858ea 100644
>> --- a/drivers/usb/storage/scsiglue.c
>> +++ b/drivers/usb/storage/scsiglue.c
>> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
>> if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
>> blk_queue_max_hw_sectors(sdev->request_queue,
>>max_sectors);
>> +} else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
>> +/* USB3 devices will be limited to 2048 sectors. This gives us
>> + * better throughput on most devices.
>> + */
>> +blk_queue_max_hw_sectors(sdev->request_queue, 2048);
>> } else if (sdev->type == TYPE_TAPE) {
>> /* Tapes need much higher max_sector limits, so just
>> * raise it to the maximum possible (4 GB / 512) and
>
> Argh! This has the same kind of problem as before. What will happen
> when somebody has a USB-3 tape drive?
I didn't know that was even plausible :-) Anyway, I'll update, but while
at that, so I use for bcdUSB instead of speed as Oliver suggested ? I
mean, a USB3 stick running on high-speed can also support 2048 max
sectors, right ?
let me know
--
balbi
signature.asc
Description: PGP signature
