RE: [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
>From: Rob Herring [mailto:r...@kernel.org]
>On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
>> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
>> Describes the qoriq usb 2.0 phy driver binding, currently used for
>> LS1043A platform.
>>
>> Signed-off-by: Sriram Dash
>> ---
>> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36
>> drivers/phy/Kconfig| 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qoriq-usb3.c | 202
>> +
>> 4 files changed, 247 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> new file mode 100644
>> index 000..d934c80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> @@ -0,0 +1,36 @@
>> +Driver for Freescale USB 3.0 PHY
>> +
>> +Required properties:
>> +
>> +- compatible : fsl,qoriq-usb3-phy
>> +- reg : register mappings for Parameter Configuration Register
>> +and Phy base offset.
>> +- reg-names : "param_ctrl" and "phy_base"
>> +- phy_type :For multi port host USB controllers, should be one of
>> +"ulpi", or "serial". For dual role USB controllers,
>> +should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Hi Rob,
>
>Do any of these really apply to a USB3 PHY?
>
The concerned USB3 phy used is UTMI. I agree to your point somewhat that
all the types are not required now. Anyway, shall I make it an optional
property, with the mention of only UTMI and ULPI?
>Rob
>
>> +
>> +Example:
>> +usbphy0: usb3-phy@084F {
>
>usb-phy@...
>
Ok. Will change in the next rev for Documentation and dts (patch 2/2)
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
>> +
>> +usbphy1: usb3-phy@0850 {
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x0850 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
>> +
>> +usbphy2: usb3-phy@0851 {
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x0851 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
--
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: Issue with Telit LE922 and cdc_mbim
Hi Bjørn, 2016-11-15 19:56 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: > >> The problem is in cdc_ncm, function cdc_ncm_bind_common, line >> >> usleep_range(1, 2); >> >> It seems that LE922 needs an higher timeout; changing the line to >> >> usleep_range(7, 8); >> >> makes the modem to work fine. > > Extremely interesting! As you probably noticed, that delay was recently > added as a workaround for the same problem on Sierra Wireless EM7455 > modems. I believe these are based on the Qualcomm MDM9230. Which > chipset is the LE922 based on? Is it also one of the newer Qualcom > chips? Yes, it is based on one of latest QC chipsets. > > >> I will submit a patch for this. > > Thanks. It would also be great if you could trigger some investigation > into the actual firmware issue. It looks like the firmware returns > control to the driver before it's actually ready at this point of > initialisation. > Yeah, for sure I will ask for some investigation also on the firmware side, even though I don't have many expectations for this. It seems that, if the modem is attached to the host and then turned on, the previous delay is not enough. And then there seems also to be constraints on the application side (e.g. ModemManager). Currently I'm not going to submit a patch until things are more clear. Thanks for your help, Daniele > > > > Bjørn -- 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: [PATHCv10 1/2] usb: USB Type-C connector class
On Mon, 2016-11-14 at 06:34 -0800, Guenter Roeck wrote:
> >>> +int typec_connect(struct typec_port *port, struct
> typec_connection *con)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + if (!con->partner && !con->cable)
> >>> + return -EINVAL;
> >>> +
> >>> + port->connected = 1;
> >>> + port->data_role = con->data_role;
> >>> + port->pwr_role = con->pwr_role;
> >>> + port->vconn_role = con->vconn_role;
> >>> + port->pwr_opmode = con->pwr_opmode;
> >>> +
> >>> + kobject_uevent(&port->dev.kobj, KOBJ_CHANGE);
> >>
> >> This worries me. Who is listening for it? What will you do with
> it?
> >> Shouldn't you just poll on an attribute file instead?
> >
> > Oliver! Did you need this or can we remove it?
> >
>
> I'll also have to make sure that the Android folks don't use it.
How then do we notify user space? poll()? Yet another demon.
I do not specifically need this, but I note that uevents are the
general tool we use to notify user space of that kind of events.
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: [PATCH] add DWR-158 in usb option
On Wed, 2016-11-16 at 10:22 +0700, Lars Melin wrote:
> On 2016-11-16 03:20, Giuseppe Lippolis wrote:
> > Signed-off-by: Giuseppe Lippolis
> > ---
> > Adding support for 3G modem DWR-158 from Dlink (I found it embedded in the
> > DWR-512).
> > ---
> >
> > --- drivers/usb/serial/option.c.orig2016-11-15 21:05:16.987504020
> > +0100
> > +++ drivers/usb/serial/option.c 2016-11-15 21:08:27.722378924 +0100
> > @@ -306,6 +306,9 @@ static void option_instat_callback(struc
> > #define DLINK_PRODUCT_DWM_652_U5 0xce16
> > #define DLINK_PRODUCT_DWM_652_U5A 0xce1e
> >
> > +#define DLINK_ATL_VENDOR_ID0x2001
> > +#define DLINK_PRODUCT_DWM_158 0x7d04
> > +
> > #define QISDA_VENDOR_ID0x1da5
> > #define QISDA_PRODUCT_H21_4512 0x4512
> > #define QISDA_PRODUCT_H21_4523 0x4523
> > @@ -1812,6 +1815,7 @@ static const struct usb_device_id option
> > { USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) }, /* Yes,
> > ALINK_VENDOR_ID */
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
> > + { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H20_4515) },
> >
> > --
> NAK.
> The verbose lsusb display which you pasted in your first mail shows
> interface #0 and #1 to be used as netdev with cdc_ether as driver.
> You must blacklist them in the option driver which otherwise will
> claim them.
Hi,
why? This thing is no ethernet. If a more specific driver, that can do
do more, like link quality or AP selection, is available, we want to use
that.
So, if you use a black list, use it in cdc_ether.
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: [GIT PULL] USB fixes for v4.9-rc4
Hi, Peter Chen writes: > On Tue, Nov 15, 2016 at 10:54:09PM -0500, David Miller wrote: >> From: Peter Chen >> Date: Wed, 16 Nov 2016 11:41:15 +0800 >> >> > I just notice that you submitted the "usb: gadget: u_ether: remove >> > interrupt throttling", and cc stable tree too, but we can't get >> > the agreement that it is suitable for all USB controllers, and David >> > added this comment later that the networking stack has no hard >> > requirement (eg, half of second) [1] which is not the same at your >> > commit log. >> >> It does fix a bug in at least one of the drivers, so it is definitely >> a step forward. > > But it let other drivers lost throttling interrupt features for USB Ethernet > gadget, it can supply option for user if throttling interrupt is > supported or not. as I've said before, the only reason why chipidea doesn't see issues is because of the forced interrupt. I have it in my TODO list to come up with a better way to handle this. Until then, we're gonna have disabled throttling. The real problem here is that dwc3 is the only driver *really* throttling interrupt so this code has never *really* been tested without any other sort of forced interrupts. cheers -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/3] xhci: Fix race related to abort operation
Hi,
OGAWA Hirofumi writes:
> diff -puN drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2
> drivers/usb/host/xhci-ring.c
> --- xhci/drivers/usb/host/xhci-ring.c~xhci-fix-abort-race22016-11-16
> 13:36:07.219329211 +0900
> +++ xhci-hirofumi/drivers/usb/host/xhci-ring.c2016-11-16
> 13:36:07.221329211 +0900
> @@ -284,6 +284,61 @@ static bool xhci_mod_cmd_timer(struct xh
> return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
> }
>
> +static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
> +{
> + if (list_empty(&xhci->cmd_list))
> + return NULL;
> + return list_first_entry(&xhci->cmd_list, struct xhci_command, cmd_list);
could use list_first_entry_or_null() here
--
balbi
signature.asc
Description: PGP signature
Re: USB stops working if a malfunctioning USB device is connected
Hi, Greg KH writes: > On Wed, Nov 16, 2016 at 12:12:53AM +0530, PrasannaKumar Muralidharan wrote: >> >> scripts/kconfig/conf --silentoldconfig Kconfig >> >> CHK include/config/kernel.release >> >> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong >> >> not supported by compiler >> >> make: *** [prepare-compiler-check] Error 1 >> >> make: *** Waiting for unfinished jobs >> > >> > So turn off CONFIG_CC_STACKPROTECTOR_STRONG or upgrade your C compiler. >> >> I turned off CONFIG_CC_STACKPROTECTOR_STRONG and got the following error >> *** >> HOSTCC scripts/basic/fixdep >> HOSTCC scripts/basic/bin2c >> HOSTCC arch/x86/tools/relocs_32.o >> HOSTCC arch/x86/tools/relocs_64.o >> HOSTCC arch/x86/tools/relocs_common.o >> HOSTLD arch/x86/tools/relocs >> CHK include/config/kernel.release >> CHK include/generated/uapi/linux/version.h >> CHK include/generated/utsrelease.h >> CC arch/x86/purgatory/purgatory.o >> AS arch/x86/purgatory/stack.o >> AS arch/x86/purgatory/setup-x86_64.o >> CC arch/x86/purgatory/sha256.o >> AS arch/x86/purgatory/entry64.o >> CC arch/x86/purgatory/string.o >> LD arch/x86/purgatory/purgatory.ro >> BIN2C arch/x86/purgatory/kexec-purgatory.c >> CHK include/generated/timeconst.h >> CC kernel/bounds.s >> kernel/bounds.c:1:0: error: code model kernel does not support PIC mode >> /* >> >> make[1]: *** [kernel/bounds.s] Error 1 >> make: *** [prepare0] Error 2 >> *** >> >> Using gcc 6.2 to compile kernel. gcc works with >> -fstack-protector-strong for a simple test c code. I doubt compiler is >> the problem. Should I make some change to make kernel compile with gcc >> 6.2? Thank you for your quick response. > > This is Ubuntu, right? Build a 64bit kernel and you should be fine, > right now Canonical is shipping a version of gcc that doesn't want to > build the kernel. There's a patch floating around, go bug the Canonical > developers to get it upstream please... > > If not, I don't know, sorry. At least Debian started building toolchains with PIE enabled by default. I've had this problem for a while, actually. I'm building kernels with: $ make CC="gcc -fno-PIE" and everything builds fine. -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/4] usb: dwc2: Fix AHB burst type for bcm2835
Hi John, > John Youn hat am 16. November 2016 um 01:36 > geschrieben: > > > The ahbcfg param for bcm2835 is specifying a HBSTLEN of 0x8 (0x10 >> 1) > which is not a valid value for that field. Remove the param and default > to using INCR4. i don't have any Synopsys documentation about this IP core. But according to p. 204 of the BCM2835 datasheet [1] the register USB_GAHBCFG is different than the other implementations: Address 0x 7E98 0008 The USB_GAHBCFG register has been adapted. Bits [4:1] which are marked in the Synopsys documentation as "Burst Length/Type (HBstLen)" have been used differently. [4]1 = Wait for all outstanding AXI writes to complete before signalling (internally) that DMA is done. 0 = don't wait. [3]Not used [2:1] Sets the maximum AXI burst length, but the bits are inverted, 00 = maximum AXI burst length of 4, 01 = maximum AXI burst length of 3, 10 = maximum AXI burst length of 2 11 = maximum AXI burst length of 1 Did you already take care of that? [1] - https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf -- 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/2] usb: dwc2: add amcc,dwc-otg support
Hi,
John Youn writes:
> On 11/14/2016 3:00 PM, John Youn wrote:
>> On 11/11/2016 3:12 PM, Christian Lamparter wrote:
>>> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
On 11/11/2016 2:05 PM, Christian Lamparter wrote:
> On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
>> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
>>> This patch adds support for the "amcc,usb-otg" device
>>> which is found in the PowerPC Canyonlands' dts.
>>>
>>> The device definition was added by:
>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
>>> board")'
>>> but without any driver support as the dwc2 driver wasn't
>>> available at that time.
>>>
>>> Note: The system can't use the generic "snps,dwc2" compatible
>>> because of the special ahbcfg configuration. The default
>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>> when the USB and SATA is used concurrently.
>>
>> I don't want to add any more of these param structures to the driver
>> unless really necessary. We're trying to remove usage of them in favor
>> of using auto-detected defaults and device properties to override
>> them.
> Ok, thanks. I think that would work. I've attached an updated patch.
> Can it be applied/queued now? Or do you want me to resent it later?
>
>> The AHB Burst is actually one of the ones we were going to do next
>> because our platform also doesn't work well with INCR4. In fact I'm
>> thinking of making the default INCR.
> Is that actually possible to change the default still? This would
> require to re-evaluate all existing archs/platforms that use
> "snps,dwc2" for INCR16 compatibility.
INCR, not INCR16, but you're right, so we may not change it even
though though INCR is usually the right choice over INCR4.
>>> What about making a device-tree property?
>>
>> Yes, that's what I meant. I'll send a change for this shortly.
>>
>>>
>>> Recommended properties:
>>> - g-ahb-bursts : specifies the ahb bursts length, should be one of
>>>"single", "INCRx", "INCR4", "INCR8", or "INCR16". If not specified
>>>the safer but inefficient "INCR4" is used. The optimal setting is
>>>"INCRx".
>>>
>>> Would this work? If so, I can make a patch over the weekend.
Anyways, with the binding, can't you just set the compatible string to
snps,dwc2?
>>>
>>> Ah, let me explain. I had a discussion with Mark Rutland and Rob Herring
>>> a while back about device-tree bindings.
>>>
>>> They made it very clear to me, that they don't want any generic "catch all
>>> compatible" strings:
>>>
>>> "Bindings should be for hardware (either specific device models, or for
>>> classes), and not for Linux drivers. The latter is subject to arbitrary
>>> changes while the former is not, as old hardware continues to exist and
>>> does not change while drivers get completely reworked." [0]
>>>
>>> Furthermore, this is an existing binding in kernel's canyonlands.dts [1]
>>> and this binding can't be easily changed. Rob Herring explained this in
>>> the context of the "basic-mmio-gpio" patch [2] when I was editing the dts
>>> to make them work with the changes I made:
>>>
>>> "You can't remove the old drivers as they are needed to work with
>>> old dtbs, so there is no gain.
>>>
>>> You would need to match on existing compatibles such as
>>> moxa,moxart-gpio and provide a match data struct that has all the info
>>> you are adding here (e.g. data register offset). Then additionally you
>>> could add "basic-mmio-gpio" (I would drop "basic" part) and the
>>> additional data associated with it. But it has to be new properties,
>>> not changing properties. Changing the reg values doesn't work."
>>>
>>> So, for this to work with the existing canyonlands.dts, I need to have
>>> the "amcc,dwc-otg" compatible string.
>>
>> Ok, if that's the case. But still a bit confused as to what driver was
>> working with it before since the binding was not defined for dwc2.
>>
>>>
>>> Of course, it would be great to hear from Rob Herring and/or Mark Rutland
>>> about this case.
>>>
>>> Regards,
>>> Christian
>>>
>>> [0]
>>> [2]
>>>
>>>
>
> From what I can tell based would be:
> bcm11351, bcm21664, bcm23550, exynos3250, stm32f429, rk3xxx,
> stratix10, meson-gxbb, rt3050 and some Altera FPGAs.
>
>> If that's all you need then a devicetree binding should be enough
>> right?
> Yes. The device is working fine so far.
>
> Regards,
> Christian
>
> ---
> From 70dd4be016b89655a56bc8260f04683b50f07644 Mon Sep 17 00:00:00 2001
> From: Christian Lamparter
> Date: Sun, 6 Nov 2016 00:39:24 +0100
> Subject: [PATCH] usb: dwc2: add a
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > Hi, > > At present I am using the uevent in the userspace to infer > the Presence of a port on the remote end through the > appearance of usbc*-partner. > > Userspace uses this info to decide on when to show a USB > notification on the screen and what should be the options > provided in the dialog. > > I was assuming that this is not something that would be dropped. > > Coding using events was relatively easier to program from userspace .. > > Is it possible to use POLL for identifying the appearance of port partner ? > I did not notice sysfs_notify call in typec_connect/typec_disconnect. > > It would also be nice to have uevent notifications when the contents > of current_data_role or current_power_role changes. > > Is that too costly to have ? Greg, could you give your opinion. In this case we do have attribute files that the user space can poll. Data role is the USB data role, so host or device, and it can change for example if the partner executes a swap. The same can happen with the power role. Thanks, -- heikki -- 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: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, 2016-11-16 at 11:30 +0200, Heikki Krogerus wrote: > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > Is that too costly to have ? > > Greg, could you give your opinion. In this case we do have attribute > files that the user space can poll. Data role is the USB data role, so > host or device, and it can change for example if the partner executes > a swap. The same can happen with the power role. IMHO the uevent is cheaper. User space cannot just poll without further infrastructure. A task needs to run to poll. A uevent can be handled through established infrastructure. Sure from a kernel level it is the heavier gun, but I think this is the wrong angle of looking at this issue. 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: [PATCH 2/3] xhci: Fix race related to abort operation
Felipe Balbi writes:
> Hi,
Hi,
> OGAWA Hirofumi writes:
>> diff -puN drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2
>> drivers/usb/host/xhci-ring.c
>> --- xhci/drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2 2016-11-16
>> 13:36:07.219329211 +0900
>> +++ xhci-hirofumi/drivers/usb/host/xhci-ring.c 2016-11-16
>> 13:36:07.221329211 +0900
>> @@ -284,6 +284,61 @@ static bool xhci_mod_cmd_timer(struct xh
>> return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
>> }
>>
>> +static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
>> +{
>> +if (list_empty(&xhci->cmd_list))
>> +return NULL;
>> +return list_first_entry(&xhci->cmd_list, struct xhci_command, cmd_list);
>
> could use list_first_entry_or_null() here
OK. Thanks for pointing out.
--
OGAWA Hirofumi
--
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: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, Nov 16, 2016 at 11:30:35AM +0200, Heikki Krogerus wrote: > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > Hi, > > > > At present I am using the uevent in the userspace to infer > > the Presence of a port on the remote end through the > > appearance of usbc*-partner. > > > > Userspace uses this info to decide on when to show a USB > > notification on the screen and what should be the options > > provided in the dialog. > > > > I was assuming that this is not something that would be dropped. > > > > Coding using events was relatively easier to program from userspace .. > > > > Is it possible to use POLL for identifying the appearance of port partner ? > > I did not notice sysfs_notify call in typec_connect/typec_disconnect. > > > > It would also be nice to have uevent notifications when the contents > > of current_data_role or current_power_role changes. > > > > Is that too costly to have ? > > Greg, could you give your opinion. In this case we do have attribute > files that the user space can poll. Data role is the USB data role, so > host or device, and it can change for example if the partner executes > a swap. The same can happen with the power role. So the same 'struct device' switches roles and attribute files are updated that need to be re-read? If so, yes KOBJ_CHANGE is correct, if a struct device is added/removed for this, then no, it doesn't make sense. Again, document this to describe what is happening and it might be more obvious to people and so these questions would not come up :) 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
[PATCH 2/3 v2] xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
Signed-off-by: OGAWA Hirofumi
---
drivers/usb/host/xhci-mem.c |1
drivers/usb/host/xhci-ring.c | 162 ++
drivers/usb/host/xhci.h |1
3 files changed, 87 insertions(+), 77 deletions(-)
diff -puN drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2
drivers/usb/host/xhci-mem.c
--- xhci/drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2 2016-11-16
18:38:52.551146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-mem.c 2016-11-16 18:38:52.553146763
+0900
@@ -2344,6 +2344,7 @@ int xhci_mem_init(struct xhci_hcd *xhci,
/* init command timeout work */
INIT_DELAYED_WORK(&xhci->cmd_timer, xhci_handle_command_timeout);
+ init_completion(&xhci->stop_completion);
page_size = readl(&xhci->op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff -puN drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2
drivers/usb/host/xhci-ring.c
--- xhci/drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2 2016-11-16
18:38:52.552146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-ring.c 2016-11-16 18:39:07.027136278
+0900
@@ -284,6 +284,60 @@ static bool xhci_mod_cmd_timer(struct xh
return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
}
+static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
+{
+ return list_first_entry_or_null(&xhci->cmd_list, struct xhci_command,
+ cmd_list);
+}
+
+/*
+ * Turn all commands on command ring with status set to "aborted" to no-op
trbs.
+ * If there are other commands waiting then restart the ring and kick the
timer.
+ * This must be called with command ring stopped and xhci->lock held.
+ */
+static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
+struct xhci_command *cur_cmd)
+{
+ struct xhci_command *i_cmd;
+ u32 cycle_state;
+
+ /* Turn all aborted commands in list to no-ops, then restart */
+ list_for_each_entry(i_cmd, &xhci->cmd_list, cmd_list) {
+
+ if (i_cmd->status != COMP_CMD_ABORT)
+ continue;
+
+ i_cmd->status = COMP_CMD_STOP;
+
+ xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
+i_cmd->command_trb);
+ /* get cycle state from the original cmd trb */
+ cycle_state = le32_to_cpu(
+ i_cmd->command_trb->generic.field[3]) & TRB_CYCLE;
+ /* modify the command trb to no-op command */
+ i_cmd->command_trb->generic.field[0] = 0;
+ i_cmd->command_trb->generic.field[1] = 0;
+ i_cmd->command_trb->generic.field[2] = 0;
+ i_cmd->command_trb->generic.field[3] = cpu_to_le32(
+ TRB_TYPE(TRB_CMD_NOOP) | cycle_state);
+
+ /*
+* caller waiting for completion is called when command
+* completion event is received for these no-op commands
+*/
+ }
+
+ xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+
+ /* ring command ring doorbell to restart the command ring */
+ if ((xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue) &&
+ !(xhci->xhc_state & XHCI_STATE_DYING)) {
+ xhci->current_cmd = cur_cmd;
+ xhci_mod_cmd_timer(xhci, XHCI_CMD_DEFAULT_TIMEOUT);
+ xhci_ring_cmd_db(xhci);
+ }
+}
+
static int xhci_ab
Re: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
On 11/15/2016 06:39 AM, Sriram Dash wrote:
>> From: Scott Wood
>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> new file mode 100644
>>> index 000..d934c80
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> @@ -0,0 +1,36 @@
>>> +Driver for Freescale USB 3.0 PHY
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : fsl,qoriq-usb3-phy
>>
>
> Hi Scott,
>
>> This is a very vague compatible. Are there versioning registers within this
>> register
>> block?
>>
>
> There are versioning registers for the phy (1.0 and 1.1). But the current
> erratum
> A008751 does not require the mentioning of the version numbers. Was planning
> to take care of the versioning when there is code diversity on the basis of
> the
> version number.
That is not how device tree bindings work. The describe the hardware,
not the driver.
That said, is the block version sufficient to tell whether a given chip
has this erratum? If so, you don't need a special property for the
erratum. If not, what is different about the PHY that is not described
by the versioning?
In any case, it would be nice to mention the version register and its
offset in the binding, just so that it becomes part of the definition of
this compatible string, and if we come out with some QorIQ chip with a
USB3 PHY that is totally different and doesn't have that version
register, it'll be clear that it needs a different compatible.
>>> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
>>> +offset) {
>>> + return __raw_readl(addr + offset);
>>> +}
>>> +
>>> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
>>> + u32 data)
>>> +{
>>> + __raw_writel(data, addr + offset);
>>> +}
>>
>> Why raw? Besides missing barriers, this will cause the accesses to be
>> native-endian
>> which is not correct.
>>
>
> The only reason for __raw_writel is to make the code faster.
Does that really matter here?
> However, shall I use writel(with both barriers and byte swap) instead
Yes, if the registers are little-endian on all chips.
> and then make appropriate changes in the value 32'h27672B2A?
Not sure what you mean here.
> In my knowledge, there are more than 5 errata in pipeline,
Then please get all of these errata described in the device tree ASAP
(unless their presence can be reliably inferred from the block version,
as discussed above).
> However, in future, if any other erratum comes up, and it has to be applied
> at any point other than during init, then the variable has to be added in
> qoriq_usb3_phy struct and the property has to be read separately.
Or if the erratum is detected by some means other than a device tree
property...
-Scott
--
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
USB: serial: cp210x: Add ID for the Zone DPMX
The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the
USB serial interface in its charging dock for the control pods, via
which some settings for the pods can be modified.
Signed-off-by: Paul Jakma
Cc: Barry Redmond
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index f61477b..243ac5e 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -131,6 +131,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB
Device */
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
+ { USB_DEVICE(0x10C4, 0x8962) }, /* Brim Brothers charging dock */
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
--
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] add DWR-158 in usb option
On 2016-11-16 15:53, Oliver Neukum wrote:
On Wed, 2016-11-16 at 10:22 +0700, Lars Melin wrote:
On 2016-11-16 03:20, Giuseppe Lippolis wrote:
Signed-off-by: Giuseppe Lippolis
---
Adding support for 3G modem DWR-158 from Dlink (I found it embedded in the
DWR-512).
---
--- drivers/usb/serial/option.c.orig2016-11-15 21:05:16.987504020 +0100
+++ drivers/usb/serial/option.c 2016-11-15 21:08:27.722378924 +0100
@@ -306,6 +306,9 @@ static void option_instat_callback(struc
#define DLINK_PRODUCT_DWM_652_U5 0xce16
#define DLINK_PRODUCT_DWM_652_U5A 0xce1e
+#define DLINK_ATL_VENDOR_ID0x2001
+#define DLINK_PRODUCT_DWM_158 0x7d04
+
#define QISDA_VENDOR_ID0x1da5
#define QISDA_PRODUCT_H21_4512 0x4512
#define QISDA_PRODUCT_H21_4523 0x4523
@@ -1812,6 +1815,7 @@ static const struct usb_device_id option
{ USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
{ USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) }, /* Yes,
ALINK_VENDOR_ID */
{ USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
+ { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },
{ USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
{ USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
{ USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H20_4515) },
--
NAK.
The verbose lsusb display which you pasted in your first mail shows
interface #0 and #1 to be used as netdev with cdc_ether as driver.
You must blacklist them in the option driver which otherwise will
claim them.
Hi,
why? This thing is no ethernet. If a more specific driver, that can do
do more, like link quality or AP selection, is available, we want to use
that.
So, if you use a black list, use it in cdc_ether.
Regards
Oliver
adding Johan as he is the maintainer
The patch will make the option driver claim the cdc_ether interfaces.
It can be fixed by either blacklisting those interfaces from option or
whitelist only the serial interfaces by including class matching.
Whitelisting is of course better.
rgds
/Lars
--
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] usbnet: prevent device rpm suspend in usbnet_probe function
On Mon, Nov 14, 2016 at 3:34 PM, Kai-Heng Feng wrote: > On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman > wrote: >> On 10.11.2016 13:22, Oliver Neukum wrote: >>> >>> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: > > On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: >> >> Oliver Neukum writes: >> >>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: >>> These problems could very well be caused by running at SuperSpeed (USB-3) instead of high speed (USB-2). > > > Yes, it's running at SuperSpeed, on a Kabylake laptop. > > It does not have this issue on a Broadwell laptop, also running at > SuperSpeed. Then I must join Oliver, being very surprised by where in the stack you attempt to fix the issue. What you write above indicates a problem in pci bridge or usb host controller, doesn't it? > > Yes, I was totally wrong about that. > >>> >>> >>> Indeed. And this means we need an XHCI specialist. >>> Mathias, we have a failure specific to one implementation of XHCI. >>> >> >> >> Could be related to resume singnalling time. >> Does the xhci fix for it in 4.9-rc3 help? >> >> commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 >> xhci: use default USB_RESUME_TIMEOUT when resuming ports. >> >> It doesn't directly explain why it would work on Broadwell but not Kabylake, >> but it resolved very similar cases. >> >> If not, then adding dynamic debug for xhci could show something. > > I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7, > on for-usb-next branch. > > Now the cdc_mbim still probe failed at the first time, but somehow it > re-probed again with a success. > > I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the > behavior is the same, first time probed failed, second time probed > success. > > The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled. I filed a bug report on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187861 > >> >> -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: [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
On 11/15/2016 11:46 AM, Sekhar Nori wrote:
> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>> This adds the device tree node for the usb otg
>> controller present in the da850 family of SoC's.
>> This also enables the otg usb controller for the lcdk board.
>>
>> Signed-off-by: Alexandre Bailon
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 8
>> arch/arm/boot/dts/da850.dtsi | 15 +++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts
>> index 7b8ab21..9f5040c 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -158,6 +158,14 @@
>> rx-num-evt = <32>;
>> };
>>
>> +&usb_phy {
>> +status = "okay";
>> +};
>
> As mentioned by David already, this node needs to be removed. Please
I have missed it. But why should I remove it?
Without it, usb otg won't work.
> rebase this on top of latest linux-davinci/master when ready for merging
> (driver changes accepted).
>
>> +
>> +&usb0 {
>> +status = "okay";
>> +};
>> +
>> &aemif {
>> pinctrl-names = "default";
>> pinctrl-0 = <&nand_pins>;
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..322a31a 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -372,6 +372,21 @@
>> >;
>> status = "disabled";
>> };
>> +usb_phy: usb-phy {
>> +compatible = "ti,da830-usb-phy";
>> +#phy-cells = <1>;
>> +status = "disabled";
>> +};
>> +usb0: usb@20 {
>> +compatible = "ti,da830-musb";
>> +reg = <0x20 0x1>;
>> +interrupts = <58>;
>> +interrupt-names = "mc";
>> +dr_mode = "otg";
>> +phys = <&usb_phy 0>;
>> +phy-names = "usb-phy";
>> +status = "disabled";
>> +};
>
> Can you separate out the soc specific changes from board changes? Please
> place the usb0 node above the mdio node. I am trying to get to a rough
> ordering based on reg property.
I will do.
>
> Thanks,
> Sekhar
>
Thanks,
Alexandre
--
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 4/4] ARM: dts: da850: Add the usb otg device node
On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
> On 11/15/2016 11:46 AM, Sekhar Nori wrote:
>> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>>> This adds the device tree node for the usb otg
>>> controller present in the da850 family of SoC's.
>>> This also enables the otg usb controller for the lcdk board.
>>>
>>> Signed-off-by: Alexandre Bailon
>>> ---
>>> arch/arm/boot/dts/da850-lcdk.dts | 8
>>> arch/arm/boot/dts/da850.dtsi | 15 +++
>>> 2 files changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>>> b/arch/arm/boot/dts/da850-lcdk.dts
>>> index 7b8ab21..9f5040c 100644
>>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>>> @@ -158,6 +158,14 @@
>>> rx-num-evt = <32>;
>>> };
>>>
>>> +&usb_phy {
>>> + status = "okay";
>>> + };
>>
>> As mentioned by David already, this node needs to be removed. Please
> I have missed it. But why should I remove it?
> Without it, usb otg won't work.
Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
preserved (but please fix the indentation on the closing brace).
The part in da850.dtsi needs to be removed as it is already merged.
Thanks,
Sekhar
--
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: cdc_mbim: probe of 2-2:1.12 failed with error -22
On Wed, Nov 16, 2016 at 06:42:27PM +0800, Kai-Heng Feng wrote: > Originally I sent a not-working patch to the mailing list [1], turns > out the patch is far from correct. > > Bjørn Mork suggests that we can cover the USB3 pair diff pins with > tape to do some experiment, but the vendor told me that there's no > such pin. > > According to the attached log, looks like xhci driver failed to get > status from port after resume, eventually make the cdc_mbim probe > failed: > > [ 10.038428] xhci_hcd :00:14.0: get port status, actual port 1 > status = 0x202c0 > [ 10.038429] xhci_hcd :00:14.0: Get port status returned 0x102c0 > [ 10.038463] usb usb2-port2: status 0001.02c0 after resume, -19 > [ 10.038465] usb 2-2: can't resume, status -19 > [ 10.038465] usb usb2-port2: logical disconnect > [ 10.038472] xhci_hcd :00:14.0: Cannot set link state. Odd. What kernel version is this? -- 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 4/4] ARM: dts: da850: Add the usb otg device node
On 11/16/2016 11:41 AM, Sekhar Nori wrote:
> On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
>> On 11/15/2016 11:46 AM, Sekhar Nori wrote:
>>> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.
Signed-off-by: Alexandre Bailon
---
arch/arm/boot/dts/da850-lcdk.dts | 8
arch/arm/boot/dts/da850.dtsi | 15 +++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts
b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..9f5040c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+ };
>>>
>>> As mentioned by David already, this node needs to be removed. Please
>
>> I have missed it. But why should I remove it?
>> Without it, usb otg won't work.
>
> Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
> preserved (but please fix the indentation on the closing brace).
OK. Thanks for the confirmation.
>
> The part in da850.dtsi needs to be removed as it is already merged.
>
> Thanks,
> Sekhar
>
--
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 v5 2/3] usb: musb: core: added helper function for parsing DT
From: Petr Kulhavy
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
Signed-off-by: Alexandre Bailon
Tested-by: David Lechner
Reviewed-by: Kevin Hilman
---
drivers/usb/musb/musb_core.c | 19 +++
drivers/usb/musb/musb_core.h | 6 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e01116e..9b44566 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..76f00f6 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,10 @@ static inline void
musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/*
+ * gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
--
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 v5 0/3] driver: Add DT support for DA8xx
Changes in v2: * Remove unrelated changes in patch 3 * Rename the device node in patch 4 Changes in v3: * Fix few mistakes in DT binding sample * Only build the device table if DT is enabled Change in v4: * Fix a nit Changes in v5: * Nothing. Resent the v4 in two seppaated series: one for platform and one for driver. Petr Kulhavy (3): dt/bindings: Add binding for the DA8xx MUSB driver usb: musb: core: added helper function for parsing DT usb: musb: da8xx: Add DT support for the DA8xx driver .../devicetree/bindings/usb/da8xx-usb.txt | 43 drivers/usb/musb/da8xx.c | 46 ++ drivers/usb/musb/musb_core.c | 19 + drivers/usb/musb/musb_core.h | 6 +++ 4 files changed, 114 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt -- 2.7.3 -- 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 v5 3/3] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Petr Kulhavy
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Signed-off-by: Alexandre Bailon
Tested-by: David Lechner
---
drivers/usb/musb/da8xx.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 2440f88..f205a03 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 51)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -487,6 +512,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power= get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -537,11 +572,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
--
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 v5 1/3] dt/bindings: Add binding for the DA8xx MUSB driver
From: Petr Kulhavy
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy
Signed-off-by: Alexandre Bailon
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or
"otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb@20 {
+ compatible = "ti,da830-musb";
+ reg = <0x0020 0x1>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
--
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: cdc_mbim: probe of 2-2:1.12 failed with error -22
On Wed, Nov 16, 2016 at 6:47 PM, Greg KH wrote: > On Wed, Nov 16, 2016 at 06:42:27PM +0800, Kai-Heng Feng wrote: >> Originally I sent a not-working patch to the mailing list [1], turns >> out the patch is far from correct. >> >> Bjørn Mork suggests that we can cover the USB3 pair diff pins with >> tape to do some experiment, but the vendor told me that there's no >> such pin. >> >> According to the attached log, looks like xhci driver failed to get >> status from port after resume, eventually make the cdc_mbim probe >> failed: >> >> [ 10.038428] xhci_hcd :00:14.0: get port status, actual port 1 >> status = 0x202c0 >> [ 10.038429] xhci_hcd :00:14.0: Get port status returned 0x102c0 >> [ 10.038463] usb usb2-port2: status 0001.02c0 after resume, -19 >> [ 10.038465] usb 2-2: can't resume, status -19 >> [ 10.038465] usb usb2-port2: logical disconnect >> [ 10.038472] xhci_hcd :00:14.0: Cannot set link state. > > Odd. What kernel version is this? > xhci/for-usb-next branch: 6005a545cadb2adca64350c7aee17d002563e8c7 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices The latest mainline tag in this branch is 4.9-rc3. -- 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 v5 2/2] ARM: dts: da850-lcdk: Enable the usb otg device node
This enables the usb otg controller for the lcdk board.
Signed-off-by: Alexandre Bailon
---
arch/arm/boot/dts/da850-lcdk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..03f9bfd 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
--
2.7.3
--
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 v5 0/2] platform: Add DT support for DA8xx
This add and enable the usb otg for da850 and da850-lcdk. This series depends on "driver: dd DT support for DA8xx" patch set. If this series is applied before the "usb: musb: da8xx: Fix few issues" patch set then the usb driver will always retrun -ENODEV. Changes in v2: * Remove unrelated changes in patch 3 * Rename the device node in patch 4 Changes in v3: * Fix few mistakes in DT binding sample * Only build the device table if DT is enabled Change in v4: * Fix a nit Changes in v5: * Remove usb_phy node from d850.dtsi because it has already been merged. * Separated the patch in two: one for the board and one for the SoC. Alexandre Bailon (2): ARM: dts: da850: Add the usb otg device node ARM: dts: da850-lcdk: Enable the usb otg device node arch/arm/boot/dts/da850-lcdk.dts | 8 arch/arm/boot/dts/da850.dtsi | 10 ++ 2 files changed, 18 insertions(+) -- 2.7.3 -- 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 v5 1/2] ARM: dts: da850: Add the usb otg device node
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
Signed-off-by: Alexandre Bailon
---
arch/arm/boot/dts/da850.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 2534aab..ddf4c6e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -383,6 +383,16 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ usb0: usb@20 {
+ compatible = "ti,da830-musb";
+ reg = <0x20 0x1>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
mdio: mdio@224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
--
2.7.3
--
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 5/6] usb: dwc3: use bus->sysdev for DMA configuration
Hi, Sriram Dash writes: > From: Arnd Bergmann > > The dma ops for dwc3 devices are not set properly. So, use a > physical device sysdev, which will be inherited from parent, > to set the hardware / firmware parameters like dma. > > Signed-off-by: Arnd Bergmann > Signed-off-by: Sriram Dash > Signed-off-by: Felipe Balbi I can't see when I gave you my S-o-B. Don't add stuff like that on your own, that's quite bad ;-) > Tested-by: Baolin Wang unfortunately this doesn't apply to my testing/next. Can you rebase only this one to testing/next? I think there are no hard dependencies within the series, so I could take this through my tree. -- balbi signature.asc Description: PGP signature
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, Nov 16, 2016 at 10:49:49AM +0100, Greg KH wrote: > On Wed, Nov 16, 2016 at 11:30:35AM +0200, Heikki Krogerus wrote: > > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > > Hi, > > > > > > At present I am using the uevent in the userspace to infer > > > the Presence of a port on the remote end through the > > > appearance of usbc*-partner. > > > > > > Userspace uses this info to decide on when to show a USB > > > notification on the screen and what should be the options > > > provided in the dialog. > > > > > > I was assuming that this is not something that would be dropped. > > > > > > Coding using events was relatively easier to program from userspace .. > > > > > > Is it possible to use POLL for identifying the appearance of port partner > > > ? > > > I did not notice sysfs_notify call in typec_connect/typec_disconnect. > > > > > > It would also be nice to have uevent notifications when the contents > > > of current_data_role or current_power_role changes. > > > > > > Is that too costly to have ? > > > > Greg, could you give your opinion. In this case we do have attribute > > files that the user space can poll. Data role is the USB data role, so > > host or device, and it can change for example if the partner executes > > a swap. The same can happen with the power role. > > So the same 'struct device' switches roles and attribute files are > updated that need to be re-read? If so, yes KOBJ_CHANGE is correct, if > a struct device is added/removed for this, then no, it doesn't make > sense. OK, I'll add KOBJ_CHANGE for those. So is it OK to everybody if I remove the KOBJ_CHANGE in typec_connect()? We will see uevent KOBJ_ADD since the partner (or cable) is added in any case. Badhri, Oliver? Thanks, -- heikki -- 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] dwc3: make PM functions as __maybe_unused
Hi,
Arnd Bergmann writes:
> A change to the suspend/resume handling in dwc3-pci introduced a
> harmless warning:
>
> drivers/usb/dwc3/dwc3-pci.c:169:12: error: ‘dwc3_pci_dsm’ defined but not
> used [-Werror=unused-function]
>
> Replacing the #ifdef around the PM functions with __maybe_unused
> annotations is the easiest way to make sure this doesn't happen
> again. A similar problem happened two months earlier and we
> ended up updating the #ifdef, but as it has come back now,
> I'd suggest going back to my earlier approach.
>
> Fixes: 9cecca75b5a0 ("usb: dwc3: pci: call _DSM for suspend/resume")
> Link: https://patchwork.kernel.org/patch/9318887/
> Signed-off-by: Arnd Bergmann
I'll just move the ifdef around. We really need a real fix for this. Why
couldn't we just always add PM callbacks and assume they won't be used
if !PM && !PM_SLEEP?
Adding __maybe_unused everywhere is rather unelegant :-(
--
balbi
signature.asc
Description: PGP signature
[PATCH] usb: dwc3: pci: avoid build warning
dwc3_pci_dsm() is only needed if (PM || PM_SLEEP),
we should make sure it's not defined if neither of
those is defined.
This fixes a randconfig build warning.
Reported-by: Arnd Bergmann
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-pci.c | 50 +++--
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8c39ec6522fd..2b0e34ddaae8 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -166,30 +166,6 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
return 0;
}
-static int dwc3_pci_dsm(struct dwc3_pci *dwc, int param)
-{
- union acpi_object *obj;
- union acpi_object tmp;
- union acpi_object argv4 = ACPI_INIT_DSM_ARGV4(1, &tmp);
-
- if (!dwc->has_dsm_for_pm)
- return 0;
-
- tmp.type = ACPI_TYPE_INTEGER;
- tmp.integer.value = param;
-
- obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), dwc->uuid,
- 1, PCI_INTEL_BXT_FUNC_PMU_PWR, &argv4);
- if (!obj) {
- dev_err(&dwc->pci->dev, "failed to evaluate _DSM\n");
- return -EIO;
- }
-
- ACPI_FREE(obj);
-
- return 0;
-}
-
static int dwc3_pci_probe(struct pci_dev *pci,
const struct pci_device_id *id)
{
@@ -293,6 +269,32 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
+#if defined(CONFIG_PM) || defined(CONFIG_PM_SLEEP)
+static int dwc3_pci_dsm(struct dwc3_pci *dwc, int param)
+{
+ union acpi_object *obj;
+ union acpi_object tmp;
+ union acpi_object argv4 = ACPI_INIT_DSM_ARGV4(1, &tmp);
+
+ if (!dwc->has_dsm_for_pm)
+ return 0;
+
+ tmp.type = ACPI_TYPE_INTEGER;
+ tmp.integer.value = param;
+
+ obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), dwc->uuid,
+ 1, PCI_INTEL_BXT_FUNC_PMU_PWR, &argv4);
+ if (!obj) {
+ dev_err(&dwc->pci->dev, "failed to evaluate _DSM\n");
+ return -EIO;
+ }
+
+ ACPI_FREE(obj);
+
+ return 0;
+}
+#endif /* CONFIG_PM || CONFIG_PM_SLEEP */
+
#ifdef CONFIG_PM
static int dwc3_pci_runtime_suspend(struct device *dev)
{
--
2.10.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: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, 2016-11-16 at 13:09 +0200, Heikki Krogerus wrote: > OK, I'll add KOBJ_CHANGE for those. > > So is it OK to everybody if I remove the KOBJ_CHANGE in > typec_connect()? We will see uevent KOBJ_ADD since the partner (or > cable) is added in any case. Badhri, Oliver? OK by me. 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
[PATCH v2 1/1] usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices
USB-3 does not have any link state that will avoid negotiating a connection
with a plugged-in cable but will signal the host when the cable is
unplugged.
For USB-3 we used to first set the link to Disabled, then to RxDdetect to
be able to detect cable connects or disconnects. But in RxDetect the
connected device is detected again and eventually enabled.
Instead set the link into U3 and disable remote wakeups for the device.
This is what Windows does, and what Alan Stern suggested.
Cc: sta...@vger.kernel.org
Cc: Alan Stern
Signed-off-by: Mathias Nyman
---
Changes since RFC-PATCH:
- send port_dev as an argument
- move checking and disabling remote wakeup to a function under CONFIG_PM
- set device state to USB_STATE_NOTATTACHED _after_ disabling remote wakup
and port disable.
---
drivers/usb/core/hub.c | 100 +
1 file changed, 35 insertions(+), 65 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 76e80d8..3775424 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -103,6 +103,8 @@
static void hub_release(struct kref *kref);
static int usb_reset_and_verify_device(struct usb_device *udev);
+static void hub_usb3_port_prepare_disable(struct usb_hub *hub,
+ struct usb_port *port_dev);
static inline char *portspeed(struct usb_hub *hub, int portstatus)
{
@@ -901,82 +903,28 @@ static int hub_set_port_link_state(struct usb_hub *hub,
int port1,
}
/*
- * If USB 3.0 ports are placed into the Disabled state, they will no longer
- * detect any device connects or disconnects. This is generally not what the
- * USB core wants, since it expects a disabled port to produce a port status
- * change event when a new device connects.
- *
- * Instead, set the link state to Disabled, wait for the link to settle into
- * that state, clear any change bits, and then put the port into the RxDetect
- * state.
+ * USB-3 does not have a similar link state as USB-2 that will avoid
negotiating
+ * a connection with a plugged-in cable but will signal the host when the cable
+ * is unplugged. Disable remote wake and set link state to U3 for USB-3 devices
*/
-static int hub_usb3_port_disable(struct usb_hub *hub, int port1)
-{
- int ret;
- int total_time;
- u16 portchange, portstatus;
-
- if (!hub_is_superspeed(hub->hdev))
- return -EINVAL;
-
- ret = hub_port_status(hub, port1, &portstatus, &portchange);
- if (ret < 0)
- return ret;
-
- /*
-* USB controller Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
-* Controller [1022:7814] will have spurious result making the following
-* usb 3.0 device hotplugging route to the 2.0 root hub and recognized
-* as high-speed device if we set the usb 3.0 port link state to
-* Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state, we
-* check the state here to avoid the bug.
-*/
- if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_RX_DETECT) {
- dev_dbg(&hub->ports[port1 - 1]->dev,
-"Not disabling port; link state is RxDetect\n");
- return ret;
- }
-
- ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
- if (ret)
- return ret;
-
- /* Wait for the link to enter the disabled state. */
- for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
- ret = hub_port_status(hub, port1, &portstatus, &portchange);
- if (ret < 0)
- return ret;
-
- if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_SS_DISABLED)
- break;
- if (total_time >= HUB_DEBOUNCE_TIMEOUT)
- break;
- msleep(HUB_DEBOUNCE_STEP);
- }
- if (total_time >= HUB_DEBOUNCE_TIMEOUT)
- dev_warn(&hub->ports[port1 - 1]->dev,
- "Could not disable after %d ms\n", total_time);
-
- return hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_RX_DETECT);
-}
-
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_device *hdev = hub->hdev;
int ret = 0;
- if (port_dev->child && set_state)
- usb_set_device_state(port_dev->child, USB_STATE_NOTATTACHED);
if (!hub->error) {
- if (hub_is_superspeed(hub->hdev))
- ret = hub_usb3_port_disable(hub, port1);
- else
+ if (hub_is_superspeed(hub->hdev)) {
+ hub_usb3_port_prepare_disable(hub, port_dev);
+ ret = hub_set_port_link_state(hub, port_dev->portnum,
+
RE: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
>From: Scott Wood
>On 11/15/2016 06:39 AM, Sriram Dash wrote:
>>> From: Scott Wood
>>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
diff --git
a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
new file mode 100644
index 000..d934c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
@@ -0,0 +1,36 @@
+Driver for Freescale USB 3.0 PHY
+
+Required properties:
+
+- compatible :fsl,qoriq-usb3-phy
>>>
>>
>> Hi Scott,
>>
>>> This is a very vague compatible. Are there versioning registers
>>> within this register block?
>>>
>>
>> There are versioning registers for the phy (1.0 and 1.1). But the
>> current erratum
>> A008751 does not require the mentioning of the version numbers. Was
>> planning to take care of the versioning when there is code diversity
>> on the basis of the version number.
>
>That is not how device tree bindings work. The describe the hardware, not the
>driver.
>
>That said, is the block version sufficient to tell whether a given chip has
>this
>erratum? If so, you don't need a special property for the erratum. If not,
>what is
>different about the PHY that is not described by the versioning?
>
>In any case, it would be nice to mention the version register and its offset
>in the
>binding, just so that it becomes part of the definition of this compatible
>string, and
>if we come out with some QorIQ chip with a
>USB3 PHY that is totally different and doesn't have that version register,
>it'll be
>clear that it needs a different compatible.
>
Okay. Will include version number in the next rev for Documentation and dt.
+static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
+offset) {
+ return __raw_readl(addr + offset); }
+
+static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
+ u32 data)
+{
+ __raw_writel(data, addr + offset); }
>>>
>>> Why raw? Besides missing barriers, this will cause the accesses to
>>> be native-endian which is not correct.
>>>
>>
>> The only reason for __raw_writel is to make the code faster.
>
>Does that really matter here?
>
>> However, shall I use writel(with both barriers and byte swap) instead
>
>Yes, if the registers are little-endian on all chips.
>
The endianness is not same for all Socs. But for most Socs, it is big-endian.
Is "iowrite32be" better instead?
>> and then make appropriate changes in the value 32'h27672B2A?
>
>Not sure what you mean here.
>
>> In my knowledge, there are more than 5 errata in pipeline,
>
>Then please get all of these errata described in the device tree ASAP (unless
>their
>presence can be reliably inferred from the block version, as discussed above).
>
Yes. We will push the errata asap.
>> However, in future, if any other erratum comes up, and it has to be
>> applied at any point other than during init, then the variable has to
>> be added in qoriq_usb3_phy struct and the property has to be read separately.
>
>Or if the erratum is detected by some means other than a device tree
>property...
>
Yes. For any other case also, it will be handled differently.
>-Scott
--
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: crash by cdc_acm driver in kernels 4.8-rc1/5
On Tue, 2016-11-15 at 14:29 +0100, Wim Osterholt wrote: > I experience a sliding scale. > With debug it crashes immediately. It may crash later on (even at shutdown > time). It's not even an oops but a warning. In the end it happens to just > work. This is very odd. We need to know where it crashes. Please try the insane debug patch I posted. 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
[bug report] [ARM] ohci-pxa27x: use ioremap() and offset for register access
Hi USB devs,
I have no idea who to contact for this, the bug predates git.
drivers/usb/host/ohci-pxa27x.c:150 pxa27x_ohci_select_pmm()
warn: odd binop '0x200 & 0x100'
drivers/usb/host/ohci-pxa27x.c
130 /*
131PMM_NPS_MODE -- PMM Non-power switching mode
132Ports are powered continuously.
133
134PMM_GLOBAL_MODE -- PMM global switching mode
135All ports are powered at the same time.
136
137PMM_PERPORT_MODE -- PMM per port switching mode
138Ports are powered individually.
139 */
140 static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci, int
mode)
141 {
142 uint32_t uhcrhda = __raw_readl(pxa_ohci->mmio_base + UHCRHDA);
143 uint32_t uhcrhdb = __raw_readl(pxa_ohci->mmio_base + UHCRHDB);
144
145 switch (mode) {
146 case PMM_NPS_MODE:
147 uhcrhda |= RH_A_NPS;
148 break;
149 case PMM_GLOBAL_MODE:
150 uhcrhda &= ~(RH_A_NPS & RH_A_PSM);
My guess is that | was intended instead of & here, but I am not sure.
151 break;
152 case PMM_PERPORT_MODE:
153 uhcrhda &= ~(RH_A_NPS);
154 uhcrhda |= RH_A_PSM;
155
156 /* Set port power control mask bits, only 3 ports. */
157 uhcrhdb |= (0x7<<17);
158 break;
159 default:
160 printk( KERN_ERR
161 "Invalid mode %d, set to non-power switch
mode.\n",
162 mode );
163
164 uhcrhda |= RH_A_NPS;
165 }
166
167 __raw_writel(uhcrhda, pxa_ohci->mmio_base + UHCRHDA);
168 __raw_writel(uhcrhdb, pxa_ohci->mmio_base + UHCRHDB);
169 return 0;
170 }
regards,
dan carpenter
--
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
Клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com
Клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com -- 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 v5 4/5] USB: ohci: da8xx: Add devicetree bindings
On Mon, Nov 14, 2016 at 03:41:02PM +0100, Axel Haslam wrote: > This patch documents the device tree bindings required for > the ohci controller found in TI da8xx family of SoC's > > Cc: robh...@kernel.org > Cc: mark.rutl...@arm.com > Cc: devicet...@vger.kernel.org > Signed-off-by: Axel Haslam > --- > .../devicetree/bindings/usb/ohci-da8xx.txt | 23 > ++ > 1 file changed, 23 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt Acked-by: Rob Herring -- 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: [PATHCv10 1/2] usb: USB Type-C connector class
> IMHO the uevent is cheaper. User space cannot just poll without further > infrastructure. A task needs to run to poll. A uevent can be handled > through established infrastructure. Thanks Oliver for stating this. This is exactly what I was facing. > OK, I'll add KOBJ_CHANGE for those. > > So is it OK to everybody if I remove the KOBJ_CHANGE in > typec_connect()? We will see uevent KOBJ_ADD since the partner (or > cable) is added in any case. Badhri, Oliver? Yes Heikki.. That's OK for me as well. Just to get my understanding right. You are planning to add KOBJ_CHANGE uevents when current_power_role or current_data_role changes and KOBJ_ADD when new port-partner or the cable is attached. Is that right ? Thanks, Badhri. On Wed, Nov 16, 2016 at 3:27 AM, Oliver Neukum wrote: > On Wed, 2016-11-16 at 13:09 +0200, Heikki Krogerus wrote: > >> OK, I'll add KOBJ_CHANGE for those. >> >> So is it OK to everybody if I remove the KOBJ_CHANGE in >> typec_connect()? We will see uevent KOBJ_ADD since the partner (or >> cable) is added in any case. Badhri, Oliver? > > OK by me. > > 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: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, Nov 16, 2016 at 06:30:23AM -0800, Badhri Jagan Sridharan wrote: > > IMHO the uevent is cheaper. User space cannot just poll without further > > infrastructure. A task needs to run to poll. A uevent can be handled > > through established infrastructure. > > Thanks Oliver for stating this. This is exactly what I was facing. > > > OK, I'll add KOBJ_CHANGE for those. > > > > So is it OK to everybody if I remove the KOBJ_CHANGE in > > typec_connect()? We will see uevent KOBJ_ADD since the partner (or > > cable) is added in any case. Badhri, Oliver? > > Yes Heikki.. That's OK for me as well. > Just to get my understanding right. You are planning to add > KOBJ_CHANGE uevents when current_power_role or > current_data_role changes and KOBJ_ADD when new port-partner > or the cable is attached. Is that right ? Yes, though I don't KOBJ_ADD separately with the partners and cables. That uevent is sent when the device for them is registered, so it's already there. Br, -- heikki -- 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] dma: cpp41: Fix handling of error path
* Sekhar Nori [161115 22:25]:
> On Wednesday 16 November 2016 02:28 AM, Tony Lindgren wrote:
> > * Sekhar Nori [161115 00:35]:
> >> If pm_runtime_get_sync() fails due to callback error, then
> >> rpm_callback() sets dev.power.runtime_error to an error value which gets
> >> cleared by an explicit call to pm_runtime_set_suspended().
> >>
> >> This will tell the framework that the status of device is suspended.
> >> Else, the failure will be sticky and on subsequent attempts,
> >> rpm_resume() will keep returning early instead of trying to resume the
> >> device again.
> >>
> >> This is as far as I can gather from code. So, I believe the recovery
> >> path should be:
> >>
> >>if (error < 0) {
> >>pm_runtime_set_suspended(cdd->ddev.dev);
> >>pm_runtime_put_noidle(cdd->ddev.dev);
> >>
> >>...
> >
> > Well we should test this :)
>
> Yes, right! Was this patch created to fix an error in practice or just
> based on code review?
Based on code review for related musb fixes. I'll test the above today
at some point.
> > BTW, what other users of cppi41 do we have in addition to musb? I think
> > davinci is or will be using it too?
>
> The list Bin provided seems accurate.
OK so it's used by musb only with no other hardware blocks using cppi41?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v2] xhci: Fix race related to abort operation
On 16.11.2016 11:50, OGAWA Hirofumi wrote:
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
Nice catch
Didn't see that race, with the possible abortion of a random command.
The retry was a workaround for a case triggered on v4.1.4 by
Vincent Pelletier (added to CC)
http://marc.info/?l=linux-usb&m=144031185222108&w=2
The race could very well explain that issue.
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
Sounds reasonable
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
Signed-off-by: OGAWA Hirofumi
---
drivers/usb/host/xhci-mem.c |1
drivers/usb/host/xhci-ring.c | 162 ++
drivers/usb/host/xhci.h |1
3 files changed, 87 insertions(+), 77 deletions(-)
diff -puN drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2
drivers/usb/host/xhci-mem.c
--- xhci/drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2 2016-11-16
18:38:52.551146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-mem.c 2016-11-16 18:38:52.553146763
+0900
@@ -2344,6 +2344,7 @@ int xhci_mem_init(struct xhci_hcd *xhci,
/* init command timeout work */
INIT_DELAYED_WORK(&xhci->cmd_timer, xhci_handle_command_timeout);
+ init_completion(&xhci->stop_completion);
page_size = readl(&xhci->op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff -puN drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2
drivers/usb/host/xhci-ring.c
--- xhci/drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2 2016-11-16
18:38:52.552146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-ring.c 2016-11-16 18:39:07.027136278
+0900
@@ -284,6 +284,60 @@ static bool xhci_mod_cmd_timer(struct xh
return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
}
+static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
+{
+ return list_first_entry_or_null(&xhci->cmd_list, struct xhci_command,
+ cmd_list);
+}
+
+/*
+ * Turn all commands on command ring with status set to "aborted" to no-op
trbs.
+ * If there are other commands waiting then restart the ring and kick the
timer.
+ * This must be called with command ring stopped and xhci->lock held.
+ */
+static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
+struct xhci_command *cur_cmd)
+{
+ struct xhci_command *i_cmd;
+ u32 cycle_state;
+
+ /* Turn all aborted commands in list to no-ops, then restart */
+ list_for_each_entry(i_cmd, &xhci->cmd_list, cmd_list) {
+
+ if (i_cmd->status != COMP_CMD_ABORT)
+ continue;
+
+ i_cmd->status = COMP_CMD_STOP;
+
+ xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
+i_cmd->command_trb);
+ /* get cycle state from the original cmd trb */
+ cycle_state = le32_to_cpu(
+ i_cmd->command_trb->generic.field[3]) & TRB_CYCLE;
+ /* modify the command trb to no-op command */
+ i_cmd->command_trb->generic.field[0] = 0;
+ i_cmd->command_trb->generic.field[1] = 0;
+ i_cmd->command_trb->generic.field[2] = 0;
+ i_cmd->command_trb->generic.field[3] = cpu_to_le32(
+ TRB_TYPE(TRB_CMD_NOOP) | cycle_state);
+
+ /*
+* caller waiting for completion is called when command
+* completion event is received for these no-op commands
+*/
+ }
+
+ xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+
+ /* ring
Re: crash by cdc_acm driver in kernels 4.8-rc1/5
On Wed, Nov 16, 2016 at 01:34:30PM +0100, Oliver Neukum wrote: > > This is very odd. We need to know where it crashes. Please try the > insane debug patch I posted. A bit of patience please. Yesterday I hadn't the modem at hand. Groeten, Wim. -- 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: [PATHCv10 1/2] usb: USB Type-C connector class
Hi Greg,
On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote:
> > +static int sysfs_strmatch(const char * const *array, size_t n, const char
> > *str)
> > +{
> > + const char *item;
> > + int index;
> > +
> > + for (index = 0; index < n; index++) {
> > + item = array[index];
> > + if (!item)
> > + break;
> > + if (sysfs_streq(item, str))
> > + return index;
> > + }
> > +
> > + return -EINVAL;
> > +}
>
> should we make this a core sysfs function?
Last question before I send v11. Is the following (the helper) OK?
diff --git a/include/linux/string.h b/include/linux/string.h
index 26b6f6a..5606810 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -135,6 +135,16 @@ static inline int strtobool(const char *s, bool *res)
}
int match_string(const char * const *array, size_t n, const char *string);
+int __sysfs_strmatch(const char * const *array, size_t n, const char *string);
+
+/**
+ * sysfs_strmatch - matches given string in an array
+ * @a: array of strings
+ * @s: string to match with
+ *
+ * Helper for __sysfs_strmatch(). Calculates the size of @a automatically.
+ */
+#define sysfs_strmatch(a, s) __sysfs_strmatch(a, ARRAY_SIZE(a), s)
#ifdef CONFIG_BINARY_PRINTF
int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
diff --git a/lib/string.c b/lib/string.c
index ed83562..a4fe035 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -656,6 +656,32 @@ int match_string(const char * const *array, size_t n,
const char *string)
}
EXPORT_SYMBOL(match_string);
+/**
+ * __sysfs_strmatch - matches given string in an array
+ * @array: array of strings
+ * @n: number of strings in the array or -1 for NULL terminated arrays
+ * @str: string to match with
+ *
+ * Returns index of @str in the @array or -EINVAL, just like match_string().
+ * Uses sysfs_streq() instead of strcmp for matching.
+ */
+int __sysfs_strmatch(const char * const *array, size_t n, const char *str)
+{
+ const char *item;
+ int index;
+
+ for (index = 0; index < n; index++) {
+ item = array[index];
+ if (!item)
+ break;
+ if (!sysfs_streq(item, str))
+ return index;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(__sysfs_strmatch);
+
#ifndef __HAVE_ARCH_MEMSET
/**
* memset - Fill a region of memory with the given value
--
heikki
--
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: [PATHCv10 1/2] usb: USB Type-C connector class
> Yes, though I don't KOBJ_ADD separately with the partners and cables.
> That uevent is sent when the device for them is registered, so it's
> already there
Makes sense. Thanks Heikki.
Regards,
Badhri
On Wed, Nov 16, 2016 at 7:20 AM, Heikki Krogerus
wrote:
> Hi Greg,
>
> On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote:
>> > +static int sysfs_strmatch(const char * const *array, size_t n, const char
>> > *str)
>> > +{
>> > + const char *item;
>> > + int index;
>> > +
>> > + for (index = 0; index < n; index++) {
>> > + item = array[index];
>> > + if (!item)
>> > + break;
>> > + if (sysfs_streq(item, str))
>> > + return index;
>> > + }
>> > +
>> > + return -EINVAL;
>> > +}
>>
>> should we make this a core sysfs function?
>
> Last question before I send v11. Is the following (the helper) OK?
>
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 26b6f6a..5606810 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -135,6 +135,16 @@ static inline int strtobool(const char *s, bool *res)
> }
>
> int match_string(const char * const *array, size_t n, const char *string);
> +int __sysfs_strmatch(const char * const *array, size_t n, const char
> *string);
> +
> +/**
> + * sysfs_strmatch - matches given string in an array
> + * @a: array of strings
> + * @s: string to match with
> + *
> + * Helper for __sysfs_strmatch(). Calculates the size of @a automatically.
> + */
> +#define sysfs_strmatch(a, s) __sysfs_strmatch(a, ARRAY_SIZE(a), s)
>
> #ifdef CONFIG_BINARY_PRINTF
> int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
> diff --git a/lib/string.c b/lib/string.c
> index ed83562..a4fe035 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -656,6 +656,32 @@ int match_string(const char * const *array, size_t n,
> const char *string)
> }
> EXPORT_SYMBOL(match_string);
>
> +/**
> + * __sysfs_strmatch - matches given string in an array
> + * @array: array of strings
> + * @n: number of strings in the array or -1 for NULL terminated arrays
> + * @str: string to match with
> + *
> + * Returns index of @str in the @array or -EINVAL, just like match_string().
> + * Uses sysfs_streq() instead of strcmp for matching.
> + */
> +int __sysfs_strmatch(const char * const *array, size_t n, const char *str)
> +{
> + const char *item;
> + int index;
> +
> + for (index = 0; index < n; index++) {
> + item = array[index];
> + if (!item)
> + break;
> + if (!sysfs_streq(item, str))
> + return index;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(__sysfs_strmatch);
> +
> #ifndef __HAVE_ARCH_MEMSET
> /**
> * memset - Fill a region of memory with the given value
>
>
> --
> heikki
> --
> 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: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, Nov 16, 2016 at 05:20:24PM +0200, Heikki Krogerus wrote:
> Hi Greg,
>
> On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote:
> > > +static int sysfs_strmatch(const char * const *array, size_t n, const
> > > char *str)
> > > +{
> > > + const char *item;
> > > + int index;
> > > +
> > > + for (index = 0; index < n; index++) {
> > > + item = array[index];
> > > + if (!item)
> > > + break;
> > > + if (sysfs_streq(item, str))
> > > + return index;
> > > + }
> > > +
> > > + return -EINVAL;
> > > +}
> >
> > should we make this a core sysfs function?
>
> Last question before I send v11. Is the following (the helper) OK?
>
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 26b6f6a..5606810 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -135,6 +135,16 @@ static inline int strtobool(const char *s, bool *res)
> }
>
> int match_string(const char * const *array, size_t n, const char *string);
> +int __sysfs_strmatch(const char * const *array, size_t n, const char
> *string);
> +
> +/**
> + * sysfs_strmatch - matches given string in an array
> + * @a: array of strings
> + * @s: string to match with
> + *
> + * Helper for __sysfs_strmatch(). Calculates the size of @a automatically.
> + */
> +#define sysfs_strmatch(a, s) __sysfs_strmatch(a, ARRAY_SIZE(a), s)
People will bikeshed the name. Why not just use sysfs_match_string() as
this does the same as match_string, but calls sysfs_string instead of
strcmp().
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
[PATCH] usb: dwc3: avoid empty-body warning
Building with W=1, we get a warning about harmless empty statements:
drivers/usb/dwc3/ep0.c: In function 'dwc3_ep0_handle_intf':
drivers/usb/dwc3/ep0.c:491:4: error: suggest braces around empty body in an
'if' statement [-Werror=empty-body]
gcc does not warn about {} here, so maybe use that instead.
Alternatively, the code could be removed entirely as it does
nothing.
Signed-off-by: Arnd Bergmann
---
This has been present in the driver for a while, but the code
just moved around, so it showed up as a new warning for me.
I hope to eventually address all W=1 warnings as they tend to
find real bugs elsewhere and we may as well fix it now that the
code has changed.
---
drivers/usb/dwc3/ep0.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 2b22ea7263d8..1e93cfc8f88b 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -486,12 +486,12 @@ static int dwc3_ep0_handle_intf(struct dwc3 *dwc,
switch (wValue) {
case USB_INTRF_FUNC_SUSPEND:
- if (wIndex & USB_INTRF_FUNC_SUSPEND_LP)
+ if (wIndex & USB_INTRF_FUNC_SUSPEND_LP) {
/* XXX enable Low power suspend */
- ;
- if (wIndex & USB_INTRF_FUNC_SUSPEND_RW)
+ }
+ if (wIndex & USB_INTRF_FUNC_SUSPEND_RW) {
/* XXX enable remote wakeup */
- ;
+ }
break;
default:
ret = -EINVAL;
--
2.9.0
--
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 stops working if a malfunctioning USB device is connected
> At least Debian started building toolchains with PIE enabled by > default. I've had this problem for a while, actually. I'm building > kernels with: > > $ make CC="gcc -fno-PIE" > > and everything builds fine. Great. Kernel build is going on now. Will post about further developments. -- 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: dwc3: pci: avoid build warning
On Wednesday, November 16, 2016 1:17:51 PM CET Felipe Balbi wrote: > dwc3_pci_dsm() is only needed if (PM || PM_SLEEP), > we should make sure it's not defined if neither of > those is defined. > > This fixes a randconfig build warning. > > Reported-by: Arnd Bergmann > Signed-off-by: Felipe Balbi > Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v2] xhci: Fix race related to abort operation
Mathias Nyman writes:
> The retry was a workaround for a case triggered on v4.1.4 by
> Vincent Pelletier (added to CC)
>
>http://marc.info/?l=linux-usb&m=144031185222108&w=2
>
> The race could very well explain that issue.
>From logs of that thread, it would has possibility about this race.
>> @@ -320,15 +367,29 @@ static int xhci_abort_cmd_ring(struct xh
>> udelay(1000);
>> ret = xhci_handshake(&xhci->op_regs->cmd_ring,
>> CMD_RING_RUNNING, 0, 3 * 1000 * 1000);
>> -if (ret == 0)
>> -return 0;
>> +if (ret < 0) {
>> +xhci_err(xhci, "Stopped the command ring failed, "
>> + "maybe the host is dead\n");
>> +xhci->xhc_state |= XHCI_STATE_DYING;
>> +xhci_halt(xhci);
>> +return -ESHUTDOWN;
>> +}
>> +}
>
> So if we can verify that the race fix solves the old issue for Vincent
> Pelletier then we could get rid of the abort retry above as well.
Right. However, I'm not sure (and maybe you neither). So I didn't
remove it in this patchset.
(After this patchset, I guess the retry will hit only when actual chip
internal confusion. I.e. retry will fail, then will chip halted.)
Well, anyway, if you decide to try to remove the retry, I also think it
would worth to try. However, it would be [PATCH 4/4] or as another
patchset.
>> +/*
>> + * Writing the CMD_RING_ABORT bit should cause a cmd completion event,
>> + * however on some host hw the CMD_RING_RUNNING bit is correctly cleared
>> + * but the completion event in never sent. Wait 2 secs (arbitrary
>> + * number) to handle those cases after negation of CMD_RING_RUNNING.
>> + */
>
> I'm speculating a bit here, but as we now can sleep, and if we could
> get rid of the abort retry couldn't we swap the order of the
> xhci_handshake(CMD_RING_RUNNING) busywait and
> wait_for_completion_timeout(). We could also use a standard command
> timeout time while waiting for the completion
>
> something like:
>
> hci_write_64(CMD_RING_ABORT)
> timed_out = wait_for_completion_timeout(XHCI_CMD_DEFAULT_TIMEOUT)
> xhci_handshake(CMD_RING_RUNNING)
> if (handshake fail) {
> xhci_halt(), etc..
>return -ESHUTDOWN
> }
> if (timed out) {
>xhci_cleanup_command_queue(xhci);
>return
> }
>
> It would reduce the time we spend in the xhci_handshake() busyloop
BTW, busyloop removal was done by "[PATCH 3/3] ...". By [PATCH 3/3], we
can simply use straight forward coding without busyloop.
>> diff -puN drivers/usb/host/xhci.h~xhci-fix-abort-race2
>> drivers/usb/host/xhci.h
>> --- xhci/drivers/usb/host/xhci.h~xhci-fix-abort-race22016-11-16
>> 18:38:52.552146764 +0900
>> +++ xhci-hirofumi/drivers/usb/host/xhci.h2016-11-16 18:38:52.554146762
>> +0900
>> @@ -1574,6 +1574,7 @@ struct xhci_hcd {
>> struct list_headcmd_list;
>> unsigned intcmd_ring_reserved_trbs;
>> struct delayed_work cmd_timer;
>> +struct completion stop_completion;
>
> Tiny thing, but maybe change stop_completion to
> cmd_ring_stop_completion. to avoid mixing it with stopping host
> controller, stop endpoint, stop device etc
OK.
--
OGAWA Hirofumi
--
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 2/3 v3] xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
Signed-off-by: OGAWA Hirofumi
---
drivers/usb/host/xhci-mem.c |1
drivers/usb/host/xhci-ring.c | 163 ++
drivers/usb/host/xhci.h |1
3 files changed, 88 insertions(+), 77 deletions(-)
diff -puN drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2
drivers/usb/host/xhci-mem.c
--- xhci/drivers/usb/host/xhci-mem.c~xhci-fix-abort-race2 2016-11-16
18:38:52.551146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-mem.c 2016-11-17 01:04:11.402014445
+0900
@@ -2344,6 +2344,7 @@ int xhci_mem_init(struct xhci_hcd *xhci,
/* init command timeout work */
INIT_DELAYED_WORK(&xhci->cmd_timer, xhci_handle_command_timeout);
+ init_completion(&xhci->cmd_ring_stop_completion);
page_size = readl(&xhci->op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff -puN drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2
drivers/usb/host/xhci-ring.c
--- xhci/drivers/usb/host/xhci-ring.c~xhci-fix-abort-race2 2016-11-16
18:38:52.552146764 +0900
+++ xhci-hirofumi/drivers/usb/host/xhci-ring.c 2016-11-17 01:04:06.393018485
+0900
@@ -284,6 +284,60 @@ static bool xhci_mod_cmd_timer(struct xh
return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
}
+static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
+{
+ return list_first_entry_or_null(&xhci->cmd_list, struct xhci_command,
+ cmd_list);
+}
+
+/*
+ * Turn all commands on command ring with status set to "aborted" to no-op
trbs.
+ * If there are other commands waiting then restart the ring and kick the
timer.
+ * This must be called with command ring stopped and xhci->lock held.
+ */
+static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
+struct xhci_command *cur_cmd)
+{
+ struct xhci_command *i_cmd;
+ u32 cycle_state;
+
+ /* Turn all aborted commands in list to no-ops, then restart */
+ list_for_each_entry(i_cmd, &xhci->cmd_list, cmd_list) {
+
+ if (i_cmd->status != COMP_CMD_ABORT)
+ continue;
+
+ i_cmd->status = COMP_CMD_STOP;
+
+ xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
+i_cmd->command_trb);
+ /* get cycle state from the original cmd trb */
+ cycle_state = le32_to_cpu(
+ i_cmd->command_trb->generic.field[3]) & TRB_CYCLE;
+ /* modify the command trb to no-op command */
+ i_cmd->command_trb->generic.field[0] = 0;
+ i_cmd->command_trb->generic.field[1] = 0;
+ i_cmd->command_trb->generic.field[2] = 0;
+ i_cmd->command_trb->generic.field[3] = cpu_to_le32(
+ TRB_TYPE(TRB_CMD_NOOP) | cycle_state);
+
+ /*
+* caller waiting for completion is called when command
+* completion event is received for these no-op commands
+*/
+ }
+
+ xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+
+ /* ring command ring doorbell to restart the command ring */
+ if ((xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue) &&
+ !(xhci->xhc_state & XHCI_STATE_DYING)) {
+ xhci->current_cmd = cur_cmd;
+ xhci_mod_cmd_timer(xhci, XHCI_CMD_DEFAULT_TIMEOUT);
+ xhci_ring_cmd_db(xhci);
+ }
+}
+
static in
Re: cdc_mbim: probe of 2-2:1.12 failed with error -22
On Wed, Nov 16, 2016 at 06:56:30PM +0800, Kai-Heng Feng wrote: > On Wed, Nov 16, 2016 at 6:47 PM, Greg KH wrote: > > On Wed, Nov 16, 2016 at 06:42:27PM +0800, Kai-Heng Feng wrote: > >> Originally I sent a not-working patch to the mailing list [1], turns > >> out the patch is far from correct. > >> > >> Bjørn Mork suggests that we can cover the USB3 pair diff pins with > >> tape to do some experiment, but the vendor told me that there's no > >> such pin. > >> > >> According to the attached log, looks like xhci driver failed to get > >> status from port after resume, eventually make the cdc_mbim probe > >> failed: > >> > >> [ 10.038428] xhci_hcd :00:14.0: get port status, actual port 1 > >> status = 0x202c0 > >> [ 10.038429] xhci_hcd :00:14.0: Get port status returned 0x102c0 > >> [ 10.038463] usb usb2-port2: status 0001.02c0 after resume, -19 > >> [ 10.038465] usb 2-2: can't resume, status -19 > >> [ 10.038465] usb usb2-port2: logical disconnect > >> [ 10.038472] xhci_hcd :00:14.0: Cannot set link state. > > > > Odd. What kernel version is this? > > > > xhci/for-usb-next branch: > 6005a545cadb2adca64350c7aee17d002563e8c7 usb: hub: Fix auto-remount of > safely removed or ejected USB-3 devices > > The latest mainline tag in this branch is 4.9-rc3. Ah, then you might want to cc: the maintainer of that branch... -- 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] dwc3: make PM functions as __maybe_unused
On Wednesday, November 16, 2016 1:13:48 PM CET Felipe Balbi wrote:
> Arnd Bergmann writes:
> > A change to the suspend/resume handling in dwc3-pci introduced a
> > harmless warning:
> >
> > drivers/usb/dwc3/dwc3-pci.c:169:12: error: ‘dwc3_pci_dsm’ defined but not
> > used [-Werror=unused-function]
> >
> > Replacing the #ifdef around the PM functions with __maybe_unused
> > annotations is the easiest way to make sure this doesn't happen
> > again. A similar problem happened two months earlier and we
> > ended up updating the #ifdef, but as it has come back now,
> > I'd suggest going back to my earlier approach.
> >
> > Fixes: 9cecca75b5a0 ("usb: dwc3: pci: call _DSM for suspend/resume")
> > Link: https://patchwork.kernel.org/patch/9318887/
> > Signed-off-by: Arnd Bergmann
>
> I'll just move the ifdef around. We really need a real fix for this. Why
> couldn't we just always add PM callbacks and assume they won't be used
> if !PM && !PM_SLEEP?
I fully agree. This is now the most common warning that gets added
to linux-next, and there are sometimes several new ones on one day, so
I'm playing whack-a-mole here.
I have a rough plan for a proper solution already, but it's going to
be hard to do since there are so many drivers using the current
method. See https://www.mail-archive.com/netdev@vger.kernel.org/msg136759.html
for what I suggested last week.
> Adding __maybe_unused everywhere is rather unelegant
I agree, we shouldn't need the #ifdef or the __maybe_unused. I always
use the latter since it's easier to get right. In this particular case,
if you had applied the original patch, it the warning would not have
come back now.
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: USB: serial: cp210x: Add ID for the Zone DPMX
On Wed, Nov 16, 2016 at 10:13:49AM +, Paul Jakma wrote: > The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the > USB serial interface in its charging dock for the control pods, via > which some settings for the pods can be modified. > > Signed-off-by: Paul Jakma > Cc: Barry Redmond Applied, thanks. Johan -- 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 v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Tue, Nov 15, 2016 at 08:35:13AM +1100, NeilBrown wrote: > On Mon, Nov 14 2016, Mark Brown wrote: > > Conflating the two seems like the whole point here. We're looking for > > something that sits between the power supply code and the USB code and > > tells the power supply code what it's allowed to do which is the result > > of a combination of physical cable detection and USB protocol. It seems > > reasonable that extcon drivers ought to be part of this but it doesn't > > seem like they are the whole story. > I don't think "between the power supply code and the USB code" is where > this thing sits. I think it sits inside the power-supply driver. > We already have extcon which sits between the phy and the power_supply > code, and the usb_notifier which sits between the USB code and the > power supply code. We don't need another go-between. ... > correct determinations and set the current limits itself. All this > could be done entirely internally, without the help of any new > subsystem. > Do you agree? > Clearly doing it that way would result in lots of code duplication and > would mean that each driver probably gets its own private set of bugs, > but it would be possible. Just undesirable. I think this is the key here - the fact that it's technically possible to implement doesn't really matter if it's sufficiently fiddly and non obvious that nobody is actually joining everything up (bits are done intermittently but not as a whole as far as I can see). > So yes, it makes perfect to provide common code which handles the > registrations, and captures the events, and translates the different > events into current levels and feeds those back to the driver. This > isn't some new subsystem, this is just a resource, provided by a > library, that power drivers can allocate and initialize if the want to. To me that's pretty much what's being done here, the code just happens to sit in USB instead but fundamentally it's just a blob of helper code, you could replace the notifier with a callback if that's the big concern here. signature.asc Description: PGP signature
Re: [PATCH 6/6] phy: twl4030-usb: Fix for musb session bit based PM
On Wednesday 16 November 2016 03:29 AM, Bin Liu wrote:
> On Tue, Nov 15, 2016 at 01:37:55PM -0800, Tony Lindgren wrote:
>> Now with musb driver implementing generic session bit based
>> PM, we need to have the USB PHYs behaving in a sane way for
>> platforms implementing PM.
>>
>> Currently twl4030-usb enables PM in twl4030_phy_power_on()
>> and then disables it in twl4030_phy_power_off(). This will
>> block PM runtime for the SoC when no cable is connected.
>>
>> Fix the issue by moving PM runtime autosuspend call to
>> happen where it gets called in twl4030_phy_power_on().
>>
>> Note that this patch should not be backported to anything
>> before commit 467d5c980709 ("usb: musb: Implement session bit
>> based runtime PM for musb-core") as before that all the
>> glue layers implemented their own PM.
>>
>> Fixes: 467d5c980709 ("usb: musb: Implement session bit based
>> runtime PM for musb-core")
>> Tested-by: Ladislav Michl
>> Tested-by: Laurent Pinchart
>> Signed-off-by: Tony Lindgren
>
> I would need Kishon's Acked-by, or he picks it to his tree.
Acked-by: Kishon Vijay Abraham I
>
> Thanks,
> -Bin.
>
>> ---
>> drivers/phy/phy-twl4030-usb.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
>> --- a/drivers/phy/phy-twl4030-usb.c
>> +++ b/drivers/phy/phy-twl4030-usb.c
>> @@ -459,8 +459,6 @@ static int twl4030_phy_power_off(struct phy *phy)
>> struct twl4030_usb *twl = phy_get_drvdata(phy);
>>
>> dev_dbg(twl->dev, "%s\n", __func__);
>> -pm_runtime_mark_last_busy(twl->dev);
>> -pm_runtime_put_autosuspend(twl->dev);
>>
>> return 0;
>> }
>> @@ -472,6 +470,8 @@ static int twl4030_phy_power_on(struct phy *phy)
>> dev_dbg(twl->dev, "%s\n", __func__);
>> pm_runtime_get_sync(twl->dev);
>> schedule_delayed_work(&twl->id_workaround_work, HZ);
>> +pm_runtime_mark_last_busy(twl->dev);
>> +pm_runtime_put_autosuspend(twl->dev);
>>
>> return 0;
>> }
>> --
>> 2.10.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] dma: cpp41: Fix handling of error path
* Tony Lindgren [161116 06:55]:
> * Sekhar Nori [161115 22:25]:
> > On Wednesday 16 November 2016 02:28 AM, Tony Lindgren wrote:
> > > * Sekhar Nori [161115 00:35]:
> > >> If pm_runtime_get_sync() fails due to callback error, then
> > >> rpm_callback() sets dev.power.runtime_error to an error value which gets
> > >> cleared by an explicit call to pm_runtime_set_suspended().
> > >>
> > >> This will tell the framework that the status of device is suspended.
> > >> Else, the failure will be sticky and on subsequent attempts,
> > >> rpm_resume() will keep returning early instead of trying to resume the
> > >> device again.
> > >>
> > >> This is as far as I can gather from code. So, I believe the recovery
> > >> path should be:
> > >>
> > >> if (error < 0) {
> > >> pm_runtime_set_suspended(cdd->ddev.dev);
> > >> pm_runtime_put_noidle(cdd->ddev.dev);
> > >>
> > >> ...
> > >
> > > Well we should test this :)
> >
> > Yes, right! Was this patch created to fix an error in practice or just
> > based on code review?
>
> Based on code review for related musb fixes. I'll test the above today
> at some point.
OK so adding pm_runtime_set_suspended() allows retries, but it also seems
dangerous as it clears dev.power.runtime_error. I think we're better of
not having cppi41 work at all on errors which now happens. Otherwise some
errors could just get ignored and we may even risk corrupting data.
Regards,
Tony
--
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 4/4] ARM: dts: da850: Add the usb otg device nodeg
On Wed, Nov 16, 2016 at 12:06:51PM +0530, Sekhar Nori wrote:
> On Wednesday 16 November 2016 02:49 AM, Bin Liu wrote:
> > On Tue, Nov 15, 2016 at 04:16:02PM +0530, Sekhar Nori wrote:
> >> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
> >>> This adds the device tree node for the usb otg
> >>> controller present in the da850 family of SoC's.
> >>> This also enables the otg usb controller for the lcdk board.
> >>>
> >>> Signed-off-by: Alexandre Bailon
> >>> ---
> >>> arch/arm/boot/dts/da850-lcdk.dts | 8
> >>> arch/arm/boot/dts/da850.dtsi | 15 +++
> >>> 2 files changed, 23 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> >>> b/arch/arm/boot/dts/da850-lcdk.dts
> >>> index 7b8ab21..9f5040c 100644
> >>> --- a/arch/arm/boot/dts/da850-lcdk.dts
> >>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> >>> @@ -158,6 +158,14 @@
> >>> rx-num-evt = <32>;
> >>> };
> >>>
> >>> +&usb_phy {
> >>> + status = "okay";
> >>> + };
> >>
> >> As mentioned by David already, this node needs to be removed. Please
> >> rebase this on top of latest linux-davinci/master when ready for merging
> >> (driver changes accepted).
> >
> > Dropped this patch due to this comment.
>
> Bin, Please do not apply dts or arch/arm/mach-davinci patches. I have a
> bunch queued through my tree and more in pipeline and it will cause
> unnecessary merge conflicts in linux-next or at Linus.
Sure, I will drop this whole set, and only apply the musb patches in the
new v5.
>
> For future, I have asked Alexandre to send driver and dts patches as
> separate series so there is no confusion on who should apply.
I will keep in mind to ping other domain maintainers before applying
non-musb patches in future.
>
> Thanks,
> Sekhar
Regards,
-Bin.
--
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: add usb option device
On Tue, 2016-11-15 at 20:13 +0100, Giuseppe Lippolis wrote:
> Dear all,
> I'm porting the Dlink DWR-512 device to LEDE (embedded linux).
> This device embed a 3G modem connected through the usb bus .
> The modem work properly with the option kernel module.
>
> I added these line in the
>
> #define DLINK_PRODUCT_DWM_652 0x3e04
> #define DLINK_PRODUCT_DWM_652_U5 0xce16
> #define DLINK_PRODUCT_DWM_652_U5A 0xce1e
>
> + #define DLINK_ATL_VENDOR_ID 0x20
> 01
> + #define DLINK_PRODUCT_DWM_158 0x7d04
>
> #define QISDA_VENDOR_ID 0x1da5
> #define QISDA_PRODUCT_H21_4512 0x4512
>
> [...]
>
> { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) }, /*
> Yes,
> ALINK_VENDOR_ID */
> { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
> + { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },
This will make option grab all the ports, as shown by your dmesg
output. But USB interfaces 0 and 1 are actually cdc-ether and should
*not* be grabbed by option.
You want to limit option to grabbing bInterfaceClass=255 to make sure
it only gets the serial ports.
Dan
> { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
> { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
>
> And at the end the system work as expected:
>
> [ 11.659320] usbcore: registered new interface driver usbserial
> [ 11.671412] usbcore: registered new interface driver
> usbserial_generic
> [ 11.684835] usbserial: USB Serial support registered for generic
> [ 11.739752] xt_time: kernel timezone is -
> [ 11.865508] PPP generic driver version 2.4.2
> [ 11.880069] NET: Registered protocol family 24
> [ 11.919594] usbcore: registered new interface driver option
> [ 11.931155] usbserial: USB Serial support registered for GSM modem
> (1-port)
> [ 11.945724] option 1-1:1.0: no of_node; not parsing pinctrl DT
> [ 11.946566] option 1-1:1.0: GSM modem (1-port) converter detected
> [ 11.959201] option1 ttyUSB0: no of_node; not parsing pinctrl DT
> [ 11.959661] option 1-1:1.1: no of_node; not parsing pinctrl DT
> [ 11.960472] option 1-1:1.1: GSM modem (1-port) converter detected
> [ 11.973103] option1 ttyUSB1: no of_node; not parsing pinctrl DT
> [ 11.973542] option 1-1:1.2: no of_node; not parsing pinctrl DT
> [ 11.974347] option 1-1:1.2: GSM modem (1-port) converter detected
> [ 11.986980] option1 ttyUSB2: no of_node; not parsing pinctrl DT
> [ 11.987462] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB2
> [ 12.001470] option 1-1:1.3: no of_node; not parsing pinctrl DT
> [ 12.002354] option 1-1:1.3: GSM modem (1-port) converter detected
> [ 12.015005] option1 ttyUSB3: no of_node; not parsing pinctrl DT
> [ 12.015479] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB3
> [ 12.029487] option 1-1:1.4: no of_node; not parsing pinctrl DT
> [ 12.030327] option 1-1:1.4: GSM modem (1-port) converter detected
> [ 12.042978] option1 ttyUSB4: no of_node; not parsing pinctrl DT
> [ 12.043463] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB4
> [ 12.057468] option 1-1:1.5: no of_node; not parsing pinctrl DT
> [ 12.058395] option 1-1:1.5: GSM modem (1-port) converter detected
> [ 12.070971] option1 ttyUSB5: no of_node; not parsing pinctrl DT
> [ 12.071482] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB5
> [ 12.085484] option 1-1:1.6: no of_node; not parsing pinctrl DT
>
>
> Here the relevant lsusb info:
>
> Bus 001 Device 002: ID 2001:7d04 D-Link Corp.
> Device Descriptor:
> bLength18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass2 Communications
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize064
> idVendor 0x2001 D-Link Corp.
> idProduct 0x7d04
> bcdDevice3.00
> iManufacturer 10 D-Link,Inc
> iProduct 11 D-Link DWM-158
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 229
> bNumInterfaces 7
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 500mA
> Interface Association:
> bLength 8
> bDescriptorType11
> bFirstInterface 0
> bInterfaceCount 2
> bFunctionClass 2 Communications
> bFunctionSubClass 6 Ethernet Networking
> bFunctionProtocol 0
> iFunction 2 COM(comm_if)
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNu
Re: [PATCH v2 1/1] usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices
On Wed, 16 Nov 2016, Mathias Nyman wrote:
> USB-3 does not have any link state that will avoid negotiating a connection
> with a plugged-in cable but will signal the host when the cable is
> unplugged.
>
> For USB-3 we used to first set the link to Disabled, then to RxDdetect to
> be able to detect cable connects or disconnects. But in RxDetect the
> connected device is detected again and eventually enabled.
>
> Instead set the link into U3 and disable remote wakeups for the device.
> This is what Windows does, and what Alan Stern suggested.
>
> Cc: sta...@vger.kernel.org
> Cc: Alan Stern
> Signed-off-by: Mathias Nyman
>
> ---
>
> Changes since RFC-PATCH:
> - send port_dev as an argument
> - move checking and disabling remote wakeup to a function under CONFIG_PM
> - set device state to USB_STATE_NOTATTACHED _after_ disabling remote wakup
> and port disable.
> ---
> drivers/usb/core/hub.c | 100
> +
> 1 file changed, 35 insertions(+), 65 deletions(-)
Just one little thing; see below. After that is changed, you can add:
Acked-by: Alan Stern
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 76e80d8..3775424 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -103,6 +103,8 @@
>
> static void hub_release(struct kref *kref);
> static int usb_reset_and_verify_device(struct usb_device *udev);
> +static void hub_usb3_port_prepare_disable(struct usb_hub *hub,
> + struct usb_port *port_dev);
>
> static inline char *portspeed(struct usb_hub *hub, int portstatus)
> {
> @@ -901,82 +903,28 @@ static int hub_set_port_link_state(struct usb_hub *hub,
> int port1,
> }
>
> /*
> - * If USB 3.0 ports are placed into the Disabled state, they will no longer
> - * detect any device connects or disconnects. This is generally not what the
> - * USB core wants, since it expects a disabled port to produce a port status
> - * change event when a new device connects.
> - *
> - * Instead, set the link state to Disabled, wait for the link to settle into
> - * that state, clear any change bits, and then put the port into the RxDetect
> - * state.
> + * USB-3 does not have a similar link state as USB-2 that will avoid
> negotiating
> + * a connection with a plugged-in cable but will signal the host when the
> cable
> + * is unplugged. Disable remote wake and set link state to U3 for USB-3
> devices
> */
> -static int hub_usb3_port_disable(struct usb_hub *hub, int port1)
> -{
> - int ret;
> - int total_time;
> - u16 portchange, portstatus;
> -
> - if (!hub_is_superspeed(hub->hdev))
> - return -EINVAL;
> -
> - ret = hub_port_status(hub, port1, &portstatus, &portchange);
> - if (ret < 0)
> - return ret;
> -
> - /*
> - * USB controller Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
> - * Controller [1022:7814] will have spurious result making the following
> - * usb 3.0 device hotplugging route to the 2.0 root hub and recognized
> - * as high-speed device if we set the usb 3.0 port link state to
> - * Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state, we
> - * check the state here to avoid the bug.
> - */
> - if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
> - USB_SS_PORT_LS_RX_DETECT) {
> - dev_dbg(&hub->ports[port1 - 1]->dev,
> - "Not disabling port; link state is RxDetect\n");
> - return ret;
> - }
> -
> - ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
> - if (ret)
> - return ret;
> -
> - /* Wait for the link to enter the disabled state. */
> - for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
> - ret = hub_port_status(hub, port1, &portstatus, &portchange);
> - if (ret < 0)
> - return ret;
> -
> - if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
> - USB_SS_PORT_LS_SS_DISABLED)
> - break;
> - if (total_time >= HUB_DEBOUNCE_TIMEOUT)
> - break;
> - msleep(HUB_DEBOUNCE_STEP);
> - }
> - if (total_time >= HUB_DEBOUNCE_TIMEOUT)
> - dev_warn(&hub->ports[port1 - 1]->dev,
> - "Could not disable after %d ms\n", total_time);
> -
> - return hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_RX_DETECT);
> -}
> -
> static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
> {
> struct usb_port *port_dev = hub->ports[port1 - 1];
> struct usb_device *hdev = hub->hdev;
> int ret = 0;
>
> - if (port_dev->child && set_state)
> - usb_set_device_state(port_dev->child, USB_STATE_NOTATTACHED);
> if (!hub->error) {
> - if (hub_is_superspeed(hub->hdev))
> - ret = hub_usb3_port_disabl
[PATCH] dmaengine: cppi41: More PM runtime fixes
Fix use of u32 instead of int for checking for negative errors values
as pointed out by Dan Carpenter .
And while testing the PM runtime error path by randomly returning
failed values in runtime resume, I noticed two more places that need
fixing:
- If pm_runtime_get_sync() fails in probe, we still need to do
pm_runtime_put_sync() to keep the use count happy. We could call
pm_runtime_put_noidle() on the error path, but we're just going
to call pm_runtime_disable() after that so pm_runtime_put_sync()
will do what we want
- We should print an error if pm_runtime_get_sync() fails in
cppi41_dma_alloc_chan_resources() so we know where it happens
Reported-by: Dan Carpenter
Fixes: 740b4be3f742 ("dmaengine: cpp41: Fix handling of error path")
Signed-off-by: Tony Lindgren
---
drivers/dma/cppi41.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -317,11 +317,12 @@ static irqreturn_t cppi41_irq(int irq, void *data)
while (val) {
u32 desc, len;
+ int error;
- status = pm_runtime_get(cdd->ddev.dev);
- if (status < 0)
+ error = pm_runtime_get(cdd->ddev.dev);
+ if (error < 0)
dev_err(cdd->ddev.dev, "%s pm runtime get:
%i\n",
- __func__, status);
+ __func__, error);
q_num = __fls(val);
val &= ~(1 << q_num);
@@ -367,6 +368,8 @@ static int cppi41_dma_alloc_chan_resources(struct dma_chan
*chan)
error = pm_runtime_get_sync(cdd->ddev.dev);
if (error < 0) {
+ dev_err(cdd->ddev.dev, "%s pm runtime get: %i\n",
+ __func__, error);
pm_runtime_put_noidle(cdd->ddev.dev);
return error;
@@ -1072,8 +1075,8 @@ static int cppi41_dma_probe(struct platform_device *pdev)
deinit_cppi41(dev, cdd);
err_init_cppi:
pm_runtime_dont_use_autosuspend(dev);
- pm_runtime_put_sync(dev);
err_get_sync:
+ pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
iounmap(cdd->usbss_mem);
iounmap(cdd->ctrl_mem);
--
2.10.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: [usb-storage] About USB Driver：
On Wed, 16 Nov 2016, xiluofei_suma wrote: > hello linux-usb, usb-storage： > > This device (12d1,14fe,0102 S 06 P 50) has unneeded SubClass and Protocol > entries in unusual_devs.h (kernel 3.10.0_s40) >Please send a copy of this message to and > Thank you for sending this. Kernel version 3.10 is seriously out of date; you ought to consider upgrading. That message has been removed in later kernel versions. 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: add usb option device
On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote:
> On Tue, 2016-11-15 at 20:13 +0100, Giuseppe Lippolis wrote:
> >
> > Dear all,
> > I'm porting the Dlink DWR-512 device to LEDE (embedded linux).
> > This device embed a 3G modem connected through the usb bus .
> > The modem work properly with the option kernel module.
> >
> > I added these line in the
> >
> > #define DLINK_PRODUCT_DWM_652 0x3e04
> > #define DLINK_PRODUCT_DWM_652_U5 0xce16
> > #define DLINK_PRODUCT_DWM_652_U5A 0xce1e
> >
> > + #define DLINK_ATL_VENDOR_ID 0x
> > 20
> > 01
> > + #define DLINK_PRODUCT_DWM_158 0x7d04
> >
> > #define QISDA_VENDOR_ID 0x1da5
> > #define QISDA_PRODUCT_H21_4512 0x4512
> >
> > [...]
> >
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) },
> > /*
> > Yes,
> > ALINK_VENDOR_ID */
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
> > + { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },
>
> This will make option grab all the ports, as shown by your dmesg
> output. But USB interfaces 0 and 1 are actually cdc-ether and should
> *not* be grabbed by option.
>
> You want to limit option to grabbing bInterfaceClass=255 to make sure
> it only gets the serial ports.
Also, is it really a D-Link DWM-158? That appears to be a USB dongle-
type device, while what's in the DWR-512 is a PCI-E minicard that looks
like a ZTE MF210, from the FCC pictures.
Dan
> Dan
>
> >
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
> >
> > And at the end the system work as expected:
> >
> > [ 11.659320] usbcore: registered new interface driver usbserial
> > [ 11.671412] usbcore: registered new interface driver
> > usbserial_generic
> > [ 11.684835] usbserial: USB Serial support registered for generic
> > [ 11.739752] xt_time: kernel timezone is -
> > [ 11.865508] PPP generic driver version 2.4.2
> > [ 11.880069] NET: Registered protocol family 24
> > [ 11.919594] usbcore: registered new interface driver option
> > [ 11.931155] usbserial: USB Serial support registered for GSM
> > modem
> > (1-port)
> > [ 11.945724] option 1-1:1.0: no of_node; not parsing pinctrl DT
> > [ 11.946566] option 1-1:1.0: GSM modem (1-port) converter
> > detected
> > [ 11.959201] option1 ttyUSB0: no of_node; not parsing pinctrl DT
> > [ 11.959661] option 1-1:1.1: no of_node; not parsing pinctrl DT
> > [ 11.960472] option 1-1:1.1: GSM modem (1-port) converter
> > detected
> > [ 11.973103] option1 ttyUSB1: no of_node; not parsing pinctrl DT
> > [ 11.973542] option 1-1:1.2: no of_node; not parsing pinctrl DT
> > [ 11.974347] option 1-1:1.2: GSM modem (1-port) converter
> > detected
> > [ 11.986980] option1 ttyUSB2: no of_node; not parsing pinctrl DT
> > [ 11.987462] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB2
> > [ 12.001470] option 1-1:1.3: no of_node; not parsing pinctrl DT
> > [ 12.002354] option 1-1:1.3: GSM modem (1-port) converter
> > detected
> > [ 12.015005] option1 ttyUSB3: no of_node; not parsing pinctrl DT
> > [ 12.015479] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB3
> > [ 12.029487] option 1-1:1.4: no of_node; not parsing pinctrl DT
> > [ 12.030327] option 1-1:1.4: GSM modem (1-port) converter
> > detected
> > [ 12.042978] option1 ttyUSB4: no of_node; not parsing pinctrl DT
> > [ 12.043463] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB4
> > [ 12.057468] option 1-1:1.5: no of_node; not parsing pinctrl DT
> > [ 12.058395] option 1-1:1.5: GSM modem (1-port) converter
> > detected
> > [ 12.070971] option1 ttyUSB5: no of_node; not parsing pinctrl DT
> > [ 12.071482] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB5
> > [ 12.085484] option 1-1:1.6: no of_node; not parsing pinctrl DT
> >
> >
> > Here the relevant lsusb info:
> >
> > Bus 001 Device 002: ID 2001:7d04 D-Link Corp.
> > Device Descriptor:
> > bLength18
> > bDescriptorType 1
> > bcdUSB 2.00
> > bDeviceClass2 Communications
> > bDeviceSubClass 0
> > bDeviceProtocol 0
> > bMaxPacketSize064
> > idVendor 0x2001 D-Link Corp.
> > idProduct 0x7d04
> > bcdDevice3.00
> > iManufacturer 10 D-Link,Inc
> > iProduct 11 D-Link DWM-158
> > iSerial 0
> > bNumConfigurations 1
> > Configuration Descriptor:
> > bLength 9
> > bDescriptorType 2
> > wTotalLength 229
> > bNumInterfaces 7
> > bConfigurationValue 1
> > iConfiguration 0
> > bmAttributes 0xa0
> > (Bus Powered)
> > Remote
Re: [PATCH 1/4] usb: dwc2: Fix AHB burst type for bcm2835
On 11/16/2016 1:25 AM, Stefan Wahren wrote: > Hi John, > >> John Youn hat am 16. November 2016 um 01:36 >> geschrieben: >> >> >> The ahbcfg param for bcm2835 is specifying a HBSTLEN of 0x8 (0x10 >> 1) >> which is not a valid value for that field. Remove the param and default >> to using INCR4. > > i don't have any Synopsys documentation about this IP core. But according to > p. > 204 of the BCM2835 datasheet [1] the register USB_GAHBCFG is different than > the > other implementations: > > Address 0x 7E98 0008 > The USB_GAHBCFG register has been adapted. Bits [4:1] which are marked in > the > Synopsys documentation as "Burst Length/Type (HBstLen)" have been used > differently. > > [4]1 = Wait for all outstanding AXI writes to complete before signalling > (internally) that > DMA is done. > 0 = don't wait. > [3]Not used > [2:1] Sets the maximum AXI burst length, but the bits are inverted, > 00 = maximum AXI burst length of 4, > 01 = maximum AXI burst length of 3, > 10 = maximum AXI burst length of 2 > 11 = maximum AXI burst length of 1 > > Did you already take care of that? > > [1] - > https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf > Ok, so that explains it. Thanks for reviewing. Since there is no checking on that value it should be fine to leave it. I'll revert this change and add a comment. If we ever get around to removing the ahbcfg parameter, we can add a special case for it. Regards, 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
[PATCH 1/6] usb: musb: Fix broken use of static variable for multiple instances
From: Tony Lindgren
We can't use static variable first for checking when musb is
initialized when we have multiple musb instances like on am335x.
Tested-by: Ladislav Michl
Reviewed-by: Johan Hovold
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_core.c | 9 +
drivers/usb/musb/musb_core.h | 2 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e01116e4c067..f1ea4494dcb2 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2291,6 +2291,7 @@ static void musb_deassert_reset(struct work_struct *work)
if (status)
goto fail5;
+ musb->is_initialized = 1;
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
@@ -2629,7 +2630,6 @@ static int musb_runtime_suspend(struct device *dev)
static int musb_runtime_resume(struct device *dev)
{
struct musb *musb = dev_to_musb(dev);
- static int first = 1;
/*
* When pm_runtime_get_sync called for the first time in driver
@@ -2640,9 +2640,10 @@ static int musb_runtime_resume(struct device *dev)
* Also context restore without save does not make
* any sense
*/
- if (!first)
- musb_restore_context(musb);
- first = 0;
+ if (!musb->is_initialized)
+ return 0;
+
+ musb_restore_context(musb);
if (musb->need_finish_resume) {
musb->need_finish_resume = 0;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a498f8a..c04abf424c5c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -385,6 +385,8 @@ struct musb {
int a_wait_bcon;/* VBUS timeout in msecs */
unsigned long idle_timeout; /* Next timeout in jiffies */
+ unsignedis_initialized:1;
+
/* active means connected and not suspended */
unsignedis_active:1;
--
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 2/6] usb: musb: Fix sleeping function called from invalid context for hdrc glue
From: Tony Lindgren
Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer
that runs in softirq context. That causes a "BUG: sleeping function called
from invalid context" every time when polling the cable status:
[] (__might_sleep) from [] (__pm_runtime_resume+0x9c/0xa0)
[] (__pm_runtime_resume) from [] (otg_timer+0x3c/0x254)
[] (otg_timer) from [] (call_timer_fn+0xfc/0x41c)
[] (call_timer_fn) from [] (expire_timers+0x120/0x210)
[] (expire_timers) from [] (run_timer_softirq+0xa4/0xdc)
[] (run_timer_softirq) from [] (__do_softirq+0x12c/0x594)
I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP enabled.
And looks like also musb_gadget_queue() suffers from the same problem.
Let's fix the issue by using a list of delayed work then call it on
resume. Note that we want to do this only when musb core and it's
parent devices are awake, and we need to make sure the DSPS glue
timer is stopped as noted by Johan Hovold .
Note that we already are re-enabling the timer with mod_timer() in
dsps_musb_enable().
Later on we may be able to remove other delayed work in the musb driver
and just do it from pending_resume_work. But this should be done only
for delayed work that does not have other timing requirements beyond
just being run on resume.
Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer")
Reported-by: Johan Hovold
Reviewed-by: Johan Hovold
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_core.c | 109 +++--
drivers/usb/musb/musb_core.h | 7 +++
drivers/usb/musb/musb_dsps.c | 36 ++
drivers/usb/musb/musb_gadget.c | 33 +++--
4 files changed, 167 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f1ea4494dcb2..384de6cd26f5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1969,6 +1969,7 @@ static struct musb *allocate_instance(struct device *dev,
INIT_LIST_HEAD(&musb->control);
INIT_LIST_HEAD(&musb->in_bulk);
INIT_LIST_HEAD(&musb->out_bulk);
+ INIT_LIST_HEAD(&musb->pending_list);
musb->vbuserr_retry = VBUSERR_RETRY_COUNT;
musb->a_wait_bcon = OTG_TIME_A_WAIT_BCON;
@@ -2018,6 +2019,84 @@ static void musb_free(struct musb *musb)
musb_host_free(musb);
}
+struct musb_pending_work {
+ int (*callback)(struct musb *musb, void *data);
+ void *data;
+ struct list_head node;
+};
+
+/*
+ * Called from musb_runtime_resume(), musb_resume(), and
+ * musb_queue_resume_work(). Callers must take musb->lock.
+ */
+static int musb_run_resume_work(struct musb *musb)
+{
+ struct musb_pending_work *w, *_w;
+ unsigned long flags;
+ int error = 0;
+
+ spin_lock_irqsave(&musb->list_lock, flags);
+ list_for_each_entry_safe(w, _w, &musb->pending_list, node) {
+ if (w->callback) {
+ error = w->callback(musb, w->data);
+ if (error < 0) {
+ dev_err(musb->controller,
+ "resume callback %p failed: %i\n",
+ w->callback, error);
+ }
+ }
+ list_del(&w->node);
+ devm_kfree(musb->controller, w);
+ }
+ spin_unlock_irqrestore(&musb->list_lock, flags);
+
+ return error;
+}
+
+/*
+ * Called to run work if device is active or else queue the work to happen
+ * on resume. Caller must take musb->lock and must hold an RPM reference.
+ *
+ * Note that we cowardly refuse queuing work after musb PM runtime
+ * resume is done calling musb_run_resume_work() and return -EINPROGRESS
+ * instead.
+ */
+int musb_queue_resume_work(struct musb *musb,
+ int (*callback)(struct musb *musb, void *data),
+ void *data)
+{
+ struct musb_pending_work *w;
+ unsigned long flags;
+ int error;
+
+ if (WARN_ON(!callback))
+ return -EINVAL;
+
+ if (pm_runtime_active(musb->controller))
+ return callback(musb, data);
+
+ w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
+ if (!w)
+ return -ENOMEM;
+
+ w->callback = callback;
+ w->data = data;
+ spin_lock_irqsave(&musb->list_lock, flags);
+ if (musb->is_runtime_suspended) {
+ list_add_tail(&w->node, &musb->pending_list);
+ error = 0;
+ } else {
+ dev_err(musb->controller, "could not add resume work %p\n",
+ callback);
+ devm_kfree(musb->controller, w);
+ error = -EINPROGRESS;
+ }
+ spin_unlock_irqrestore(&musb->list_lock, flags);
+
+ return error;
+}
+EXPORT_SYMBOL_
[PATCH 0/6] musb-fixes for v4.9-rc6
Hi Greg, Hope this is not too late for -rc6. This set fixes a long standing musb regression introduced in v4.8. Please let me know if any change is needed. Thanks, -Bin. --- Tony Lindgren (6): usb: musb: Fix broken use of static variable for multiple instances usb: musb: Fix sleeping function called from invalid context for hdrc glue usb: musb: Fix PM for hub disconnect usb: musb: Add missing pm_runtime_disable and drop 2430 PM timeout usb: musb: Drop pointless PM runtime code for dsps glue phy: twl4030-usb: Fix for musb session bit based PM drivers/phy/phy-twl4030-usb.c | 4 +- drivers/usb/musb/musb_core.c | 147 - drivers/usb/musb/musb_core.h | 13 +++- drivers/usb/musb/musb_dsps.c | 58 drivers/usb/musb/musb_gadget.c | 39 +-- drivers/usb/musb/omap2430.c| 10 ++- drivers/usb/musb/tusb6010.c| 6 +- 7 files changed, 209 insertions(+), 68 deletions(-) -- 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 4/6] usb: musb: Add missing pm_runtime_disable and drop 2430 PM timeout
From: Tony Lindgren
We are missing pm_runtime_disable() in 2430 glue layer. Further,
we only need to enable PM runtime and disable it on exit. With
musb_core.c doing PM, the glue layer as a parent will always be
active when musb_core.c is active.
This fixes host enumeration issues with some devices as reported
by Ladislav Michl .
And holding an RPM reference while deregistering the child would
lead to a crash in omap2430_runtime_suspend() which dereferences
the now freed child's driver data on put as pointed out by
Johan Hovold :
Unable to handle kernel paging request at virtual address 6b6b6f17
...
[] (omap2430_runtime_suspend) from []
(pm_generic_runtime_suspend+0x3c/0x48)
[] (pm_generic_runtime_suspend) from []
(_od_runtime_suspend+0x1c/0x30)
[] (_od_runtime_suspend) from [] (__rpm_callback+0x3c/0x70)
[] (__rpm_callback) from [] (rpm_callback+0x30/0x90)
[] (rpm_callback) from [] (rpm_suspend+0x118/0x6b4)
[] (rpm_suspend) from [] (rpm_idle+0x104/0x440)
[] (rpm_idle) from [] (__pm_runtime_idle+0x7c/0xb0)
[] (__pm_runtime_idle) from [] (omap2430_remove+0x38/0x58)
[] (omap2430_remove) from [] (platform_drv_remove+0x34/0x4c)
Note that if changes are needed to the autosuspend timeout, it should
be done in musb_core.c.
Reported-by: Ladislav Michl
Fixes: 87326e858448 ("usb: musb: Remove extra PM runtime calls from
2430 glue layer")
Tested-by: Ladislav Michl
Reviewed-by: Johan Hovold
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Signed-off-by: Bin Liu
---
drivers/usb/musb/omap2430.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index cc1225485509..e8be8e39ab8f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -513,17 +513,18 @@ static int omap2430_probe(struct platform_device *pdev)
}
pm_runtime_enable(glue->dev);
- pm_runtime_use_autosuspend(glue->dev);
- pm_runtime_set_autosuspend_delay(glue->dev, 100);
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err2;
+ goto err3;
}
return 0;
+err3:
+ pm_runtime_disable(glue->dev);
+
err2:
platform_device_put(musb);
@@ -535,10 +536,7 @@ static int omap2430_remove(struct platform_device *pdev)
{
struct omap2430_glue *glue = platform_get_drvdata(pdev);
- pm_runtime_get_sync(glue->dev);
platform_device_unregister(glue->musb);
- pm_runtime_put_sync(glue->dev);
- pm_runtime_dont_use_autosuspend(glue->dev);
pm_runtime_disable(glue->dev);
return 0;
--
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 6/6] phy: twl4030-usb: Fix for musb session bit based PM
From: Tony Lindgren
Now with musb driver implementing generic session bit based
PM, we need to have the USB PHYs behaving in a sane way for
platforms implementing PM.
Currently twl4030-usb enables PM in twl4030_phy_power_on()
and then disables it in twl4030_phy_power_off(). This will
block PM runtime for the SoC when no cable is connected.
Fix the issue by moving PM runtime autosuspend call to
happen where it gets called in twl4030_phy_power_on().
Note that this patch should not be backported to anything
before commit 467d5c980709 ("usb: musb: Implement session bit
based runtime PM for musb-core") as before that all the
glue layers implemented their own PM.
Fixes: 467d5c980709 ("usb: musb: Implement session bit based
runtime PM for musb-core")
Tested-by: Ladislav Michl
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Acked-by: Kishon Vijay Abraham I
Signed-off-by: Bin Liu
---
drivers/phy/phy-twl4030-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 87e6334eab93..547ca7b3f098 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -459,8 +459,6 @@ static int twl4030_phy_power_off(struct phy *phy)
struct twl4030_usb *twl = phy_get_drvdata(phy);
dev_dbg(twl->dev, "%s\n", __func__);
- pm_runtime_mark_last_busy(twl->dev);
- pm_runtime_put_autosuspend(twl->dev);
return 0;
}
@@ -472,6 +470,8 @@ static int twl4030_phy_power_on(struct phy *phy)
dev_dbg(twl->dev, "%s\n", __func__);
pm_runtime_get_sync(twl->dev);
schedule_delayed_work(&twl->id_workaround_work, HZ);
+ pm_runtime_mark_last_busy(twl->dev);
+ pm_runtime_put_autosuspend(twl->dev);
return 0;
}
--
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 3/6] usb: musb: Fix PM for hub disconnect
From: Tony Lindgren
With a USB hub disconnected, devctl can be 0x19 for about a second
on am335x and will stay forever on at least omap3. And we get no
further interrupts when devctl session bit clears. This keeps
PM runtime active.
Let's fix the issue by polling devctl until the session bit clears
or times out. We can do this by making musb->irq_work into
delayed_work.
And with the polling implemented, we can now also have the quirk
for invalid VBUS it to avoid disconnecting too early while VBUS
is ramping up.
Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime
PM for musb-core")
Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
Tested-by: Ladislav Michl
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_core.c | 29 +++--
drivers/usb/musb/musb_core.h | 4 ++--
drivers/usb/musb/musb_gadget.c | 6 +++---
drivers/usb/musb/tusb6010.c| 6 +++---
4 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 384de6cd26f5..c3e172e15ec3 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -986,7 +986,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
}
#endif
- schedule_work(&musb->irq_work);
+ schedule_delayed_work(&musb->irq_work, 0);
return handled;
}
@@ -1855,14 +1855,23 @@ static void musb_pm_runtime_check_session(struct musb
*musb)
MUSB_DEVCTL_HR;
switch (devctl & ~s) {
case MUSB_QUIRK_B_INVALID_VBUS_91:
- if (!musb->session && !musb->quirk_invalid_vbus) {
- musb->quirk_invalid_vbus = true;
+ if (musb->quirk_retries--) {
musb_dbg(musb,
-"First invalid vbus, assume no session");
+"Poll devctl on invalid vbus, assume no
session");
+ schedule_delayed_work(&musb->irq_work,
+ msecs_to_jiffies(1000));
+
return;
}
- break;
case MUSB_QUIRK_A_DISCONNECT_19:
+ if (musb->quirk_retries--) {
+ musb_dbg(musb,
+"Poll devctl on possible host mode
disconnect");
+ schedule_delayed_work(&musb->irq_work,
+ msecs_to_jiffies(1000));
+
+ return;
+ }
if (!musb->session)
break;
musb_dbg(musb, "Allow PM on possible host mode disconnect");
@@ -1886,9 +1895,9 @@ static void musb_pm_runtime_check_session(struct musb
*musb)
if (error < 0)
dev_err(musb->controller, "Could not enable: %i\n",
error);
+ musb->quirk_retries = 3;
} else {
musb_dbg(musb, "Allow PM with no session: %02x", devctl);
- musb->quirk_invalid_vbus = false;
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
}
@@ -1899,7 +1908,7 @@ static void musb_pm_runtime_check_session(struct musb
*musb)
/* Only used to provide driver mode change events */
static void musb_irq_work(struct work_struct *data)
{
- struct musb *musb = container_of(data, struct musb, irq_work);
+ struct musb *musb = container_of(data, struct musb, irq_work.work);
musb_pm_runtime_check_session(musb);
@@ -2288,7 +2297,7 @@ static void musb_deassert_reset(struct work_struct *work)
musb_generic_disable(musb);
/* Init IRQ workqueue before request_irq */
- INIT_WORK(&musb->irq_work, musb_irq_work);
+ INIT_DELAYED_WORK(&musb->irq_work, musb_irq_work);
INIT_DELAYED_WORK(&musb->deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(&musb->finish_resume_work, musb_host_finish_resume);
@@ -2385,7 +2394,7 @@ static void musb_deassert_reset(struct work_struct *work)
musb_host_cleanup(musb);
fail3:
- cancel_work_sync(&musb->irq_work);
+ cancel_delayed_work_sync(&musb->irq_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
if (musb->dma_controller)
@@ -2452,7 +2461,7 @@ static int musb_remove(struct platform_device *pdev)
*/
musb_exit_debugfs(musb);
- cancel_work_sync(&musb->irq_work);
+ cancel_delayed_work_sync(&musb->irq_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
pm_runtime_get_sync(musb->controller);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 15b1f93c7037..91817d77d59c
[PATCH 5/6] usb: musb: Drop pointless PM runtime code for dsps glue
From: Tony Lindgren
This already gets done automatically by PM runtime and we have
a separate autosuspend timeout in musb_core.c.
Reviewed-by: Johan Hovold
Tested-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_dsps.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 6096c84ab67a..feae1561b9ab 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -783,28 +783,13 @@ static int dsps_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
pm_runtime_enable(&pdev->dev);
- pm_runtime_use_autosuspend(&pdev->dev);
- pm_runtime_set_autosuspend_delay(&pdev->dev, 200);
-
- ret = pm_runtime_get_sync(&pdev->dev);
- if (ret < 0) {
- dev_err(&pdev->dev, "pm_runtime_get_sync FAILED");
- goto err2;
- }
-
ret = dsps_create_musb_pdev(glue, pdev);
if (ret)
- goto err3;
-
- pm_runtime_mark_last_busy(&pdev->dev);
- pm_runtime_put_autosuspend(&pdev->dev);
+ goto err;
return 0;
-err3:
- pm_runtime_put_sync(&pdev->dev);
-err2:
- pm_runtime_dont_use_autosuspend(&pdev->dev);
+err:
pm_runtime_disable(&pdev->dev);
return ret;
}
@@ -815,9 +800,6 @@ static int dsps_remove(struct platform_device *pdev)
platform_device_unregister(glue->musb);
- /* disable usbss clocks */
- pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return 0;
--
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: [PATCHv3 0/6] musb fixes for v4.9-rc cycle
Hi, On Tue, Nov 15, 2016 at 01:37:49PM -0800, Tony Lindgren wrote: > Hi all, > > Here's v3 of musb fixes for issues that I've been able to track down. > The PM changes merged for v4.9 popped up various issues reported by > people that I had not seen earlier with my tests. > > As many people depend on this driver, I'd like to have these merged > for v4.9-rc cycle. > > Regards, > > Tony > > > Changes since v2: > > - Collect acks, update patch descriptions and remove one comment > line based on comments from Johan Hovold > > Changes since v1: > > - Numerous changes to patch 2/4 for the sleeping function fix > based on comments from Johan > > - Two new patches to fix issues with devices not always > enumerating by removing pointless PM runtime code > > Tony Lindgren (6): > usb: musb: Fix broken use of static variable for multiple instances > usb: musb: Fix sleeping function called from invalid context for hdrc > glue > usb: musb: Fix PM for hub disconnect > usb: musb: Add missing pm_runtime_disable and drop 2430 PM timeout > usb: musb: Drop pointless PM runtime code for dsps glue > phy: twl4030-usb: Fix for musb session bit based PM > > drivers/phy/phy-twl4030-usb.c | 4 +- > drivers/usb/musb/musb_core.c | 147 > - > drivers/usb/musb/musb_core.h | 13 +++- > drivers/usb/musb/musb_dsps.c | 58 > drivers/usb/musb/musb_gadget.c | 39 +-- > drivers/usb/musb/omap2430.c| 10 ++- > drivers/usb/musb/tusb6010.c| 6 +- > 7 files changed, 209 insertions(+), 68 deletions(-) > Applied and pushed out. Thanks, -Bin. -- 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: PROBLEM: Oops when deactivating gadget serial driver
Hi, For me, it is always reproducible when CONFIG_U_SERIAL_CONSOLE is enabled. But I think that GDB is misleading, it has probably nothing to do with gs_buf_free(). For me, it looks like the real problem is that in gserial_console_exit(), kthread_stop() is called on the (in my case) uninitialised variable gscons_info.console_thread. I am going to propose a fix. Regards Felix > Hello, > > In 4.8.6 and 4.9-rc5, the gadget serial driver crashes during > deinitialisation when compiled with CONFIG_U_SERIAL_CONSOLE. > > Steps to reproduce: > modprobe g-serial > rmmod g-serial > > The problem also occurs when using configfs, when the UDC is unbound. > > I does not make a difference if I use my PLX3380 (driver net2280) as > UDC, or dummy-hcd. > > > excerpt from dmesg output (complete output see below): > > [ 75.705246] BUG: unable to handle kernel > [ 75.751165] NULL pointer dereference > [ 75.791826] at 0018 > [ 75.814807] IP: [] kthread_stop+0x16/0x110 > [ 75.882611] PGD 0 > > [ 75.922339] Oops: 0002 [#1] SMP > [ 75.959880] Modules linked in: cdc_acm usb_f_acm u_serial g_serial(-) > libcomposite configfs dummy_hcd bnep nls_ascii nls_cp437 vfat fat > intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 > lrw gf128mul glue_helper ablk_helper cryptd uvcvideo videobuf2_vmalloc > videobuf2_memops videobuf2_v4l2 videobuf2_core videodev xpad ff_memless > media joydev snd_hda_codec_hdmi snd_usb_audio snd_usbmidi_lib > snd_hda_codec_realtek btusb btrtl efi_pstore btbcm snd_hda_codec_generic > btintel bluetooth serio_raw rfkill crc16 efivars snd_hda_intel sg > snd_hda_codec snd_hda_core snd_hwdep snd_seq_midi snd_seq_midi_event > snd_pcm_oss snd_rawmidi snd_mixer_oss udc_core snd_pcm snd_seq > snd_seq_device lpc_ich snd_timer mfd_core snd soundcore battery > [ 76.816163] nuvoton_cir rc_core mei_me mei evdev intel_smartconnect > shpchp ie31200_edac tpm_tis tpm_tis_core tpm edac_core parport_pc ppdev > lp parport efivarfs autofs4 btrfs xor raid6_pq hid_logitech_hidpp > hid_logitech_dj hid_generic usbhid hid uas usb_storage sr_mod cdrom > sd_mod nouveau ahci libahci i915 crc32c_intel libata ttm i2c_algo_bit > ehci_pci xhci_pci psmouse xhci_hcd drm_kms_helper ehci_hcd scsi_mod > r8169 mii usbcore drm nvme nvme_core fjes button [last unloaded: net2280] > [ 77.316999] CPU: 2 PID: 853 Comm: rmmod Not tainted 4.9.0-rc5 #3 > [ 77.388856] Hardware name: To Be Filled By O.E.M. To Be Filled By > O.E.M./Z77 Extreme3, BIOS P1.50 07/11/2013 > [ 77.506474] task: 880419f6a100 task.stack: c90002e8c000 > [ 77.577292] RIP: 0010:[] [] > kthread_stop+0x16/0x110 > [ 77.674214] RSP: 0018:c90002e8fdb0 EFLAGS: 00010286 > [ 77.737754] RAX: 0001 RBX: RCX: > > [ 77.823133] RDX: 0001 RSI: 0246 RDI: > > [ 77.908513] RBP: c90002e8fdc8 R08: R09: > 0001 > [ 77.993892] R10: 019d R11: 001f R12: > > [ 78.079271] R13: 88041b8d8400 R14: 0001 R15: > 55fd59f5a1e0 > [ 78.164649] FS: 7f82500be700() GS:88042f28() > knlGS: > [ 78.261467] CS: 0010 DS: ES: CR0: 80050033 > [ 78.330206] CR2: 0018 CR3: 00041bee2000 CR4: > 001406e0 > [ 78.415586] Stack: > [ 78.439609] c0b8e720 88041b8d8400 > c90002e8fdf0 > [ 78.528522] c0b8bb52 88041a106300 0001 > 880419fc2ea8 > [ 78.617436] c90002e8fe08 c0aed749 c0aef600 > c90002e8fe20 > [ 78.706350] Call Trace: > [ 78.735579] [] gserial_free_line+0x72/0xb0 [u_serial] > [ 78.815758] [] acm_free_instance+0x19/0x30 [usb_f_acm] > [ 78.896978] [] usb_put_function_instance+0x20/0x30 > [libcomposite] > [ 78.989634] [] gs_unbind+0x3b/0x70 [g_serial] > [ 79.061493] [] __composite_unbind+0x61/0xb0 > [libcomposite] > [ 79.146872] [] composite_unbind+0x13/0x20 > [libcomposite] > [ 79.230172] [] usb_gadget_remove_driver+0x3d/0x90 > [udc_core] > [ 79.317632] [] > usb_gadget_unregister_driver+0x6e/0xc0 [udc_core] > [ 79.409248] [] usb_composite_unregister+0x12/0x20 > [libcomposite] > [ 79.500866] [] cleanup+0x10/0xda8 [g_serial] > [ 79.571685] [] SyS_delete_module+0x192/0x270 > [ 79.642508] [] ? exit_to_usermode_loop+0x90/0xb0 > [ 79.717486] [] entry_SYSCALL_64_fastpath+0x1e/0xad > [ 79.794543] Code: 89 c6 e8 6e ff ff ff 48 89 df e8 06 bd fd ff 5b 5d > c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc 53 0f 1f 44 > 00 00 41 ff 44 24 18 4c 89 e7 e8 bc f1 ff ff 48 85 c0 48 89 c3 74 > [ 80.027071] RIP [] kthread_stop+0x16/0x110 > [ 80.095915] RSP > [ 80.137617] CR2: 0018 > [ 80.177270] ---[ end trace 5b3336a407e1698c ]--- > > > (gdb) list *(gserial_free_line+0x72) > 0x1b
[PATCH 2/2] usb: gadget: serial: fix possible Oops caused by calling kthread_stop(NULL)
Add check for NULL before calling kthread_stop(). There were cases in which gserial_console_exit() was called, but the console thread was not started. This resulted in an invalid kthread_stop(NULL) call. Signed-off-by: Felix Hädicke --- drivers/usb/gadget/function/u_serial.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c index 5fedead..f58c775 100644 --- a/drivers/usb/gadget/function/u_serial.c +++ b/drivers/usb/gadget/function/u_serial.c @@ -1256,7 +1256,8 @@ static void gserial_console_exit(void) struct gscons_info *info = &gscons_info; unregister_console(&gserial_cons); - kthread_stop(info->console_thread); + if (info->console_thread != NULL) + kthread_stop(info->console_thread); gs_buf_free(&info->con_buf); } -- 2.10.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] usb: gadget: serial: zero-initialize struct variable gscons_info
There can be cases when members of the gscons_info struct are used
uninitialized, e. g. in, gserial_console_exit(), if gs_console_setup()
was not called before.
Signed-off-by: Felix Hädicke
---
drivers/usb/gadget/function/u_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index e0cd1e4..5fedead 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1043,7 +1043,7 @@ static struct tty_driver *gs_tty_driver;
#ifdef CONFIG_U_SERIAL_CONSOLE
-static struct gscons_info gscons_info;
+static struct gscons_info gscons_info = {};
static struct console gserial_cons;
static struct usb_request *gs_request_new(struct usb_ep *ep)
--
2.10.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
AW: add usb option device
Dear All, thanks for the very interesting discussion. > > This will make option grab all the ports, as shown by your dmesg > > output. But USB interfaces 0 and 1 are actually cdc-ether and should > > *not* be grabbed by option. > > > > You want to limit option to grabbing bInterfaceClass=255 to make sure > > it only gets the serial ports. > Actually the device have 2 cdc_ether interface and the others are serial comm. This is the bootlog of the original oem firmware: hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected usb 2-1: new high speed USB device using rt3xxx-ehci and address 2 usb 2-1: configuration #1 chosen from 1 choice usbcore: registered new interface driver cdc_ether usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbserial_generic 2-1:1.2: generic converter detected usb 2-1: generic converter now attached to ttyUSB0 usbserial_generic 2-1:1.3: generic converter detected usb 2-1: generic converter now attached to ttyUSB1 usbserial_generic 2-1:1.4: generic converter detected usb 2-1: generic converter now attached to ttyUSB2 usbserial_generic 2-1:1.5: generic converter detected usb 2-1: generic converter now attached to ttyUSB3 usbserial_generic 2-1:1.6: generic converter detected usb 2-1: generic converter now attached to ttyUSB4 usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core and at the end of the modem configuration: usbnet0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:77.25.169.193 Bcast:77.25.169.195 Mask:255.255.255.252 inet6 addr: fe80:::feaa:/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:272 (272.0 B) TX bytes:600 (600.0 B) Therefore I also consider convenient preserve the first two interface for the cdc_ether. Can you please clarify me the differences between black and white list and how to configure it? > Also, is it really a D-Link DWM-158? That appears to be a USB dongle- type > device, while what's in the DWR-512 is a PCI-E minicard that looks like a ZTE > MF210, from the FCC pictures. How is interested in having more info about the modem and the router can read the description page I compiled here: https://wiki.openwrt.org/inbox/d-link/d-link_dwr-512_b I will make additional test with different driver configuration and I will come back to you. Bye. -- 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: add usb option device
On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote: > This will make option grab all the ports, as shown by your dmesg > output. But USB interfaces 0 and 1 are actually cdc-ether and should > *not* be grabbed by option. > > You want to limit option to grabbing bInterfaceClass=255 to make sure > it only gets the serial ports. Hi, what happens if you actually use these ethernet interfaces while somebody uses the serial interfaces? 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
AW: add usb option device
> > This will make option grab all the ports, as shown by your dmesg > > output. But USB interfaces 0 and 1 are actually cdc-ether and should > > *not* be grabbed by option. I also have another curiosity: Why the driver architecture doesn't recognize autonomously the cdc-ether Interface and only gets the serial ports? Thanks, Bye. > -Ursprüngliche Nachricht- > Von: Oliver Neukum [mailto:oneu...@suse.com] > Gesendet: Mittwoch, 16. November 2016 21:57 > An: Dan Williams > Cc: Giuseppe Lippolis ; linux-usb@vger.kernel.org > Betreff: Re: add usb option device > > On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote: > > This will make option grab all the ports, as shown by your dmesg > > output. But USB interfaces 0 and 1 are actually cdc-ether and should > > *not* be grabbed by option. > > > > You want to limit option to grabbing bInterfaceClass=255 to make sure > > it only gets the serial ports. > > Hi, > > what happens if you actually use these ethernet interfaces while somebody > uses the serial interfaces? > > 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: [PATCH 1/2] usb: gadget: serial: zero-initialize struct variable gscons_info
Hello.
On 11/16/2016 11:46 PM, Felix Hädicke wrote:
There can be cases when members of the gscons_info struct are used
uninitialized, e. g. in, gserial_console_exit(), if gs_console_setup()
was not called before.
Signed-off-by: Felix Hädicke
---
drivers/usb/gadget/function/u_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index e0cd1e4..5fedead 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1043,7 +1043,7 @@ static struct tty_driver *gs_tty_driver;
#ifdef CONFIG_U_SERIAL_CONSOLE
-static struct gscons_info gscons_info;
+static struct gscons_info gscons_info = {};
That shouldn't change anything -- static variables are always zeroed.
[...]
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
Re: [PATCH 1/2] usb: gadget: serial: zero-initialize struct variable gscons_info
ok, thanks for the hint. I dind't know this.
Just ignore this patch.
Am 16.11.2016 um 22:42 schrieb Sergei Shtylyov:
> Hello.
>
> On 11/16/2016 11:46 PM, Felix Hädicke wrote:
>
>> There can be cases when members of the gscons_info struct are used
>> uninitialized, e. g. in, gserial_console_exit(), if gs_console_setup()
>> was not called before.
>>
>> Signed-off-by: Felix Hädicke
>> ---
>> drivers/usb/gadget/function/u_serial.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/u_serial.c
>> b/drivers/usb/gadget/function/u_serial.c
>> index e0cd1e4..5fedead 100644
>> --- a/drivers/usb/gadget/function/u_serial.c
>> +++ b/drivers/usb/gadget/function/u_serial.c
>> @@ -1043,7 +1043,7 @@ static struct tty_driver *gs_tty_driver;
>>
>> #ifdef CONFIG_U_SERIAL_CONSOLE
>>
>> -static struct gscons_info gscons_info;
>> +static struct gscons_info gscons_info = {};
>
>That shouldn't change anything -- static variables are always zeroed.
>
> [...]
>
> 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
--
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/6] usb: dwc2: Minor fixes and cleanup
This series includes some minor fixes and cleanup commits for dwc2 that we've had locally for some time. Razmik Karapetyan (5): usb: dwc2: Don't program DMA address for 0 length request usb: dwc2: Fix Control Write issue in DMA mode usb: dwc2: Remove unnecessary request length checking usb: dwc2: Fix fifo_show() functionality usb: dwc2: Move functions from header to source Sevak Arakelyan (1): usb: dwc2: Stop Complete Splits after Data PID == 0 drivers/usb/dwc2/debugfs.c | 2 +- drivers/usb/dwc2/gadget.c | 19 +++ drivers/usb/dwc2/hcd.c | 58 ++--- drivers/usb/dwc2/hcd.h | 5 drivers/usb/dwc2/hcd_intr.c | 7 +- 5 files changed, 44 insertions(+), 47 deletions(-) -- 2.10.0 -- 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 3/6] usb: dwc2: Fix Control Write issue in DMA mode
From: Razmik Karapetyan
While sending zlp for DWC2_EP0_STATUS_IN EP direction was changed to IN.
Change it back to complete OUT transfer request.
This affects only on DMA mode, because DMA buffer map/unmap function is
direction sensitive.
Signed-off-by: Razmik Karapetyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4dd5f1e..39eccbb 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2527,6 +2527,13 @@ static void dwc2_hsotg_complete_in(struct dwc2_hsotg
*hsotg,
/* Finish ZLP handling for IN EP0 transactions */
if (hs_ep->index == 0 && hsotg->ep0_state == DWC2_EP0_STATUS_IN) {
dev_dbg(hsotg->dev, "zlp packet sent\n");
+
+ /*
+* While send zlp for DWC2_EP0_STATUS_IN EP direction was
+* changed to IN. Change back to complete OUT transfer request
+*/
+ hs_ep->dir_in = 0;
+
dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, 0);
if (hsotg->test_mode) {
int ret;
--
2.10.0
--
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/6] usb: dwc2: Stop Complete Splits after Data PID == 0
From: Sevak Arakelyan
Stop sending complete split requests in case of ISOC IN split transfers
after getting data with PID0. Otherwise we will get a NYET for each
additional IN token.
Signed-off-by: Sevak Arakelyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/hcd_intr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 0f26334..b8f4b6a 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -915,6 +915,8 @@ static int dwc2_xfercomp_isoc_split_in(struct dwc2_hsotg
*hsotg,
{
struct dwc2_hcd_iso_packet_desc *frame_desc;
u32 len;
+ u32 hctsiz;
+ u32 pid;
if (!qtd->urb)
return 0;
@@ -932,7 +934,10 @@ static int dwc2_xfercomp_isoc_split_in(struct dwc2_hsotg
*hsotg,
qtd->isoc_split_offset += len;
- if (frame_desc->actual_length >= frame_desc->length) {
+ hctsiz = dwc2_readl(hsotg->regs + HCTSIZ(chnum));
+ pid = (hctsiz & TSIZ_SC_MC_PID_MASK) >> TSIZ_SC_MC_PID_SHIFT;
+
+ if (frame_desc->actual_length >= frame_desc->length || pid == 0) {
frame_desc->status = 0;
qtd->isoc_frame_index++;
qtd->complete_split = 0;
--
2.10.0
--
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 6/6] usb: dwc2: Move functions from header to source
From: Razmik Karapetyan
Removed extern specifier from dwc2_host_start(), dwc2_host_disconnect()
and dwc2_host_hub_info() functions. Moved those functions from header
to source. Then make them static.
Signed-off-by: Razmik Karapetyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/hcd.c | 58 +-
drivers/usb/dwc2/hcd.h | 5 -
2 files changed, 29 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fb7f8e9..911c3b3 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -649,6 +649,35 @@ static void dwc2_dump_channel_info(struct dwc2_hsotg
*hsotg,
#endif /* VERBOSE_DEBUG */
}
+static int _dwc2_hcd_start(struct usb_hcd *hcd);
+
+static void dwc2_host_start(struct dwc2_hsotg *hsotg)
+{
+ struct usb_hcd *hcd = dwc2_hsotg_to_hcd(hsotg);
+
+ hcd->self.is_b_host = dwc2_hcd_is_b_host(hsotg);
+ _dwc2_hcd_start(hcd);
+}
+
+static void dwc2_host_disconnect(struct dwc2_hsotg *hsotg)
+{
+ struct usb_hcd *hcd = dwc2_hsotg_to_hcd(hsotg);
+
+ hcd->self.is_b_host = 0;
+}
+
+static void dwc2_host_hub_info(struct dwc2_hsotg *hsotg, void *context,
+ int *hub_addr, int *hub_port)
+{
+ struct urb *urb = context;
+
+ if (urb->dev->tt)
+ *hub_addr = urb->dev->tt->hub->devnum;
+ else
+ *hub_addr = 0;
+ *hub_port = urb->dev->ttport;
+}
+
/*
* =
* Low Level Host Channel Access Functions
@@ -4022,35 +4051,6 @@ static struct dwc2_hsotg *dwc2_hcd_to_hsotg(struct
usb_hcd *hcd)
return p->hsotg;
}
-static int _dwc2_hcd_start(struct usb_hcd *hcd);
-
-void dwc2_host_start(struct dwc2_hsotg *hsotg)
-{
- struct usb_hcd *hcd = dwc2_hsotg_to_hcd(hsotg);
-
- hcd->self.is_b_host = dwc2_hcd_is_b_host(hsotg);
- _dwc2_hcd_start(hcd);
-}
-
-void dwc2_host_disconnect(struct dwc2_hsotg *hsotg)
-{
- struct usb_hcd *hcd = dwc2_hsotg_to_hcd(hsotg);
-
- hcd->self.is_b_host = 0;
-}
-
-void dwc2_host_hub_info(struct dwc2_hsotg *hsotg, void *context, int *hub_addr,
- int *hub_port)
-{
- struct urb *urb = context;
-
- if (urb->dev->tt)
- *hub_addr = urb->dev->tt->hub->devnum;
- else
- *hub_addr = 0;
- *hub_port = urb->dev->ttport;
-}
-
/**
* dwc2_host_get_tt_info() - Get the dwc2_tt associated with context
*
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index d92656d..1ed5fa2 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -793,11 +793,6 @@ extern void dwc2_hcd_dump_frrem(struct dwc2_hsotg *hsotg);
#define URB_SEND_ZERO_PACKET 0x2
/* Host driver callbacks */
-
-extern void dwc2_host_start(struct dwc2_hsotg *hsotg);
-extern void dwc2_host_disconnect(struct dwc2_hsotg *hsotg);
-extern void dwc2_host_hub_info(struct dwc2_hsotg *hsotg, void *context,
- int *hub_addr, int *hub_port);
extern struct dwc2_tt *dwc2_host_get_tt_info(struct dwc2_hsotg *hsotg,
void *context, gfp_t mem_flags,
int *ttport);
--
2.10.0
--
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 4/6] usb: dwc2: Remove unnecessary request length checking
From: Razmik Karapetyan
Remove request length checking from dwc2_hsotg_unmap_dma() and
dwc2_hsotg_map_dma(). That checking is done in functions called from
those functions, usb_gadget_unmap_request_by_dev() and
usb_gadget_map_request_by_dev() respectively, so it's unnecessary.
Signed-off-by: Razmik Karapetyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 39eccbb..b95930f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -316,11 +316,6 @@ static void dwc2_hsotg_unmap_dma(struct dwc2_hsotg *hsotg,
struct dwc2_hsotg_req *hs_req)
{
struct usb_request *req = &hs_req->req;
-
- /* ignore this if we're not moving any data */
- if (hs_req->req.length == 0)
- return;
-
usb_gadget_unmap_request(&hsotg->gadget, req, hs_ep->dir_in);
}
@@ -1101,13 +1096,8 @@ static int dwc2_hsotg_map_dma(struct dwc2_hsotg *hsotg,
struct dwc2_hsotg_ep *hs_ep,
struct usb_request *req)
{
- struct dwc2_hsotg_req *hs_req = our_req(req);
int ret;
- /* if the length is zero, ignore the DMA data */
- if (hs_req->req.length == 0)
- return 0;
-
ret = usb_gadget_map_request(&hsotg->gadget, req, hs_ep->dir_in);
if (ret)
goto dma_error;
--
2.10.0
--
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 5/6] usb: dwc2: Fix fifo_show() functionality
From: Razmik Karapetyan NPTXFIFO's start address is showing 0x0300 instead of 0x0800. Replaced val & FIFOSIZE_DEPTH_MASK by val & FIFOSIZE_STARTADDR_MASK in fifo_show() function. Signed-off-by: Razmik Karapetyan Signed-off-by: John Youn --- drivers/usb/dwc2/debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c index 55d91f2..0a13091 100644 --- a/drivers/usb/dwc2/debugfs.c +++ b/drivers/usb/dwc2/debugfs.c @@ -213,7 +213,7 @@ static int fifo_show(struct seq_file *seq, void *v) val = dwc2_readl(regs + GNPTXFSIZ); seq_printf(seq, "NPTXFIFO: Size %d, Start 0x%08x\n", val >> FIFOSIZE_DEPTH_SHIFT, - val & FIFOSIZE_DEPTH_MASK); + val & FIFOSIZE_STARTADDR_MASK); seq_puts(seq, "\nPeriodic TXFIFOs:\n"); -- 2.10.0 -- 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 2/6] usb: dwc2: Don't program DMA address for 0 length request
From: Razmik Karapetyan
Check the request length in dwc2_hsotg_start_req() function. If
length == 0, do not write DMA address to control register.
Signed-off-by: Razmik Karapetyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ad0cd0e..4dd5f1e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1018,7 +1018,7 @@ static void dwc2_hsotg_start_req(struct dwc2_hsotg *hsotg,
/* write size / packets */
dwc2_writel(epsize, hsotg->regs + epsize_reg);
- if (using_dma(hsotg) && !continuing) {
+ if (using_dma(hsotg) && !continuing && (length != 0)) {
/*
* write DMA address to control register, buffer
* already synced by dwc2_hsotg_ep_queue().
--
2.10.0
--
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 v2 3/4] usb: dwc2: Use the ahb_burst param
Use the new ahb_burst (instead of ahbcfg) to program the GAHBCFG.HBSTLEN
in both host and gadget mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/hcd.c| 8 +++-
drivers/usb/dwc2/params.c | 10 --
3 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ad0cd0e..da11292 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3231,7 +3231,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
if (using_dma(hsotg)) {
dwc2_writel(GAHBCFG_GLBL_INTR_EN | GAHBCFG_DMA_EN |
- (GAHBCFG_HBSTLEN_INCR4 << GAHBCFG_HBSTLEN_SHIFT),
+ (hsotg->params.ahb_burst << GAHBCFG_HBSTLEN_SHIFT),
hsotg->regs + GAHBCFG);
/* Set DDMA mode support in the core if needed */
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fb7f8e9..7f57d5d 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -273,11 +273,9 @@ static int dwc2_gahbcfg_init(struct dwc2_hsotg *hsotg)
case GHWCFG2_INT_DMA_ARCH:
dev_dbg(hsotg->dev, "Internal DMA Mode\n");
- if (hsotg->params.ahbcfg != -1) {
- ahbcfg &= GAHBCFG_CTRL_MASK;
- ahbcfg |= hsotg->params.ahbcfg &
- ~GAHBCFG_CTRL_MASK;
- }
+ ahbcfg &= ~GAHBCFG_HBSTLEN_MASK;
+ ahbcfg |= (hsotg->params.ahb_burst <<
+ GAHBCFG_HBSTLEN_SHIFT);
break;
case GHWCFG2_SLAVE_ONLY_ARCH:
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 8bc2745..e0281e4 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -988,15 +988,6 @@ static void dwc2_set_param_reload_ctl(struct dwc2_hsotg
*hsotg, int val)
hsotg->params.reload_ctl = val;
}
-static void dwc2_set_param_ahbcfg(struct dwc2_hsotg *hsotg, int val)
-{
- if (val != -1)
- hsotg->params.ahbcfg = val;
- else
- hsotg->params.ahbcfg = GAHBCFG_HBSTLEN_INCR4 <<
- GAHBCFG_HBSTLEN_SHIFT;
-}
-
static void dwc2_set_param_otg_ver(struct dwc2_hsotg *hsotg, int val)
{
if (DWC2_OUT_OF_BOUNDS(val, 0, 1)) {
@@ -1226,7 +1217,6 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
dwc2_set_param_en_multiple_tx_fifo(hsotg,
params->en_multiple_tx_fifo);
dwc2_set_param_reload_ctl(hsotg, params->reload_ctl);
- dwc2_set_param_ahbcfg(hsotg, params->ahbcfg);
dwc2_set_param_otg_ver(hsotg, params->otg_ver);
dwc2_set_param_uframe_sched(hsotg, params->uframe_sched);
dwc2_set_param_external_id_pin_ctl(hsotg, params->external_id_pin_ctl);
--
2.10.0
--
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 v2 2/4] usb: dwc2: Add binding for AHB burst
Add the "snps,ahb-burst" binding and read it in.
This property controls which burst type to perform on the AHB bus as a
master in internal DMA mode. This overrides the legacy param value,
which we need to keep around for now since several platforms use it.
Some platforms may see better or worse performance based on this
value. The HAPS platform is one example where all INCRx have worse
performance than INCR.
Other platforms (such as the Canyonlands board) report that the default
value causes system hangs.
Signed-off-by: John Youn
Cc: Christian Lamparter
---
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h| 9 +
drivers/usb/dwc2/params.c | 56 ++
3 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 6c7c2bce..9e7b4b4 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,6 +26,8 @@ Optional properties:
Refer to phy/phy-bindings.txt for generic phy consumer properties
- dr_mode: shall be one of "host", "peripheral" and "otg"
Refer to usb/generic.txt
+- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
+ "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
- 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.
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..75c238c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -430,6 +430,12 @@ enum dwc2_ep0_state {
* needed.
* 0 - No (default)
* 1 - Yes
+ * @ahb_burst: Specifies the AHB burst.
+ * 0 - Single
+ * 1 - INCR
+ * 3 - INCR4 (default)
+ * 5 - INCR8
+ * 7 - INCR16
* @g_dma: Enables gadget dma usage (default: autodetect).
* @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
* @g_rx_fifo_size:The periodic rx fifo size for the device, in
@@ -507,6 +513,9 @@ struct dwc2_core_params {
* properties and cannot be set directly in this structure.
*/
+ /* Global parameters */
+ u8 ahb_burst;
+
/* Host parameters */
bool host_dma;
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index d44b31c..8bc2745 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1098,6 +1098,60 @@ static void dwc2_set_param_tx_fifo_sizes(struct
dwc2_hsotg *hsotg)
}
}
+static const char *const ahb_bursts[] = {
+ [GAHBCFG_HBSTLEN_SINGLE]= "SINGLE",
+ [GAHBCFG_HBSTLEN_INCR] = "INCR",
+ [GAHBCFG_HBSTLEN_INCR4] = "INCR4",
+ [GAHBCFG_HBSTLEN_INCR8] = "INCR8",
+ [GAHBCFG_HBSTLEN_INCR16]= "INCR16",
+};
+
+static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
+{
+ const char *str = NULL;
+ int burst;
+ int ret;
+
+ ret = device_property_read_string(hsotg->dev,
+ "snps,ahb-burst", &str);
+ if (ret < 0)
+ return ret;
+
+ burst = match_string(ahb_bursts,
+ARRAY_SIZE(ahb_bursts), str);
+ if (burst < 0) {
+ dev_err(hsotg->dev,
+ "Invalid parameter '%s' for ahb-burst\n", str);
+ }
+
+ return burst;
+}
+
+static void dwc2_set_ahb_burst(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_core_params *p = &hsotg->params;
+ int burst;
+ int ret;
+
+ /* Default burst value */
+ burst = GAHBCFG_HBSTLEN_INCR4;
+
+ /* Get the legacy param value, if set. */
+ if (p->ahbcfg != -1) {
+ burst = (p->ahbcfg & GAHBCFG_HBSTLEN_MASK) >>
+ GAHBCFG_HBSTLEN_SHIFT;
+ }
+
+ /* Override it from devicetree, if set. */
+ ret = dwc2_get_property_ahb_burst(hsotg);
+ if (ret >= 0)
+ burst = ret;
+
+ /* Set the parameter */
+ p->ahb_burst = (u8)burst;
+ dev_dbg(hsotg->dev, "Setting ahb-burst to %d\n", burst);
+}
+
static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
{
struct dwc2_hw_params *hw = &hsotg->hw_params;
@@ -1178,6 +1232,8 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
dwc2_set_param_external_id_pin_ctl(hsotg, params->external_id_pin_ctl);
dwc2_set_param_hibernation(hsotg, params->hibernation);
+ dwc2_set_ahb_burst(hsotg);
+
/*
* Set devicetree-only parameters. These parameters do not
* take any values from @params.
--
2.10.0
--
To unsubscrib
[PATCH v2 1/4] usb: dwc2: Document the AHB burst value for bcm2835
The BCM2835 has an alternate function for the GAHBCFG.HBSTLEN field.
Document this difference in the code.
Cc: Stefan Wahren
Signed-off-by: John Youn
---
drivers/usb/dwc2/params.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index a786256..d44b31c 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -93,6 +93,13 @@ static const struct dwc2_core_params params_bcm2835 = {
.host_ls_low_power_phy_clk = 0,/* 48 MHz */
.ts_dline = 0,
.reload_ctl = 0,
+
+ /*
+* Although this value would normally be invalid, for BCM2835,
+* the GAHBCFG.HBSTLEN field has a different meaning from that
+* defined by Synopsys. See the BCM2835 databook section 15.2
+* for details.
+*/
.ahbcfg = 0x10,
.uframe_sched = 0,
.external_id_pin_ctl= -1,
--
2.10.0
--
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 v2 0/4] usb: dwc2: Add AHB burst configuration
This series adds a binding for AHB burst, reads it in, and configures the controller for the specified burst type. Tested on HAPS platform with DWC_hsotg IP version 3.30a. v2: * Don't remove the bcm2835 ahbcfg param and document why. John Youn (4): usb: dwc2: Document the AHB burst value for bcm2835 usb: dwc2: Add binding for AHB burst usb: dwc2: Use the ahb_burst param usb: dwc2: pci: Add AHB burst property for HAPS Documentation/devicetree/bindings/usb/dwc2.txt | 2 + drivers/usb/dwc2/core.h| 9 drivers/usb/dwc2/gadget.c | 2 +- drivers/usb/dwc2/hcd.c | 8 ++- drivers/usb/dwc2/params.c | 73 ++ drivers/usb/dwc2/pci.c | 1 + 6 files changed, 79 insertions(+), 16 deletions(-) -- 2.10.0 -- 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 v2 4/4] usb: dwc2: pci: Add AHB burst property for HAPS
Set the AHB burst to INCR for HAPS.
Signed-off-by: John Youn
---
drivers/usb/dwc2/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index a23329e..146b7ce 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -67,6 +67,7 @@ static int dwc2_pci_quirks(struct pci_dev *pdev, struct
platform_device *dwc2)
if (pdev->vendor == PCI_VENDOR_ID_SYNOPSYS &&
pdev->device == PCI_PRODUCT_ID_HAPS_HSOTG) {
struct property_entry properties[] = {
+ PROPERTY_ENTRY_STRING("snps,ahb-burst", "INCR"),
{ },
};
--
2.10.0
--
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: crash by cdc_acm driver in kernels 4.8-rc1/5
On Wed, Nov 16, 2016 at 04:07:57PM +0100, Wim Osterholt wrote: > A bit of patience please. Yesterday I hadn't the modem at hand. Whell, I lost track of what happens where with which config file.. Confusion about the bug not appearing an too many configs with SMP set where I'm sure the machine(s) crashed on it. The intention was to now use just one machine, to avoid confusion. This is not going to work, due to problems with my video card. (Crashes when it writes text beyond framebuffer space?) VGA mode keeps working now.. We'll see.. Okay, a virgin start then. A new 4.8.8 downloaded. A config from 4.7.9. Make oldconfig. Accept all defaults for the new options. CONFIG_SMP was set. Made two kernels, with and without SMP set. Both kernels behaved the same: an OOPS at cdc_acm loading. Fortunately the bug is still there. In this very config the SMP setting does not seem to matter. Now a retry of 4.9-rc5. I take the config of 4.8.8 and accept the default for the new options. SMP set. No call trace appears. For completeness I should also try with SMP unset. That is for tomorrow then. BTW, your latest patch was not yet applied here. At work where I had no oops today, it gave an output count from 0 to 41, looping (30-39) through 16 buffers. More tomorrow. Need urgent sleep now. Regards, Wim. -- 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: add usb option device
On 2016-11-17 01:35, Dan Williams wrote: Also, is it really a D-Link DWM-158? That appears to be a USB dongle- type device, while what's in the DWR-512 is a PCI-E minicard that looks like a ZTE MF210, from the FCC pictures. DWR-512A1 uses the ZTE MF210 module while DWR-512B1 uses the D-Link DWM-800A module. Giuseppes photos shows a DWM-800A module but with a label from an alternative manufacturer (maybe from the original manufacturer who makes them for D-Link). DWR-512B1 is the same router as DWR-712C1 (FCC Id KA2WR712C1) except for the broadband module which is a DWM-800B in DWR-712C1. Only difference between A and B version of the modules is HSPA+ vs DC-HSPA+ ie only a firmware difference, they share the same hardware all the way down to the same PCB from what I can see. So I am also curious to know where DWM-158 comes from as I can't see it mentioned in Giuseppes wiki page log but it is possible that D-Link has used the same firmware as for the DWM-800A module as they use for DWMZ-158. rgds /Lars -- 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: add usb option device
On 2016-11-17 03:57, Oliver Neukum wrote: On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote: This will make option grab all the ports, as shown by your dmesg output. But USB interfaces 0 and 1 are actually cdc-ether and should *not* be grabbed by option. You want to limit option to grabbing bInterfaceClass=255 to make sure it only gets the serial ports. Hi, what happens if you actually use these ethernet interfaces while somebody uses the serial interfaces? You can obviously not make a connection over the ppp modem serial interface at the same time as you are connected over the cdc_ether interfaces, you have to choose which connect method you prefer. Keep in mind that there is no management protocol specification for cdc_ether so that is sometimes carried out over a serial interface using AT cmds. So to answer your worries, yes we want both drivers to bind. rgds /Lars -- 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: cdc_mbim: probe of 2-2:1.12 failed with error -22
On Wed, Nov 16, 2016 at 6:56 PM, Kai-Heng Feng wrote: > On Wed, Nov 16, 2016 at 6:47 PM, Greg KH wrote: >> On Wed, Nov 16, 2016 at 06:42:27PM +0800, Kai-Heng Feng wrote: >>> Originally I sent a not-working patch to the mailing list [1], turns >>> out the patch is far from correct. >>> >>> Bjørn Mork suggests that we can cover the USB3 pair diff pins with >>> tape to do some experiment, but the vendor told me that there's no >>> such pin. >>> >>> According to the attached log, looks like xhci driver failed to get >>> status from port after resume, eventually make the cdc_mbim probe >>> failed: >>> >>> [ 10.038428] xhci_hcd :00:14.0: get port status, actual port 1 >>> status = 0x202c0 >>> [ 10.038429] xhci_hcd :00:14.0: Get port status returned 0x102c0 >>> [ 10.038463] usb usb2-port2: status 0001.02c0 after resume, -19 >>> [ 10.038465] usb 2-2: can't resume, status -19 >>> [ 10.038465] usb usb2-port2: logical disconnect >>> [ 10.038472] xhci_hcd :00:14.0: Cannot set link state. >> >> Odd. What kernel version is this? >> > > xhci/for-usb-next branch: > 6005a545cadb2adca64350c7aee17d002563e8c7 usb: hub: Fix auto-remount of > safely removed or ejected USB-3 devices > > The latest mainline tag in this branch is 4.9-rc3. [CC to maintainers] -- 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 net 2/2] r8152: rx descriptor check
Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Tuesday, November 15, 2016 9:11 AM [...] > If it was possible to get it wrong once, it should be possible to > get it wrong twice, especially if some part of the hardware design > is recycled. I don't mean anything else. I agree with you. However, I have to let it could be reproduced for confirming it. Besides, the behavior is different for PCIe and USB device. There is no action of DMA for USB device. It is done by the USB host controller. And, the USB host controller wouldn't allow the device sends a data which is more than the size of the buffer. Best Regards, Hayes -- 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
