Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric
On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: > Currently qw_sign requires UTF-8 character to set, but returns UTF-16 > when read. This isn't obvious when simply using cat since the null > characters are not visible, but hexdump unveils the true string: > > # echo MSFT100 > os_desc/qw_sign > # hexdump -C os_desc/qw_sign > 4d 00 53 00 46 00 54 00 31 00 30 00 30 00|M.S.F.T.1.0.0.| > > Make qw_sign symmetric by returning an UTF-8 string too. Also follow > common convention and add a new line at the end. Doesn't USB require that strings be in UTF-16? So why have the kernel convert them? 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 2/2] fs: configfs: use hexadecimal values and new line
On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote: > Other unsigned properties return hexadecimal values, follow this > convention when printing b_vendor_code too. Also add newlines to > the OS Descriptor support related properties, like other sysfs > files use. configfs is not sysfs, so watch out, you might not need/want those new lines as tools read the values and are not expecting them. Have you verified that nothing will break with this? How have you tested it? 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] fs: configfs: make qw_sign attribute symmetric
On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: > Currently qw_sign requires UTF-8 character to set, but returns UTF-16 > when read. This isn't obvious when simply using cat since the null > characters are not visible, but hexdump unveils the true string: > > # echo MSFT100 > os_desc/qw_sign > # hexdump -C os_desc/qw_sign > 4d 00 53 00 46 00 54 00 31 00 30 00 30 00|M.S.F.T.1.0.0.| > > Make qw_sign symmetric by returning an UTF-8 string too. Also follow > common convention and add a new line at the end. The newline is not part of the descriptor, so why add it? 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 2/8] power: add power sequence library
On Wed, Feb 01, 2017 at 12:10:17AM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 3, 2017 at 7:33 AM, Peter Chen wrote: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example like hard-wired mmc devices and usb devices. > > > > This power sequence is hard to be described at device tree and handled by > > related host driver, so we have created a common power sequence > > library to cover this requirement. The core code has supplied > > some common helpers for host driver, and individual power sequence > > libraries handle kinds of power sequence for devices. The pwrseq > > librares always need to allocate extra instance for compatible > > string match. > > > > pwrseq_generic is intended for general purpose of power sequence, which > > handles gpios and clocks currently, and can cover other controls in > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off > > if only one power sequence is needed, else call of_pwrseq_on_list > > /of_pwrseq_off_list instead (eg, USB hub driver). > > > > For new power sequence library, it can add its compatible string > > to pwrseq_of_match_table, then the pwrseq core will match it with > > DT's, and choose this library at runtime. > > > > Signed-off-by: Peter Chen > > Tested-by: Maciej S. Szmigiero > > Tested-by Joshua Clayton > > Reviewed-by: Matthias Kaehlcke > > Tested-by: Matthias Kaehlcke > > Quite honestly, I have a really hard time with trying to follow this > code and the total lack of documentation makes it even harder. In > particular, the generic power sequence code is not even commented at > all, so it really is hard to say how this is going to work, let alone > deciding whether or not to apply it. > > Plus, of course, the USB core changes must be acked by the maintainer > thereof for me to be able to handle the series. Ah crap, I wanted you to explain it as I too couldn't figure it out :) > But at this point I basically need you to explain the design to me, please. Same here. 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: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
>> At boot time, probe function of multiple connected devices >> (proprietary devices) execute simultaneously. > >What exactly do you mean here? How can probe happen "simultaneously"? >The USB core prevents this, right? I have observed two scenarios to call probe function: Scenario #1: Driver inserted and attaching USB Device: Yes, you are right, two probes at same time is not happening in this scenario. Scenario #2: USB Device attached and inserting Driver: In this case probe has been called in context of insmod, refer following code flow: init -> usb_register_driver -> driver_register -> bus_add_driver -> driver_attach -> bus_for_each_dev -> __driver_attach -> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev I have observed the crash in Scenario #2, as two probes executes at same time in this scenario. And init_usb_class_mutex lock require to prevent race condition. >> And because of the following code path race condition happens: >> probe->usb_register_dev->init_usb_class > >Why is this just showing up now, and hasn't been an issue for the decade >or so this code has been around? What changed? > >> Tested with these changes, and problem has been solved. > >What changes? Tested with my patch (i.e. locking with init_usb_class_mutex). thanks, ajay kaher - Original Message - Sender : gre...@linuxfoundation.org Date : 2017-01-31 12:31 (GMT+5:30) Title : Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote: > > > At boot time, probe function of multiple connected devices > (proprietary devices) execute simultaneously. What exactly do you mean here? How can probe happen "simultaneously"? The USB core prevents this, right? And what do you mean exactly by "(proprietary devices)"? > And because of the following code path race condition happens: > probe->usb_register_dev->init_usb_class Why is this just showing up now, and hasn't been an issue for the decade or so this code has been around? What changed? > Tested with these changes, and problem has been solved. What changes? thanks, greg k-h Thanks and Regards, Ajay Kaher
Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote: > > >> At boot time, probe function of multiple connected devices > >> (proprietary devices) execute simultaneously. > > > >What exactly do you mean here? How can probe happen "simultaneously"? > >The USB core prevents this, right? > > I have observed two scenarios to call probe function: > > Scenario #1: Driver inserted and attaching USB Device: > Yes, you are right, two probes at same time is not happening > in this scenario. > > Scenario #2: USB Device attached and inserting Driver: > In this case probe has been called in context of insmod, > refer following code flow: > init -> usb_register_driver -> driver_register -> bus_add_driver -> > driver_attach -> bus_for_each_dev -> __driver_attach -> > driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev > > I have observed the crash in Scenario #2, as two probes executes at > same time in this scenario. And init_usb_class_mutex lock require to > prevent race condition. What about the fact that in __driver_attach() we call device_lock() so that probe never gets called at the same time for the same device? Or are you saying that you can load multiple USB modules at the same time? If so, how is insmod running on multiple cpus at the same time? I thought we had a global lock there to prevent that from happening (i.e. only one module can be loaded at a time.) Or is that what has recently changed? What is causing your modules to be loaded from userspace? What type of device is this happening for? And why haven't we seen this before? What kernel versions have you had a problem with this? And what for what drivers specifically? > >> And because of the following code path race condition happens: > >> probe->usb_register_dev->init_usb_class > > > >Why is this just showing up now, and hasn't been an issue for the decade > >or so this code has been around? What changed? > > > >> Tested with these changes, and problem has been solved. > > > >What changes? > > Tested with my patch (i.e. locking with init_usb_class_mutex). I don't see a patch here :( 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 2/2] fs: configfs: use hexadecimal values and new line
Hi, Greg KH writes: > On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote: >> Other unsigned properties return hexadecimal values, follow this >> convention when printing b_vendor_code too. Also add newlines to >> the OS Descriptor support related properties, like other sysfs >> files use. > > configfs is not sysfs, so watch out, you might not need/want those new > lines as tools read the values and are not expecting them. > > Have you verified that nothing will break with this? How have you > tested it? I would rather not change things like that, specially since Android guys are alreadying using configfs. -- balbi signature.asc Description: PGP signature
Re: [PATCH 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h
Le 31/01/2017 à 20:18, Russell King a écrit : > drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of > declaration > drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of > struct-union-enum-specifier > drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface > drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of > type declaration > drivers/net/ethernet/cadence/macb.h:877:1: sparse: got } > In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0: > drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name > 'phy_interface_t' > phy_interface_t phy_interface; > ^~~ > > Add linux/phy.h to macb.h > > Signed-off-by: Russell King Acked-by: Nicolas Ferre > --- > drivers/net/ethernet/cadence/macb.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/ethernet/cadence/macb.h > b/drivers/net/ethernet/cadence/macb.h > index d67adad67be1..383da8cf5f6d 100644 > --- a/drivers/net/ethernet/cadence/macb.h > +++ b/drivers/net/ethernet/cadence/macb.h > @@ -10,6 +10,8 @@ > #ifndef _MACB_H > #define _MACB_H > > +#include > + > #define MACB_GREGS_NBR 16 > #define MACB_GREGS_VERSION 2 > #define MACB_MAX_QUEUES 8 > -- Nicolas Ferre -- 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 4.10-rc3 07/13] net: mvneta: fix build errors when linux/phy*.h is removed from net/dsa.h
Hello, On Tue, 31 Jan 2017 19:18:59 +, Russell King wrote: > drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of > 'status' isn't known > drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of > 'changed' isn't known > drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has > initializer but incomplete type > drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of > function 'fixed_phy_update_state' [-Werror=implicit-function-declaration] > > Add linux/phy_fixed.h to mvneta.c > > Signed-off-by: Russell King Acked-by: Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h
On 01/31/2017 08:18 PM, Russell King wrote: drivers/net/ethernet/broadcom/bgmac.c:1015:17: error: dereferencing pointer to incomplete type 'struct mii_bus' drivers/net/ethernet/broadcom/bgmac.c:1185:2: error: implicit declaration of function 'phy_start' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1198:2: error: implicit declaration of function 'phy_stop' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1239:9: error: implicit declaration of function 'phy_mii_ioctl' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1389:28: error: 'phy_ethtool_get_link_ksettings' undeclared here (not in a function) drivers/net/ethernet/broadcom/bgmac.c:1390:28: error: 'phy_ethtool_set_link_ksettings' undeclared here (not in a function) drivers/net/ethernet/broadcom/bgmac.c:1403:13: error: dereferencing pointer to incomplete type 'struct phy_device' drivers/net/ethernet/broadcom/bgmac.c:1417:3: error: implicit declaration of function 'phy_print_status' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1424:26: error: storage size of 'fphy_status' isn't known drivers/net/ethernet/broadcom/bgmac.c:1424:9: error: variable 'fphy_status' has initializer but incomplete type drivers/net/ethernet/broadcom/bgmac.c:1425:11: warning: excess elements in struct initializer drivers/net/ethernet/broadcom/bgmac.c:1425:3: error: unknown field 'link' specified in initializer drivers/net/ethernet/broadcom/bgmac.c:1426:12: note: in expansion of macro 'SPEED_1000' drivers/net/ethernet/broadcom/bgmac.c:1426:3: error: unknown field 'speed' specified in initializer drivers/net/ethernet/broadcom/bgmac.c:1427:13: note: in expansion of macro 'DUPLEX_FULL' drivers/net/ethernet/broadcom/bgmac.c:1427:3: error: unknown field 'duplex' specified in initializer drivers/net/ethernet/broadcom/bgmac.c:1432:12: error: implicit declaration of function 'fixed_phy_register' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1432:31: error: 'PHY_POLL' undeclared (first use in this function) drivers/net/ethernet/broadcom/bgmac.c:1438:8: error: implicit declaration of function 'phy_connect_direct' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1439:6: error: 'PHY_INTERFACE_MODE_MII' undeclared (first use in this function) drivers/net/ethernet/broadcom/bgmac.c:1521:2: error: implicit declaration of function 'phy_disconnect' [-Werror=implicit-function-declaration] drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration specifiers or '...' before string constant Add linux/phy.h to bgmac.c Signed-off-by: Russell King Acked-by: Rafał Miłecki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: On 01/25/2017 10:03 AM, Rafał Miłecki wrote: On 21 January 2017 at 22:42, Jacek Anaszewski wrote: On 01/21/2017 05:24 PM, Rafał Miłecki wrote: On 20 January 2017 at 23:35, Jacek Anaszewski wrote: On 01/20/2017 10:56 PM, Rafał Miłecki wrote: From: Rafał Miłecki Some LEDs can be related to particular devices described in DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Signed-off-by: Rafał Miłecki --- V2: Replace "usb-ports" with "led-triggers" property which is more generic and allows specifying other devices as well. When bindings patch is related to some followup implementation, they usually go through the same tree. Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve examples by adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is there any way to solve this dependency issue? Or should this patch wait until 3.11 is released? --- Documentation/devicetree/bindings/leds/common.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 24b656014089..17632a041196 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -49,6 +49,17 @@ Optional properties for child nodes: - panic-indicator : This property specifies that the LED should be used, if at all possible, as a panic indicator. +- led-triggers : List of devices that should trigger this LED activity. Some + LEDs can be related to a specific device and should somehow + indicate its state. E.g. USB 2.0 LED may react to device(s) in + a USB 2.0 port(s). Another common example is switch or router + with multiple Ethernet ports each of them having its own LED + assigned (assuminled-trigger-usbportg they are not hardwired). + In such cases this property should contain phandle(s) of + related device(s). In many cases LED can be related to more + than one device (e.g. one USB LED vs. multiple USB ports) so a + list of entries can be specified. + This implies that it is possible to define multiple triggers for a LED class device but it is not supported by LED Trigger core. There is linux,default-trigger property which allows to define one trigger that will be initially assigned. With proposed "led-triggers" property one could assign different trigger *sources* to a LED. You could e.g. assign 2 USB ports, network device & CPU to a single LED. For reason explained above Linux couldn't support all of them at once. I am aware that this is renamed usb-ports property from v1, that attempts to address Rob's comment, but we can't do that this way. Maybe usb-ports property could be documented in led-trigger-usbport's specific bindings and a reference to it could be added next to the related entry on the list of the available LED triggers (which is actually missing) in Documentation/devicetree/bindings/leds/common.txt. I'm wondering if we need to care about this Linux limitation and if it should stop us from adding this flexible DT property. Maybe we could live with Linux having limitation of supporting one trigger type at a time? That's what I meant. Generally I have objections to the generic property for defining list of allowed triggers. That's why I proposed to stay by usb-ports property that would be specific to only one trigger: led-trigger-usbport. led-trigger-usbport in fact is an entirely new type of LED trigger. LED triggers is a kernel based source of events. All existing triggers react only to a single, well defined source of events, whereas led-trigger-usbport allows to define the scope of events (usb ports) to notify about. Activity on each port is treated similarly and the LED class device that listens to the trigger notifications doesn't know which exact port triggered the notification. From this POV led-trigger-usbport is kind of facade, which allows for it to fit well into the LED Trigger design and API, and usb ports are not identical with LED triggers, but sit rather one level below. It is led-trigger-usbport which is visible to the LED subsystem, and not every single usb port. So e.g. if one assigns 2 USB ports + network device + CPU and decides to use "usport" trigger driver he'll get LED indicating status of USB ports only. How would it be different from the current state? Only in limiting the scope of triggers available for a LED class device. It won't differ from the current state. I just wanted to make it clear Linux trigger drivers may respect only selected "led-triggers" values (phandles). Like "usbport" respecting USB port phandles but ig
Re: [PATCH 5/6] DT bindings documentation for Broadcom IPROC USB Device controller.
On Mon, Jan 30, 2017 at 01:26:12PM +0530, Raviteja Garimella wrote: > The device node is used for UDCs integrated into Broadcom's > iProc family of SoCs'. The UDC is based on Synopsys Designware > Cores AHB Subsystem USB Device Controller IP. > > Signed-off-by: Raviteja Garimella > --- > .../bindings/usb/brcm,iproc-snps-udc.txt | 24 > ++ > 1 file changed, 24 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt > > diff --git a/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt > b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt > new file mode 100644 > index 000..537dd4d > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt > @@ -0,0 +1,24 @@ > +Broadcom IPROC USB Device controller. > + > +The device node is used for UDCs integrated into Broadcom's > +iProc family of SoCs'. The UDC is based on Synopsys Designware > +Cores AHB Subsystem Device Controller. > + > +Required properties: > + - compatible: should be "brcm,iproc-snps-udc" Adding "snps" in here adds nothing really. Again, please use per SoC compatible strings. > + - reg: Offset and length of UDC register set > + - interrupts: description of interrupt line > + - phys: phandle to phy node. > + - extcon: phandle to the extcon device. This is optional and > + not required for those that don't require extcon support. > + Extcon support will be required if the UDC is connected to > + a Dual Role Device Phy that supports both Host and Device > + mode based on the external cable. Drop this property. > + > +Example: > + udc_dwc: usb@664e { > + compatible = "brcm,iproc-snps-udc"; > + reg = <0x664e 0x2000>; > + interrupts = ; > + phys = <&usbdrd_phy>; > + extcon = <&usbdrd_phy>"; > -- > 2.1.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] usb: gadget: udc: atmel: fix debug output
The debug output now contains the wrong variable, as seen from the compiler warning: drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used uninitialized in this function [-Werror=maybe-uninitialized] DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", This changes the debug output the same way as the other code. Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation scheme") Signed-off-by: Arnd Bergmann --- drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c index 11bbce28bc23..2035906b8ced 100644 --- a/drivers/usb/gadget/udc/atmel_usba_udc.c +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c @@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc) { struct usba_ep *ep = to_usba_ep(_ep); struct usba_udc *udc = ep->udc; - unsigned long flags, ept_cfg, maxpacket; + unsigned long flags, maxpacket; unsigned int nr_trans; DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc); @@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc) ep->is_in = 0; DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", - ep->ep.name, ept_cfg, maxpacket); + ep->ep.name, ep->ept_cfg, maxpacket); if (usb_endpoint_dir_in(desc)) { ep->is_in = 1; -- 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: [PATCH 2/2] fs: configfs: use hexadecimal values and new line
On 2017-02-01 01:02, Felipe Balbi wrote: > Hi, > > Greg KH writes: >> On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote: >>> Other unsigned properties return hexadecimal values, follow this >>> convention when printing b_vendor_code too. Also add newlines to >>> the OS Descriptor support related properties, like other sysfs >>> files use. >> >> configfs is not sysfs, so watch out, you might not need/want those new >> lines as tools read the values and are not expecting them. >> >> Have you verified that nothing will break with this? How have you >> tested it? I am actually writing OS Descriptor support for libusbgx (fork of libusbg) when I stumbled upon this. The helper function there do not care about the new line, but I just thought we should fix it for the sake of coherency to the other properties. I am also fine dropping this patch. > > I would rather not change things like that, specially since Android guys > are alreadying using configfs. Do you happen to know where the source of that part is? So we could check if they make use of any OS Descriptor support yet... -- Stefan -- 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] fs: configfs: make qw_sign attribute symmetric
On 2017-02-01 00:06, Greg KH wrote: > On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: >> Currently qw_sign requires UTF-8 character to set, but returns UTF-16 >> when read. This isn't obvious when simply using cat since the null >> characters are not visible, but hexdump unveils the true string: >> >> # echo MSFT100 > os_desc/qw_sign >> # hexdump -C os_desc/qw_sign >> 4d 00 53 00 46 00 54 00 31 00 30 00 30 00 >> |M.S.F.T.1.0.0.| >> >> Make qw_sign symmetric by returning an UTF-8 string too. Also follow >> common convention and add a new line at the end. > > Doesn't USB require that strings be in UTF-16? So why have the kernel > convert them? That is a discussion we should have had when the write side of this has been added: static ssize_t os_desc_qw_sign_store(struct config_item *item, const char *page, size_t len) { struct gadget_info *gi = os_desc_item_to_gadget_info(item); int res, l; l = min((int)len, OS_STRING_QW_SIGN_LEN >> 1); if (page[l - 1] == '\n') --l; mutex_lock(&gi->lock); res = utf8s_to_utf16s(page, l, UTF16_LITTLE_ENDIAN, (wchar_t *) gi->qw_sign, OS_STRING_QW_SIGN_LEN); if (res > 0) res = len; mutex_unlock(&gi->lock); return res; } The store function is definitely already in use today, e.g. this script used for ev3dev: https://github.com/ev3dev/ev3-systemd/blob/ev3dev-jessie/scripts/ev3-usb.sh Changing it to UTF-16 would break that script... So changing the store part is the lesser of two evils. Regarding new line: Just following what other attributes are doing by using the GS_STRINGS_R macro. -- Stefan -- 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: gadget: udc: atmel: fix debug output
On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: > The debug output now contains the wrong variable, as seen from the compiler > warning: > > drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': > drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used > uninitialized in this function [-Werror=maybe-uninitialized] > DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", > > This changes the debug output the same way as the other code. > > Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation > scheme") > Signed-off-by: Arnd Bergmann Acked-by: Alexandre Belloni > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c > b/drivers/usb/gadget/udc/atmel_usba_udc.c > index 11bbce28bc23..2035906b8ced 100644 > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c > @@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct > usb_endpoint_descriptor *desc) > { > struct usba_ep *ep = to_usba_ep(_ep); > struct usba_udc *udc = ep->udc; > - unsigned long flags, ept_cfg, maxpacket; > + unsigned long flags, maxpacket; > unsigned int nr_trans; > > DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc); > @@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct > usb_endpoint_descriptor *desc) > ep->is_in = 0; > > DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", > - ep->ep.name, ept_cfg, maxpacket); > + ep->ep.name, ep->ept_cfg, maxpacket); > > if (usb_endpoint_dir_in(desc)) { > ep->is_in = 1; > -- > 2.9.0 > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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] usb: gadget: udc: atmel: fix debug output
Le 01/02/2017 à 18:00, Alexandre Belloni a écrit : > On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: >> The debug output now contains the wrong variable, as seen from the compiler >> warning: >> >> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': >> drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be >> used uninitialized in this function [-Werror=maybe-uninitialized] >> DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", >> >> This changes the debug output the same way as the other code. >> >> Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation >> scheme") >> Signed-off-by: Arnd Bergmann > Acked-by: Alexandre Belloni Acked-by: Nicolas Ferre > >> --- >> drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c >> b/drivers/usb/gadget/udc/atmel_usba_udc.c >> index 11bbce28bc23..2035906b8ced 100644 >> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c >> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c >> @@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct >> usb_endpoint_descriptor *desc) >> { >> struct usba_ep *ep = to_usba_ep(_ep); >> struct usba_udc *udc = ep->udc; >> -unsigned long flags, ept_cfg, maxpacket; >> +unsigned long flags, maxpacket; >> unsigned int nr_trans; >> >> DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc); >> @@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct >> usb_endpoint_descriptor *desc) >> ep->is_in = 0; >> >> DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n", >> -ep->ep.name, ept_cfg, maxpacket); >> +ep->ep.name, ep->ept_cfg, maxpacket); >> >> if (usb_endpoint_dir_in(desc)) { >> ep->is_in = 1; >> -- >> 2.9.0 >> > -- Nicolas Ferre -- 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 4.10-rc3 11/13] net: liquidio: fix build errors when linux/phy*.h is removed from net/dsa.h
Russell King wrote on Tue [2017-Jan-31 19:19:19 +]: > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: type defaults > to 'int' in declaration of 'MODULE_AUTHOR' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: type defaults > to 'int' in declaration of 'MODULE_DESCRIPTION' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: type defaults > to 'int' in declaration of 'MODULE_LICENSE' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: type defaults > to 'int' in declaration of 'MODULE_VERSION' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:36: error: expected ')' > before 'int' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:37: error: expected ')' > before string constant > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: error: type defaults > to 'int' in declaration of 'MODULE_DEVICE_TABLE' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: parameter > names (without types) in function declaration > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: error: type defaults > to 'int' in declaration of 'module_init' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: parameter > names (without types) in function declaration > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: data > definition has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: error: type defaults > to 'int' in declaration of 'module_exit' > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: parameter > names (without types) in function declaration > drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_main.c:36: warning: data definition > has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: type defaults to > 'int' in declaration of 'MODULE_AUTHOR' > drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_main.c:37: warning: data definition > has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: type defaults to > 'int' in declaration of 'MODULE_DESCRIPTION' > drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_main.c:38: warning: data definition > has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: type defaults to > 'int' in declaration of 'MODULE_LICENSE' > drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: function > declaration isn't a prototype > drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: expected > declaration specifiers or '...' before string constant > drivers/net/ethernet/cavium/liquidio/lio_main.c:39: warning: data definition > has no type or storage class > drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: type defaults to > 'int' in declarat
Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
On 02/01/2017 04:56 PM, Rafał Miłecki wrote: > On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: >> On 01/31/2017 05:11 PM, Rafał Miłecki wrote: >>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: On 01/25/2017 10:03 AM, Rafał Miłecki wrote: > On 21 January 2017 at 22:42, Jacek Anaszewski > wrote: >> On 01/21/2017 05:24 PM, Rafał Miłecki wrote: >>> On 20 January 2017 at 23:35, Jacek Anaszewski >>> wrote: On 01/20/2017 10:56 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > Some LEDs can be related to particular devices described in DT. > This > property allows specifying such relations. E.g. USB LED should > usually > be used to indicate some USB port(s) state. > > Signed-off-by: Rafał Miłecki > --- > V2: Replace "usb-ports" with "led-triggers" property which is > more generic and > allows specifying other devices as well. > > When bindings patch is related to some followup implementation, > they usually go > through the same tree. > > Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: > Improve examples by > adding some context") from kernel/git/j.anaszewski/linux-leds.git > . Is there any > way to solve this dependency issue? Or should this patch wait > until 3.11 is > released? > --- > Documentation/devicetree/bindings/leds/common.txt | 16 > > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/devicetree/bindings/leds/common.txt > b/Documentation/devicetree/bindings/leds/common.txt > index 24b656014089..17632a041196 100644 > --- a/Documentation/devicetree/bindings/leds/common.txt > +++ b/Documentation/devicetree/bindings/leds/common.txt > @@ -49,6 +49,17 @@ Optional properties for child nodes: > - panic-indicator : This property specifies that the LED should > be used, > if at all possible, as a panic indicator. > > +- led-triggers : List of devices that should trigger this LED > activity. Some > + LEDs can be related to a specific device and > should somehow > + indicate its state. E.g. USB 2.0 LED may react to > device(s) in > + a USB 2.0 port(s). Another common example is > switch or router > + with multiple Ethernet ports each of them having > its own LED > + assigned (assuminled-trigger-usbportg they are not > hardwired). > + In such cases this property should contain > phandle(s) of > + related device(s). In many cases LED can be > related to more > + than one device (e.g. one USB LED vs. multiple USB > ports) so a > + list of entries can be specified. > + This implies that it is possible to define multiple triggers for a LED class device but it is not supported by LED Trigger core. There is linux,default-trigger property which allows to define one trigger that will be initially assigned. >> >>> With proposed "led-triggers" property one could assign different >>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, >>> network >>> device & CPU to a single LED. For reason explained above Linux >>> couldn't support all of them at once. >>> >>> I am aware that this is renamed usb-ports property from v1, that attempts to address Rob's comment, but we can't do that this way. Maybe usb-ports property could be documented in led-trigger-usbport's specific bindings and a reference to it could be added next to the related entry on the list of the available LED triggers (which is actually missing) in Documentation/devicetree/bindings/leds/common.txt. >>> >>> I'm wondering if we need to care about this Linux limitation and >>> if it >>> should stop us from adding this flexible DT property. Maybe we could >>> live with Linux having limitation of supporting one trigger type >>> at a >>> time? >> >> That's what I meant. Generally I have objections to the generic >> property for defining list of allowed triggers. That's why I proposed >> to stay by usb-ports property that would be specific to only one >> trigger: led-trigger-usbport. >> >> led-trigger-usbport in fact is an entirely new type of LED trigger. >> LED triggers is a kernel based source of events. All existing >> triggers >> react only to a single, well defined source of events, whereas >> led-trigger-usbport allows to define the sc
Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: On 02/01/2017 04:56 PM, Rafał Miłecki wrote: On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: Thanks a lot Jacek for this explanation (and sorry but I needed a bit of time to think about this). I can finally see your point, I think we're on the same page now. I think that for all this time I was thinking from the pure DT perspective. If you ignore fact that Linux has multiple LED trigger drivers, then "led-triggers" may not sound that bad. After reading your description however I can see this property can be misleading as Linux people may think "drivers" when seeing "triggers". I still think this is a useful property and I hope we can still find a way to name it in a sane way: to be nice from DT PoV and march Linux LEDs subsystem. I also see the need for this property. I think we should still work on some generic property (without linux, prefix) as this seems to be something generic, not really specific to Linux implementation. Specifying relation between LED and devices is something than AFAICS can be reused by other systems as well. So my suggestion is to try some new name & leave linux,default-trigger to allow specifying one single trigger driver as required by current Linux implementation. What do you think about this? There are few suggestions to came to my mind: "trigger-sources" "trigger-devices" "led-trigger-devices" "led-related-devices" "led-event-devices" trigger-devices would work in this specific use case, where we can give phandles to usb ports. Nonetheless, we have also other kernel based events serving as trigger sources - e.g. timer. In this case I'd go for trigger-sources, but we'd need to have some generic way of defining the source like timer. I'd leave timer for later discussion but I'm glad you brought this problem. Maybe we could discuss this on another example that is more supported like GPIOs? We know this property allows specifying USB ports and we want it to support mixing various sources. So a very simple sample case seems to be using it for specifying GPIO as trigger source. Is this possible to mix various entries in a list assigned to single property? Let's say: trigger-sources = <&ohci_port1>, <&ehci_port1>, <&gpio 1 GPIO_ACTIVE_HIGH>; According to my knowledge all elements in the list are elements of one array, no matter if they are comma separated or space separated in "<>" brackets. DT maintainer would have to confirm that though. This matches my knowledge as well. Is this possible to support this? If so, which function I can use to detect what is pointed by a phandle? I'm not that familiar with DT and I'm not sure how to handle this. I wonder if this is correct way to go. Maybe we should think of creating entirely new trigger mechanism that would allow for having multiple active triggers at a time. I'm OK with reworking Linux's triggers if it need be. I think we should agree on binding(s) first though. Of course trigger-sources would be still useful for defining a list of devices of the same type like in case of usbport trigger. Nonetheless, I have a problem with this property being a part of LED class device DT bindings. Triggers are not tightly coupled with LED class devices, but trigger-sources being a list of usb ports would be applicable only to usbport trigger. What if there was another combo trigger e.g. for reporting activity on mulitple GPIOs? That was exactly my point with above trigger-sources example including 2 USB ports & GPIO. Should we have separate list of trigger sources per any possible existing trigger type? Aren't we going to far from pure hardware description the Device Tree was initially predestined to? That would simplify things, but it gets us back to *multiple* properties like led-usb-triggers (or led-usb-trigger-sources) led-pci-triggers (or led-pci-trigger-sources) led-gpio-triggers (or led-gpio-trigger-sources) etc. Last time Rob said he's not going to accept something like this, see: On 23 January 2017 at 17:45, Rob Herring wrote: > I'm not going to accept something specific to USB. So the choice is make > the existing property work for USB or design something more flexible and > generic. So I think the main question right now is if this is possible to support mixed entries in a list like that trigger-sources = <&ohci_port1>, <&ehci_port1>, <&gpio 1 GPIO_ACTIVE_HIGH>; I posted as example. I was also trying to find help on IRC #devicetree channel but didn't get any response: [09:15] hi, i've a question about mixing various entries in a single list [09:16] is this possible to have different /syntax/ in every list element [09:16] and have driver detect what does it reference? [09:16] i'll post an example [09:17] trigger-sources = <&ohci_port1>, <&ehci_port1>, <&gpio 1 GPIO_ACTIVE_HIGH>; [09:18] this question is related to my work in [PATCH V2 1/2] dt-bindings: l
[PATCH 04/17] usb: musb: da8xx: remove redundant code
The session is cleared in the core whenever musb_platform_disable() is called, so clearing it in the glue driver *_musb_disable() is redundant. Signed-off-by: Bin Liu --- drivers/usb/musb/da8xx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index cd3d763720b3..d5766ebeb761 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -125,7 +125,6 @@ static void da8xx_musb_disable(struct musb *musb) musb_writel(reg_base, DA8XX_USB_INTR_MASK_CLEAR_REG, DA8XX_INTR_USB_MASK | DA8XX_INTR_TX_MASK | DA8XX_INTR_RX_MASK); - musb_writeb(musb->mregs, MUSB_DEVCTL, 0); musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 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 00/17] musb patches for v4.11-rc1
Hi Greg, This musb patch set is for next v4.11-rc1. It adds suspend/resume support in DA8xx glue, adds H3/V3s SoC support, fixes incorrect CPPI reference in DA8xx glue, switch to static id naming for musb-hdrc device to give consistent user experience, and a few compile warning fixes and cleanups. It also changes the musb test mode handling which should enable the host mode for Nokia N900. Please let me know if any change is needed. Regards, -Bin. --- Alexandre Bailon (4): usb: musb: da8xx: Remove CPPI 3.0 quirk and methods usb: musb: da8xx: Add support of suspend / resume usb: musb: Add a quirk to preserve the session during suspend usb: musb: da8xx: Fix host mode suspend Bhumika Goyal (1): usb: musb: omap2430: constify dev_pm_ops structures Bin Liu (6): usb: musb: remove musb_generic_disable function usb: musb: dsps: remove redundant code usb: musb: da8xx: remove redundant code usb: musb: am35x: remove redundant code usb: musb: davinci: remove redundant code usb: musb: dsps: switch to static id for musb-hdrc platform devices Chanwoo Choi (1): usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier Icenowy Zheng (1): usb: musb: sunxi: add support for the variant in H3/V3s SoC Jérémy Lefaure (1): usb: musb: blackfin: fix unused warnings on suspend/resume Pali Rohár (1): usb: musb: debugfs: allow forcing host mode together with speed in testmode Tony Lindgren (1): usb: musb: Add support for optional VBUS irq to dsps glue layer Wei Yongjun (1): usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static .../bindings/usb/allwinner,sun4i-a10-musb.txt | 4 +- drivers/usb/musb/am35x.c | 1 - drivers/usb/musb/blackfin.c| 6 +- drivers/usb/musb/da8xx.c | 36 +- drivers/usb/musb/davinci.c | 1 - drivers/usb/musb/musb_core.c | 27 ++--- drivers/usb/musb/musb_core.h | 1 + drivers/usb/musb/musb_debugfs.c| 46 +--- drivers/usb/musb/musb_dsps.c | 123 - drivers/usb/musb/omap2430.c| 2 +- drivers/usb/musb/sunxi.c | 47 ++-- 11 files changed, 208 insertions(+), 86 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 03/17] usb: musb: dsps: remove redundant code
The session is cleared in the core whenever musb_platform_disable() is called, so clearing it in the glue driver *_musb_disable() is redundant. Signed-off-by: Bin Liu --- drivers/usb/musb/musb_dsps.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 9f125e179acd..ceb646be20d9 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -186,7 +186,6 @@ static void dsps_musb_disable(struct musb *musb) musb_writel(reg_base, wrp->epintr_clear, wrp->txep_bitmap | wrp->rxep_bitmap); del_timer_sync(&glue->timer); - musb_writeb(musb->mregs, MUSB_DEVCTL, 0); } /* Caller must take musb->lock */ -- 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 02/17] usb: musb: remove musb_generic_disable function
musb_generic_disable() only has two lines of code. So remove it and let the callers directly call those two lines. Signed-off-by: Bin Liu --- drivers/usb/musb/musb_core.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fca288bbc800..b1f082f42112 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1040,16 +1040,6 @@ static void musb_enable_interrupts(struct musb *musb) } -static void musb_generic_disable(struct musb *musb) -{ - void __iomem*mbase = musb->mregs; - - musb_disable_interrupts(musb); - - /* off */ - musb_writeb(mbase, MUSB_DEVCTL, 0); -} - /* * Program the HDRC to start (enable interrupts, dma, etc.). */ @@ -1106,8 +1096,8 @@ void musb_stop(struct musb *musb) { /* stop IRQs, timers, ... */ musb_platform_disable(musb); - musb_generic_disable(musb); - musb_dbg(musb, "HDRC disabled"); + musb_disable_interrupts(musb); + musb_writeb(musb->mregs, MUSB_DEVCTL, 0); /* FIXME * - mark host and/or peripheral drivers unusable/inactive @@ -2312,7 +2302,8 @@ static void musb_deassert_reset(struct work_struct *work) /* be sure interrupts are disabled before connecting ISR */ musb_platform_disable(musb); - musb_generic_disable(musb); + musb_disable_interrupts(musb); + musb_writeb(musb->mregs, MUSB_DEVCTL, 0); /* Init IRQ workqueue before request_irq */ INIT_DELAYED_WORK(&musb->irq_work, musb_irq_work); @@ -2486,11 +2477,13 @@ static int musb_remove(struct platform_device *pdev) pm_runtime_get_sync(musb->controller); musb_host_cleanup(musb); musb_gadget_cleanup(musb); + spin_lock_irqsave(&musb->lock, flags); musb_platform_disable(musb); - musb_generic_disable(musb); - spin_unlock_irqrestore(&musb->lock, flags); + musb_disable_interrupts(musb); musb_writeb(musb->mregs, MUSB_DEVCTL, 0); + spin_unlock_irqrestore(&musb->lock, flags); + pm_runtime_dont_use_autosuspend(musb->controller); pm_runtime_put_sync(musb->controller); pm_runtime_disable(musb->controller); @@ -2665,7 +2658,8 @@ static int musb_suspend(struct device *dev) unsigned long flags; musb_platform_disable(musb); - musb_generic_disable(musb); + musb_disable_interrupts(musb); + musb_writeb(musb->mregs, MUSB_DEVCTL, 0); WARN_ON(!list_empty(&musb->pending_list)); spin_lock_irqsave(&musb->lock, flags); -- 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 01/17] usb: musb: da8xx: Remove CPPI 3.0 quirk and methods
From: Alexandre Bailon DA8xx driver is registering and using the CPPI 3.0 DMA controller but actually, the DA8xx has a CPPI 4.1 DMA controller. Remove the CPPI 3.0 quirk and methods. Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros") Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA") Cc: Signed-off-by: Alexandre Bailon Acked-by: Sergei Shtylyov Acked-by: Tony Lindgren Signed-off-by: Bin Liu --- drivers/usb/musb/da8xx.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index e89708d839e5..cd3d763720b3 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -458,15 +458,11 @@ static inline u8 get_vbus_power(struct device *dev) } static const struct musb_platform_ops da8xx_ops = { - .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP, + .quirks = MUSB_INDEXED_EP, .init = da8xx_musb_init, .exit = da8xx_musb_exit, .fifo_mode = 2, -#ifdef CONFIG_USB_TI_CPPI_DMA - .dma_init = cppi_dma_controller_create, - .dma_exit = cppi_dma_controller_destroy, -#endif .enable = da8xx_musb_enable, .disable= da8xx_musb_disable, -- 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 06/17] usb: musb: davinci: remove redundant code
The session is cleared in the core whenever musb_platform_disable() is called, so clearing it in the glue driver *_musb_disable() is redundant. Signed-off-by: Bin Liu --- drivers/usb/musb/davinci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index cee61a51645e..52b491d3d5d8 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -133,7 +133,6 @@ static void davinci_musb_disable(struct musb *musb) DAVINCI_USB_USBINT_MASK | DAVINCI_USB_TXINT_MASK | DAVINCI_USB_RXINT_MASK); - musb_writeb(musb->mregs, MUSB_DEVCTL, 0); musb_writel(musb->ctrl_base, DAVINCI_USB_EOI_REG, 0); if (is_dma_capable() && !dma_off) -- 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 05/17] usb: musb: am35x: remove redundant code
The session is cleared in the core whenever musb_platform_disable() is called, so clearing it in the glue driver *_musb_disable() is redundant. Signed-off-by: Bin Liu --- drivers/usb/musb/am35x.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c index 50ca8052bc8e..02fbb4fe3745 100644 --- a/drivers/usb/musb/am35x.c +++ b/drivers/usb/musb/am35x.c @@ -121,7 +121,6 @@ static void am35x_musb_disable(struct musb *musb) musb_writel(reg_base, CORE_INTR_MASK_CLEAR_REG, AM35X_INTR_USB_MASK); musb_writel(reg_base, EP_INTR_MASK_CLEAR_REG, AM35X_TX_INTR_MASK | AM35X_RX_INTR_MASK); - musb_writeb(musb->mregs, MUSB_DEVCTL, 0); musb_writel(reg_base, USB_END_OF_INTR_REG, 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 12/17] usb: musb: dsps: switch to static id for musb-hdrc platform devices
The dsps glue uses PLATFORM_DEVID_AUTO when creating the musb-hdrc platform devices, this causes that the id will change in each system depending on the order of driver probe, the order of the usb instances defined in device-tree, or the list of enabled devices which use also PLATFORM_DEVID_AUTO in kernel config. This id inconsistency causes trouble in shell scripting or user guide documentation. So switch it to static id, starting from 0 to the musb instance with lower MMR offset. This scheme is also aligned to the naming in the SoC. Signed-off-by: Bin Liu --- drivers/usb/musb/musb_dsps.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index ceb646be20d9..9542d20b2785 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -695,7 +695,8 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue, resources[1] = *res; /* allocate the child platform device */ - musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO); + musb = platform_device_alloc("musb-hdrc", + (resources[0].start & 0xFFF) == 0x400 ? 0 : 1); if (!musb) { dev_err(dev, "failed to allocate musb device\n"); return -ENOMEM; -- 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 09/17] usb: musb: da8xx: Fix host mode suspend
From: Alexandre Bailon On da8xx, VBUS is not maintained during suspend when musb is in host mode. On resume, all the connected devices will be disconnected and then will be enumerated again. This happens because MUSB_DEVCTL is cleared during suspend. Use the quirk MUSB_PRESERVE_SESSION to preseve MUSB_DEVCTL during suspend. Signed-off-by: Alexandre Bailon Signed-off-by: Bin Liu --- drivers/usb/musb/da8xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index eb5acee82173..d79c288ccbf2 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -457,7 +457,7 @@ static inline u8 get_vbus_power(struct device *dev) } static const struct musb_platform_ops da8xx_ops = { - .quirks = MUSB_INDEXED_EP, + .quirks = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION, .init = da8xx_musb_init, .exit = da8xx_musb_exit, -- 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 13/17] usb: musb: blackfin: fix unused warnings on suspend/resume
From: Jérémy Lefaure When CONFIG_PM_SLEEP is disabled, SIMPLE_DEV_PM_OPS does not use bfin_resume and bfin_suspend even if CONFIG_PM is enabled: drivers/usb/musb/blackfin.c:602:12: warning: ‘bfin_resume’ defined but not used [-Wunused-function] static int bfin_resume(struct device *dev) ^~~ drivers/usb/musb/blackfin.c:585:12: warning: ‘bfin_suspend’ defined but not used [-Wunused-function] static int bfin_suspend(struct device *dev) ^~~~ The preprocessor condition should be on CONFIG_PM_SLEEP, not on CONFIG_PM. However it is better to mark these functions as __maybe_unused. Signed-off-by: Jérémy Lefaure Signed-off-by: Bin Liu --- drivers/usb/musb/blackfin.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c index 896798071817..4418574a36a1 100644 --- a/drivers/usb/musb/blackfin.c +++ b/drivers/usb/musb/blackfin.c @@ -581,8 +581,7 @@ static int bfin_remove(struct platform_device *pdev) return 0; } -#ifdef CONFIG_PM -static int bfin_suspend(struct device *dev) +static int __maybe_unused bfin_suspend(struct device *dev) { struct bfin_glue*glue = dev_get_drvdata(dev); struct musb *musb = glue_to_musb(glue); @@ -599,7 +598,7 @@ static int bfin_suspend(struct device *dev) return 0; } -static int bfin_resume(struct device *dev) +static int __maybe_unused bfin_resume(struct device *dev) { struct bfin_glue*glue = dev_get_drvdata(dev); struct musb *musb = glue_to_musb(glue); @@ -608,7 +607,6 @@ static int bfin_resume(struct device *dev) return 0; } -#endif static SIMPLE_DEV_PM_OPS(bfin_pm_ops, bfin_suspend, bfin_resume); -- 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 11/17] usb: musb: debugfs: allow forcing host mode together with speed in testmode
From: Pali Rohár Based on the musb ug, force_host bit is allowed to be set along with force_hs or force_fs bit. It could help to implement forced host mode via testmode on Nokia N900. Signed-off-by: Pali Rohár Signed-off-by: Bin Liu --- drivers/usb/musb/musb_debugfs.c | 46 ++--- 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c index dd70c88419d2..952733ceaac8 100644 --- a/drivers/usb/musb/musb_debugfs.c +++ b/drivers/usb/musb/musb_debugfs.c @@ -153,28 +153,34 @@ static int musb_test_mode_show(struct seq_file *s, void *unused) pm_runtime_mark_last_busy(musb->controller); pm_runtime_put_autosuspend(musb->controller); - if (test & MUSB_TEST_FORCE_HOST) + if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS)) + seq_printf(s, "force host full-speed\n"); + + else if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS)) + seq_printf(s, "force host high-speed\n"); + + else if (test == MUSB_TEST_FORCE_HOST) seq_printf(s, "force host\n"); - if (test & MUSB_TEST_FIFO_ACCESS) + else if (test == MUSB_TEST_FIFO_ACCESS) seq_printf(s, "fifo access\n"); - if (test & MUSB_TEST_FORCE_FS) + else if (test == MUSB_TEST_FORCE_FS) seq_printf(s, "force full-speed\n"); - if (test & MUSB_TEST_FORCE_HS) + else if (test == MUSB_TEST_FORCE_HS) seq_printf(s, "force high-speed\n"); - if (test & MUSB_TEST_PACKET) + else if (test == MUSB_TEST_PACKET) seq_printf(s, "test packet\n"); - if (test & MUSB_TEST_K) + else if (test == MUSB_TEST_K) seq_printf(s, "test K\n"); - if (test & MUSB_TEST_J) + else if (test == MUSB_TEST_J) seq_printf(s, "test J\n"); - if (test & MUSB_TEST_SE0_NAK) + else if (test == MUSB_TEST_SE0_NAK) seq_printf(s, "test SE0 NAK\n"); return 0; @@ -198,7 +204,7 @@ static ssize_t musb_test_mode_write(struct file *file, struct seq_file *s = file->private_data; struct musb *musb = s->private; u8 test; - charbuf[18]; + charbuf[24]; pm_runtime_get_sync(musb->controller); test = musb_readb(musb->mregs, MUSB_TESTMODE); @@ -213,30 +219,36 @@ static ssize_t musb_test_mode_write(struct file *file, if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) return -EFAULT; - if (strstarts(buf, "force host")) + if (strstarts(buf, "force host full-speed")) + test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS; + + else if (strstarts(buf, "force host high-speed")) + test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS; + + else if (strstarts(buf, "force host")) test = MUSB_TEST_FORCE_HOST; - if (strstarts(buf, "fifo access")) + else if (strstarts(buf, "fifo access")) test = MUSB_TEST_FIFO_ACCESS; - if (strstarts(buf, "force full-speed")) + else if (strstarts(buf, "force full-speed")) test = MUSB_TEST_FORCE_FS; - if (strstarts(buf, "force high-speed")) + else if (strstarts(buf, "force high-speed")) test = MUSB_TEST_FORCE_HS; - if (strstarts(buf, "test packet")) { + else if (strstarts(buf, "test packet")) { test = MUSB_TEST_PACKET; musb_load_testpacket(musb); } - if (strstarts(buf, "test K")) + else if (strstarts(buf, "test K")) test = MUSB_TEST_K; - if (strstarts(buf, "test J")) + else if (strstarts(buf, "test J")) test = MUSB_TEST_J; - if (strstarts(buf, "test SE0 NAK")) + else if (strstarts(buf, "test SE0 NAK")) test = MUSB_TEST_SE0_NAK; musb_writeb(musb->mregs, MUSB_TESTMODE, test); -- 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 07/17] usb: musb: da8xx: Add support of suspend / resume
From: Alexandre Bailon Implement PM methods specifics for da8xx glue. The only thing to do is to power off the phy. As the registers are in retention during suspend, there is no need to save them. Signed-off-by: Alexandre Bailon Signed-off-by: Bin Liu --- drivers/usb/musb/da8xx.c | 29 + 1 file changed, 29 insertions(+) diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index d5766ebeb761..eb5acee82173 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -573,6 +573,34 @@ static int da8xx_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int da8xx_suspend(struct device *dev) +{ + int ret; + struct da8xx_glue *glue = dev_get_drvdata(dev); + + ret = phy_power_off(glue->phy); + if (ret) + return ret; + clk_disable_unprepare(glue->clk); + + return 0; +} + +static int da8xx_resume(struct device *dev) +{ + int ret; + struct da8xx_glue *glue = dev_get_drvdata(dev); + + ret = clk_prepare_enable(glue->clk); + if (ret) + return ret; + return phy_power_on(glue->phy); +} +#endif + +static SIMPLE_DEV_PM_OPS(da8xx_pm_ops, da8xx_suspend, da8xx_resume); + #ifdef CONFIG_OF static const struct of_device_id da8xx_id_table[] = { { @@ -588,6 +616,7 @@ static int da8xx_remove(struct platform_device *pdev) .remove = da8xx_remove, .driver = { .name = "musb-da8xx", + .pm = &da8xx_pm_ops, .of_match_table = of_match_ptr(da8xx_id_table), }, }; -- 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 10/17] usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
From: Chanwoo Choi This patch just uses the resource-managed extcon API when registering the extcon notifier. Signed-off-by: Chanwoo Choi Acked-by: Maxime Ripard Signed-off-by: Bin Liu --- drivers/usb/musb/sunxi.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c index 64545de4871f..05cab67d4106 100644 --- a/drivers/usb/musb/sunxi.c +++ b/drivers/usb/musb/sunxi.c @@ -251,14 +251,14 @@ static int sunxi_musb_init(struct musb *musb) writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0); /* Register notifier before calling phy_init() */ - ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); + ret = devm_extcon_register_notifier(glue->dev, glue->extcon, + EXTCON_USB_HOST, &glue->host_nb); if (ret) goto error_reset_assert; ret = phy_init(glue->phy); if (ret) - goto error_unregister_notifier; + goto error_reset_assert; musb->isr = sunxi_musb_interrupt; @@ -267,9 +267,6 @@ static int sunxi_musb_init(struct musb *musb) return 0; -error_unregister_notifier: - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); error_reset_assert: if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) reset_control_assert(glue->rst); @@ -293,9 +290,6 @@ static int sunxi_musb_exit(struct musb *musb) phy_exit(glue->phy); - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); - if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) reset_control_assert(glue->rst); -- 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 14/17] usb: musb: Add support for optional VBUS irq to dsps glue layer
From: Tony Lindgren We can now configure the PMIC interrupt to provide us VBUS events. In that case we don't need to constantly poll the status and can make it optional. This is only wired up for the mini-B interface on beaglebone. Note that eventually we should get also the connect status for the host interface when the am335x internal PM coprocessor provides us with an IRQ chip. For now, we still need to poll for the host mode status. Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu --- drivers/usb/musb/musb_dsps.c | 117 ++- 1 file changed, 93 insertions(+), 24 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 9542d20b2785..92cf68f8f2c1 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -118,6 +118,7 @@ struct dsps_glue { struct device *dev; struct platform_device *musb; /* child musb pdev */ const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */ + int vbus_irq; /* optional vbus irq */ struct timer_list timer;/* otg_workaround timer */ unsigned long last_timer;/* last timer data for each instance */ bool sw_babble_enabled; @@ -145,6 +146,29 @@ struct dsps_glue { { "mode", 0xe8 }, }; +static void dsps_mod_timer(struct dsps_glue *glue, int wait_ms) +{ + int wait; + + if (wait_ms < 0) + wait = msecs_to_jiffies(glue->wrp->poll_timeout); + else + wait = msecs_to_jiffies(wait_ms); + + mod_timer(&glue->timer, jiffies + wait); +} + +/* + * If no vbus irq from the PMIC is configured, we need to poll VBUS status. + */ +static void dsps_mod_timer_optional(struct dsps_glue *glue) +{ + if (glue->vbus_irq) + return; + + dsps_mod_timer(glue, -1); +} + /** * dsps_musb_enable - enable interrupts */ @@ -167,8 +191,7 @@ static void dsps_musb_enable(struct musb *musb) /* start polling for ID change in dual-role idle mode */ if (musb->xceiv->otg->state == OTG_STATE_B_IDLE && musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE) - mod_timer(&glue->timer, jiffies + - msecs_to_jiffies(wrp->poll_timeout)); + dsps_mod_timer(glue, -1); } /** @@ -198,6 +221,9 @@ static int dsps_check_status(struct musb *musb, void *unused) u8 devctl; int skip_session = 0; + if (glue->vbus_irq) + del_timer(&glue->timer); + /* * We poll because DSPS IP's won't expose several OTG-critical * status change events (from the transceiver) otherwise. @@ -208,8 +234,7 @@ static int dsps_check_status(struct musb *musb, void *unused) switch (musb->xceiv->otg->state) { case OTG_STATE_A_WAIT_VRISE: - mod_timer(&glue->timer, jiffies + - msecs_to_jiffies(wrp->poll_timeout)); + dsps_mod_timer_optional(glue); break; case OTG_STATE_A_WAIT_BCON: musb_writeb(musb->mregs, MUSB_DEVCTL, 0); @@ -218,17 +243,19 @@ static int dsps_check_status(struct musb *musb, void *unused) case OTG_STATE_A_IDLE: case OTG_STATE_B_IDLE: - if (devctl & MUSB_DEVCTL_BDEVICE) { - musb->xceiv->otg->state = OTG_STATE_B_IDLE; - MUSB_DEV_MODE(musb); - } else { - musb->xceiv->otg->state = OTG_STATE_A_IDLE; - MUSB_HST_MODE(musb); + if (!glue->vbus_irq) { + if (devctl & MUSB_DEVCTL_BDEVICE) { + musb->xceiv->otg->state = OTG_STATE_B_IDLE; + MUSB_DEV_MODE(musb); + } else { + musb->xceiv->otg->state = OTG_STATE_A_IDLE; + MUSB_HST_MODE(musb); + } + if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session) + musb_writeb(mregs, MUSB_DEVCTL, + MUSB_DEVCTL_SESSION); } - if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session) - musb_writeb(mregs, MUSB_DEVCTL, MUSB_DEVCTL_SESSION); - mod_timer(&glue->timer, jiffies + - msecs_to_jiffies(wrp->poll_timeout)); + dsps_mod_timer_optional(glue); break; case OTG_STATE_A_WAIT_VFALL: musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; @@ -331,15 +358,13 @@ static irqreturn_t dsps_interrupt(int irq, void *hci) */ musb->int_usb &= ~MUSB_INTR_VBUSERROR; musb->xceiv->otg->state = OTG_STATE_A_WAIT_VFALL; - mod_timer(&glue->timer,
[PATCH 08/17] usb: musb: Add a quirk to preserve the session during suspend
From: Alexandre Bailon On da8xx, VBUS is not maintained during suspend when musb is in host mode. On resume, all the connected devices will be disconnected and then will be enumerated again. This happens because MUSB_DEVCTL is cleared during suspend. Add a quirk to not clear MUSB_DEVCTL and then preserve the session during a suspend. Signed-off-by: Alexandre Bailon Signed-off-by: Bin Liu --- drivers/usb/musb/musb_core.c | 3 ++- drivers/usb/musb/musb_core.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index b1f082f42112..27887189fd14 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2659,7 +2659,8 @@ static int musb_suspend(struct device *dev) musb_platform_disable(musb); musb_disable_interrupts(musb); - musb_writeb(musb->mregs, MUSB_DEVCTL, 0); + if (!(musb->io.quirks & MUSB_PRESERVE_SESSION)) + musb_writeb(musb->mregs, MUSB_DEVCTL, 0); WARN_ON(!list_empty(&musb->pending_list)); spin_lock_irqsave(&musb->lock, flags); diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h index ade902ea1221..ab0c858af9d3 100644 --- a/drivers/usb/musb/musb_core.h +++ b/drivers/usb/musb/musb_core.h @@ -172,6 +172,7 @@ enum musb_g_ep0_state { */ struct musb_platform_ops { +#define MUSB_PRESERVE_SESSION BIT(7) #define MUSB_DMA_UX500 BIT(6) #define MUSB_DMA_CPPI41BIT(5) #define MUSB_DMA_CPPI BIT(4) -- 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 15/17] usb: musb: omap2430: constify dev_pm_ops structures
From: Bhumika Goyal Declare dev_pm_ops structures as const as they are only stored in the pm field of a device_driver structure. This field is of type const, so dev_pm_ops structures having similar properties can be declared const too. Size details after cross compiling the .o file for arm architecture. File size before: drivers/usb/musb/omap2430.o textdata bss dec hex filename 4141 400 8454911c5 usb/musb/omap2430.o File size after: drivers/usb/musb/omap2430.o textdata bss dec hex filename 4333 200 8454111bd usb/musb/omap2430.o Signed-off-by: Bhumika Goyal [b-...@ti.com: added omap2430 in commit subject prefix] Signed-off-by: Bin Liu --- drivers/usb/musb/omap2430.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 8b73214a9ea3..456f3e6ecf03 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -575,7 +575,7 @@ static int omap2430_runtime_resume(struct device *dev) return 0; } -static struct dev_pm_ops omap2430_pm_ops = { +static const struct dev_pm_ops omap2430_pm_ops = { .runtime_suspend = omap2430_runtime_suspend, .runtime_resume = omap2430_runtime_resume, }; -- 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 16/17] usb: musb: sunxi: add support for the variant in H3/V3s SoC
From: Icenowy Zheng Allwinner H3/V3s features a variant of MUSB controller, which lacks one endpoint. Add support for it. Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard [b-...@ti.com: added usb: to commit subject prefix] Signed-off-by: Bin Liu --- .../bindings/usb/allwinner,sun4i-a10-musb.txt | 4 +-- drivers/usb/musb/sunxi.c | 35 -- 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt index 862cd7c79805..d9b42da016f3 100644 --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt @@ -2,8 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller --- Required properties: - - compatible : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb" - or "allwinner,sun8i-a33-musb" + - compatible : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb", + "allwinner,sun8i-a33-musb" or "allwinner,sun8i-h3-musb" - reg : mmio address range of the musb controller - clocks : clock specifier for the musb controller ahb gate clock - reset : reset specifier for the ahb reset (A31 and newer only) diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c index 05cab67d4106..c9a09b5bb6e5 100644 --- a/drivers/usb/musb/sunxi.c +++ b/drivers/usb/musb/sunxi.c @@ -639,6 +639,20 @@ static void sunxi_musb_writew(void __iomem *addr, unsigned offset, u16 data) MUSB_EP_FIFO_SINGLE(5, FIFO_RX, 512), }; +/* H3/V3s OTG supports only 4 endpoints */ +#define SUNXI_MUSB_MAX_EP_NUM_H3 5 + +static struct musb_fifo_cfg sunxi_musb_mode_cfg_h3[] = { + MUSB_EP_FIFO_SINGLE(1, FIFO_TX, 512), + MUSB_EP_FIFO_SINGLE(1, FIFO_RX, 512), + MUSB_EP_FIFO_SINGLE(2, FIFO_TX, 512), + MUSB_EP_FIFO_SINGLE(2, FIFO_RX, 512), + MUSB_EP_FIFO_SINGLE(3, FIFO_TX, 512), + MUSB_EP_FIFO_SINGLE(3, FIFO_RX, 512), + MUSB_EP_FIFO_SINGLE(4, FIFO_TX, 512), + MUSB_EP_FIFO_SINGLE(4, FIFO_RX, 512), +}; + static const struct musb_hdrc_config sunxi_musb_hdrc_config = { .fifo_cfg = sunxi_musb_mode_cfg, .fifo_cfg_size = ARRAY_SIZE(sunxi_musb_mode_cfg), @@ -650,6 +664,18 @@ static void sunxi_musb_writew(void __iomem *addr, unsigned offset, u16 data) .dma= 0, }; +static struct musb_hdrc_config sunxi_musb_hdrc_config_h3 = { + .fifo_cfg = sunxi_musb_mode_cfg_h3, + .fifo_cfg_size = ARRAY_SIZE(sunxi_musb_mode_cfg_h3), + .multipoint = true, + .dyn_fifo = true, + .soft_con = true, + .num_eps= SUNXI_MUSB_MAX_EP_NUM_H3, + .ram_bits = SUNXI_MUSB_RAM_BITS, + .dma= 0, +}; + + static int sunxi_musb_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data pdata; @@ -692,7 +718,10 @@ static int sunxi_musb_probe(struct platform_device *pdev) return -EINVAL; } pdata.platform_ops = &sunxi_musb_ops; - pdata.config= &sunxi_musb_hdrc_config; + if (!of_device_is_compatible(np, "allwinner,sun8i-h3-musb")) + pdata.config = &sunxi_musb_hdrc_config; + else + pdata.config = &sunxi_musb_hdrc_config_h3; glue->dev = &pdev->dev; INIT_WORK(&glue->work, sunxi_musb_work); @@ -704,7 +733,8 @@ static int sunxi_musb_probe(struct platform_device *pdev) if (of_device_is_compatible(np, "allwinner,sun6i-a31-musb")) set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags); - if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb")) { + if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb") || + of_device_is_compatible(np, "allwinner,sun8i-h3-musb")) { set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags); set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, &glue->flags); } @@ -798,6 +828,7 @@ static int sunxi_musb_remove(struct platform_device *pdev) { .compatible = "allwinner,sun4i-a10-musb", }, { .compatible = "allwinner,sun6i-a31-musb", }, { .compatible = "allwinner,sun8i-a33-musb", }, + { .compatible = "allwinner,sun8i-h3-musb", }, {} }; MODULE_DEVICE_TABLE(of, sunxi_musb_match); -- 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 17/17] usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static
From: Wei Yongjun Fixes the following sparse warning: drivers/usb/musb/musb_dsps.c:270:6: warning: symbol 'dsps_musb_clear_ep_rxintr' was not declared. Should it be static? Signed-off-by: Wei Yongjun Signed-off-by: Bin Liu --- drivers/usb/musb/musb_dsps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 92cf68f8f2c1..c171a0f13bc3 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -293,7 +293,7 @@ static void otg_timer(unsigned long _musb) pm_runtime_put_autosuspend(dev); } -void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum) +static void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum) { u32 epintr; struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent); -- 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 net,stable] qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card
On Tue, 2017-01-24 at 10:36 +0100, Bjørn Mork wrote: > Bjørn Mork writes: > > > From: Dan Williams > > Woops! I didn't intend to blame this on you Dan. Sorry. I reused > your > commit message, and obviously unintentionally also the "author" > line... > > But you did create the pattern, so it was only fair to give you the > credit :) Hey, I'll take whatever credit I can get! Dan -- 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