Re: [PATCH v3 2/4] usb: musb: core: added helper function for parsing DT
Alexandre Bailon writes:
> From: Petr Kulhavy
>
> This adds the function musb_get_mode() to get the DT property "dr_mode"
>
> Signed-off-by: Petr Kulhavy
> Acked-by: Sergei Shtylyov
> Signed-off-by: Alexandre Bailon
> Tested-by: David Lechner
> ---
> drivers/usb/musb/musb_core.c | 19 +++
> drivers/usb/musb/musb_core.h | 5 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 27dadc0..bba07e7 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -100,6 +100,7 @@
> #include
> #include
> #include
> +#include
>
> #include "musb_core.h"
> #include "musb_trace.h"
> @@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device
> *dev)
> return dev_get_drvdata(dev);
> }
>
> +enum musb_mode musb_get_mode(struct device *dev)
> +{
> + enum usb_dr_mode mode;
> +
> + mode = usb_get_dr_mode(dev);
> + switch (mode) {
> + case USB_DR_MODE_HOST:
> + return MUSB_HOST;
> + case USB_DR_MODE_PERIPHERAL:
> + return MUSB_PERIPHERAL;
> + case USB_DR_MODE_OTG:
> + case USB_DR_MODE_UNKNOWN:
> + default:
> + return MUSB_OTG;
> + }
> +}
> +EXPORT_SYMBOL_GPL(musb_get_mode);
> +
> /*-*/
>
> #ifndef CONFIG_BLACKFIN
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 2cb88a49..a406468 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -617,4 +617,9 @@ static inline void
> musb_platform_post_root_reset_end(struct musb *musb)
> musb->ops->post_root_reset_end(musb);
> }
>
> +/* gets the "dr_mode" property from DT and converts it into musb_mode
> + * if the property is not found or not recognized returns MUSB_OTG
> + */
nit: multi-line comment style
> +extern enum musb_mode musb_get_mode(struct device *dev);
> +
> #endif /* __MUSB_CORE_H__ */
Otherwise,
Reviewed-by: Kevin Hilman
Kevin
--
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
usbip device reset
Hi there, I struggle with a problem of broken usbip connections. The situation is the following: usbip server: Openwrt (LEDE - kernel 4.4.12) device powered by a battery in the woods connected via wifi to a local network. usbip client: ubuntu 16.04 64bit with self compiled kernel 4.6.2. The usbip server serves a "C-Media Electronics Inc. USB PnP Sound Device". The usbip client uses this device via ALSA for a ffmpeg service. The ffmpeg service gets (re)started by systemd service unit. The ffmpeg writes one vorbis file each day and additionally serves the stream to ffserver. Every now and then (I couldn't find a reason yet) the usbip connection gets lost. Last time the connection was running for nearly 23 days. uptime usbip server: 105 days uptime usbip client: 30 days dmesg on client when the connection gets lost: [2051897.472372] usb usb5: Not yet implemented [2051897.473483] usb usb5: Not yet implemented [2051897.474407] usb usb5: Not yet implemented [2051897.475386] usb usb5: Not yet implemented [2059111.396128] vhci_hcd: connection reset by peer [2059111.396233] vhci_hcd: stop threads [2059111.396242] vhci_hcd: release socket [2059111.396249] vhci_hcd: disconnect device [2059111.396294] usb 5-1: USB disconnect, device number 2 [2059111.396638] vhci_hcd: dequeue a urb 8800b74e4500 [2059111.396644] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396646] vhci_hcd: gives back urb 8800b74e4500 [2059111.396650] vhci_hcd: dequeue a urb 8800b74e4600 [2059111.396652] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396654] vhci_hcd: gives back urb 8800b74e4600 [2059111.396657] vhci_hcd: dequeue a urb 8800b74e4700 [2059111.396659] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396661] vhci_hcd: gives back urb 8800b74e4700 [2059111.396664] vhci_hcd: dequeue a urb 8800b74e4800 [2059111.39] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396668] vhci_hcd: gives back urb 8800b74e4800 [2059111.396671] vhci_hcd: dequeue a urb 8800b74e4900 [2059111.396673] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396675] vhci_hcd: gives back urb 8800b74e4900 [2059111.396678] vhci_hcd: dequeue a urb 8800b74e4c00 [2059111.396680] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396682] vhci_hcd: gives back urb 8800b74e4c00 [2059111.396685] vhci_hcd: dequeue a urb 8800b74e4d00 [2059111.396687] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396689] vhci_hcd: gives back urb 8800b74e4d00 [2059111.396692] vhci_hcd: dequeue a urb 8800b74e4e00 [2059111.396694] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396696] vhci_hcd: gives back urb 8800b74e4e00 [2059111.396699] vhci_hcd: dequeue a urb 8800b74e4f00 [2059111.396701] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396703] vhci_hcd: gives back urb 8800b74e4f00 [2059111.396706] vhci_hcd: dequeue a urb 8800b74e4a00 [2059111.396708] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396710] vhci_hcd: gives back urb 8800b74e4a00 [2059111.396713] vhci_hcd: dequeue a urb 8800b74e4b00 [2059111.396715] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396717] vhci_hcd: gives back urb 8800b74e4b00 [2059111.396720] vhci_hcd: dequeue a urb 880024029b00 [2059111.396722] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396724] vhci_hcd: gives back urb 880024029b00 [2059111.396871] vhci_hcd: dequeue a urb 88009e1a4a80 [2059111.396873] vhci_hcd: device 8800d6e6a290 seems to be disconnected [2059111.396876] vhci_hcd: gives back urb 88009e1a4a80 usbip server: [5242788.550105] wlan0: authenticate with 70:62:b8:2f:4f:9e [5242788.565693] wlan0: send auth to 70:62:b8:2f:4f:9e (try 1/3) [5242788.572561] wlan0: authenticated [5242788.577715] wlan0: associate with 70:62:b8:2f:4f:9e (try 1/3) [5242788.586829] wlan0: RX AssocResp from 70:62:b8:2f:4f:9e (capab=0x431 status=0 aid=1) [5242788.593625] wlan0: associated [5382075.114791] usbip-host 1-1: unlink urb 81a37f00 [5382075.118279] usbip-host 1-1: failed to unlink a urb 81a37f00, ret -36 [5560060.290463] usbip-host 1-1: recv a header, 0 [5560060.296580] usbip-host 1-1: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection [5560060.417659] usbip-host 1-1: reset full-speed USB device number 2 using ehci-platform [5560060.572063] usbip-host 1-1: device reset [5560060.578758] usbip-host 1-1: stub up [5560060.807346] usbip-host 1-1: recv a header, 0 [5560060.937658] usbip-host 1-1: reset full-speed USB device number 2 using ehci-platform [5560061.092057] usbip-host 1-1: device reset [5560061.098889] usbip-host 1-1: stub up [6418039.358832] usbip-host 1-1: recv a header, 0 [6418040.377649] usbip-host 1-1: lock for reset [6418096.387835] usbip-host 1-1: usbip-host: register new dev
Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahas...@baylibre.com wrote: > From: Axel Haslam > > Some regulator supplies have an over-current pin that is > activated when the hw detects an over current condition. > When this happens, the hardware enters a current limited > mode. > > Extend the fixed regulator driver with the ability > to handle irq's from the over-current pin and report > an over current event to the consumers via a regulator > notifier. Also, add device tree bindings to allow to > pass a gpio for over current monitoring. > > Signed-off-by: Axel Haslam > --- > .../bindings/regulator/fixed-regulator.txt | 4 ++ > drivers/regulator/fixed.c | 64 > ++ > include/linux/regulator/consumer.h | 5 ++ > include/linux/regulator/fixed.h| 3 + > 4 files changed, 76 insertions(+) > > diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt > b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt > index 4fae41d..d20bf67 100644 > --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt > +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt > @@ -11,6 +11,8 @@ If this property is missing, the default assumed is Active > low. > - gpio-open-drain: GPIO is open drain type. >If this property is missing then default assumption is false. > -vin-supply: Input supply name. > +- oc-gpio: Input gpio that signals an over current condition "-gpios" is the preferred form. So "oc-gpios". > +- oc-active-high: The polarity of the over current pin is high This should be specified in the gpio flags cell. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Fri, Oct 28 2016, Baolin Wang wrote: >> >> 3/ usb_charger_notify_state() does nothing if the state doesn't change. >> When the extcon detects an SDP, it will be called to set the state >> to USB_CHARGER_PRESENT. The value of cur.sdp_max will be whatever >> it happened to be before, which is probably wrong. > > Sorry, I did not get your points here, could you please explain it explicitly? usb_charger_get_current() is used to get the min/max current that is supported. In the case that an SDP (non-super-speed) has been detected it will report the values sdp_min and sdp_max. Ignoring usb_charger_set_current(), sdp_max is set - to DEFAULT_SDP_CUR_MAX (500) at initializaion - to cur_limit when usb_charger_set_cur_limit_by_gadget() is called which happens after USB negotiation, once an allowed vbus_draw is negotiated. This means that the first time you plug in an SDP cable, the reported max will be 500, even though nothing has been negotiated. The maximum before negotiation is much less than that - I don't remember exactly how much. If negotiation completes, the sdp_max will be set to whatever was negotiated. Maybe 200mA. If you unplug, and then plug another SDP cable in, the sdp_max will still be 200mA - different from the first time, but still not correct. It will remain incorrect until (and unless) USB negotiation completes. > >> When after USB negotiation completes, >> usb_charger_set_cur_limit_by_gadget() >> will call into usb_charger_notify_state() to set USB_CHARGER_PRESENT >> again, but with a new current. This will be ignored, as the state is >> already USB_CHARGER_PRESENT. > > No, we will notify the user the current has been changed by one work. I can see no evidence in the code to justify this assertion, and you didn't even try to provide any. > >> >> 4/ I still strongly object to the ->get_charger_type() interface. >> You previously said: >> >> No. User can implement the get_charger_type() method to access the >> PMIC registers to get the charger type, which is one very common method. >> >> I suggest that if the PMIC registers report the charger type, then the >> PMIC driver should register an EXTCON and report the charger type >> through that. Then the information would be directly available to >> user-space, and the usb-charger framework would have a single uniform >> mechanism for being told the cable type. > > We just access only one PMIC register to get the charger type, which > is no need add one driver for that and there are no any events for > extcon. Some sample code in power driver can be like below: If there are no events, then how do you know when a charger has been plugged in? Do you poll? In any case, one of the major values provided by using an OS like Linux is uniform interfaces. If a device can detect what sort of cable is inserted, then that information should be presented as an EXTCON. >> >> Related: I don't like charger_type_show(). I don't think >> the usb-charger should export that information to user-space because >> extcon already does that, and duplication is confusing and pointless. > > I think we should combine all charger related information into one > place for user. Moreover if we don't get charger type from extcon, we > should also need one place to export the charger type. Yes and no. Certainly a uniform consistent interface should be presented. "a usb charger" is not the right abstraction. It is not a thing that should have independent existence. To everybody else in the world, a "usb charger" in a box that you plug into the wall, and which has a cable to plug into your device. It is not part of the device itself. In general, you cannot point to any component in a device that is the "usb charger" so it isn't clear that Linux should even know about a "usb charger". There is a battery-charger which can take whatever current is available and feed it to the battery. It may well be appropriate for user-space to have fine control of the current that this uses quite independently of whatever is plugged in (I have a board which can get the current via USB or via a more direct connection). There is also a USB PHY which can detect when a cable is plugged in (possibly just because 5V appears on VBUS) and can usually detect some details of the cable. It should report, via the EXTCON interface, the presence and type of the cable. Maybe these are all in the one integrated circuit, maybe not. On the board I have, the one IC includes the USB phy, the battery charger, the audio codec, some regulators, some GPIOs and other stuff. We have separate drivers for each logical component, unified by an "mfd" driver. From the interface design perspective, the number of ICs doesn't matter at all. The interface presented, both within the kernel and out to user-space, should be consistent. Every USB port should present with an EXTCON, and if it can detect types of cables, those cable types should be visible in th
Re: [dmesg] usb 2-1.5:1.0: rebind failed: -517
On Sat, Oct 29, 2016 at 03:53:24PM -0300, Cristian wrote: > Hello, > > Report in https://bugzilla.kernel.org/show_bug.cgi?id=185591 > You may provide more information about bug, eg, how to trigger the bug, the frequency of the bug? "-517" is -EPROBE_DEFER, it means some resources for this device are not ready. -- 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
[PATCH 1/1] usb: chipidea: move the lock initialization to core file
This can fix below dump when the lock is accessed at host mode due to it is not initialized. root@imx6qdlsolo:~# cat /sys/kernel/debug/ci_hdrc.1/port_test [ 929.904518] INFO: trying to register non-static key. [ 929.909536] the code is fine but needs lockdep annotation. [ 929.915043] turning off the locking correctness validator. [ 929.920567] CPU: 0 PID: 687 Comm: cat Not tainted 4.9.0-rc1-00064-g903de10 #1155 [ 929.927987] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 929.934189] Backtrace: [ 929.936719] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 929.944312] r7:de47a000[ 929.946690] r6:6193 r5:[ 929.950322] r4:c0e2346c [ 929.952883] [ 929.954413] [] (show_stack) from [] (dump_stack+0xb4/0xe8) [ 929.961675] [] (dump_stack) from [] (register_lock_class+0x4fc/0x56c) [ 929.969871] r10:c0e23564[ 929.972335] r9:de47be70 r8:c163f444[ 929.975967] r7:ddcd4024 r6:[ 929.979598] r5: [ 929.982158] r4:[ 929.984534] r3:0001 [ 929.987092] [ 929.988622] [] (register_lock_class) from [] (__lock_acquire+0x80/0x10f0) [ 929.997166] r10:c0e23564[ 929.999632] r9:de47be70 r8:ddcd4024[ 930.003265] r7:c163f444 r6:ddec3c00[ 930.006898] r5:6193 [ 930.009458] r4:[ 930.011832] [ 930.013368] [] (__lock_acquire) from [] (lock_acquire+0x74/0x94) [ 930.021129] r10:0001[ 930.023594] r9:de47be70 r8:de47bf80[ 930.027225] r7:0001 r6:0001[ 930.030857] r5:6193 [ 930.033417] r4:[ 930.035791] [ 930.037329] [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x40/0x54) [ 930.045787] r7:dddb3c80[ 930.048163] r6:c062a468 r5:2113[ 930.051795] r4:ddcd4014 [ 930.054354] [ 930.055885] [] (_raw_spin_lock_irqsave) from [] (ci_port_test_show+0x2c/0x70) [ 930.064776] r6:ddd930c0[ 930.067153] r5:ddcd4010 r4:ddcd4014[ 930.070783] [ 930.072329] [] (ci_port_test_show) from [] (seq_read+0x1ac/0x4f8) [ 930.080179] r9:de47be70[ 930.082555] r8:de47bf80 r7:dddb3c80[ 930.086188] r6:0001 r5:[ 930.089820] r4:ddd930c0 [ 930.092404] [] (seq_read) from [] (full_proxy_read+0x54/0x6c) [ 930.099907] r10:[ 930.102372] r9:c0a6ad70 r8:de47bf80[ 930.106004] r7:0002 r6:b6dd1000[ 930.109636] r5:dddb3c80 [ 930.112197] r4:c0248ed8[ 930.114572] [ 930.116110] [] (full_proxy_read) from [] (__vfs_read+0x34/0x118) [ 930.123872] r9:de47a000[ 930.126250] r8:c0107fc4 r7:0002[ 930.129883] r6:de47bf80 r5:c039eb88[ 930.133515] r4:dddb3c80 [ 930.136091] [] (__vfs_read) from [] (vfs_read+0x8c/0x11c) [ 930.143247] r9:de47a000[ 930.145625] r8:c0107fc4 r7:de47bf80[ 930.149259] r6:b6dd1000 r5:dddb3c80[ 930.152891] r4:0002 [ 930.155469] [] (vfs_read) from [] (SyS_read+0x4c/0xa8) [ 930.162363] r8:c0107fc4[ 930.164741] r7:0002 r6:b6dd1000[ 930.168373] r5:dddb3c80 r4:dddb3c80[ 930.172001] [ 930.173540] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x1c) [ 930.181041] r7:0003[ 930.183419] r6:b6dd1000 r5:0002[ 930.187051] r4:0002 [ 930.189611] mode = 0 Cc: #v4.1+ Signed-off-by: Peter Chen --- drivers/usb/chipidea/core.c | 1 + drivers/usb/chipidea/udc.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index a7d2c68..c5e7f3d 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -873,6 +873,7 @@ static int ci_hdrc_probe(struct platform_device *pdev) if (!ci) return -ENOMEM; + spin_lock_init(&ci->lock); ci->dev = dev; ci->platdata = dev_get_platdata(dev); ci->imx28_write_fix = !!(ci->platdata->flags & diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 1e0ffad..e7bd064 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1886,8 +1886,6 @@ static int udc_start(struct ci_hdrc *ci) struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps; int retval = 0; - spin_lock_init(&ci->lock); - ci->gadget.ops = &usb_gadget_ops; ci->gadget.speed= USB_SPEED_UNKNOWN; ci->gadget.max_speed= USB_SPEED_HIGH; -- 2.7.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/1] usb: phy: phy-generic: add the implementation of .set_suspend
Add clock operation at .set_suspend if the PHY has
suspend requirement, it can be benefit of power saving for
phy and the whole system (parent clock may also be disabled).
Signed-off-by: Peter Chen
---
drivers/usb/phy/phy-generic.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 8311ba2..89d6e7a 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -59,6 +59,15 @@ EXPORT_SYMBOL_GPL(usb_phy_generic_unregister);
static int nop_set_suspend(struct usb_phy *x, int suspend)
{
+ struct usb_phy_generic *nop = dev_get_drvdata(x->dev);
+
+ if (!IS_ERR(nop->clk)) {
+ if (suspend)
+ clk_disable_unprepare(nop->clk);
+ else
+ clk_prepare_enable(nop->clk);
+ }
+
return 0;
}
--
2.7.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
Re: [PATCH v7, 0/8] Add MediaTek USB3 DRD Driver
On Fri, 2016-10-28 at 12:37 +0200, Matthias Brugger wrote: > Hi Chunfeng, > > On 10/19/2016 04:28 AM, Chunfeng Yun wrote: > > These patches introduce the MediaTek USB3 dual-role controller > > driver. > > > > The driver can be configured as Dual-Role Device (DRD), > > Peripheral Only and Host Only (xHCI) modes. It works well > > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is > > tested on MT8173 platform which only contains USB2.0 device IP, > > and on MT6290 platform which contains USB3.0 device IP. [...] > > > > Change in v2: > > 1. modify binding docs according to suggestions > > 2. modify some comments and remove some dummy blank lines > > 3. fix memory leakage > > > > > > Chunfeng Yun (8): > > dt-bindings: mt8173-xhci: support host side of dual-role mode > > dt-bindings: mt8173-mtu3: add devicetree bindings > > usb: xhci-mtk: make IPPC register optional > > usb: Add MediaTek USB3 DRD driver > > usb: mtu3: Super-Speed Peripheral mode support > > usb: mtu3: host only mode support > > usb: mtu3: dual-role mode support > > arm64: dts: mediatek: add USB3 DRD driver > > > > I tried the driver with my mt8173-evb, but wasn't able to get USB > working (no usb stick detected when adding to the usb port). > Can you test it again by USB3.0 type-A port? If it works, then regulators of vusb33 and vbus are got after PROBE_DEFER of mt6397-regulator driver; For OTG port, need cherry pick a patch: https://patchwork.kernel.org/patch/9055261/ which is abandoned because GPIO driver owner wants to fix all pins with the same problem. Then device will be recognized well when connected to PC with OTG cable. But it is a trouble for OTG host mode, due to vbus 5.5V of OTG port is originally provided by charger driver which is not upstreamed on EVB board, we need rework the board to control vbus by gpio. There is a simple way, you can plug in a self-powered hub to test OTG host mode. > # dmesg |grep mtu > [0.428420] mtu3 11271000.usb: failed to get vusb33 > [0.510570] mtu3 11271000.usb: failed to get vbus > [0.592103] mtu3 11271000.usb: failed to get vbus > > > Relevant config options: > CONFIG_USB_MTU3=y > CONFIG_USB_MTU3_HOST=y > CONFIG_USB_MTU3_DEBUG=y > CONFIG_PHY_MT65XX_USB3=y > > > Looks like an error in the device tree. I can see that the mt6397 > regulater get's initialized *after* the mtu3 driver: > [0.505166] mt6397-regulator mt6397-regulator: Chip ID = 0x4097 > > Not sure if this is related. > Any idea whats going wrong here? > as above. Sorry for inconvenience > Cheers, > Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
On Thu, Oct 27, 2016 at 11:34:04AM +0200, Alexandre Bailon wrote: > From: Petr Kulhavy > > DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver. > > Signed-off-by: Petr Kulhavy > Signed-off-by: Alexandre Bailon > --- > .../devicetree/bindings/usb/da8xx-usb.txt | 43 > ++ > 1 file changed, 43 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
