Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote: > On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: > > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: > > > > + 1500, > > > + 1800, > > > + 550, > > > +}; > > > Why 550 is the last, but not 1800? > > You'd have to ask the hardware engineers who designed the chip. I > suspect it's because 550 was added at a late stage in the design process > but I'm basically just guessing there. ok, I just had suspected below function's correctness, after looking it again, it always set 1800 as charging limit, does it be expected? +/* In miliamps */ +static unsigned int wm831x_usb_limits[] = { + 0, + 2, + 100, + 500, + 900, + 1500, + 1800, + 550, +}; + +static int wm831x_usb_limit_change(struct notifier_block *nb, + unsigned long limit, void *data) +{ + struct wm831x_power *wm831x_power = container_of(nb, +struct wm831x_power, +usb_notify); + int i, best; + + /* Find the highest supported limit */ + best = 0; + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) { + if (limit < wm831x_usb_limits[i] && + wm831x_usb_limits[best] < wm831x_usb_limits[i]) + best = i; + } + + dev_dbg(wm831x_power->wm831x->dev, + "Limiting USB current to %dmA", wm831x_usb_limits[best]); + + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE, + WM831X_USB_ILIM_MASK, best); + + return 0; +} + > > > > */ > > > @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device > > > *pdev) > > > } > > > } > > > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) { > > > Where the wm831x_pdata->usb_gadget is initialized? > > It's platform data, it will be initialised by whatever registers the > platform data. Get it, I just do not find in this patch set, thanks. -- Best Regards, Peter Chen -- 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: Stack dump when try to store uframe_periodic_max
On Mon, Aug 17, 2015 at 12:04:07PM -0400, Alan Stern wrote: > On Mon, 17 Aug 2015, Peter Zijlstra wrote: > > > On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: > > > On Mon, 17 Aug 2015, Peter Chen wrote: > > > > > > > Hi Alan, > > > > > > > > When run "echo 105 > > > > > /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max", > > > > if lockdep check is enabled, there is below dump, I am afraid it can't > > > > find how to fix it, the warning shows the key is not persistent. > > > > (see line 757, kernel/locking/lockdep.c). > > > > > > > > > > > > [ 70.190430] INFO: trying to register non-static key. > > > > [ 70.195437] the code is fine but needs lockdep annotation. > > > > [ 70.200939] turning off the locking correctness validator. > > > > > I don't understand this either. > > > > > > Maybe Peter Z. can help. This dump is triggered by the > > > spin_lock_irqsave() call in > > > drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That > > > function doesn't appear to be unusual in any way. > > > > Can it happen this code is called before a corresponding > > spin_lock_init()? > > No; the spinlock gets initialized in ehci_init() long before the sysfs > file is registered. > > > Alternatively, memory corruption is an option. If something stomped on > > the lockdep state you can trigger this I suppose. > oops, sorry, it is memory corruption. The chipidea driver overrides platform device's drvdata as its private data (struct ci_hdrc *), this data was expected as struct usb_hcd * at store_uframe_periodic_max. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote: > On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote: > > On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: > > > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: > > > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) { > > > Where the wm831x_pdata->usb_gadget is initialized? > > It's platform data, it will be initialised by whatever registers the > > platform data. > passing pointers through pdata ? It's a char * to a name, not a pointer to struct. signature.asc Description: Digital signature
Re: [PATCH 1/3] Honor ACPI _CCA attribute setting
On Fri, Aug 14, 2015 at 09:12:28AM -0500, Jeremy Linton wrote: > Hello Suravee, > > On 08/13/2015 08:45 PM, Suravee Suthikulpanit wrote: > > On 8/13/15 04:51, Jeremy Linton wrote: > >> ACPI configurations can now mark devices as noncoherent, > >> support that choice. > > > > This change was in my earlier revisions for the original patch series to > > add ACPI CCA support. At the time, this was pushed back since we were > > not sure whether this would be a useful case, and whether such hardware > > exists. > > Yes, I was made aware of that conversation during the review here. > > Basically, the ARM Juno development platform has a mix of coherent and > noncoherent devices. The EHCI being one of the primary noncoherent > peripherals. Without which, the usefulness of the platform for > developing with an ACPI kernel is limited. > Tesed-by: Huang Shijie -- 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 3/3] Add ACPI bindings for the EHCI platform driver.
On Thu, Aug 13, 2015 at 10:13:44AM -0500, Jeremy Linton wrote: Hi Jeremy, Please add my tested-by for your next version: Tested-by: Huang Shijie thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] gadget: Introduce the usb charger framework
On 18 August 2015 at 01:24, Mark Brown wrote: > On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote: >> On 14 August 2015 at 23:27, Greg KH wrote: >> > On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: > >> >> + * This program is free software; you can redistribute it and/or modify >> >> + * it under the terms of the GNU General Public License as published by >> >> + * the Free Software Foundation; either version 2 of the License, or >> >> + * (at your option) any later version. > >> > I have to ask, do you really mean "any later version"? > >> I think I did not get your point, could you explain it detailedly? > > Unlike a lot of userspace projects the kernel is normally just licensed > under GPLv2 without the option to relicense with a later version so the > "...or any later version" is a bit unusual. There is some controversy > about some of the changes in GPLv3. Make sense. Thanks a lot. -- Baolin.wang Best Regards -- 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: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework
On 17 August 2015 at 23:25, Tim Bird wrote: > > > On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote: >> On 14 August 2015 at 23:27, Greg KH wrote: >>> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. >>> >>> I have to ask, do you really mean "any later version"? >>> >> >> I think I did not get your point, could you explain it detailedly? > > The full kernel is licensed under v2 of the GPL only, not "any later version". > See the second paragraph at the top of the COPYING file in the root directory > of the kernel source tree. There are differences on individual files, but > having this file allow "any later version" makes it different from much of > rest of the kernel. > > Unless you have a specific reason to allow greater-than-V2 GPL licensing on > this > file, you should change the licensing clause. The following wording appears > to be pretty popular: > > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > Hi Tim, Make sense of it. Thanks for your explanation. > -- Tim -- Baolin.wang Best Regards -- 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
[no subject]
Please contact me about this project (mrsyuen@outlook.com) Regards -- 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
Fwd: USB - Generic Serial device : Unable to read more than 4095 bytes
Hi, Regarding the above issue, I was checking the USB- Generic driver, And I tried the following things and found my data loss issue is fixed. change point >> In usb_serial_probe() function in usb-serial.c /* set up the endpoint information */ for (i = 0; i < num_bulk_in; ++i) { endpoint = bulk_in_endpoint[i]; port = serial->port[i]; buffer_size = max_t(int, serial->type->bulk_in_size, usb_endpoint_maxp(endpoint)); buffer_size = 16384; .. .. I changed the buffer_size value used in urb, previously it was 64 bytes now it is 16384 and I found my data loss issue fixed. Could you tell me is there any issue with this changes ? I am using this driver in embedded platform and in my application other devices will not use USB -Generic driver. Regards, Arun On Sat, Aug 8, 2015 at 2:50 AM, Greg KH wrote: > > On Fri, Aug 07, 2015 at 07:26:15PM +0900, arun k wrote: > > Hi, > > > > I am stuck with the above issue, > > I have some doubts regarding USB - Generic driver > > 1. Could you please explain me why USB - Generic driver is slow ? > > Because it was designed that way, it is not for high-speed data > throughput at all. It is a stop-gap measure for dumb usb devices that > want to emulate a serial connection. If you need a "real" driver, to > handle high rates of data, you will need to write a new driver for it. > > > 2. Now I am try to study USB - Generic driver implementation , I am > > confused with the function usb_serial_generic_read_bulk_callback() , > > could you please tell me from where this function is calling ? > > I recommend reading the USB chapter in the Linux Device Drivers book > (version 3, free online) to understand how USB drivers work. After > that, the answer should be obvious (hint, look at where that function > pointer is assigned to something...) > > > 3. If you have any detailed doc regarding the implementation of USB - > > Generic serial driver, Please send to me, > > The source code is pretty well documented :) > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote: > On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: > > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: > > > > + 1500, > > > + 1800, > > > + 550, > > > +}; > > > Why 550 is the last, but not 1800? > > You'd have to ask the hardware engineers who designed the chip. I > suspect it's because 550 was added at a late stage in the design process > but I'm basically just guessing there. > > > > */ > > > @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device > > > *pdev) > > > } > > > } > > > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) { > > > Where the wm831x_pdata->usb_gadget is initialized? > > It's platform data, it will be initialised by whatever registers the > platform data. passing pointers through pdata ? -- balbi signature.asc Description: Digital signature
repeat... Re: BUG: usb: phy: msm: problem with EPROBE defer and extcon cleanup
Sorry - I mistyped Ivan's e-mail the first time. On 08/17/2015 04:43 PM, Tim Bird wrote: > Ivan, > > I'm seeing a bug in the phy-msm-usb.c code, when I get an EPROBE defer during > probing the driver. > The code is statically linked in the kernel, and the dts for my board is > specifying an extcon phandle > for the ID pin. > > Below is a fragment of the kernel output for a boot of this code. Messages > prefixed with TRB > are my own debug printks. Note that the notifier block (at ee23513c) that > gets registered > with extcon before the first probe failure, ultimately gets used during an ID > pin event > (status change) by raw_notifier_call_chain(). This notifier block should be > unregistered > if the probe fails, so that only the second one registered is on the call > chain. > > Let me know if you plan to work on this. I'm otherwise occupied the > remainder of this week, > so won't have time to work on it, but I can probably get to it early next > week if you don't. > > Regards, > -- Tim > > > [1.435543] NET: Registered protocol family 17 > > [1.439773] Key type dns_resolver registered > > [1.444041] Registering SWP/SWPB emulation handler > > [1.451259] msm_otg f9a55000.usb-phy: failed to get phandle in > /soc/usb-phy@f9a55000 node > [1.452915] TRB: registering notifier for ext_id > > [1.464681] TRB: motg=ee235010, id=ee23513c, nb=ee23513c > > [1.465957] msm_otg f9a55000.usb-phy: OTG regs = f011e000 > > [1.471532] msm_otg f9a55000.usb-phy: Failed to get supply 'v3p3': -517 > > [1.477416] msm_hsusb_host f9a55000.ehci: ehci_msm proble > > [1.482889] msm_hsusb_host f9a55000.ehci: unable to find transceiver > > [1.488762] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe > > [1.501689] l20: supplied by vreg-boost-bypass > > [1.503694] s3: operation not allowed > > [1.505072] mmc0: Switching to 3.3V signalling voltage failed > > [1.545275] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] > using ADMA > [1.545615] msm_otg f9a55000.usb-phy: failed to get phandle in > /soc/usb-phy@f9a55000 node > [1.551749] TRB: registering notifier for ext_id > > [1.559835] TRB: motg=ed893e10, id=ed893f3c, nb=ed893f3c > > [1.564578] msm_otg f9a55000.usb-phy: OTG regs = f0132000 > > [1.569985] l24: supplied by vreg-boost-bypass > > [1.575342] l6: supplied by s2 > > [1.579737] l6: operation not allowed > > [1.582458] l24: operation not allowed > > [1.586229] reg (HPM) > > [1.608277] mmc0: MAN_BKOPS_EN bit is not set > > [1.615708] mmc0: new HS200 MMC card at address 0001 > > [1.616252] mmcblk0: mmc0:0001 SEM16G 14.6 GiB > > [1.619888] mmcblk0boot0: mmc0:0001 SEM16G partition 1 4.00 MiB > > [1.624128] mmcblk0boot1: mmc0:0001 SEM16G partition 2 4.00 MiB > > [1.630063] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 4.00 MiB > > [1.638255] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 > p16 p17 p18 p19 p20 > [1.695676] msm_hsusb_host f9a55000.ehci: ehci_msm proble > > [1.695749] msm_otg f9a55000.usb-phy: Host mode is not supported > > [1.700054] msm_hsusb_host f9a55000.ehci: unable to register with > transceiver > [1.706184] msm_otg f9a55000.usb-phy: OTG runtime idle > > [1.713500] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe > > [1.718267] f9a55000.usb-controller sup
BUG: usb: phy: msm: problem with EPROBE defer and extcon cleanup
Ivan, I'm seeing a bug in the phy-msm-usb.c code, when I get an EPROBE defer during probing the driver. The code is statically linked in the kernel, and the dts for my board is specifying an extcon phandle for the ID pin. Below is a fragment of the kernel output for a boot of this code. Messages prefixed with TRB are my own debug printks. Note that the notifier block (at ee23513c) that gets registered with extcon before the first probe failure, ultimately gets used during an ID pin event (status change) by raw_notifier_call_chain(). This notifier block should be unregistered if the probe fails, so that only the second one registered is on the call chain. Let me know if you plan to work on this. I'm otherwise occupied the remainder of this week, so won't have time to work on it, but I can probably get to it early next week if you don't. Regards, -- Tim [1.435543] NET: Registered protocol family 17 [1.439773] Key type dns_resolver registered [1.444041] Registering SWP/SWPB emulation handler [1.451259] msm_otg f9a55000.usb-phy: failed to get phandle in /soc/usb-phy@f9a55000 node [1.452915] TRB: registering notifier for ext_id [1.464681] TRB: motg=ee235010, id=ee23513c, nb=ee23513c [1.465957] msm_otg f9a55000.usb-phy: OTG regs = f011e000 [1.471532] msm_otg f9a55000.usb-phy: Failed to get supply 'v3p3': -517 [1.477416] msm_hsusb_host f9a55000.ehci: ehci_msm proble [1.482889] msm_hsusb_host f9a55000.ehci: unable to find transceiver [1.488762] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe [1.501689] l20: supplied by vreg-boost-bypass [1.503694] s3: operation not allowed [1.505072] mmc0: Switching to 3.3V signalling voltage failed [1.545275] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] using ADMA [1.545615] msm_otg f9a55000.usb-phy: failed to get phandle in /soc/usb-phy@f9a55000 node [1.551749] TRB: registering notifier for ext_id [1.559835] TRB: motg=ed893e10, id=ed893f3c, nb=ed893f3c [1.564578] msm_otg f9a55000.usb-phy: OTG regs = f0132000 [1.569985] l24: supplied by vreg-boost-bypass [1.575342] l6: supplied by s2 [1.579737] l6: operation not allowed [1.582458] l24: operation not allowed [1.586229] reg (HPM) [1.608277] mmc0: MAN_BKOPS_EN bit is not set [1.615708] mmc0: new HS200 MMC card at address 0001 [1.616252] mmcblk0: mmc0:0001 SEM16G 14.6 GiB [1.619888] mmcblk0boot0: mmc0:0001 SEM16G partition 1 4.00 MiB [1.624128] mmcblk0boot1: mmc0:0001 SEM16G partition 2 4.00 MiB [1.630063] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 4.00 MiB [1.638255] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 [1.695676] msm_hsusb_host f9a55000.ehci: ehci_msm proble [1.695749] msm_otg f9a55000.usb-phy: Host mode is not supported [1.700054] msm_hsusb_host f9a55000.ehci: unable to register with transceiver [1.706184] msm_otg f9a55000.usb-phy: OTG runtime idle [1.713500] msm_hsusb f9a55000.usb-controller: ci_hdrc_msm_probe [1.718267] f9a55000.usb-controller supply vbus not found, using dummy regulator [1.724762] TRB: in ci_hdrc_probe [1.731807] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, revision: 10, lpm: 0; cap: f013a100 op: f013a140 [1.737561] ci_hd
Re: [PATCH 0/2] USB: option/usb_wwan: silence errors on disconnect
On Mon, Aug 17, 2015 at 09:04:37AM -0700, Greg Kroah-Hartman wrote: > On Mon, Aug 17, 2015 at 05:35:22PM +0200, Johan Hovold wrote: > > These patches prevent URB status and resubmission errors from being > > reported when an in-use device is being disconnected. > > These looks good to me, want me to add them to the patches you sent the > pull request for so we can get them into 4.3-rc1? That'd be great, thanks. I have a couple of device id patches queued up as well. I'll just send them on to you tomorrow. 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 1/2] USB: symbolserial: Use usb_get_serial_port_data
On Mon, Aug 17, 2015 at 09:06:15AM -0700, Greg Kroah-Hartman wrote: > On Mon, Aug 17, 2015 at 05:31:46PM +0200, Philipp Hachtmann wrote: > > The driver used usb_get_serial_data(port->serial) which compiled but > > resulted > > in a NULL pointer being returned (and subsequently used). I did not go > > deeper > > into this but I guess this is a regression. > > > > Signed-off-by: Philipp Hachtmann > > --- > > drivers/usb/serial/symbolserial.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > Doh, obviously no one has used this driver in a long time, thanks for > these patches... Wow... > Johan, mind if I take these directly? Please do. This one should be tagged: Fixes: a85796ee5149 ("USB: symbolserial: move private-data allocation to port_probe") Cc: stable # v3.10 And for both patches: Acked-by: Johan Hovold 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] usb: dwc3: pci: passing forward the ACPI companion
On Mon, Aug 17, 2015 at 10:26:53AM -0700, David Cohen wrote: > On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote: > > On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote: > > > Sharing the APCI companion with the core platforms device so > > > > ACPI :-) > > > > > it has access to all DWC3's resources. > > > > and which resources are these ? and why can't they be abstrated out in > > dwc3-pci ? > > I could think about USB phy devices on legacy BYT-CR products. But since > we got Heikki's ULPI bus we are able to move ACPI companion to their own > phy device on future. we need a better commit log explaining why this is really needed. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/3] gadget: Introduce the usb charger framework
On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote: > On 14 August 2015 at 23:27, Greg KH wrote: > > On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License as published by > >> + * the Free Software Foundation; either version 2 of the License, or > >> + * (at your option) any later version. > > I have to ask, do you really mean "any later version"? > I think I did not get your point, could you explain it detailedly? Unlike a lot of userspace projects the kernel is normally just licensed under GPLv2 without the option to relicense with a later version so the "...or any later version" is a bit unusual. There is some controversy about some of the changes in GPLv3. signature.asc Description: Digital signature
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: > > + 1500, > > + 1800, > > + 550, > > +}; > Why 550 is the last, but not 1800? You'd have to ask the hardware engineers who designed the chip. I suspect it's because 550 was added at a late stage in the design process but I'm basically just guessing there. > > */ > > @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device > > *pdev) > > } > > } > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) { > Where the wm831x_pdata->usb_gadget is initialized? It's platform data, it will be initialised by whatever registers the platform data. signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: pci: passing forward the ACPI companion
On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote: > On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote: > > Sharing the APCI companion with the core platforms device so > > ACPI :-) > > > it has access to all DWC3's resources. > > and which resources are these ? and why can't they be abstrated out in > dwc3-pci ? I could think about USB phy devices on legacy BYT-CR products. But since we got Heikki's ULPI bus we are able to move ACPI companion to their own phy device on future. BR, David -- 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 v9 1/7] usb: interface authorization: Declare authorized attribute
On Sat, Aug 08, 2015 at 11:32:50AM +0200, Stefan Koch wrote: > The attribute authorized shows the authorization state for an interface. > > Signed-off-by: Stefan Koch This email bounces, so I have to rip this series out of the tree :( Please resend this with a working email for a signed-off-by line. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: external USB-Speaker and "Not enough bandwidth for altsetting 1"
Am 2015-08-04 um 08:14 schrieb Clemens Ladisch: Alan Stern wrote: On Sun, 2 Aug 2015, Jakob Schürz wrote: P: Vendor=138a ProdID=003f Rev= 1.04 Do you happen to know what this device is? usb.ids says Validity Sensors VFS495 Fingerprint Reader. Yes it's true. But I don't use this Finger-Print-Reader. (Even it doesn't work for me...) Does it make any difference if you remove the Bluetooth radio and the HP webcam? They compete for bandwidth on the same bus as the AC209N speakers. In theory there should be plenty of bandwidth for all these devices to run at the same time. All these devices have (small) interrupt endpoints for some kind of status reporting. It might be possible that the sheer number of periodically scheduled transactions overflows some limit in the firmware or driver. Sounds bad... :-( Jakob Schürz -- 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-serial updates for v4.3-rc1
On Mon, Aug 17, 2015 at 12:00:42PM +0200, Johan Hovold wrote: > Hi Greg, > > Here are my updates for v4.3-rc1. All have been in linux-next for some > time. > > Thanks, > Johan > > > The following changes since commit 52721d9d3334c1cb1f76219a161084094ec634dc: > > Linux 4.2-rc3 (2015-07-19 14:45:02 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.3-rc1 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: symbolserial: Use usb_get_serial_port_data
On Mon, Aug 17, 2015 at 05:31:46PM +0200, Philipp Hachtmann wrote: > The driver used usb_get_serial_data(port->serial) which compiled but resulted > in a NULL pointer being returned (and subsequently used). I did not go deeper > into this but I guess this is a regression. > > Signed-off-by: Philipp Hachtmann > --- > drivers/usb/serial/symbolserial.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Doh, obviously no one has used this driver in a long time, thanks for these patches... Johan, mind if I take these directly? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] USB: option/usb_wwan: silence errors on disconnect
On Mon, Aug 17, 2015 at 05:35:22PM +0200, Johan Hovold wrote: > These patches prevent URB status and resubmission errors from being > reported when an in-use device is being disconnected. These looks good to me, want me to add them to the patches you sent the pull request for so we can get them into 4.3-rc1? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stack dump when try to store uframe_periodic_max
On Mon, 17 Aug 2015, Peter Zijlstra wrote: > On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: > > On Mon, 17 Aug 2015, Peter Chen wrote: > > > > > Hi Alan, > > > > > > When run "echo 105 > > > > /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max", > > > if lockdep check is enabled, there is below dump, I am afraid it can't > > > find how to fix it, the warning shows the key is not persistent. > > > (see line 757, kernel/locking/lockdep.c). > > > > > > > > > [ 70.190430] INFO: trying to register non-static key. > > > [ 70.195437] the code is fine but needs lockdep annotation. > > > [ 70.200939] turning off the locking correctness validator. > > > I don't understand this either. > > > > Maybe Peter Z. can help. This dump is triggered by the > > spin_lock_irqsave() call in > > drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That > > function doesn't appear to be unusual in any way. > > Can it happen this code is called before a corresponding > spin_lock_init()? No; the spinlock gets initialized in ehci_init() long before the sysfs file is registered. > Alternatively, memory corruption is an option. If something stomped on > the lockdep state you can trigger this I suppose. Can you suggest any particular debugging printk for Peter C. to try? 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
[PATCH 0/2] USB: symbolserial: Fix OOPS (regression) and data length
I bought a Symbol DS3508 2D imager barcode scanner, configured it to behave as "simple COM port", and my machine OOPSed immediately. The result are the two attached patches. The first one is actually needed to get the whole thing again without that nasty NULL pointer dereference. The second patch makes the driver exclude useless zero bytes from the payload data. I assume this could lead to discussions because I found (and removed) a comment that says that the driver will send all data from the urb buffer to the tty layer without taking the communicated length (from the scanner, in the first byte of a buffer) into account. For your amusement here's what happened to my machine before writing the first patch: [ 3801.712295] usb 6-2: new full-speed USB device number 12 using uhci_hcd [ 3801.883708] usb 6-2: New USB device found, idVendor=05e0, idProduct=0600 [ 3801.883712] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3801.883714] usb 6-2: Product: Symbol Bar Code Scanner [ 3801.883716] usb 6-2: Manufacturer: Symbol Technologies, Inc, 2008 [ 3801.883718] usb 6-2: SerialNumber: S/N:5520B838ED22C34CBC619E74103732B8 Rev:PAAALS00-002-R01- [ 3801.889804] symbolserial 6-2:1.0: symbol converter detected [ 3801.889962] usb 6-2: symbol converter now attached to ttyUSB0 [ 3801.896738] BUG: unable to handle kernel NULL pointer dereference at (null) [ 3801.896741] IP: [] _raw_spin_lock_irqsave+0xb/0x30 [ 3801.896746] PGD 61fb5b067 PUD 6208dd067 PMD 0 [ 3801.896748] Oops: 0002 [#1] SMP [ 3801.896749] Modules linked in: nvidia(O) [ 3801.896751] CPU: 7 PID: 8640 Comm: ModemManager Tainted: G O 4.2.0-rc7 #27 [ 3801.896752] Hardware name: System manufacturer System Product Name/P6T WS PRO, BIOS 120409/16/2010 [ 3801.896753] task: 88061daaba80 ti: 8800ba608000 task.ti: 8800ba608000 [ 3801.896754] RIP: 0010:[] [] _raw_spin_lock_irqsave+0xb/0x30 [ 3801.896756] RSP: 0018:8800ba60bba8 EFLAGS: 00010046 [ 3801.896757] RAX: RBX: 0296 RCX: 8806220b4800 [ 3801.896757] RDX: 0001 RSI: 8806220b4800 RDI: [ 3801.896758] RBP: 8806220b4800 R08: 0001 R09: c94d6000 [ 3801.896759] R10: 3000 R11: c94d5fff R12: 880623832780 [ 3801.896759] R13: 880591b09000 R14: 880591b09000 R15: 88061daaba80 [ 3801.896760] FS: 7fc35e569840() GS:88063fce() knlGS: [ 3801.896761] CS: 0010 DS: ES: CR0: 80050033 [ 3801.896762] CR2: CR3: 00061df01000 CR4: 06e0 [ 3801.896762] Stack: [ 3801.896763] 8153267b 8806243dd0a8 8806220b4808 [ 3801.896764] 8806238327e8 81511cc6 880591b09000 813c4b2e [ 3801.896765] 880591b09000 8806220b4808 880591b09000 8806220b4918 [ 3801.896766] Call Trace: [ 3801.896769] [] ? symbol_open+0x1b/0x70 [ 3801.896772] [] ? serial_port_activate+0x56/0x90 [ 3801.896775] [] ? tty_port_tty_set+0x2e/0x90 [ 3801.896776] [] ? tty_port_open+0x76/0xc0 [ 3801.896778] [] ? tty_init_dev+0x8f/0x1a0 [ 3801.896779] [] ? tty_open+0xf5/0x5a0 [ 3801.896782] [] ? mount_fs+0x160/0x160 [ 3801.896784] [] ? chrdev_open+0x9c/0x170 [ 3801.896785] [] ? cdev_put+0x20/0x20 [ 3801.896786] [] ? do_dentry_open+0x1c0/0x2f0 [ 3801.896788] [] ? path_openat+0x380/0x1030 [ 3801.896789] [] ? terminate_walk+0xa2/0xb0 [ 3801.896790] [] ? do_filp_open+0x70/0xd0 [ 3801.896792] [] ? __alloc_fd+0x37/0x100 [ 3801.896794] [] ? do_sys_open+0x11e/0x200 [ 3801.896795] [] ? entry_SYSCALL_64_fastpath+0x12/0x6a [ 3801.896795] Code: 31 c0 ba 01 00 00 00 f0 0f b1 17 85 c0 75 02 f3 c3 89 c6 e9 68 6d 91 ff 0f 1f 84 00 00 00 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 0f b1 17 85 c0 75 05 48 89 d8 5b c3 89 c6 e8 41 6d 91 ff 48 [ 3801.896809] RIP [] _raw_spin_lock_irqsave+0xb/0x30 [ 3801.896811] RSP [ 3801.896812] CR2: [ 3801.896813] ---[ end trace 196415182e1cd411 ]--- Philipp Hachtmann (2): USB: symbolserial: Use usb_get_serial_port_data USB: symbolserial: Correct transferred data size drivers/usb/serial/symbolserial.c | 24 +++- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.1.4 -- 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: symbolserial: Use usb_get_serial_port_data
The driver used usb_get_serial_data(port->serial) which compiled but resulted in a NULL pointer being returned (and subsequently used). I did not go deeper into this but I guess this is a regression. Signed-off-by: Philipp Hachtmann --- drivers/usb/serial/symbolserial.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/serial/symbolserial.c b/drivers/usb/serial/symbolserial.c index 8fceec7..6ed8044 100644 --- a/drivers/usb/serial/symbolserial.c +++ b/drivers/usb/serial/symbolserial.c @@ -94,7 +94,7 @@ exit: static int symbol_open(struct tty_struct *tty, struct usb_serial_port *port) { - struct symbol_private *priv = usb_get_serial_data(port->serial); + struct symbol_private *priv = usb_get_serial_port_data(port); unsigned long flags; int result = 0; @@ -120,7 +120,7 @@ static void symbol_close(struct usb_serial_port *port) static void symbol_throttle(struct tty_struct *tty) { struct usb_serial_port *port = tty->driver_data; - struct symbol_private *priv = usb_get_serial_data(port->serial); + struct symbol_private *priv = usb_get_serial_port_data(port); spin_lock_irq(&priv->lock); priv->throttled = true; @@ -130,7 +130,7 @@ static void symbol_throttle(struct tty_struct *tty) static void symbol_unthrottle(struct tty_struct *tty) { struct usb_serial_port *port = tty->driver_data; - struct symbol_private *priv = usb_get_serial_data(port->serial); + struct symbol_private *priv = usb_get_serial_port_data(port); int result; bool was_throttled; -- 2.1.4 -- 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/2] USB: symbolserial: Correct transferred data size
The scanner (here DS3508) always returns 64 bytes per urb buffer. The first byte indicates the data length used in the current buffer. There even was a comment describing this. But the comment also said that we'll send everything in the buffer to the tty layer. That means sending the actual barcode data and lots of trailing zeroes. This patch lets the driver only send the real data. Signed-off-by: Philipp Hachtmann --- drivers/usb/serial/symbolserial.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/usb/serial/symbolserial.c b/drivers/usb/serial/symbolserial.c index 6ed8044..37f3ad1 100644 --- a/drivers/usb/serial/symbolserial.c +++ b/drivers/usb/serial/symbolserial.c @@ -60,17 +60,15 @@ static void symbol_int_callback(struct urb *urb) usb_serial_debug_data(&port->dev, __func__, urb->actual_length, data); + /* +* Data from the device comes with a 1 byte header: +* +* ... +*/ if (urb->actual_length > 1) { - data_length = urb->actual_length - 1; - - /* -* Data from the device comes with a 1 byte header: -* -* data... -* This is real data to be sent to the tty layer -* we pretty much just ignore the size and send everything -* else to the tty layer. -*/ + data_length = data[0]; + if (data_length > (urb->actual_length - 1)) + data_length = urb->actual_length - 1; tty_insert_flip_string(&port->port, &data[1], data_length); tty_flip_buffer_push(&port->port); } else { -- 2.1.4 -- 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/2] USB: usb_wwan: silence read errors on disconnect
Silence read-urb resubmission errors when the device is going away. Signed-off-by: Johan Hovold --- drivers/usb/serial/usb_wwan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c index 2f805cb386a5..825305cb71d9 100644 --- a/drivers/usb/serial/usb_wwan.c +++ b/drivers/usb/serial/usb_wwan.c @@ -282,7 +282,7 @@ static void usb_wwan_indat_callback(struct urb *urb) /* Resubmit urb so we continue receiving */ err = usb_submit_urb(urb, GFP_ATOMIC); if (err) { - if (err != -EPERM) { + if (err != -EPERM && err != -ENODEV) { dev_err(dev, "%s: resubmit read urb failed. (%d)\n", __func__, err); /* busy also in error unless we are killed */ -- 2.4.6 -- 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: option: silence interrupt errors
Avoid spamming the logs (e.g. with -EPROTO errors) when attempting to resubmit the interrupt urb while a disconnect of an in-use device is being processed. Signed-off-by: Johan Hovold --- drivers/usb/serial/option.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 983c911b3986..3992f7709b70 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1942,7 +1942,7 @@ static void option_instat_callback(struct urb *urb) } else if (status == -ENOENT || status == -ESHUTDOWN) { dev_dbg(dev, "%s: urb stopped: %d\n", __func__, status); } else - dev_err(dev, "%s: error %d\n", __func__, status); + dev_dbg(dev, "%s: error %d\n", __func__, status); /* Resubmit urb so we continue receiving IRQ data */ if (status != -ESHUTDOWN && status != -ENOENT) { -- 2.4.6 -- 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/2] USB: option/usb_wwan: silence errors on disconnect
These patches prevent URB status and resubmission errors from being reported when an in-use device is being disconnected. Johan Johan Hovold (2): USB: option: silence interrupt errors USB: usb_wwan: silence read errors on disconnect drivers/usb/serial/option.c | 2 +- drivers/usb/serial/usb_wwan.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.4.6 -- 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: option driver crashes on modem removal
On Tue, Aug 11, 2015 at 12:31:47PM +0200, Yegor Yefremov wrote: > On Tue, Aug 11, 2015 at 11:58 AM, Bjørn Mork wrote: > > [replaced 'netdev' with 'linux-usb' as this concerns a USB serial driver > > only] > > > > Yegor Yefremov writes: > > > >> I have following problem. When removing USB dongle 07d1:3e01 or > >> SierraWireless MC7304 I get following messages: > >> > >> option1 ttyUSB10: option_instat_callback: error -71 > >> option1 ttyUSB9: option_instat_callback: error -71 > >> option1 ttyUSB10: option_instat_callback: error -71 > >> option1 ttyUSB9: option_instat_callback: error -71 > >> option1 ttyUSB10: option_instat_callback: error -71 > >> option1 ttyUSB9: option_instat_callback: error -71 > >> INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0, > >> t=2102 jiffies, g=694, c=693, q=24) > >> INFO: Stall ended before state dump start > >> option1 ttyUSB10: option_instat_callback: error -71 > >> > >> drivers/usb/serial/option.c seems to make nothing with such a status > >> and just prints error. How one would handle this properly and just > >> unregister device? Do you need more info? > >> > >> Tested kernels: 3.18.20 and 4.2.0-rc5 (this kernel shows only RCU stall > >> crash) > >> Hardware: TI am335x > > > > > > Isn't the device unregistered? What else can be done here? > > The problem is, that the system is dead (stall). It only prints > "option1 ttyUSB10: option_instat_callback: error -71" endlessly > (kernel 3.18.20) and console shows no reaction for input. And when you > start watchdog from userspace the systems reboots after specified > timeout (watchdog -t 5 -T 10 /dev/watchdog). Related issues have been reported with musb (BeagleBone Black) and dwc controllers (RPi) when using an external hub. The exact reasons have not yet been fully determined, including whether it is the hub driver that is prevented from processing the event or if the disconnect event is never received at all. See for example: https://lkml.kernel.org/r/20150409171314.GA30002@localhost In the cases I've seen, changing the timing slightly was enough to make the problem go away. Specifically, avoiding a large, unnecessary memcpy or silencing an error message was sufficient. This obviously does not solve the underlying issue, but could you try the below patch nonetheless? We don't want these error messages for the "valid" use case of removing an in-use device anyway. Thanks, Johan >From 81913b6a91bd53b4f00455618c141c35148acbfc Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Mon, 17 Aug 2015 16:48:47 +0200 Subject: [PATCH] USB: option: silence interrupt errors Avoid spamming the logs (e.g. with -EPROTO errors) when attempting to resubmit the interrupt urb while a disconnect of an in-use device is being processed. Signed-off-by: Johan Hovold --- drivers/usb/serial/option.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 983c911b3986..3992f7709b70 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1942,7 +1942,7 @@ static void option_instat_callback(struct urb *urb) } else if (status == -ENOENT || status == -ESHUTDOWN) { dev_dbg(dev, "%s: urb stopped: %d\n", __func__, status); } else - dev_err(dev, "%s: error %d\n", __func__, status); + dev_dbg(dev, "%s: error %d\n", __func__, status); /* Resubmit urb so we continue receiving IRQ data */ if (status != -ESHUTDOWN && status != -ENOENT) { -- 2.4.6 -- 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: Stack dump when try to store uframe_periodic_max
On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: > On Mon, 17 Aug 2015, Peter Chen wrote: > > > Hi Alan, > > > > When run "echo 105 > > > /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max", > > if lockdep check is enabled, there is below dump, I am afraid it can't > > find how to fix it, the warning shows the key is not persistent. > > (see line 757, kernel/locking/lockdep.c). > > > > > > [ 70.190430] INFO: trying to register non-static key. > > [ 70.195437] the code is fine but needs lockdep annotation. > > [ 70.200939] turning off the locking correctness validator. > I don't understand this either. > > Maybe Peter Z. can help. This dump is triggered by the > spin_lock_irqsave() call in > drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That > function doesn't appear to be unusual in any way. Can it happen this code is called before a corresponding spin_lock_init()? Alternatively, memory corruption is an option. If something stomped on the lockdep state you can trigger this I suppose. -- 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: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework
On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote: > On 14 August 2015 at 23:27, Greg KH wrote: >> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >> >> I have to ask, do you really mean "any later version"? >> > > I think I did not get your point, could you explain it detailedly? The full kernel is licensed under v2 of the GPL only, not "any later version". See the second paragraph at the top of the COPYING file in the root directory of the kernel source tree. There are differences on individual files, but having this file allow "any later version" makes it different from much of rest of the kernel. Unless you have a specific reason to allow greater-than-V2 GPL licensing on this file, you should change the licensing clause. The following wording appears to be pretty popular: * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. -- Tim -- 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] xhci: mediatek: support MTK xHCI host controller
Hi On 07.08.2015 15:30, Chunfeng Yun wrote: MTK xhci host controller defines some extra SW scheduling parameters for HW to minimize the scheduling effort for synchronous and interrupt endpoints. The parameters are put into reseved DWs of slot context and endpoint context ... + * The TD size is the number of max packet sized packets remaining in the TD + * (including this TRB), right shifted by 10. + * It must fit in bits 21:17, so it can't be bigger than 31. + */ +u32 xhci_mtk_td_remainder_quirk(unsigned int td_running_total, + unsigned trb_buffer_length, struct urb *urb) +{ + u32 max = 31; + int remainder, td_packet_count, packet_transferred; + unsigned int td_transfer_size = urb->transfer_buffer_length; + unsigned int maxp; + + maxp = GET_MAX_PACKET(usb_endpoint_maxp(&urb->ep->desc)); + + /* 0 for the last TRB */ + if (td_running_total + trb_buffer_length == td_transfer_size) + return 0; + + packet_transferred = td_running_total / maxp; + td_packet_count = DIV_ROUND_UP(td_transfer_size, maxp); + remainder = td_packet_count - packet_transferred; + + if (remainder > max) + return max << 17; + else + return remainder << 17; +} I started looking at this xhci_mtk_td_remainder() function, one of the places this patch touches the existing xhci code. The remainder functions in xhci are already bit too messy, and adding one more function which does almost the same thing makes it even messier. For example queuing a bulk transfer will end up like this: /* Set the TRB length, TD size, and interrupter fields. */ if (xhci->hci_version < 0x100) { - remainder = xhci_td_remainder( + if (xhci->quirks & XHCI_MTK_HOST) { + remainder = xhci_mtk_td_remainder_quirk( + running_total, trb_buff_len, urb); + } else { + remainder = xhci_td_remainder( urb->transfer_buffer_length - running_total); + } } else { remainder = xhci_v1_0_td_remainder(running_total, trb_buff_len, total_packet_count, urb, and similar for isoc and control transfers. I'll see if I can simplify the existing remainder calculations into one function, then it should be enough to just add something like this into it: if (xhci->quirks & XHCI_MTK_HOST) trb_buff_len = 0; This way we can skip all the extra hassle that comes with a new exported quirk function Is the Mediatek xhci really a xHCI 0.96 or older controller? (hci_version < 0x100) Not a xHCI 1.0 or 1.1 ? -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: Stack dump when try to store uframe_periodic_max
On Mon, 17 Aug 2015, Peter Chen wrote: > Hi Alan, > > When run "echo 105 > > /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max", > if lockdep check is enabled, there is below dump, I am afraid it can't > find how to fix it, the warning shows the key is not persistent. > (see line 757, kernel/locking/lockdep.c). > > > [ 70.190430] INFO: trying to register non-static key. > [ 70.195437] the code is fine but needs lockdep annotation. > [ 70.200939] turning off the locking correctness validator. > [ 70.206455] CPU: 0 PID: 752 Comm: sh Not tainted > 4.2.0-rc6-00030-g91b123e-dirty #475 > [ 70.214216] Hardware name: Freescale i.MX6 SoloX (Device Tree) > [ 70.220064] Backtrace: > [ 70.222585] [<800142e4>] (dump_backtrace) from [<800144d8>] > (show_stack+0x18/0x1c) > [ 70.230176] r6:80b39960 r5: r4: r3: > [ 70.235965] [<800144c0>] (show_stack) from [<807d2d58>] > (dump_stack+0x8c/0xa4) > [ 70.243231] [<807d2ccc>] (dump_stack) from [<8006e184>] > (__lock_acquire+0x1d24/0x1ecc) > [ 70.251164] r6: r5: r4:80cc3188 r3:0001 > [ 70.256947] [<8006c460>] (__lock_acquire) from [<8006ec04>] > (lock_acquire+0x74/0x94) > [ 70.264706] r10:bcf73f80 r9:bd7d290c r8:bbd5fe80 r7:0001 r6:804cc2ec > r5:60010093 > [ 70.272669] r4: > [ 70.275254] [<8006eb90>] (lock_acquire) from [<807dc618>] > (_raw_spin_lock_irqsave+0x48/0x5c) > [ 70.283707] r7:bdbba010 r6:804cc2ec r5:80010013 r4:bdbba28c > [ 70.289494] [<807dc5d0>] (_raw_spin_lock_irqsave) from [<804cc2ec>] > (store_uframe_periodic_max+0x4c/0x12c) > [ 70.299164] r6:bbd5fe80 r5:bdbba28c r4:0004 > [ 70.303881] [<804cc2a0>] (store_uframe_periodic_max) from [<803dae98>] > (dev_attr_store+0x20/0x2c) > [ 70.312768] r7: r6:bbd5fe80 r5:bd7d2900 r4:0004 > [ 70.318549] [<803dae78>] (dev_attr_store) from [<80172d24>] > (sysfs_kf_write+0x54/0x58) > [ 70.326494] [<80172cd0>] (sysfs_kf_write) from [<80171f10>] > (kernfs_fop_write+0xc4/0x1a8) > [ 70.334686] r6: r5:0004 r4:bd7d2900 r3:80172cd0 > [ 70.340471] [<80171e4c>] (kernfs_fop_write) from [<80103f44>] > (__vfs_write+0x2c/0xe0) > [ 70.348316] r10: r9:bcf72000 r8:80010844 r7:bcf73f80 r6:0169d408 > r5:bcf73f80 > [ 70.356278] r4:bcdad500 > [ 70.358863] [<80103f18>] (__vfs_write) from [<801047e8>] > (vfs_write+0x98/0x16c) > [ 70.366187] r8:80010844 r7:bcf73f80 r6:0169d408 r5:0004 r4:bcdad500 > [ 70.373029] [<80104750>] (vfs_write) from [<80105064>] > (SyS_write+0x4c/0xa8) > [ 70.380092] r8:80010844 r7:0169d408 r6:0004 r5:bcdad500 r4:bcdad500 > [ 70.386941] [<80105018>] (SyS_write) from [<80010660>] > (ret_fast_syscall+0x0/0x54) > [ 70.394525] r7:0004 r6:76f95b48 r5:0169d408 r4:0004 > [ 70.400307] ci_hdrc ci_hdrc.1: setting max periodic bandwidth to 84% (== > 105 usec/uframe) > [ 70.408507] ci_hdrc ci_hdrc.1: max periodic bandwidth set is non-standard I don't understand this either. Maybe Peter Z. can help. This dump is triggered by the spin_lock_irqsave() call in drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That function doesn't appear to be unusual in any way. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: host: ehci-sys: delete useless bus_to_hcd conversion
On Mon, 17 Aug 2015, Peter Chen wrote: > The ehci platform device's drvdata is the pointer of struct usb_hcd > already, so we doesn't need to call bus_to_hcd conversion again. > > Cc: > Signed-off-by: Peter Chen > --- > drivers/usb/host/ehci-sysfs.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/host/ehci-sysfs.c b/drivers/usb/host/ehci-sysfs.c > index 5e44407..5216f2b 100644 > --- a/drivers/usb/host/ehci-sysfs.c > +++ b/drivers/usb/host/ehci-sysfs.c > @@ -29,7 +29,7 @@ static ssize_t show_companion(struct device *dev, > int count = PAGE_SIZE; > char*ptr = buf; > > - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev))); > + ehci = hcd_to_ehci(dev_get_drvdata(dev)); > nports = HCS_N_PORTS(ehci->hcs_params); > > for (index = 0; index < nports; ++index) { > @@ -54,7 +54,7 @@ static ssize_t store_companion(struct device *dev, > struct ehci_hcd *ehci; > int portnum, new_owner; > > - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev))); > + ehci = hcd_to_ehci(dev_get_drvdata(dev)); > new_owner = PORT_OWNER; /* Owned by companion */ > if (sscanf(buf, "%d", &portnum) != 1) > return -EINVAL; > @@ -85,7 +85,7 @@ static ssize_t show_uframe_periodic_max(struct device *dev, > struct ehci_hcd *ehci; > int n; > > - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev))); > + ehci = hcd_to_ehci(dev_get_drvdata(dev)); > n = scnprintf(buf, PAGE_SIZE, "%d\n", ehci->uframe_periodic_max); > return n; > } > @@ -101,7 +101,7 @@ static ssize_t store_uframe_periodic_max(struct device > *dev, > unsigned long flags; > ssize_t ret; > > - ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev))); > + ehci = hcd_to_ehci(dev_get_drvdata(dev)); > if (kstrtouint(buf, 0, &uframe_periodic_max) < 0) > return -EINVAL; Acked-by: Alan Stern This does indeed look like a strange mistake. It worked only because the embedded usb_bus structure lies at the start of the usb_hcd structure. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: reuse the platform_data to store the ci info
On Mon, 17 Aug 2015, Peter Chen wrote: > > That's not quite what I had in mind. I was thinking of something more > > like this: > > > > Platform device drvdata > struct usb_pointers > > | > > | > > |---|---| > > | | | > > gadget hcd otg > > > > where struct usb_pointers (maybe you can think of a better name) looks > > like this: > > > > struct usb_pointers { > > struct usb_hcd *hcd; > > struct usb_gadget *gadget; > > struct usb_otg *otg; > > }; > > > > If you want, you can use your IP Core device in place of my platform > > device. All that matters is that the parent device of the root hub > > (for hosts) or gadget (for peripherals) should store the address of a > > usb_pointers structure in its drvdata. > > > > I am wonder how you get hcd pointer at hcd core code? The platform > device drvdata is not hcd pointer any more, instead, it is platform > device private data. The platform device private data will now be a usb_pointers structure. The hcd core code will simply do: struct usb_pointers *usbptr = platform_get_drvdata(dev); hcd = usbptr->hcd; We can allocate some extra space at the end of the usb_pointers structure if the platform/glue driver wants to store additional data in there. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: pci: passing forward the ACPI companion
On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote: > Sharing the APCI companion with the core platforms device so ACPI :-) > it has access to all DWC3's resources. and which resources are these ? and why can't they be abstrated out in dwc3-pci ? > Signed-off-by: Heikki Krogerus > --- > drivers/usb/dwc3/dwc3-pci.c | 1 + > 1 file changed, 1 insertion(+) > > Hi, > > This depends on being able to prevent execution of ACPI power methods > more then once. Mika has made a patch for that: > https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=712e960f0ee9337f3473ba3de2bcfc7e87b7c5a4 > > > Thanks, > > diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c > index f626179..89eb364 100644 > --- a/drivers/usb/dwc3/dwc3-pci.c > +++ b/drivers/usb/dwc3/dwc3-pci.c > @@ -154,6 +154,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, > goto err; > > dwc3->dev.parent = dev; > + ACPI_COMPANION_SET(&dwc3->dev, ACPI_COMPANION(dev)); > > ret = platform_device_add(dwc3); > if (ret) { > -- > 2.5.0 > -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 0/3] Introduce usb charger framework to deal with the usb gadget power negotation
On 17 August 2015 at 16:20, Li Jun wrote: > On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote: >> On 17 August 2015 at 09:15, Li Jun wrote: >> > On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: >> >> On 14 August 2015 at 16:55, Li Jun wrote: >> >> > Hi Baolin, >> >> > >> >> > On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: >> >> >> Currently the Linux kernel does not provide any standard integration >> >> >> of this >> >> >> feature that integrates the USB subsystem with the system power >> >> >> regulation >> >> >> provided by PMICs meaning that either vendors must add this in their >> >> >> kernels >> >> >> or USB gadget devices based on Linux (such as mobile phones) may not >> >> >> behave >> >> >> as they should. >> >> >> >> >> >> Providing a standard framework for doing this in the kernel. >> >> >> >> >> > >> >> > Why not add power supply class support into this? >> >> > >> >> >> >> Hi Jun, >> >> >> >> We don't need the power supply class support into the usb charger, >> > I suppose usb charger is also a power supply for the system, we can use >> > power >> > supply class framework for notify mechanism and get/set many >> > attributes(maybe >> > also the current limit), I see those usb charger drivers under >> > ./driver/power/ >> > are designed with power supply supported. >> > >> >> I don't think so. The usb charger is rely on the usb gadget, which is >> not a complete power supply device and it combines the usb and the >> power supply. Thus we make it into usb gadget system. Thanks. >> > Why it cannot be a complete power supply device? I was thinking this > framework can cover it, I have no doubt on putting this framework > into gadget system, but still can't understand why we don't need > power supply class at all for a usb charger, or you think introduce > power supply into usb gadget is not a right direction from code structure > point view? > We just do not think the usb charger as a real device, which is only used to set the current limitation when the usb charger state is changed detecting by extcon device or usb gadget. So we just need one message to notify the power user to set the current limitation when uab charge is added or removed. I also agree with the power supply framework can cover it, but we don't need to implement it to be another power supply, cause there is a real device as the power supply to deal with the power issue in the system. Thanks. > Li Jun >> > Li Jun >> >> just introduce the notify mechanism for power to set the current limit >> >> when notifying some events from usb charger. Maybe I misunderstand >> >> your meanings, please describe it detailedly. Thanks for your >> >> comments. >> >> >> >> > Li Jun >> >> > >> >> >> >> >> >> >> >> -- >> >> Baolin.wang >> >> Best Regards >> >> >> >> -- >> Baolin.wang >> Best Regards -- Baolin.wang Best Regards -- 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: pci: passing forward the ACPI companion
Sharing the APCI companion with the core platforms device so it has access to all DWC3's resources. Signed-off-by: Heikki Krogerus --- drivers/usb/dwc3/dwc3-pci.c | 1 + 1 file changed, 1 insertion(+) Hi, This depends on being able to prevent execution of ACPI power methods more then once. Mika has made a patch for that: https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=712e960f0ee9337f3473ba3de2bcfc7e87b7c5a4 Thanks, diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index f626179..89eb364 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -154,6 +154,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, goto err; dwc3->dev.parent = dev; + ACPI_COMPANION_SET(&dwc3->dev, ACPI_COMPANION(dev)); ret = platform_device_add(dwc3); if (ret) { -- 2.5.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: [PATCH v2 8/9] usb: serial: mxuport: Simplify return statement
On Tue, Aug 04, 2015 at 02:04:35PM +, Karajgaonkar, Saurabh (S.) wrote: > From: Saurabh Karajgaonkar > > Replace redundant variable use in return statement. > > Signed-off-by: Saurabh Karajgaonkar > --- > drivers/usb/serial/mxuport.c | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c > index 460a406..31a8b47 100644 > --- a/drivers/usb/serial/mxuport.c > +++ b/drivers/usb/serial/mxuport.c > @@ -1137,13 +1137,9 @@ static int mxuport_port_probe(struct usb_serial_port > *port) > return err; > > /* Set interface (RS-232) */ > - err = mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE, > - MX_INT_RS232, > - port->port_number); > - if (err) > - return err; > - > - return 0; > + return mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE, > + MX_INT_RS232, > + port->port_number); I do not consider this an improvement as it makes the final ctrl-request call look different from the previous two without any real benefit. I'll drop this one. 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] usb: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module
On Sat, Aug 15, 2015 at 08:13:08PM -0400, David Ward wrote: > This is an HP-branded Sierra Wireless EM7355: > https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2 > > Signed-off-by: David Ward 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] USB: ftdi_sio: Added custom PID for CustomWare products
On Mon, Aug 03, 2015 at 08:15:40AM +0200, Matthijs Kooijman wrote: > Hi Lars, > > > What I meant is that ...FTDI_C. should come before ...FTDI_S > > and not after, but I've had a look at the whole ftdi_sio.c source > > now and it looks horrible. > > I think it doesn't really matter where you put your additions, do as > > others has done and put them at a random position.. > Yeah, I looked at that, the commits I looked at just added new stuff at > the end, and so did I :-) It's a good rule of thumb to try to keep the entries sorted, but yeah, it's not always possible. 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] USB: ftdi_sio: Added custom PID for CustomWare products
On Sun, Aug 02, 2015 at 02:00:00PM +0200, Matthijs Kooijman wrote: > CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex > products. > > Signed-off-by: Matthijs Kooijman 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 1/1] add-ZTE-pid
On Sun, Aug 02, 2015 at 08:41:48PM -0700, Liu.Zhao wrote: Make sure to always include a commit message. Also change you Subject (patch summary) to something more descriptive using the following format: USB: option: add ZTE PIDs > Signed-off-by: Liu.Zhao > --- > drivers/usb/serial/option.c | 29 + > 1 file changed, 29 insertions(+) > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > index f0c0c53..6996308 100644 > --- a/drivers/usb/serial/option.c > +++ b/drivers/usb/serial/option.c > @@ -285,6 +285,10 @@ static void option_instat_callback(struct urb *urb); > #define ZTE_PRODUCT_MC2718 0xffe8 > #define ZTE_PRODUCT_AD3812 0xffeb > #define ZTE_PRODUCT_MC2716 0xffed > +#define ZTE_PRODUCT_ZM8620_X 0x0396 > +#define ZTE_PRODUCT_ME3620_X 0x1432 > +#define ZTE_PRODUCT_ME3620_L 0x1433 > +#define ZTE_PRODUCT_ME3620_MBIM 0x0426 I already asked you to try to keep these sorted according to PID (e.g. add them sorted before ZTE_PRODUCT_AC2726). > > #define BENQ_VENDOR_ID 0x04a5 > #define BENQ_PRODUCT_H10 0x4068 > @@ -544,6 +548,23 @@ static const struct option_blacklist_info > zte_mc2716_z_blacklist = { > .sendsetup = BIT(1) | BIT(2) | BIT(3), > }; > > +static const struct option_blacklist_info zte_zm8620_x_blacklist = { > + .reserved = BIT(3) | BIT(4) | BIT(5), > +}; > + > +static const struct option_blacklist_info zte_me3620_x_blacklist = { > + .reserved = BIT(3) | BIT(4) | BIT(5), > +}; > + > +static const struct option_blacklist_info zte_me3620_l_blacklist = { > + .reserved = BIT(3) | BIT(4) | BIT(5), > +}; > + > +static const struct option_blacklist_info zte_me3620_mbim_blacklist = { > + .reserved = BIT(2) | BIT(3) | BIT(4), > +}; I also asked you to consider reusing the blacklist structs for related devices (e.g. zte_me3620_xl). Please keep these new structs sorted by symbol name as well. > + > + Remove the stray newline. > static const struct option_blacklist_info huawei_cdc12_blacklist = { > .reserved = BIT(1) | BIT(2), > }; > @@ -1592,6 +1613,14 @@ static const struct usb_device_id option_ids[] = { > { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) }, > { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) }, > { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) }, > + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X), > + .driver_info = (kernel_ulong_t)&zte_zm8620_x_blacklist }, > + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X), > + .driver_info = (kernel_ulong_t)&zte_me3620_x_blacklist }, > + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L), > + .driver_info = (kernel_ulong_t)&zte_me3620_l_blacklist }, > + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM), > + .driver_info = (kernel_ulong_t)&zte_me3620_mbim_blacklist }, And try to keep these entries sorted on symbol names as well (e.g. add them sorted after ZTE_PRODUCT_MC2716). > { USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) }, > { USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) }, Otherwise the patch is now on the right format. Could you fix up the above and resend? Please include a "[PATCH v3]"-prefix in you subject when resending. 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
Offerta di prestito tra individuo serio ed affidabile in Francia
Qui presento me signora Marie Anna French donna di affari che risiedono in Francia. Vengo da questo rende questa email fai parte di un'offerta di prestito finanziario che vanno da € 1000 a € 2.500.000 con una percentuale di restituzione dell'importo pari al 3% rimborsabile al momento il numero di anni sarebbe ma favore Se siete interessati a questa offerta di prestito si prega gentilmente di mettersi in contatto. Sarà seguito secondo le leggi francesi in vigore Si prega di mettersi in contatto se siete interessati a questa offerta di prestito all'indirizzo: marieanna...@yahoo.fr Mrs Marie Anna -- 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
Offerta di prestito tra individuo serio ed affidabile in Francia
Qui presento me signora Marie Anna French donna di affari che risiedono in Francia. Vengo da questo rende questa email fai parte di un'offerta di prestito finanziario che vanno da € 1000 a € 2.500.000 con una percentuale di restituzione dell'importo pari al 3% rimborsabile al momento il numero di anni sarebbe ma favore Se siete interessati a questa offerta di prestito si prega gentilmente di mettersi in contatto. Sarà seguito secondo le leggi francesi in vigore Si prega di mettersi in contatto se siete interessati a questa offerta di prestito all'indirizzo: marieanna...@yahoo.fr Mrs Marie Anna -- 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
[GIT PULL] USB-serial updates for v4.3-rc1
Hi Greg, Here are my updates for v4.3-rc1. All have been in linux-next for some time. Thanks, Johan The following changes since commit 52721d9d3334c1cb1f76219a161084094ec634dc: Linux 4.2-rc3 (2015-07-19 14:45:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.3-rc1 for you to fetch changes up to 26c78daade0fbeef7f20bae3c5508a7c571078cd: USB: io_ti: Add heartbeat to keep idle EP/416 ports from disconnecting (2015-07-31 12:09:57 +0200) USB-serial updates for v4.3-rc1 Here's a fix for a long-standing issue with the pl2303 divisor calculations that affects some non-standard baudrates that were enabled in v3.18. Adding support for newer Edgeport devices and firmware required changes to the io_ti driver and also exposed some issues with the driver's current firmware handling. Included is also a URL comment-typo fix. Signed-off-by: Johan Hovold Michał Pecio (1): USB: pl2303: fix baud-rate divisor calculations Nik Nyby (1): USB: serial: ftdi_sio: Fix broken URL in comment Peter E. Berger (4): USB: io_ti: Increase insufficient timeout for firmware downloads USB: io_ti: Fix firmware version handling USB: io_ti: Add firmware image sanity checks USB: io_ti: Add heartbeat to keep idle EP/416 ports from disconnecting drivers/usb/serial/ftdi_sio_ids.h | 2 +- drivers/usb/serial/io_ti.c| 279 +- drivers/usb/serial/pl2303.c | 35 +++-- 3 files changed, 240 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: misc: usbtest: format max packet size for iso transfer
The current code prints all wMaxPacketSize content at endpoint descriptor, if there is a high speed, high bandwidth endpoint, it may confuse the users, eg, if there are 3 transactions during microframe, it will print "wMaxPacket 1400" for packet content. This commit splits wMaxpacketSize and transaction numbers for output messages. Signed-off-by: Peter Chen --- drivers/usb/misc/usbtest.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index 0bbafe7..9517812 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -1925,10 +1925,11 @@ test_iso_queue(struct usbtest_dev *dev, struct usbtest_param *param, memset(urbs, 0, sizeof(urbs)); udev = testdev_to_usbdev(dev); dev_info(&dev->intf->dev, - "... iso period %d %sframes, wMaxPacket %04x\n", + "iso period %d %sframes, wMaxPacket %d, transactions: %d\n", 1 << (desc->bInterval - 1), (udev->speed == USB_SPEED_HIGH) ? "micro" : "", - usb_endpoint_maxp(desc)); + usb_endpoint_maxp(desc) & 0x7ff, + 1 + (0x3 & (usb_endpoint_maxp(desc) >> 11))); for (i = 0; i < param->sglen; i++) { urbs[i] = iso_alloc_urb(udev, pipe, desc, @@ -1942,7 +1943,7 @@ test_iso_queue(struct usbtest_dev *dev, struct usbtest_param *param, } packets *= param->iterations; dev_info(&dev->intf->dev, - "... total %lu msec (%lu packets)\n", + "total %lu msec (%lu packets)\n", (packets * (1 << (desc->bInterval - 1))) / ((udev->speed == USB_SPEED_HIGH) ? 8 : 1), packets); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Introduce usb charger framework to deal with the usb gadget power negotation
On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote: > On 17 August 2015 at 09:15, Li Jun wrote: > > On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: > >> On 14 August 2015 at 16:55, Li Jun wrote: > >> > Hi Baolin, > >> > > >> > On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: > >> >> Currently the Linux kernel does not provide any standard integration of > >> >> this > >> >> feature that integrates the USB subsystem with the system power > >> >> regulation > >> >> provided by PMICs meaning that either vendors must add this in their > >> >> kernels > >> >> or USB gadget devices based on Linux (such as mobile phones) may not > >> >> behave > >> >> as they should. > >> >> > >> >> Providing a standard framework for doing this in the kernel. > >> >> > >> > > >> > Why not add power supply class support into this? > >> > > >> > >> Hi Jun, > >> > >> We don't need the power supply class support into the usb charger, > > I suppose usb charger is also a power supply for the system, we can use > > power > > supply class framework for notify mechanism and get/set many > > attributes(maybe > > also the current limit), I see those usb charger drivers under > > ./driver/power/ > > are designed with power supply supported. > > > > I don't think so. The usb charger is rely on the usb gadget, which is > not a complete power supply device and it combines the usb and the > power supply. Thus we make it into usb gadget system. Thanks. > Why it cannot be a complete power supply device? I was thinking this framework can cover it, I have no doubt on putting this framework into gadget system, but still can't understand why we don't need power supply class at all for a usb charger, or you think introduce power supply into usb gadget is not a right direction from code structure point view? Li Jun > > Li Jun > >> just introduce the notify mechanism for power to set the current limit > >> when notifying some events from usb charger. Maybe I misunderstand > >> your meanings, please describe it detailedly. Thanks for your > >> comments. > >> > >> > Li Jun > >> > > >> > >> > >> > >> -- > >> Baolin.wang > >> Best Regards > > > > -- > Baolin.wang > Best Regards -- 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: Fwd: [Bug 102101] USB 3 storage device disconnects after S3 resume,and re-enumerate it.
Hi, all > https://bugzilla.kernel.org/show_bug.cgi?id=102101 > > Bug ID: 102101 >Summary: USB 3 storage device disconnects after S3 resume,and > re-enumerate it. I debug this problem ,and I find that when I suspend to ram (STR), the STS_SRE bit is set. and re-initialize the HC during resume, In xhci_resume() function, after xhci_handshake() is called , I printk the xhci->op_regs->status, it is 0x401, means the STS_SRE bit is set. I can not understand. This is normal ? Aaron Chou On Tue, Aug 4, 2015 at 8:42 AM, Aaron Zhou wrote: > Yes,I saw the code. > And the uPD720201 's device ID is 0014. > I have changed the code ,but it is without any help. > > On Mon, Aug 3, 2015 at 9:59 PM, Mathias Nyman > wrote: >> On 02.08.2015 08:37, Aaron Zhou wrote: >>> Oh sorry! >>> I have tired the 4.2-rc4 kernel, but the bug is still exist. >>> >>> Anyway,It is the first step that to kown whether the Renesas >>> Technology Corp. uPD720201 chip performance fine on X86 system after >>> resume. >>> I don't have the experimental environment. >> >> xhci driver has a quirk to reset Renesas uPD720202 USB 3.0 Host Controller >> device [0015] >> on resume. Does the uPD720201 have the same device ID? >> >> lspci -vmnnd 1912 >> >> -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