Re: cdc_mbim with Huawei E3372, nothing works
On Mon, Feb 23, 2015 at 11:59:14 +0100, Bjørn Mork wrote: > Aleksander Morgado writes: > > > On Tue, Feb 17, 2015 at 4:32 PM, Sami Farin > > wrote: > >> ifconfig > >> wwp3s0u1c2: flags=4291 mtu 1500 > >> inet 46.132.188.224 netmask 255.255.255.192 broadcast > >> 46.132.188.255 > >> inet6 fe80:: prefixlen 64 scopeid 0x20 > >> ether 32:35:3a:64:2e:25 txqueuelen 1000 (Ethernet) > >> RX packets 0 bytes 0 (0.0 B) > >> RX errors 17764 dropped 0 overruns 0 frame 0 > >> TX packets 6714 bytes 18446744073709268911 (1638.3 PiB) > >> TX errors 1427 dropped 0 overruns 0 carrier 0 collisions 0 > >> > > > > That's a ton of RX errors in there, and an... unusual number of TX > > bytes as well. > > > > Bjørn, any idea? > > Not really... > > The TX bytes definitely looks we managed to end up with a negative > count: 18446744073709268911 = 2^64 - 282705 > > Which I guess means that my new attempt to "correct" the tx_bytes > counter in cdc_ncm_fill_tx_frame() must have gone bananas. Hmm, looks > like that will happen if we fail to submit the urb for some reason. We ... Now with kernel 4.0.0+ModemManager 1.4.8: wwp5s0u1c2: flags=4291 mtu 1500 inet 46.132.185.141 netmask 255.255.255.252 broadcast 46.132.185.143 ether 4a:2a:90:69:e7:ad txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 13 dropped 0 overruns 0 frame 0 TX packets 239 bytes 588410534190 (548.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wwp5s0u1c2: flags=4291 mtu 1500 inet 46.132.185.141 netmask 255.255.255.252 broadcast 46.132.185.143 ether 4a:2a:90:69:e7:ad txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 14 dropped 0 overruns 0 frame 0 TX packets 240 bytes 592705501549 (552.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 so it's messing up passing of errors, 592705501549-588410534190=4294967359 2^32-4294967359=-63 -- -- 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] [RFC] usb: xhci: Add to check CRR bit in xhci_suspend()
According to the xHCI spec "4.23.2 xHCI Power Management", the CRR bit
of CRCR register should be zero before setting Run/Stop (R/S) = '0'.
Otherwise, the STS_HALT is not set until the CRR is cleared on specific
xHCI controllers. In case of R-Car SoCs, it spent about 90 ms to clear
the CRR. So, to avoid the quirks XHCI_SLOW_SUSPEND, the driver calls
the aborting function if the CRR is set to 1.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/host/xhci-ring.c | 2 +-
drivers/usb/host/xhci.c | 21 -
drivers/usb/host/xhci.h | 1 +
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index f5397a5..21f3932 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -280,7 +280,7 @@ void xhci_ring_cmd_db(struct xhci_hcd *xhci)
readl(&xhci->dba->doorbell[0]);
}
-static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
+int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
{
u64 temp_64;
int ret;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..d2d81a0 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -892,7 +892,7 @@ static void xhci_disable_port_wake_on_bits(struct xhci_hcd
*xhci)
*/
int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
- int rc = 0;
+ int rc = 0, ret;
unsigned intdelay = XHCI_MAX_HALT_USEC;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
u32 command;
@@ -918,6 +918,25 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
/* step 1: stop endpoint */
/* skipped assuming that port suspend has done */
+ /*
+* According to the xHCI spec "4.23.2 xHCI Power Management", the CRR
+* bit of CRCR register should be zero before setting Run/Stop (R/S) =
+* '0', the driver calls the aborting function if the CRR is set to 1.
+*/
+ if (xhci_read_64(xhci, &xhci->op_regs->cmd_ring) & CMD_RING_RUNNING) {
+ /* unlock here because this may wait about 5 seconds */
+ spin_unlock_irq(&xhci->lock);
+ ret = xhci_abort_cmd_ring(xhci);
+ if (unlikely(ret == -ESHUTDOWN)) {
+ xhci_err(xhci, "Abort command ring failed\n");
+ xhci_cleanup_command_queue(xhci);
+ usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
+ xhci_dbg(xhci, "xHCI host controller is dead.\n");
+ return ret;
+ }
+ spin_lock_irq(&xhci->lock);
+ }
+
/* step 2: clear Run/Stop bit */
command = readl(&xhci->op_regs->command);
command &= ~CMD_RUN;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 8e421b8..c861bf0 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1796,6 +1796,7 @@ struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
union xhci_trb *end_trb, dma_addr_t suspect_dma, bool debug);
int xhci_is_vendor_info_code(struct xhci_hcd *xhci, unsigned int
trb_comp_code);
void xhci_ring_cmd_db(struct xhci_hcd *xhci);
+int xhci_abort_cmd_ring(struct xhci_hcd *xhci);
int xhci_queue_slot_control(struct xhci_hcd *xhci, struct xhci_command *cmd,
u32 trb_type, u32 slot_id);
int xhci_queue_address_device(struct xhci_hcd *xhci, struct xhci_command *cmd,
--
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
Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi, My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG Controllers. a) If no one is working, we have interest to start developing them b) If there is someone already developing them, we have interest in collaborating with the on going work Thanks, Joao Pinto -- 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] usbhid: Add a quirk for raphnet multi-gamepad adapters
On Sat, 25 Apr 2015, Raphael Assenat wrote: > The raphnet.net 4nes4snes and 2nes2snes multi-joystick adapters use a > single HID report descriptor with one report ID per controller. This > has the effect that the inputs of otherwise independent game controllers > get packed in one large joystick device. > > With this patch each controller gets its own /dev/input/jsX device, > which is more natural and less confusing than having all inputs going > to the same place. Applied, thanks. -- Jiri Kosina SUSE Labs -- 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: [BUG] xhci_hcd: intermittent bug with VL812 hub: Bad Slot ID 2 Could not allocate xHCI USB device data structures
On Sat, Apr 25, 2015 at 10:39:23PM +0100, Chris Bainbridge wrote: > Kernel: v4.0-10710-g27cf3a1 > > Hardware: > > IvyBridge Macbook (Panther Point PCH), 2 external USB3 ports > AmazonBasics 10 Port USB 3.0 Hub (3x VIA VL812 hub controllers) > > Bug: > > In ~7%-10% of boots there is an error: > > [0.604801] xhci_hcd :00:14.0: Bad Slot ID 2 > [0.604802] xhci_hcd :00:14.0: Could not allocate xHCI USB > device data structures > [0.604805] usb usb1-port3: couldn't allocate usb_device > > When this happens, no USB2 devices will be detected on the hub - the > three USB2 hub controllers (2109:2812) from the hub are not detected. > > This problem does not seem to occur in OS X: on 60 boots the USB2 > devices appeared every time. I'm also getting this with 3.19.5: [0.812455] xhci_hcd :00:14.0: Bad Slot ID 2 [0.813104] xhci_hcd :00:14.0: Could not allocate xHCI USB device data structures [0.813756] usb usb1-port4: couldn't allocate usb_device This could be a regression in 3.19 as I've never come across this before. It happened on the first boot with 3.19 and I immediately reverted to 3.18 (this is my main machine) so not sure if it happens on every boot. This is with an "Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)" controller and the external USB 3.0 hub in my monitor (0451:8042 Texas Instruments, Inc. Hub): /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 6: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M I don't seem to be able to reproduce it on a different machine (but perhaps I didn't try hard enough if it is indeed intermittent). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: ether: Fix MAC address parsing
MAC address is often written without leading zeros. Example: 00:14:3d:0f:ff:fe can be written as 0:14:3d:f:ff:fe Convention of skipping leading zeros is used in libc. enther_ntoa_r() generates MAC address without leading zeros. Fix get_ether_addr() to correctly parse MAC address with and without leading zeros. Signed-off-by: Krzysztof Opasiak --- drivers/usb/gadget/function/u_ether.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c index f1fd777..1e3ee2a 100644 --- a/drivers/usb/gadget/function/u_ether.c +++ b/drivers/usb/gadget/function/u_ether.c @@ -713,9 +713,11 @@ static int get_ether_addr(const char *str, u8 *dev_addr) if ((*str == '.') || (*str == ':')) str++; - num = hex_to_bin(*str++) << 4; - num |= hex_to_bin(*str++); - dev_addr [i] = num; + + num = hex_to_bin(*str++); + if ((*str != '.') && (*str != ':')) + num = num << 4 | hex_to_bin(*str++); + dev_addr[i] = num; } if (is_valid_ether_addr(dev_addr)) return 0; -- 1.7.9.5 -- 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: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()
Hi Sasha,
On Wed, Apr 08, 2015 at 05:29:16PM +, Mark Enstone wrote:
> Everyone, thank you for your attention and suggestions.
>
> Johan, perfect, thank you, that did indeed help and has fixed the
> issue I was seeing.
>
> The change replaced dev_err() with dev_dbg() -- thus not logging (by
> default) what was a very noisy flood of messages. Does that simply
> change timing enough such that the USB HCD has time to process the
> disconnect? Or is there something else going on that I'm missing?
> > -Original Message-
> > From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
> > Sent: Tuesday, April 07, 2015 2:58 PM
> > To: Mark Enstone
> > Cc: linux-usb@vger.kernel.org
> > Subject: Re: Question: drivers/usb/serial/generic.c:
> > usb_serial_generic_read_bulk_callback()
> > Could you try updating to 3.19 (or later) or to cherry pick aa8e22128b40
> > ("usb: serial: silence all non-critical read errors") and see if that helps?
> >
> > We should backport that one to stable either way.
You may want to add aa8e22128b40 ("usb: serial: silence all non-critical
read errors") to 3.18-stable as it fixes a lock-up-on-disconnect
regression with at least two controllers (3.15 through 3.18 are
affected).
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cdc_mbim with Huawei E3372, nothing works
Sami Farin writes: > Now with kernel 4.0.0+ModemManager 1.4.8: > > wwp5s0u1c2: flags=4291 mtu 1500 > inet 46.132.185.141 netmask 255.255.255.252 broadcast 46.132.185.143 > ether 4a:2a:90:69:e7:ad txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 13 dropped 0 overruns 0 frame 0 > TX packets 239 bytes 588410534190 (548.0 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > wwp5s0u1c2: flags=4291 mtu 1500 > inet 46.132.185.141 netmask 255.255.255.252 broadcast 46.132.185.143 > ether 4a:2a:90:69:e7:ad txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 14 dropped 0 overruns 0 frame 0 > TX packets 240 bytes 592705501549 (552.0 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > so it's messing up passing of errors, 592705501549-588410534190=4294967359 > 2^32-4294967359=-63 Argh. I thought this was fixed now. We do mix a lot of signed and unsigned integers of different sizes while calculating the tx_bytes delta. I guess that goes wrong somewhere. Will try to clean up. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] xhci_hcd: intermittent bug with VL812 hub: Bad Slot ID 2 Could not allocate xHCI USB device data structures
On 27.04.2015 12:30, Johan Hovold wrote: > On Sat, Apr 25, 2015 at 10:39:23PM +0100, Chris Bainbridge wrote: >> Kernel: v4.0-10710-g27cf3a1 >> >> Hardware: >> >> IvyBridge Macbook (Panther Point PCH), 2 external USB3 ports >> AmazonBasics 10 Port USB 3.0 Hub (3x VIA VL812 hub controllers) >> >> Bug: >> >> In ~7%-10% of boots there is an error: >> >> [0.604801] xhci_hcd :00:14.0: Bad Slot ID 2 >> [0.604802] xhci_hcd :00:14.0: Could not allocate xHCI USB >> device data structures >> [0.604805] usb usb1-port3: couldn't allocate usb_device >> >> When this happens, no USB2 devices will be detected on the hub - the >> three USB2 hub controllers (2109:2812) from the hub are not detected. >> >> This problem does not seem to occur in OS X: on 60 boots the USB2 >> devices appeared every time. > Does reverting commit 6fecd4f2a58c60028b1a75deefcf111516d3f836 USB: separate usb_address0 mutexes for each bus Help? The "Bad Slot ID 2" followed by "Could not allocate xHCI USB device data structures" is shown if we try to allocate device data structure for an already existing device. We rely on a couple xhci wide variables during device enabling, xhci->addr_dev and xhci->slot_id, and also rely on them being protected by the usb_address0 mutex. As xhci handles both a USB-2 and USB-3 bus and the mutex was changed to be per bus it's possible that xhci->addr_dev and xhci_>slot_id race. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libusbg: print leading zero for MAC address bytes
Hello Stefan, On 04/24/2015 09:27 PM, Stefan Agner wrote: The ethernet gadget driver requires the hex formatted MAC address bytes with leading zero, in other words each byte needs to be two characters in length (see get_ether_addr in u_ether.c). The libc implementation ether_ntoa does not print leading zeros. Hence use our own implementation which provides the format expected by the kernel. Signed-off-by: Stefan Agner Reviewed-by: Krzysztof Opasiak Thank you for your patch. Very good catch. I haven't noticed this earlier. In my opinion kernel should accept MAC address without leading 0 so I have prepared a patch with this[1]. But of course for compatibility with older kernels your commit should be applied. Together with a few other libusbg community members we continue development in my github repo[2]. As we are almost 100 commits ahead I had to rebase your patch with some changes before applying it to my tree. That's why you will find my signoff instead of reviewed-by on your commit in my tree[3]. Footnotes: 1 - http://article.gmane.org/gmane.linux.usb.general/125080 2 - https://github.com/kopasiak/libusbg 3 - https://github.com/kopasiak/libusbg/commit/93631e618436989ebd7e9df2c997c175feb14bda Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Revert "usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap"
This reverts commit 70843f623b58 ("usb: host: ehci-msm: Use
devm_ioremap_resource instead of devm_ioremap") and commit
e507bf577e5a ("host: ehci-msm: remove duplicate check on resource"),
because msm_otg and this driver are using same address space to
access AHB mode and USB command registers.
Cc: Vivek Gautam
Signed-off-by: Ivan T. Ivanov
---
Changes since v0:
* Add note to patch description that also commit e507bf577e5a is reverted.
drivers/usb/host/ehci-msm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..275c92e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd->regs = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(hcd->regs)) {
- ret = PTR_ERR(hcd->regs);
+ if (!res) {
+ dev_err(&pdev->dev, "Unable to get memory resource\n");
+ ret = -ENODEV;
goto put_hcd;
}
+
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
+ hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
+ if (!hcd->regs) {
+ dev_err(&pdev->dev, "ioremap failed\n");
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
/*
* OTG driver takes care of PHY initialization, clock management,
--
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] [RFC] usb: xhci: Add to check CRR bit in xhci_suspend()
On 27.04.2015 11:55, Yoshihiro Shimoda wrote:
Hi
> According to the xHCI spec "4.23.2 xHCI Power Management", the CRR bit
> of CRCR register should be zero before setting Run/Stop (R/S) = '0'.
> Otherwise, the STS_HALT is not set until the CRR is cleared on specific
> xHCI controllers. In case of R-Car SoCs, it spent about 90 ms to clear
> the CRR. So, to avoid the quirks XHCI_SLOW_SUSPEND, the driver calls
> the aborting function if the CRR is set to 1.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/usb/host/xhci-ring.c | 2 +-
> drivers/usb/host/xhci.c | 21 -
> drivers/usb/host/xhci.h | 1 +
> 3 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index f5397a5..21f3932 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -280,7 +280,7 @@ void xhci_ring_cmd_db(struct xhci_hcd *xhci)
> readl(&xhci->dba->doorbell[0]);
> }
>
> -static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
> +int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
> {
> u64 temp_64;
> int ret;
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index ec8ac16..d2d81a0 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -892,7 +892,7 @@ static void xhci_disable_port_wake_on_bits(struct
> xhci_hcd *xhci)
> */
> int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
> {
> - int rc = 0;
> + int rc = 0, ret;
> unsigned intdelay = XHCI_MAX_HALT_USEC;
> struct usb_hcd *hcd = xhci_to_hcd(xhci);
> u32 command;
> @@ -918,6 +918,25 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
> /* step 1: stop endpoint */
> /* skipped assuming that port suspend has done */
>
> + /*
> + * According to the xHCI spec "4.23.2 xHCI Power Management", the CRR
> + * bit of CRCR register should be zero before setting Run/Stop (R/S) =
> + * '0', the driver calls the aborting function if the CRR is set to 1.
> + */
> + if (xhci_read_64(xhci, &xhci->op_regs->cmd_ring) & CMD_RING_RUNNING) {
> + /* unlock here because this may wait about 5 seconds */
> + spin_unlock_irq(&xhci->lock);
> + ret = xhci_abort_cmd_ring(xhci);
Would it work for R-Car if we instead of unlocking and and aborting the command
just wait for
the CRR bit to turn 0 before setting Run/stop = 0?
Aborting the command ring by setting CA bit in CRCR will generate a command
abort/stop completion event,
which will point to the stopped/aborted event on the command ring. We are
however clearing the command
ring completely in xhci_suspend() right after this, and setting the dequeue
pointer to the beginning of
the ring. This will likely mess with the handling of the abort/stop event.
Waiting for the CRR to clear could be done using:
xhci_handshake(&xhci->op_regs->cmd_ring, CMD_RING_RUNNING, timeout)
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
On Mon, Apr 27, 2015 at 09:59:19AM +0100, Joao Pinto wrote: > Hi, > > My name is Joao Pinto and I am working at Synopsys as a Software Engineer > mainly > in the USB Subsystem. > > I am sending you this email in order to know if someone is already working in > the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG > Controllers. Have you looked at the latest kernel tree to verify what is and is not supported? That's your best source of information. > a) If no one is working, we have interest to start developing them Don't you already have internal code for these chips? Have you tested Linux with them? > b) If there is someone already developing them, we have interest in > collaborating with the on going work Look at the changelog entries for the drivers for these chips, that should give you the information you need here. But really, running the latest kernel and seeing what doesn't work for your hardware, and sending patches to fix this is the best way forward, don't you agree? 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: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()
On 04/27/2015 05:44 AM, Johan Hovold wrote:
>>> Could you try updating to 3.19 (or later) or to cherry pick aa8e22128b40
>>> > > ("usb: serial: silence all non-critical read errors") and see if that
>>> > > helps?
>>> > >
>>> > > We should backport that one to stable either way.
> You may want to add aa8e22128b40 ("usb: serial: silence all non-critical
> read errors") to 3.18-stable as it fixes a lock-up-on-disconnect
> regression with at least two controllers (3.15 through 3.18 are
> affected).
I've added it to the queue, thanks!
Thanks,
Sasha
--
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] Revert "usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap"
On Mon, 27 Apr 2015, Ivan T. Ivanov wrote:
> This reverts commit 70843f623b58 ("usb: host: ehci-msm: Use
> devm_ioremap_resource instead of devm_ioremap") and commit
> e507bf577e5a ("host: ehci-msm: remove duplicate check on resource"),
> because msm_otg and this driver are using same address space to
> access AHB mode and USB command registers.
>
> Cc: Vivek Gautam
> Signed-off-by: Ivan T. Ivanov
> ---
>
> Changes since v0:
>
> * Add note to patch description that also commit e507bf577e5a is reverted.
>
> drivers/usb/host/ehci-msm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
> index 9db74ca..275c92e 100644
> --- a/drivers/usb/host/ehci-msm.c
> +++ b/drivers/usb/host/ehci-msm.c
> @@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device *pdev)
> }
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - hcd->regs = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(hcd->regs)) {
> - ret = PTR_ERR(hcd->regs);
> + if (!res) {
> + dev_err(&pdev->dev, "Unable to get memory resource\n");
> + ret = -ENODEV;
> goto put_hcd;
> }
> +
> hcd->rsrc_start = res->start;
> hcd->rsrc_len = resource_size(res);
> + hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
> + if (!hcd->regs) {
> + dev_err(&pdev->dev, "ioremap failed\n");
> + ret = -ENOMEM;
> + goto put_hcd;
> + }
>
> /*
>* OTG driver takes care of PHY initialization, clock management,
> --
> 1.9.1
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZLP sending request from gadget
On Mon, Apr 27, 2015 at 10:57:24AM +0530, Anjana V Kumar wrote: > Hi Balbi, > > This is regarding the gadget serial (serial.c) deciding to send the > ZLP by setting req->zero to 1/0. > > The udc driver in our case decides to send the ZLP based on the > req->zero value set by the gadget. > > But we see that the serial gadget driver does not set req->zero. But > others like u_ether and f_massstorage are setting the same. > > Is there any specific reason why this is not done in gadget serial ? maybe a bug ? No idea off the top of my head. -- balbi signature.asc Description: Digital signature
Re: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi Greg, On 4/27/2015 3:27 PM, Greg KH wrote: > On Mon, Apr 27, 2015 at 09:59:19AM +0100, Joao Pinto wrote: >> Hi, >> >> My name is Joao Pinto and I am working at Synopsys as a Software Engineer >> mainly >> in the USB Subsystem. >> >> I am sending you this email in order to know if someone is already working in >> the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG >> Controllers. > > Have you looked at the latest kernel tree to verify what is and is not > supported? That's your best source of information. I checked the USB Mailing List archive and the USB Git trees in order to find any reference of these drivers but nothing was found, so I would conclude that nothing was submitted about these 2 subjects. > >> a) If no one is working, we have interest to start developing them > > Don't you already have internal code for these chips? Have you tested > Linux with them? As you know internal code is not always suitable for kernel submission and so sometimes it is better to upgrade a std kernel driver like dwc3 (USB 3.0 Device) in order to make it support 3.1 as well. > >> b) If there is someone already developing them, we have interest in >> collaborating with the on going work > > Look at the changelog entries for the drivers for these chips, that > should give you the information you need here. I have checked the USB tree' logs as I said previously and nothing relevant was found. > > But really, running the latest kernel and seeing what doesn't work for > your hardware, and sending patches to fix this is the best way forward, > don't you agree? I agree with you if we are dealing with small improvements or bug fixes, but in this case we are dealing with new drivers or important updates on existing ones. One of the good practices I read about kernel development is to ask first if someone is already working in a particular subject to avoid work duplication and that's what I am doing in this email. > > thanks, > > greg k-h > Thanks, Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: gadget: call gadget driver's ->suspend/->resume
On Sat, Apr 25, 2015 at 10:47:42AM -0500, Felipe Balbi wrote: > Hi, Hi Felipe, > > On Fri, Apr 24, 2015 at 01:56:25PM -0700, David Cohen wrote: > > > > > > When going into bus suspend/resume we _must_ > > > > > > call gadget driver's ->suspend/->resume callbacks > > > > > > accordingly. This patch implements that very feature > > > > > > which has been missing forever. > > > > > > > > > > > > Cc: # 3.14 > > > > > > Signed-off-by: Felipe Balbi > > > > > > Signed-off-by: David Cohen > > > > > > --- > > > > > > > > > > > > Hi, > > > > > > > > > > > > This patch was introduced on v3.15. > > > > > > But the issue it fixes already existed on v3.14 and v3.14 is a long > > > > > > term > > > > > > support version. > > > > > > > > > > Can you show me a log of this breaking anywhere ? Why do you consider > > > > > this a bug fix ? What sort of drawbacks did you notice ? > > > > > > > > We're seeing BC1.2 compliance test failure. I borrowed this info from > > > > the bug report :) > > > > > > > > 1. BC1.2 compliance testing - SDP2.0 > > > > --- > > > > 1. On Connect to active Host (Expected result: 100mA to 500mA): > > > >Actual result 100mA to 500mA > > > > > > > > 2. On Host Suspend (ER: Fall back to 0mA): > > > >not falling back to 0mA, remains at 500mA > > > > > > > > 3. On Connect to Suspended Host (ER: 100mA to 0mA): > > > >cable-props shown as 100mA, which means drawing a current of 100mA > > > > from > > > >Suspended Host > > > > > > > > 4. On making Host active (ER: 500mA): > > > >500mA > > > > > > But we don't support Battery Charging with dwc3 as of now :-) In fact, > > > just note that none of the BC registers are even defined in the current > > > driver anywhere. Seems like you should cherry-pick these to your vendor > > > tree, but v3.14 vanilla, because it doesn't support BC1.2, can't be > > > claimed to be at fault, right ? > > > > We could call it a missing feature that could lead to a potential bug :) > > By your own comment, he "must" was stressed out: > > sure it was because they really must be called :-) However, the only > actual problem that arises from not calling them is with something > that's not supported :-) > > > When going into bus suspend/resume we _must_ > > call gadget driver's ->suspend/->resume callbacks > > accordingly. This patch implements that very feature > > which has been missing forever. > > ''' > > > > Since v3.14 is a LTS kernel and the changes are safe, it's worth to > > consider. > > definitely worth to consider, but not as something that fixes BC1.2 > because that's, as said, not supported in any public tree :-) Thanks for the reply. The gadget having this issue is really out-of-tree (android gadget). I could do 2 next steps: 1) I could drop android gadget and try to reproduce this issue using legacy g_ffs, which supports adbd as well. 2) I could propose this change directly on google's android 3.14 tree instead. Would you prefer one of those? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi Joao, On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: > >> My name is Joao Pinto and I am working at Synopsys as a Software Engineer > >> mainly > >> in the USB Subsystem. > >> > >> I am sending you this email in order to know if someone is already working > >> in > >> the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG > >> Controllers. > > > > Have you looked at the latest kernel tree to verify what is and is not > > supported? That's your best source of information. > > I checked the USB Mailing List archive and the USB Git trees in order to find > any reference of these drivers but nothing was found, so I would conclude that > nothing was submitted about these 2 subjects. one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg controller available on e.g. raspberry pi. For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, I don't know anybody, except for synopsys employees, with access to the USB 3.1 documentation, but I would assume the core to be similar to the current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please confirm). If that's the case, then an incremental patch adding USB 3.1 support is much more desirable than an entire new driver. > >> a) If no one is working, we have interest to start developing them > > > > Don't you already have internal code for these chips? Have you tested > > Linux with them? > > As you know internal code is not always suitable for kernel submission > and so sometimes it is better to upgrade a std kernel driver like dwc3 > (USB 3.0 Device) in order to make it support 3.1 as well. yes, it's better to upgrade that driver, however, that driver is not device only. I won't repeat myself trying to explain why we still don't have DRD/OTG support, but it's coming. > >> b) If there is someone already developing them, we have interest in > >> collaborating with the on going work > > > > Look at the changelog entries for the drivers for these chips, that > > should give you the information you need here. > > I have checked the USB tree' logs as I said previously and nothing relevant > was > found. > > > > > But really, running the latest kernel and seeing what doesn't work for > > your hardware, and sending patches to fix this is the best way forward, > > don't you agree? > > I agree with you if we are dealing with small improvements or bug fixes, but > in > this case we are dealing with new drivers or important updates on existing > ones. I would assume that USB 3.1 itself is a very small change. The bulk of the changes will probably come due to Type-C connector and USB Power Delivery and Billboard classes, however, that's not coupled with USB 3.1 at all. > One of the good practices I read about kernel development is to ask > first if someone is already working in a particular subject to avoid > work duplication and that's what I am doing in this email. that's correct, it's always good to ask and doesn't really hurt anybody, but you also need to know who to ask :-) Greg can't know about everything (although usually... well), and since you're talking about changes to dwc2 and dwc3 it would be nice to Cc the maintainers for those drivers, right ? ;-) cheers -- balbi signature.asc Description: Digital signature
Re: ZLP sending request from gadget
Felipe Balbi wrote: > On Mon, Apr 27, 2015 at 10:57:24AM +0530, Anjana V Kumar wrote: > > But we see that the serial gadget driver does not set req->zero. But > > others like u_ether and f_massstorage are setting the same. > > > > Is there any specific reason why this is not done in gadget serial ? > > maybe a bug ? No idea off the top of my head. The protocol may simply not require any ZLP. //Peter pgpEVcvdRo5yc.pgp Description: PGP signature
Re: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi Filipe, On 4/27/2015 3:56 PM, Felipe Balbi wrote: > Hi Joao, > > On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG Controllers. >>> >>> Have you looked at the latest kernel tree to verify what is and is not >>> supported? That's your best source of information. >> >> I checked the USB Mailing List archive and the USB Git trees in order to find >> any reference of these drivers but nothing was found, so I would conclude >> that >> nothing was submitted about these 2 subjects. > > one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg > controller available on e.g. raspberry pi. > > For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or > FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, > I don't know anybody, except for synopsys employees, with access to the > USB 3.1 documentation, but I would assume the core to be similar to the > current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please > confirm). > > If that's the case, then an incremental patch adding USB 3.1 support is > much more desirable than an entire new driver. > a) If no one is working, we have interest to start developing them >>> >>> Don't you already have internal code for these chips? Have you tested >>> Linux with them? >> >> As you know internal code is not always suitable for kernel submission >> and so sometimes it is better to upgrade a std kernel driver like dwc3 >> (USB 3.0 Device) in order to make it support 3.1 as well. > > yes, it's better to upgrade that driver, however, that driver is not > device only. I won't repeat myself trying to explain why we still don't > have DRD/OTG support, but it's coming. > b) If there is someone already developing them, we have interest in collaborating with the on going work >>> >>> Look at the changelog entries for the drivers for these chips, that >>> should give you the information you need here. >> >> I have checked the USB tree' logs as I said previously and nothing relevant >> was >> found. >> >>> >>> But really, running the latest kernel and seeing what doesn't work for >>> your hardware, and sending patches to fix this is the best way forward, >>> don't you agree? >> >> I agree with you if we are dealing with small improvements or bug fixes, but >> in >> this case we are dealing with new drivers or important updates on existing >> ones. > > I would assume that USB 3.1 itself is a very small change. The bulk of > the changes will probably come due to Type-C connector and USB Power > Delivery and Billboard classes, however, that's not coupled with USB 3.1 > at all. > >> One of the good practices I read about kernel development is to ask >> first if someone is already working in a particular subject to avoid >> work duplication and that's what I am doing in this email. > > that's correct, it's always good to ask and doesn't really hurt anybody, > but you also need to know who to ask :-) Greg can't know about > everything (although usually... well), and since you're talking about > changes to dwc2 and dwc3 it would be nice to Cc the maintainers for > those drivers, right ? ;-) > > cheers > Thank you very much for your inputs! When I have more details I will contact you about dwc3. Have a nice day! -- Joao -- 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: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi, On Mon, Apr 27, 2015 at 04:04:08PM +0100, Joao Pinto wrote: > Hi Filipe, that's Felipe (and yes, I know it's João, but you spelled it without ~) :-) > On 4/27/2015 3:56 PM, Felipe Balbi wrote: > > Hi Joao, > > > > On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: > My name is Joao Pinto and I am working at Synopsys as a Software > Engineer mainly > in the USB Subsystem. > > I am sending you this email in order to know if someone is already > working in > the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 > OTG > Controllers. > >>> > >>> Have you looked at the latest kernel tree to verify what is and is not > >>> supported? That's your best source of information. > >> > >> I checked the USB Mailing List archive and the USB Git trees in order to > >> find > >> any reference of these drivers but nothing was found, so I would conclude > >> that > >> nothing was submitted about these 2 subjects. > > > > one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg > > controller available on e.g. raspberry pi. > > > > For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or > > FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, > > I don't know anybody, except for synopsys employees, with access to the > > USB 3.1 documentation, but I would assume the core to be similar to the > > current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please > > confirm). > > > > If that's the case, then an incremental patch adding USB 3.1 support is > > much more desirable than an entire new driver. > > > a) If no one is working, we have interest to start developing them > >>> > >>> Don't you already have internal code for these chips? Have you tested > >>> Linux with them? > >> > >> As you know internal code is not always suitable for kernel submission > >> and so sometimes it is better to upgrade a std kernel driver like dwc3 > >> (USB 3.0 Device) in order to make it support 3.1 as well. > > > > yes, it's better to upgrade that driver, however, that driver is not > > device only. I won't repeat myself trying to explain why we still don't > > have DRD/OTG support, but it's coming. > > > b) If there is someone already developing them, we have interest in > collaborating with the on going work > >>> > >>> Look at the changelog entries for the drivers for these chips, that > >>> should give you the information you need here. > >> > >> I have checked the USB tree' logs as I said previously and nothing > >> relevant was > >> found. > >> > >>> > >>> But really, running the latest kernel and seeing what doesn't work for > >>> your hardware, and sending patches to fix this is the best way forward, > >>> don't you agree? > >> > >> I agree with you if we are dealing with small improvements or bug fixes, > >> but in > >> this case we are dealing with new drivers or important updates on existing > >> ones. > > > > I would assume that USB 3.1 itself is a very small change. The bulk of > > the changes will probably come due to Type-C connector and USB Power > > Delivery and Billboard classes, however, that's not coupled with USB 3.1 > > at all. > > > >> One of the good practices I read about kernel development is to ask > >> first if someone is already working in a particular subject to avoid > >> work duplication and that's what I am doing in this email. > > > > that's correct, it's always good to ask and doesn't really hurt anybody, > > but you also need to know who to ask :-) Greg can't know about > > everything (although usually... well), and since you're talking about > > changes to dwc2 and dwc3 it would be nice to Cc the maintainers for > > those drivers, right ? ;-) > > > > cheers > > > > Thank you very much for your inputs! When I have more details I will > contact you about dwc3. Have a nice day! you too, thanks -- balbi signature.asc Description: Digital signature
Re: Synopsys IPs: USB 3.1 Device & Host and USB 2.0 OTG
Hi, On 4/27/2015 4:49 PM, Felipe Balbi wrote: > Hi, > > On Mon, Apr 27, 2015 at 04:04:08PM +0100, Joao Pinto wrote: >> Hi Filipe, > > that's Felipe (and yes, I know it's João, but you spelled it without ~) > > :-) > >> On 4/27/2015 3:56 PM, Felipe Balbi wrote: >>> Hi Joao, >>> >>> On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: >> My name is Joao Pinto and I am working at Synopsys as a Software >> Engineer mainly >> in the USB Subsystem. >> >> I am sending you this email in order to know if someone is already >> working in >> the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 >> OTG >> Controllers. > > Have you looked at the latest kernel tree to verify what is and is not > supported? That's your best source of information. I checked the USB Mailing List archive and the USB Git trees in order to find any reference of these drivers but nothing was found, so I would conclude that nothing was submitted about these 2 subjects. >>> >>> one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg >>> controller available on e.g. raspberry pi. >>> >>> For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or >>> FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, >>> I don't know anybody, except for synopsys employees, with access to the >>> USB 3.1 documentation, but I would assume the core to be similar to the >>> current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please >>> confirm). >>> >>> If that's the case, then an incremental patch adding USB 3.1 support is >>> much more desirable than an entire new driver. >>> >> a) If no one is working, we have interest to start developing them > > Don't you already have internal code for these chips? Have you tested > Linux with them? As you know internal code is not always suitable for kernel submission and so sometimes it is better to upgrade a std kernel driver like dwc3 (USB 3.0 Device) in order to make it support 3.1 as well. >>> >>> yes, it's better to upgrade that driver, however, that driver is not >>> device only. I won't repeat myself trying to explain why we still don't >>> have DRD/OTG support, but it's coming. >>> >> b) If there is someone already developing them, we have interest in >> collaborating with the on going work > > Look at the changelog entries for the drivers for these chips, that > should give you the information you need here. I have checked the USB tree' logs as I said previously and nothing relevant was found. > > But really, running the latest kernel and seeing what doesn't work for > your hardware, and sending patches to fix this is the best way forward, > don't you agree? I agree with you if we are dealing with small improvements or bug fixes, but in this case we are dealing with new drivers or important updates on existing ones. >>> >>> I would assume that USB 3.1 itself is a very small change. The bulk of >>> the changes will probably come due to Type-C connector and USB Power >>> Delivery and Billboard classes, however, that's not coupled with USB 3.1 >>> at all. >>> One of the good practices I read about kernel development is to ask first if someone is already working in a particular subject to avoid work duplication and that's what I am doing in this email. >>> >>> that's correct, it's always good to ask and doesn't really hurt anybody, >>> but you also need to know who to ask :-) Greg can't know about >>> everything (although usually... well), and since you're talking about >>> changes to dwc2 and dwc3 it would be nice to Cc the maintainers for >>> those drivers, right ? ;-) >>> >>> cheers >>> >> >> Thank you very much for your inputs! When I have more details I will >> contact you about dwc3. Have a nice day! > > you too, thanks > Sorry Filipe, in Portugal we have the two ways: Felipe and Filipe! Cheers, Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: gadget: call gadget driver's ->suspend/->resume
On Mon, Apr 27, 2015 at 07:55:58AM -0700, David Cohen wrote: > On Sat, Apr 25, 2015 at 10:47:42AM -0500, Felipe Balbi wrote: > > Hi, > > Hi Felipe, > > > > > On Fri, Apr 24, 2015 at 01:56:25PM -0700, David Cohen wrote: > > > > > > > When going into bus suspend/resume we _must_ > > > > > > > call gadget driver's ->suspend/->resume callbacks > > > > > > > accordingly. This patch implements that very feature > > > > > > > which has been missing forever. > > > > > > > > > > > > > > Cc: # 3.14 > > > > > > > Signed-off-by: Felipe Balbi > > > > > > > Signed-off-by: David Cohen > > > > > > > --- > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > This patch was introduced on v3.15. > > > > > > > But the issue it fixes already existed on v3.14 and v3.14 is a > > > > > > > long term > > > > > > > support version. > > > > > > > > > > > > Can you show me a log of this breaking anywhere ? Why do you > > > > > > consider > > > > > > this a bug fix ? What sort of drawbacks did you notice ? > > > > > > > > > > We're seeing BC1.2 compliance test failure. I borrowed this info from > > > > > the bug report :) > > > > > > > > > > 1. BC1.2 compliance testing - SDP2.0 > > > > > --- > > > > > 1. On Connect to active Host (Expected result: 100mA to 500mA): > > > > >Actual result 100mA to 500mA > > > > > > > > > > 2. On Host Suspend (ER: Fall back to 0mA): > > > > >not falling back to 0mA, remains at 500mA > > > > > > > > > > 3. On Connect to Suspended Host (ER: 100mA to 0mA): > > > > >cable-props shown as 100mA, which means drawing a current of 100mA > > > > > from > > > > >Suspended Host > > > > > > > > > > 4. On making Host active (ER: 500mA): > > > > >500mA > > > > > > > > But we don't support Battery Charging with dwc3 as of now :-) In fact, > > > > just note that none of the BC registers are even defined in the current > > > > driver anywhere. Seems like you should cherry-pick these to your vendor > > > > tree, but v3.14 vanilla, because it doesn't support BC1.2, can't be > > > > claimed to be at fault, right ? > > > > > > We could call it a missing feature that could lead to a potential bug :) > > > By your own comment, he "must" was stressed out: > > > > sure it was because they really must be called :-) However, the only > > actual problem that arises from not calling them is with something > > that's not supported :-) > > > > > When going into bus suspend/resume we _must_ > > > call gadget driver's ->suspend/->resume callbacks > > > accordingly. This patch implements that very feature > > > which has been missing forever. > > > ''' > > > > > > Since v3.14 is a LTS kernel and the changes are safe, it's worth to > > > consider. > > > > definitely worth to consider, but not as something that fixes BC1.2 > > because that's, as said, not supported in any public tree :-) > > Thanks for the reply. > The gadget having this issue is really out-of-tree (android gadget). > I could do 2 next steps: > 1) I could drop android gadget and try to reproduce this issue using > legacy g_ffs, which supports adbd as well. > 2) I could propose this change directly on google's android 3.14 tree > instead. > > Would you prefer one of those? hehe, I'll let Greg decide, I'm not against the patch, as I said before, but I'm also not entirely sure it fits within stable rules ;-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] drivers/usb/chipidea/debuc.c: avoid out of bound read
On 22.04.2015 03:26, Peter Chen wrote: > On Tue, Apr 21, 2015 at 09:25:41PM +0200, Heinrich Schuchardt wrote: >> Hello Peter, >> >> thanks for reviewing. >> >> On 21.04.2015 03:32, Peter Chen wrote: >>> On Fri, Apr 17, 2015 at 08:04:13AM +0200, Heinrich Schuchardt wrote: A string written by the user may not be zero terminated. sscanf may read memory beyond the buffer if no zero byte is found. Signed-off-by: Heinrich Schuchardt --- drivers/usb/chipidea/debug.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index dfb05ed..ef08af3 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -88,9 +88,13 @@ static ssize_t ci_port_test_write(struct file *file, const char __user *ubuf, char buf[32]; int ret; - if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) + count = min_t(size_t, sizeof(buf) - 1, count); + if (copy_from_user(buf, ubuf, count)) return -EFAULT; >>> >>> Any reasons to change above? >> >> Otherwise we would have two lines with the term >> min_t(size_t, sizeof(buf) - 1, count). > > Sorry, two lines of min_t(..)? Why I can't find it? Hello Peter, in my patch I write: count = min_t(size_t, sizeof(buf) - 1, count); if (copy_from_user(buf, ubuf, count)) return -EFAULT; /* sscanf requires a zero terminated string */ buf[count] = 0; Without the first part of the change I would have had to write: if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) return -EFAULT; /* sscanf requires a zero terminated string */ buf[min_t(size_t, sizeof(buf) - 1, count)] = 0; We should do the same calculation "min_t(size_t, sizeof(buf) - 1, count)" only once in the coding. Best regards Heinrich > > >> >> This would make the code harder to read. >> + /* sscanf requires a zero terminated string */ + buf[count] = 0; + >>> >>> I prefer using '\0' >> >> If you confirm the rest of the patch is ok, I will send an updated patch. >> >> Best regards >> >> Heinrich >> >>> if (sscanf(buf, "%u", &mode) != 1) return -EINVAL; >> > -- 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: phy: rcar-gen2-usb: Fix USBHS_UGSTS_LOCK value
Hi, On Thu, Apr 02, 2015 at 08:22:34PM +0900, Yoshihiro Shimoda wrote: > According to the technical update (No. TN-RCS-B011A/E), the UGSTS LOCK > bit location is bit 8, not bits 9 and 8. So, this patch fixes the > USBHS_UGSTS_LOCK value. > > Signed-off-by: Yoshihiro Shimoda this doesn't apply to v4.1-rc1, if it's still needed, please rebase. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: xudc: fix return value check in xudc_probe()
Hi, On Thu, Apr 16, 2015 at 08:17:30PM +0800, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns > ERR_PTR() and never returns NULL. The NULL test in the return > value check should be replaced with IS_ERR(). > > Signed-off-by: Wei Yongjun doesn't apply to v4.1-rc1, if it's still needed, please rebase. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 18/22] usb: dwc2: host: don't use dma_alloc_coherent with irqs disabled
Hi,
On Tue, Mar 24, 2015 at 10:01:06AM +0100, Mian Yousaf Kaukab wrote:
> diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
> index 63207dc..3735ae6 100644
> --- a/drivers/usb/dwc2/hcd_queue.c
> +++ b/drivers/usb/dwc2/hcd_queue.c
> @@ -231,9 +231,10 @@ void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct
> dwc2_qh *qh)
> {
> if (hsotg->core_params->dma_desc_enable > 0)
> dwc2_hcd_qh_free_ddma(hsotg, qh);
> - else if (qh->dw_align_buf)
> - dma_free_coherent(hsotg->dev, qh->dw_align_buf_size,
> - qh->dw_align_buf, qh->dw_align_buf_dma);
> + else if (qh->dw_align_buf) {
> + kfree(qh->dw_align_buf);
> + qh->dw_align_buf_dma = (dma_addr_t)0;
> + }
kfree(NULL) is safe. This could be:
else {
kfree;
qh->dw;
}
> kfree(qh);
> }
>
> --
> 2.3.3
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 12/22] usb: dwc2: gadget: enable otg flag in dual role configuration
On Tue, Mar 24, 2015 at 10:01:00AM +0100, Mian Yousaf Kaukab wrote: > From: Gregory Herrero missing commit log. > Signed-off-by: Gregory Herrero > --- > drivers/usb/dwc2/gadget.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 56a08ac..eb906bd 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -3525,6 +3525,8 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq) > hsotg->gadget.max_speed = USB_SPEED_HIGH; > hsotg->gadget.ops = &s3c_hsotg_gadget_ops; > hsotg->gadget.name = dev_name(dev); > + if (hsotg->dr_mode == USB_DR_MODE_OTG) > + hsotg->gadget.is_otg = 1; > > /* reset the system */ > > -- > 2.3.3 > -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 00/22] usb: third series of updates for dwc2 driver
On Wed, Apr 01, 2015 at 07:03:31PM -0700, John Youn wrote: > On 3/24/2015 2:00 AM, Mian Yousaf Kaukab wrote: > > Hi, > > This patchset consists of some bug fixes and feature enhancements for > > the dwc2 driver. All the patches are verified on dwc2 v3.0a with > > dedicated fifos. Main focus of testing was with dma enabled. Although > > basic testing without dma was also done. > > > > This is based on testing/next branch in Felipe's git. > > > > Thank you, > > > > Best regards, > > Yousaf > > > > History: > > v4: > > - Fixed comment from Julius Werner > > v3: > > - Fixed comments from Julius Werner and Sergei Shtylyov > > - Dropped "usb: dwc2: allow dwc2_pci to be a module even when dwc2 is > > statically linked" > >due to http://marc.info/?l=linux-usb&m=142661773703793&w=2 > > - "usb: dwc2: host: ensure qtb exists before dereferencing it" is added > >to fix a NULL pointer dereferencing bug > > v2: > > - Fixed comments from John Youn and Julius Werner > > - Fixed regression, found by John, when switching to gadget mode > >after running host mode > > - Added patch to add core parameter for enabling/disabling hibernation > > - Added patch to build dwc2_pci.ko independent from dwc2.ko > > v1: > > - Fixed comments from John Youn and Robert Baldyga > > - Dropped all changes to pci.c due to > >http://permalink.gmane.org/gmane.linux.usb.general/123411 > > - Added patch to remove unnecessary EXPORT_SYMBOL_GPL calls > > > > Gregory Herrero (15): > > usb: dwc2: add controller hibernation support > > usb: dwc2: implement hibernation during bus suspend/resume > > usb: dwc2: controller must update lx_state before releasing lock > > usb: dwc2: add external_id_pin_ctl core parameter > > usb: dwc2: gadget: use reset detect interrupt > > usb: dwc2: gadget: ignore pm suspend/resume in L2 > > usb: dwc2: gadget: prevent new request submission during suspend > > usb: dwc2: gadget: powerup controller if needed > > usb: dwc2: gadget: enable otg flag in dual role configuration > > usb: dwc2: host: add bus_suspend/bus_resume callback > > usb: dwc2: host: resume root hub on port connect > > usb: dwc2: host: spinlock urb_enqueue > > usb: dwc2: host: don't use dma_alloc_coherent with irqs disabled > > usb: dwc2: add hibernation core parameter > > usb: dwc2: host: ensure qtb exists before dereferencing it > > > > Jingwu Lin (1): > > usb: dwc2: host: implement test mode > > > > Mian Yousaf Kaukab (6): > > usb: dwc2: move debugfs code to a separate file > > usb: dwc2: debugfs: add support for complete register dump > > usb: dwc2: set parameter values in probe function > > usb: dwc2: gadget: remove s3c_hsotg_ep_disable_force > > usb: dwc2: host: register handle to the phy > > usb: dwc2: remove dwc2_platform.ko > > > > drivers/usb/dwc2/Kconfig | 8 - > > drivers/usb/dwc2/Makefile| 9 +- > > drivers/usb/dwc2/core.c | 439 +++- > > drivers/usb/dwc2/core.h | 120 ++- > > drivers/usb/dwc2/core_intr.c | 45 ++- > > drivers/usb/dwc2/debug.h | 27 ++ > > drivers/usb/dwc2/debugfs.c | 771 > > +++ > > drivers/usb/dwc2/gadget.c| 459 +++--- > > drivers/usb/dwc2/hcd.c | 100 +++--- > > drivers/usb/dwc2/hcd.h | 7 +- > > drivers/usb/dwc2/hcd_intr.c | 66 +++- > > drivers/usb/dwc2/hcd_queue.c | 15 +- > > drivers/usb/dwc2/platform.c | 25 +- > > 13 files changed, 1570 insertions(+), 521 deletions(-) > > create mode 100644 drivers/usb/dwc2/debug.h > > create mode 100644 drivers/usb/dwc2/debugfs.c > > > > For this series: > > Acked-by: John Youn Ok, I had two minor comments to the patchset, so I'll wait for another version. Hopefully it comes with your acked-by in place so it saves me some time ;-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 15/22] usb: dwc2: host: add bus_suspend/bus_resume callback
On Tue, Mar 24, 2015 at 10:01:03AM +0100, Mian Yousaf Kaukab wrote:
> From: Gregory Herrero
missing commit log.
> Signed-off-by: Gregory Herrero
> ---
> drivers/usb/dwc2/hcd.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 919658e..bc04b3f8 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -2313,6 +2313,22 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
> usleep_range(1000, 3000);
> }
>
> +static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> +
> + hsotg->lx_state = DWC2_L2;
> + return 0;
> +}
> +
> +static int _dwc2_hcd_resume(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> +
> + hsotg->lx_state = DWC2_L0;
> + return 0;
> +}
> +
> /* Returns the current frame number */
> static int _dwc2_hcd_get_frame_number(struct usb_hcd *hcd)
> {
> @@ -2683,6 +2699,9 @@ static struct hc_driver dwc2_hc_driver = {
> .hub_status_data = _dwc2_hcd_hub_status_data,
> .hub_control = _dwc2_hcd_hub_control,
> .clear_tt_buffer_complete = _dwc2_hcd_clear_tt_buffer_complete,
> +
> + .bus_suspend = _dwc2_hcd_suspend,
> + .bus_resume = _dwc2_hcd_resume,
> };
>
> /*
> --
> 2.3.3
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 14/22] usb: dwc2: host: register handle to the phy
On Tue, Mar 24, 2015 at 10:01:02AM +0100, Mian Yousaf Kaukab wrote: > If phy driver is present register hcd handle to it. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/usb/dwc2/hcd.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c > index 1cca5e0..919658e 100644 > --- a/drivers/usb/dwc2/hcd.c > +++ b/drivers/usb/dwc2/hcd.c > @@ -2913,6 +2913,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq) > /* Don't support SG list at this point */ > hcd->self.sg_tablesize = 0; > > + if (!IS_ERR_OR_NULL(hsotg->uphy)) when is uphy NULL ? Aparently, only platform.c sets it to NULL in case of error, I'd say we should just make NULL a valid PHY pointer, then we can remove a bunch of these checks scattered around. -- balbi signature.asc Description: Digital signature
Re: [RFC 5/6] usb: gadget: atmel_usba: use atmel_io.h to provide on-chip IO
On Thu, Mar 26, 2015 at 12:56:47PM +0100, Hans-Christian Egtvedt wrote:
> Around Thu 26 Mar 2015 11:45:53 + or thereabout, Ben Dooks wrote:
> > Use to provide IO accessors which work on both
> > AVR32 and ARM for on-chip peripherals.
> >
> > Signed-off-by: Ben Dooks
>
> Acked-by: Hans-Christian Egtvedt
>
> > --
> > CC: Nicolas Ferre
> > CC: Felipe Balbi
> > CC: Greg Kroah-Hartman
> > CC: linux-usb@vger.kernel.org
> > ---
> > drivers/usb/gadget/udc/atmel_usba_udc.c | 1 +
> > drivers/usb/gadget/udc/atmel_usba_udc.h | 12 +++-
> > 2 files changed, 4 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
> > b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > index be2f503..6735585 100644
> > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h
> > b/drivers/usb/gadget/udc/atmel_usba_udc.h
> > index 92bd486..3d40aa3 100644
> > --- a/drivers/usb/gadget/udc/atmel_usba_udc.h
> > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
> > @@ -191,15 +191,9 @@
> > | USBA_BF(name, value))
> >
> > /* Register access macros */
> > -#ifdef CONFIG_AVR32
> > -#define usba_io_readl __raw_readl
> > -#define usba_io_writel __raw_writel
> > -#define usba_io_writew __raw_writew
> > -#else
> > -#define usba_io_readl readl_relaxed
> > -#define usba_io_writel writel_relaxed
> > -#define usba_io_writew writew_relaxed
> > -#endif
> > +#define usba_io_readl atmel_oc_readl
> > +#define usba_io_writel atmel_oc_writel
> > +#define usba_io_writew atmel_oc_writew
>
> Same comment as earlier patch, it would be nice to remove the define
> usba_io_{read,write}{l,w} defines in a follow-up patch.
I'm fine with this too. Is this targetted at v4.2 ?
--
balbi
signature.asc
Description: Digital signature
[PATCH V7 0/9] Tegra xHCI support
This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, - patches 4 and 5: adding an MFD driver for the XUSB cmoplex, - patches 6 and 7: adding a driver for the mailbox used to communicate with the xHCI controller's firmware, and - patches 8 and 9: adding a xHCI host-controller driver. The addition of USB PHY support to the XUSB padctl driver has been dropped from v7. Thierry will be posting those patches later. Given the many compile and run-time dependencies in this series, it is probably best if the first 3 patches are picked up by the relevant maintainers in topic branches so that the remainder of the series can go through the Tegra tree. Tested on Jetson TK1 and Nyan-Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles. This has also been tested, with additional out-of-tree patches, on a Tegra132-based board. Based on v4.1-rc1. A branch with the entire series is available at: https://github.com/abrestic/linux/tree/tegra-xhci-v7 Changes from v6: - Dropped PHY changes from series. Will be posted later by Thierry. - Added an MFD device with the mailbox and xHCI host as sub-devices. Changes from v5: - Addressed review comments from Jassi and Felipe. Changes from v4: - Made USB support optional in padctl driver. - Made usb3-port a pinconfig property again. - Cleaned up mbox_request_channel() error handling and allowed it to defer probing (patch 3). - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested by Thierry. - Addressed Thierry's review comments. Changes from v3: - Fixed USB2.0 flakiness on Jetson-TK1. - Switched to 32-bit DMA mask for host. - Addressed Stephen's review comments. Chagnes from v2: - Dropped mailbox channel specifier. The mailbox driver allocates virtual channels backed by the single physical channel. - Added support for HS_CURR_LEVEL adjustment pinconfig property, which will be required for the Blaze board. - Addressed Stephen's review comments. Changes from v1: - Converted mailbox driver to use the common mailbox framework. - Fixed up host driver so that it can now be built and used as a module. - Addressed Stephen's review comments. - Misc. cleanups. Andrew Bresticker (8): xhci: Set shared HCD's hcd_priv in xhci_gen_setup mailbox: Make struct mbox_controller's ops field const mfd: Add binding document for NVIDIA Tegra XUSB mfd: Add driver for NVIDIA Tegra XUSB mailbox: Add NVIDIA Tegra XUSB mailbox binding mailbox: Add NVIDIA Tegra XUSB mailbox driver usb: Add NVIDIA Tegra xHCI controller binding usb: xhci: Add NVIDIA Tegra xHCI host-controller driver Benson Leung (1): mailbox: Fix up error handling in mbox_request_channel() .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 30 + .../bindings/mfd/nvidia,tegra124-xusb.txt | 46 + .../bindings/usb/nvidia,tegra124-xhci.txt | 90 ++ drivers/mailbox/Kconfig| 8 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 11 +- drivers/mailbox/omap-mailbox.c | 6 +- drivers/mailbox/tegra-xusb-mailbox.c | 275 ++ drivers/mfd/Kconfig| 7 + drivers/mfd/Makefile | 1 + drivers/mfd/tegra-xusb.c | 167 drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-pci.c| 5 - drivers/usb/host/xhci-plat.c | 5 - drivers/usb/host/xhci-tegra.c | 946 + drivers/usb/host/xhci.c| 6 +- include/linux/mailbox_controller.h | 2 +- include/soc/tegra/xusb.h | 49 ++ 19 files changed, 1647 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c create mode 100644 drivers/mfd/tegra-xusb.c create mode 100644 drivers/usb/host/xhci-tegra.c create mode 100644 include/soc/tegra/xusb.h -- 2.2.0.rc0.207.ga3a616c -- 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 V7 5/9] mfd: Add driver for NVIDIA Tegra XUSB
Add an MFD driver for the XUSB host complex found on NVIDIA Tegra124
and later SoCs.
Signed-off-by: Andrew Bresticker
Cc: Samuel Ortiz
Cc: Lee Jones
---
New for v7.
---
drivers/mfd/Kconfig | 7 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/tegra-xusb.c | 167 +++
include/soc/tegra/xusb.h | 19 ++
4 files changed, 194 insertions(+)
create mode 100644 drivers/mfd/tegra-xusb.c
create mode 100644 include/soc/tegra/xusb.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d5ad04d..61872b4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1430,6 +1430,13 @@ config MFD_STW481X
in various ST Microelectronics and ST-Ericsson embedded
Nomadik series.
+config MFD_TEGRA_XUSB
+ tristate "NVIDIA Tegra XUSB"
+ depends on ARCH_TEGRA
+ select MFD_CORE
+ help
+ Support for the XUSB complex found on NVIDIA Tegra124 and later SoCs.
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0e5cfeb..7588caf 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -181,6 +181,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
+obj-$(CONFIG_MFD_TEGRA_XUSB) += tegra-xusb.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
new file mode 100644
index 000..d30d259
--- /dev/null
+++ b/drivers/mfd/tegra-xusb.c
@@ -0,0 +1,167 @@
+/*
+ * NVIDIA Tegra XUSB MFD driver
+ *
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct tegra_xusb_soc_data {
+ struct mfd_cell *devs;
+ unsigned int num_devs;
+};
+
+static struct resource tegra_xhci_resources[] = {
+ {
+ .name = "host",
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "xhci",
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "ipfs",
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource tegra_xusb_mbox_resources[] = {
+ {
+ .name = "smi",
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell tegra124_xusb_devs[] = {
+ {
+ .name = "tegra-xhci",
+ .of_compatible = "nvidia,tegra124-xhci",
+ },
+ {
+ .name = "tegra-xusb-mbox",
+ .of_compatible = "nvidia,tegra124-xusb-mbox",
+ },
+};
+
+static const struct tegra_xusb_soc_data tegra124_xusb_data = {
+ .devs = tegra124_xusb_devs,
+ .num_devs = ARRAY_SIZE(tegra124_xusb_devs),
+};
+
+static const struct of_device_id tegra_xusb_of_match[] = {
+ { .compatible = "nvidia,tegra124-xusb", .data = &tegra124_xusb_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
+
+static struct regmap_config tegra_fpci_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int tegra_xusb_probe(struct platform_device *pdev)
+{
+ const struct tegra_xusb_soc_data *soc;
+ const struct of_device_id *match;
+ struct tegra_xusb *xusb;
+ struct resource *res;
+ void __iomem *fpci_base;
+ int irq, ret;
+
+ xusb = devm_kzalloc(&pdev->dev, sizeof(*xusb), GFP_KERNEL);
+ if (!xusb)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, xusb);
+
+ match = of_match_node(tegra_xusb_of_match, pdev->dev.of_node);
+ soc = match->data;
+
+ irq = platform_get_irq_byname(pdev, "host");
+ if (irq < 0)
+ return irq;
+ tegra_xhci_resources[0].start = irq;
+ tegra_xhci_resources[0].end = irq;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "xhci");
+ if (!res)
+ return -ENODEV;
+ tegra_xhci_resources[1].start = res->start;
+ tegra_xhci_resources[1].end = res->end;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ipfs");
+ if (!res)
+ return -ENODEV;
+ tegra_xhci_resources[2].start = res->start;
+ tegra_xhci_resources[2].end = res->end;
+
+ soc->devs[0].resources = tegra_xhci_resources;
+ soc->devs[0].num_resources = ARRAY_SIZE(tegra_xhci_resources);
+
+ irq = platform_get_irq_byname(pdev, "smi");
+ if (irq < 0)
+ return irq;
+ tegra_xusb_mbox_resources[0].start = irq;
+
[PATCH V7 9/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
Add support for the on-chip xHCI host controller present on Tegra SoCs. The controller requires external firmware which must be loaded before using the controller. This driver loads the firmware, starts the controller, and is able to service host-specific messages sent by the controller's firmware. The controller also supports USB device mode as well as powergating of the SuperSpeed and host-controller logic when not in use, but support for these is not yet implemented. Based on work by: Ajay Gupta Bharath Yadav Signed-off-by: Andrew Bresticker Cc: Mathias Nyman Cc: Greg Kroah-Hartman --- Changes from v6: - Access FPCI registers using parent MFD's regmap. - Made regulator names and PHY types part of the SoC-specific data since they will be different on Tegra210. - Other cosmetic cleanups. Changes from v5: - Added dependency on COMPILE_TEST and MAILBOX. - Added TODO about powergating support. Changes from v4: - Poll for controller to finish booting. - Addressed review comments from Thierry. Changes from v3: - Used 32-bit DMA mask (platforms may have > 32-bit physical address space and < 64-bit dma_addr_t). - Moved comment about SET_BW command. Changes from v2: - Added filtering out of non-host mailbox messages. - Removed MODULE_ALIAS. Changes from v1: - Updated to use common mailbox API. - Fixed up so that the driver can be built and used as a module. - Incorporated review feedback from Stephen. - Misc. cleanups. --- drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-tegra.c | 946 ++ 3 files changed, 957 insertions(+) create mode 100644 drivers/usb/host/xhci-tegra.c diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 197a6a3..22601d0 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -50,6 +50,16 @@ config USB_XHCI_RCAR Say 'Y' to enable the support for the xHCI host controller found in Renesas R-Car ARM SoCs. +config USB_XHCI_TEGRA + tristate "xHCI support for NVIDIA Tegra SoCs" + depends on MFD_TEGRA_XUSB || COMPILE_TEST + depends on MAILBOX + depends on RESET_CONTROLLER + select FW_LOADER + ---help--- + Say 'Y' to enable the support for the xHCI host controller + found in NVIDIA Tegra124 and later SoCs. + endif # USB_XHCI_HCD config USB_EHCI_HCD diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 65b0b6a..1b98107 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o +obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c new file mode 100644 index 000..6230a2d --- /dev/null +++ b/drivers/usb/host/xhci-tegra.c @@ -0,0 +1,946 @@ +/* + * NVIDIA Tegra xHCI host controller driver + * + * Copyright (C) 2014 NVIDIA Corporation + * Copyright (C) 2014 Google, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "xhci.h" + +#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 12000 +#define TEGRA_XHCI_SS_CLK_LOW_SPEED 1200 + +/* FPCI CFG registers */ +#define XUSB_CFG_1 0x004 +#define XUSB_IO_SPACE_EN BIT(0) +#define XUSB_MEM_SPACE_EN BIT(1) +#define XUSB_BUS_MASTER_ENBIT(2) +#define XUSB_CFG_4 0x010 +#define XUSB_BASE_ADDR_SHIFT 15 +#define XUSB_BASE_ADDR_MASK 0x1 +#define XUSB_CFG_ARU_C11_CSBRANGE 0x41c +#define XUSB_CFG_CSB_BASE_ADDR 0x800 + +/* IPFS registers */ +#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180 +#define IPFS_EN_FPCI BIT(0) +#define IPFS_XUSB_HOST_INTR_MASK_0 0x188 +#define IPFS_IP_INT_MASK BIT(16) +#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_00x1bc + +#define CSB_PAGE_SELECT_MASK 0x7f +#define CSB_PAGE_SELECT_SHIFT 9 +#define CSB_PAGE_OFFSET_MASK 0x1ff +#define CSB_PAGE_SELECT(addr) ((addr) >> (CSB_PAGE_SELECT_SHIFT) &\ +CSB_PAGE_SELECT_MASK) +#define CSB_PAGE_OFFSET(addr) ((addr) & CSB_PAGE_OFFSET_MASK) + +/* Falcon CSB registers */ +#define XUSB_FALC_CPUCTL 0
[PATCH V7 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
Signed-off-by: Andrew Bresticker
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Jassi Brar
---
Changes from v6:
- Removed reg/interrupts properties.
No changes from v3/v4/v5.
Changes from v2:
- Dropped channel specifier.
- Added pointer to mailbox documentation.
Changes from v1:
- Updated to use common mailbox bindings.
---
.../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
new file mode 100644
index 000..9d89afa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
@@ -0,0 +1,30 @@
+NVIDIA Tegra XUSB mailbox
+=
+
+The Tegra XUSB mailbox is used by the Tegra xHCI controller's firmware to
+communicate requests to the host and PHY drivers.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
+ Otherwise, must contain '"nvidia,-xusb-mbox",
+ "nvidia,tegra124-xusb-mbox"' where is tegra132.
+ - #mbox-cells: Should be 0. There is only one physical channel.
+
+Example:
+
+ mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+
+ #mbox-cells = <0>;
+ };
+
+ usb-host {
+ ...
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ ...
+ };
--
2.2.0.rc0.207.ga3a616c
--
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 V7 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI host-controller.
Signed-off-by: Andrew Bresticker
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Samuel Ortiz
Cc: Lee Jones
---
New for v7.
---
.../bindings/mfd/nvidia,tegra124-xusb.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
new file mode 100644
index 000..6a46680
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
@@ -0,0 +1,46 @@
+NVIDIA Tegra XUSB host copmlex
+==
+
+The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
+controller and a mailbox for communication with the XUSB micro-controller.
+
+Required properties:
+
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
+ Otherwise, must contain '"nvidia,-xusb", "nvidia,tegra124-xusb"'
+ where is tegra132.
+ - reg: Must contain register base and length for each register set listed
+ in reg-names.
+ - reg-names: Must include the following entries:
+ - xhci
+ - fpci
+ - ipfs
+ - interrupts: Must contain an interrupt for each entry in interrupt-names.
+ - interrupt-names: Must include the following entries:
+ - host
+ - smi
+ - pme
+
+Example:
+
+ usb@0,7009 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70098000 0x0 0x1000>,
+ <0x0 0x70099000 0x0 0x1000>;
+ reg-names = "xhci", "fpci", "ipfs";
+ interrupts = ,
+,
+;
+ interrupt-names = "host", "smi", "pme";
+
+ usb-host {
+ compatible = "nvidia,tegra124-xhci";
+ ...
+ };
+
+ mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ ...
+ };
+ };
--
2.2.0.rc0.207.ga3a616c
--
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 V7 8/9] usb: Add NVIDIA Tegra xHCI controller binding
Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.
Signed-off-by: Andrew Bresticker
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Mathias Nyman
Cc: Greg Kroah-Hartman
---
Changes from v6:
- Removed XUSB_DEV related clocks/resets. They will be consumed by
a separate driver and binding.
- Removed reg/interrupts properties.
No changes from v5.
Changes from v4:
- Updated regulator names, as suggested by Thierry.
No changes from v3.
Changes from v2:
- Added mbox-names property.
Changes from v1:
- Updated to use common mailbox bindings.
- Added remaining XUSB-related clocks and resets.
- Updated list of power supplies to be more accurate wrt to the hardware.
---
.../bindings/usb/nvidia,tegra124-xhci.txt | 90 ++
1 file changed, 90 insertions(+)
create mode 100644
Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
new file mode 100644
index 000..5c980b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
@@ -0,0 +1,90 @@
+NVIDIA Tegra xHCI controller
+
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xhci".
+ Otherwise, must contain '"nvidia,-xhci", "nvidia,tegra124-xhci"'
+ where is tegra132.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- xusb_host
+- xusb_host_src
+- xusb_falcon_src
+- xusb_ss
+- xusb_ss_src
+- xusb_ss_div2
+- xusb_hs_src
+- xusb_fs_src
+- pll_u_480m
+- clk_m
+- pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - xusb_host
+ - xusb_ss
+ - xusb_src
+ Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - mboxes: Must contain an entry for the XUSB mailbox channel.
+ See ../mailbox/mailbox.txt for details.
+ - mbox-names: Must include the following entries:
+ - xusb
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply. Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05V.
+ - avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V.
+ - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V.
+ - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3V.
+
+Optional properties:
+
+ - phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+ Names must be of the form "-" where is one of "utmi",
+ "hsic", or "usb3" and is a 0-based index. On Tegra124, there may
+ be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+
+ usb-host {
+ compatible = "nvidia,tegra124-xhci";
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+<&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+<&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+<&tegra_car TEGRA124_CLK_XUSB_SS>,
+<&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+<&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+<&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+<&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+<&tegra_car TEGRA124_CLK_PLL_U_480M>,
+<&tegra_car TEGRA124_CLK_CLK_M>,
+<&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ phys = <&padctl TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+ <&padctl TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+ <&padctl TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+ phy-names
[PATCH V7 7/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver. The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested. All incoming messages are sent to both virtual channels.
Signed-off-by: Andrew Bresticker
Cc: Jassi Brar
---
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
Changes from v5:
- Poll for TX completion using MBOX_OWNER field.
Changes from v4:
- Use chan->cl to indicate channel allocation status
- Addressed review comments from Thierry
No changes from v3.
Changes from v2:
- Fixed mailbox IRQ vs. channel alloc/free race.
- Renamed defines to match TRM.
- Dropped channel specifier and instead allocated virtual channels as they
were requested.
- Removed MODULE_ALIAS.
Changes from v1:
- Converted to common mailbox framework.
- Removed useless polling sequences in TX path.
- Moved xusb include from linux/ to soc/tegra/
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-xusb-mailbox.c | 275 +++
include/soc/tegra/xusb.h | 30
4 files changed, 315 insertions(+)
create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..37da641 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,12 @@ config ALTERA_MBOX
An implementation of the Altera Mailbox soft core. It is used
to send message between processors. Say Y here if you want to use the
Altera mailbox support.
+
+config TEGRA_XUSB_MBOX
+ tristate "NVIDIA Tegra XUSB Mailbox"
+ depends on MFD_TEGRA_XUSB
+ help
+ Mailbox driver for the XUSB complex found on NVIDIA Tegra124 and
+ later SoCs. The XUSB mailbox is used to communicate between the
+ XUSB microcontroller and the host processor.
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..d77012a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX) += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c
b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 000..f0cac4d
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,275 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define XUSB_MBOX_NUM_CHANS2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD 0xe4
+#define MBOX_DEST_FALCBIT(27)
+#define MBOX_DEST_PME BIT(28)
+#define MBOX_DEST_SMI BIT(29)
+#define MBOX_DEST_XHCIBIT(30)
+#define MBOX_INT_EN BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN 0xe8
+#define CMD_DATA_SHIFT0
+#define CMD_DATA_MASK 0xff
+#define CMD_TYPE_SHIFT24
+#define CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER0xf0
+#define MBOX_OWNER_NONE 0
+#define MBOX_OWNER_FW 1
+#define MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR 0x428
+#define MBOX_SMI_INTR_FW_HANG BIT(1)
+#define MBOX_SMI_INTR_EN BIT(3)
+
+struct tegra_xusb_mbox {
+ struct mbox_controller mbox;
+ struct tegra_xusb *xusb;
+ spinlock_t lock;
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long
offset)
+{
+ u32 val;
+
+ regmap_read(mbox->xusb->fpci_regs, offset, &val);
+
+ return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+ unsigned long offset)
+{
+ regmap_write(mbox->xusb->fpci_regs, offset, val);
+}
+
+static inline struct tegra_xusb_mbox *to_tegra_mbox(struct mbox_controller *c)
+{
+ return container_of(c, struct tegra_xusb_mb
[PATCH V7 2/9] mailbox: Make struct mbox_controller's ops field const
The mailbox controller's channel ops ought to be read-only.
Signed-off-by: Andrew Bresticker
Cc: Jassi Brar
---
No changes from v5/v6.
New for v5.
---
include/linux/mailbox_controller.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mailbox_controller.h
b/include/linux/mailbox_controller.h
index d4cf96f..68c4245 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -72,7 +72,7 @@ struct mbox_chan_ops {
*/
struct mbox_controller {
struct device *dev;
- struct mbox_chan_ops *ops;
+ const struct mbox_chan_ops *ops;
struct mbox_chan *chans;
int num_chans;
bool txdone_irq;
--
2.2.0.rc0.207.ga3a616c
--
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 V7 3/9] mailbox: Fix up error handling in mbox_request_channel()
From: Benson Leung
mbox_request_channel() currently returns EBUSY in the event the controller
is not present or if of_xlate() fails, but in neither case is EBUSY really
appropriate. Return EPROBE_DEFER if the controller is not yet present
and change of_xlate() to return an ERR_PTR instead of NULL so that the
error can be propagated back to the caller of mbox_request_channel().
Signed-off-by: Benson Leung
Signed-off-by: Andrew Bresticker
Cc: Jassi Brar
Cc: Suman Anna
---
Changes from v6:
- Update omap-mailbox's xlate() to return error codes.
No changes from v5.
New for v5.
---
drivers/mailbox/mailbox.c | 11 ---
drivers/mailbox/omap-mailbox.c | 6 +++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..c3c42d4 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -318,7 +318,7 @@ struct mbox_chan *mbox_request_channel(struct mbox_client
*cl, int index)
return ERR_PTR(-ENODEV);
}
- chan = NULL;
+ chan = ERR_PTR(-EPROBE_DEFER);
list_for_each_entry(mbox, &mbox_cons, node)
if (mbox->dev->of_node == spec.np) {
chan = mbox->of_xlate(mbox, &spec);
@@ -327,7 +327,12 @@ struct mbox_chan *mbox_request_channel(struct mbox_client
*cl, int index)
of_node_put(spec.np);
- if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+ if (IS_ERR(chan)) {
+ mutex_unlock(&con_mutex);
+ return chan;
+ }
+
+ if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(&con_mutex);
return ERR_PTR(-EBUSY);
@@ -390,7 +395,7 @@ of_mbox_index_xlate(struct mbox_controller *mbox,
int ind = sp->args[0];
if (ind >= mbox->num_chans)
- return NULL;
+ return ERR_PTR(-EINVAL);
return &mbox->chans[ind];
}
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 0f332c1..e0df27b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -639,18 +639,18 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
mdev = container_of(controller, struct omap_mbox_device, controller);
if (WARN_ON(!mdev))
- return NULL;
+ return ERR_PTR(-EINVAL);
node = of_find_node_by_phandle(phandle);
if (!node) {
pr_err("%s: could not find node phandle 0x%x\n",
__func__, phandle);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
mbox = omap_mbox_device_find(mdev, node->name);
of_node_put(node);
- return mbox ? mbox->chan : NULL;
+ return mbox ? mbox->chan : ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
--
2.2.0.rc0.207.ga3a616c
--
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 V7 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
for the shared HCD, requiring xHCI host-controller drivers to set it
between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
that bit out of the host-controller drivers and into xhci_gen_setup().
Signed-off-by: Andrew Bresticker
Reviewed-by: Felipe Balbi
Cc: Mathias Nyman
Cc: Greg Kroah-Hartman
---
No changes from v5/v6.
New for v5.
Peviously posted here: https://lkml.org/lkml/2014/10/30/726
---
drivers/usb/host/xhci-pci.c | 5 -
drivers/usb/host/xhci-plat.c | 5 -
drivers/usb/host/xhci.c | 6 +++---
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2af32e2..f9ce741 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -247,11 +247,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
goto dealloc_usb2_hcd;
}
- /* Set the xHCI pointer before xhci_pci_setup() (aka hcd_driver.reset)
-* is called by usb_add_hcd().
-*/
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
-
retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
IRQF_SHARED);
if (retval)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 783e819..852b1e9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,11 +147,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
- /*
-* Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
-* is called by usb_add_hcd().
-*/
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..2901a67 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4849,9 +4849,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t
get_quirks)
*/
hcd->has_tt = 1;
} else {
- /* xHCI private pointer was set in xhci_pci_probe for the second
-* registered roothub.
-*/
+ xhci = hcd_to_xhci(hcd->primary_hcd);
+ *((struct xhci_hcd **) hcd->hcd_priv) = xhci;
+
return 0;
}
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] add HNP polling support for usb otg fsm
On Mon, Apr 20, 2015 at 10:00:49PM +0800, Li Jun wrote: > On Thu, Mar 26, 2015 at 05:38:11PM +0800, Peter Chen wrote: > > On Wed, Mar 25, 2015 at 07:25:24PM +0800, Li Jun wrote: > > > On Wed, Mar 25, 2015 at 02:43:43PM +0800, Chen Peter-B29397 wrote: > > > > > > > > > On Wed, Mar 25, 2015 at 02:03:51PM +0800, Peter Chen wrote: > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > The above three patches are in Greg's next tree, after I apply your > > > > > > chipidea fix [1] for pullup dp, it still some other problems for > > > > > > HNP, > > > > > > am I missing something? > > > > > > > > > > > > The procedures to reproduce: > > > > > > > > > > > > - Connect USB cable and MicroAB cable between two boards > > > > > > - Boot up two boards > > > > > > - load g_mass_storage at B-device side, the enumeration will > > > > > > success, > > > > > > and A will see a usb mass-storage device > > > > > > - load g_mass_storage at A-device side > > > > > > - Do HNP at B side, the HNP will succeed echo 1 > > > > > > > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req > > > > > > - Do HNP at A side > > > > > > echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req > > > > > > > > > > > > The problem has occurred, the A can't be back to host again. > > > > > > > > > > > I use your peter-usb-dev branch and did not found the problem, so I > > > > > need use > > > > > Greg's tree to try again? > > > > > > > > > > > > > No, I first found this problem with my dev tree, then, I rebase the > > > > latest Greg next > > > > tree, this problem still exists. You can try to use FSL imx6dl sdb as > > > > A device and imx6sx sdb > > > > as B device to reproduce it. > > > > > > > > > > It can work with my i.MX6DL + i.MX6Q SD, but with i.MX6DL + i.MX6SX SDB, > > > I can > > > reproduce the problem you reported, which triggers a bug in our otg_fsm > > > driver, > > > I will send out a patch to fix it. > > > > > > Li Jun > > > > > > > Jun, > > > > With your two chipidea fixes [1][2], I can run otg test successfully. > > > > [1] > > https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/commit/?h=ci-for-usb-stable&id=885510e8778bf0f2d38e2fd0807d8f84ca12a8d9 > > [2] > > https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/commit/?h=ci-for-usb-next&id=80c4b00dd0bee2ff5f430fae7e96d9599d36682f > > > > Hi Felipe, > > > > I am ok with this series, if you have no more comments, would you help > > queue this series through your tree? > > > > ping... TODO for tomorrow -- balbi signature.asc Description: Digital signature
RE: [PATCH] [RFC] usb: xhci: Add to check CRR bit in xhci_suspend()
Hi,
Thank you for the comments!
> Sent: Monday, April 27, 2015 10:15 PM
>
> On 27.04.2015 11:55, Yoshihiro Shimoda wrote:
> Hi
>
> > According to the xHCI spec "4.23.2 xHCI Power Management", the CRR bit
> > of CRCR register should be zero before setting Run/Stop (R/S) = '0'.
> > Otherwise, the STS_HALT is not set until the CRR is cleared on specific
> > xHCI controllers. In case of R-Car SoCs, it spent about 90 ms to clear
> > the CRR. So, to avoid the quirks XHCI_SLOW_SUSPEND, the driver calls
> > the aborting function if the CRR is set to 1.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/usb/host/xhci-ring.c | 2 +-
> > drivers/usb/host/xhci.c | 21 -
> > drivers/usb/host/xhci.h | 1 +
> > 3 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index f5397a5..21f3932 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
< snip >
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index ec8ac16..d2d81a0 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -892,7 +892,7 @@ static void xhci_disable_port_wake_on_bits(struct
> > xhci_hcd *xhci)
> > */
> > int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
> > {
> > - int rc = 0;
> > + int rc = 0, ret;
> > unsigned intdelay = XHCI_MAX_HALT_USEC;
> > struct usb_hcd *hcd = xhci_to_hcd(xhci);
> > u32 command;
> > @@ -918,6 +918,25 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
> > /* step 1: stop endpoint */
> > /* skipped assuming that port suspend has done */
> >
> > + /*
> > +* According to the xHCI spec "4.23.2 xHCI Power Management", the CRR
> > +* bit of CRCR register should be zero before setting Run/Stop (R/S) =
> > +* '0', the driver calls the aborting function if the CRR is set to 1.
> > +*/
> > + if (xhci_read_64(xhci, &xhci->op_regs->cmd_ring) & CMD_RING_RUNNING) {
> > + /* unlock here because this may wait about 5 seconds */
> > + spin_unlock_irq(&xhci->lock);
> > + ret = xhci_abort_cmd_ring(xhci);
>
> Would it work for R-Car if we instead of unlocking and and aborting the
> command just wait for
> the CRR bit to turn 0 before setting Run/stop = 0?
Unfortunately, it didn't work correctly. However, after setting Run/stop = 0,
it worked correctly.
(According to the Table 36 of xHCI spec, the CRR bit will be cleared if the R/S
but us cleared to 0.)
> Aborting the command ring by setting CA bit in CRCR will generate a command
> abort/stop completion event,
> which will point to the stopped/aborted event on the command ring. We are
> however clearing the command
> ring completely in xhci_suspend() right after this, and setting the dequeue
> pointer to the beginning of
> the ring. This will likely mess with the handling of the abort/stop event.
Thank you for the comment. I understood that this driver should not call
aborting function here.
> Waiting for the CRR to clear could be done using:
> xhci_handshake(&xhci->op_regs->cmd_ring, CMD_RING_RUNNING, timeout)
Thank you for the suggestion.
As I tested above, after I applied the following patch, R-Car SoCs environment
worked correctly.
However, I don't know that it is a reasonable solution for all xHCI controllers.
Should I add a new quirks? Or, should it use a XHCI_SLOW_SUSPEND instead of the
below patch?
(If R-Car SoCs with XHCI_SLOW_SUSPEND, it also worked correctly.)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -923,6 +923,15 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
command &= ~CMD_RUN;
writel(command, &xhci->op_regs->command);
+ /*
+* The STS_HALT is not set until the CRR is cleared on specific
+* xHCI controllers (e.g. R-Car SoCs) after this driver set the R/S
+* to 0. So, to avoid using a quirks XHCI_SLOW_SUSPEND, this driver
+* waits for the CRR to clear using xhci_handshake().
+*/
+ xhci_handshake(&xhci->op_regs->cmd_ring, CMD_RING_RUNNING, 0,
+ 5 * 1000 * 1000);
+
/* Some chips from Fresco Logic need an extraordinary delay */
delay *= (xhci->quirks & XHCI_SLOW_SUSPEND) ? 10 : 1;
Best regards,
Yoshihiro Shimoda
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: phy: rcar-gen2-usb: Fix USBHS_UGSTS_LOCK value
Hi, > Sent: Tuesday, April 28, 2015 4:45 AM > > Hi, > > On Thu, Apr 02, 2015 at 08:22:34PM +0900, Yoshihiro Shimoda wrote: > > According to the technical update (No. TN-RCS-B011A/E), the UGSTS LOCK > > bit location is bit 8, not bits 9 and 8. So, this patch fixes the > > USBHS_UGSTS_LOCK value. > > > > Signed-off-by: Yoshihiro Shimoda > > this doesn't apply to v4.1-rc1, if it's still needed, please rebase. Thank you for the notice. I found that this patch has been already merged in v4.1-rc1 by Greg. Best regards, Yoshihiro Shimoda > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: renesas_usbhs: Revise the binding document about the dma-names
Hi Felipe, > Sent: Thursday, April 09, 2015 6:06 PM > > On Thu, Apr 09, 2015 at 01:17:44AM +0100, Yoshihiro Shimoda wrote: > > Hi Mark, > > > > > > > > On Wed, Apr 08, 2015 at 11:42:24AM +0100, Yoshihiro Shimoda wrote: > > > > Since the DT should describe the hardware (not the driver limitation), > > > > This patch revises the binding document about the dma-names to change > > > > simple numbering as "ch%d" instead of "tx" and "rx". > > > > > > The naming given in this patch looks more sensible to me. > > > > Thank you for your comment! > > > > > > Also this patch fixes the actual code of renesas_usbhs driver to handle > > > > the new dma-names. > > > > > > > > Signed-off-by: Yoshihiro Shimoda > > > > --- > > > > This patch is based on Felipe's usb.bit / testing/next branch. > > > > (commit id = bbc78c07a51f6fd29c227b1220a9016e585358ba) > > > > > > I take it the existing driver and binding haven't hit mainline, and > > > therefore there are no users yet? > > > > That's correct. At the moment, nobody uses the dma-names in the node of > > renesas_usbhs yet. > > Given that: > > Acked-by: Mark Rutland Would you apply this patch to your repository? (If possible, it is merged in your fixes branch because the commit ab330cf388 is already merged on v4.1-rc1 and this patch is related to the commit.) Or, should I resubmit this patch with Mark and Geert's Acked-by? (I confirmed that this patch could be applied on the branches of both fixes and testing/next.) Best regards, Yoshihiro Shimoda P.S. I am surprised, the Morimoto-san's patch "tidyup usbhs_for_each_dfifo macro" is threaded to this patch. However, this patch is not related to the Morimoto-san's patch. http://thread.gmane.org/gmane.linux.ports.sh.devel/45229/focus=124680 > Thanks, > Mark. -- 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
