Re: Crash in dwc3 driver on module unload
Hi,
On Fri, Apr 12, 2013 at 01:55:02AM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, April 09, 2013 12:42 AM
> >
> > On Tue, Apr 09, 2013 at 02:36:51AM +, Paul Zimmerman wrote:
> > > I'm getting a crash when I rmmod the dwc3-pci driver in latest Linus, and
> > > also in 3.8.6 and 3.8.0.
> > >
> > > Screenshot (two parts) are here:
> > > http://ompldr.org/vaTFibQ/IMG1.jpg
> > > http://ompldr.org/vaTFicA/IMG2.jpg
> > >
> > > Unfortunately the very first part of the crash has scrolled off the
> > > screen.
> > >
> > > I've decoded the crash a bit. The call chain descends through
> > > platform_device_unregister(glue->dwc3) in dwc3_pci_remove(). It hits the
> > > warning in kobject_put():
> > >
> > > void kobject_put(struct kobject *kobj)
> > > {
> > > if (kobj) {
> > > if (!kobj->state_initialized)
> > > WARN(1, KERN_WARNING "kobject: '%s' (%p): is
> > > not "
> > > "initialized, yet kobject_put() is being
> > > "
> > > "called.\n", kobject_name(kobj), kobj);
> > > kref_put(&kobj->kref, kobject_release);
> > > }
> > > }
> > >
> > > and crashes when it tries to print the string, presumably because the
> > > kobj->name field is either NULL or poisoned. So probably the kobject has
> > > already been freed, or is in the process of being freed?
> > >
> > > Any ideas? Any debugging hints?
> >
> > looks like the PHY is being unregistered too early. I believe that's
> > because PHY's dev is just a pointer to the real dev and maybe that's
> > what's wrong.
> >
> > Here's what happens:
> >
> > devm_usb_get_phy() will find the PHY and issue a get_device(phy->dev).
> > phy->dev is initialized to (in your case) nop_xceiv's &pdev->dev.
> >
> > When you remove dwc3.ko, due to devm_usb_phy_get(),
> > devm_usb_phy_release() will get called which will issue a
> > put_device(phy->dev), and that will trigger nop_xceiv's platform_device
> > release, once you remove dwc3-pci.ko, you see the trigger.
> >
> > I'm adding Kishon to the loop to help out figuring out what the best fix
> > would be.
>
> I found out a couple more things about this.
>
> If I do "rmmod dwc3" first, and then do "rmmod dwc3-pci", it doesn't
> crash.
>
> On a related note, if I just do "modprobe dwc3-pci", then dwc3.ko
> doesn't get loaded. I have to do "modprobe dwc3" too, to get
> everything loaded. Shouldn't dwc3.ko be a dependency of dwc3-pci.ko,
> and get loaded automatically? Could this missing dependency also
> explain the crash on "rmmod dwc3-pci"?
there are no direct dependencies between those two modules other than
the fact that dwc3-pci.ko creates dwc3.ko's struct platform_device.
That, however, should be enough for udev to load the proper module. If
it's not loading, that's usually a bogus (or lack thereof)
MODULE_ALIAS().
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
On Thursday 11 April 2013 10:28:33 Dan Williams wrote: > > Looks it isn't a good practice to duplicate code in above four functions, > > but > > it should be OK to merge first. > > Oliver requested this approach. I'd originally taken your suggestion to > merge them, but this proved somewhat more complicated and Oliver > rejected that approach. We don't do functions which do a different thing based on flags. Linus chewed our posteriors for that. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9] usb/gadget: change sysfs parent device for USB Ethernet
On Thursday, April 11, 2013 5:00 PM Alan Stern wrote: > On Thu, 11 Apr 2013, Andrzej Pietrasiewicz wrote: > > > This adds a new sysfs root device to serve as a replacement for > > devices which are available only when a gadget is being bound. > > > > It is motivated by adding configfs support to USB Ethernet functions. > > When configfs is there, we would like to be able to mkdir some > > function directory, e.g.: > > > > $ mkdir functions/ecm.usb0 > > > > and have the usb0 available in the system (albeit in an unconfigured, > > or default state) at this very point, which is _way_ before the gadget > > What do you mean by "available in the system"? I mean that it is registered with register_netdev. So if $ ifconfig -a is issued we get e.g. usb0Link encap:Ethernet HWaddr 12:f3:12:23:c3:e7 (...) > > > is actually bound. However, this poses a chicken and egg problem. > > In order for the interface to appear in the system, it needs to be > > What interface are you talking about? Is it a USB interface, a network > interface, a programming interface, a user interface, or some other sort > of interface? > The usb0 from the example above. > > registered with register_netdev. But in order to register it, its > > parent device must be known and it becomes known only later during > > gadget's bind. > > Why must this happen before the gadget driver is bound? What can't it > happen after the driver is bound and before the gadget is connected to a > host? > I am not sure if I understand you well, but bounding the driver happens after the gadget is connected to a host, not the other way round. That is, the USB device is enumerated, configuration is selected, functions (e.g. f_ncm) are bound to USB. Only at this moment is the parent device known in the g_ncm.ko. Discoverability is one of the key ideas of configfs, this is what Joel Becker, configfs' author says. So once userspace creates the ncm.usb0 function, it wants to know what will be the interface name associated with it. The only way to know it is to have the network device registered with register_netdev and this requires providing the parent device. > > This patch adds a /sys/devices/usb_gadget root device, which is > > registered during module_init of libcomposite, so it is available at > > any time for all libcomposite users and is used as a parent device for > > USB Ethernet devices instead of the gadget->dev. > > I can't understand the reasoning here. It's like saying I should be able > to configure the network settings for my ethernet controller before the > e100 driver is bound to it. > I think the analogy is incorrect. The equivalent of e100 driver is the f_ncm driver which is loaded at the very moment the ncm.usb0 directory is created. The binding I am talking about refers to "connecting" the f_ncm to the underlying transport infrastructure, which is USB and it looks to me more like plugging an Ethernet cable to a socket in a network card. > Are you sure this is necessary? I assume you are questioning the changing of the parent device of the network device. In order to achieve the goals stated above I think it is necessary, because the network device needs to have a parent device and I am not sure if net core allows setting it later, after the device is registered. > > Alan Stern Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Device Hibernation: Wake from resume initiated by host
Hi Folks, I am trying to understand working of one hibernation scenario wrt to usb device controller say dwc3. 1. Host PC goes to suspend and enters into U3. 2. Device also enters U3 and generate hibernation event to software. 3. At this moment system with usb device goes to power save mode (say suspend to RAM). Everything is off except PMC and USB Phy. 4. After some time PC with usb host resumes. 5. U3 exit is detected by device PHY and communicated to PMC. 6. PMC does the reset and whole system resumes. My question is, how does usb device resume in this case? I understand that there is a limitation of 20 ms for U3_Exit. How will linux driver be able to do this within this time limit? Regards Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote: >> The work will complete when memory is reclaimed, and the rx/tx path is >> still working, so memory reclaim can continue and the deadlock may not >> be caused, may it? > > Only if the memory allocation goes to the same interface. If the blocking > interface > is storage, something bad happens (data loss not deadlock) OK, got it, it should be both since reset can't move on, so memory reclaim can't complete to satisfy the allocation. But I am wondering if it is a case which is worth the consideration. Almost all USB probe() allocate memory with GFP_KERNEL, then the similar scenario(data loss only this time) might happen too. Do we need to fix all USB drivers? Wrt. the usbnet_status_start() API, looks no good reason to call it in another queue context, it should be enough to call it in probe() or bind() if init_status() can be put before info->bind() in usbnet_probe(). Then looks the mem_flags isn't needed in both cases, and we should always take GFP_NOIO inside the API? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
On Friday 12 April 2013 17:42:46 Ming Lei wrote: > On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote: > >> The work will complete when memory is reclaimed, and the rx/tx path is > >> still working, so memory reclaim can continue and the deadlock may not > >> be caused, may it? > > > > Only if the memory allocation goes to the same interface. If the blocking > > interface > > is storage, something bad happens (data loss not deadlock) > > OK, got it, it should be both since reset can't move on, so > memory reclaim can't complete to satisfy the allocation. > > But I am wondering if it is a case which is worth the consideration. The remedy is close to trivial, so yes. > Almost all USB probe() allocate memory with GFP_KERNEL, then > the similar scenario(data loss only this time) might happen too. Do we > need to fix all USB drivers? No. We assume that probing happens before the interfaces are used. Furthermore, if this turns out to be real, we can reuse your fix for the general (w.o. work queue) reset case. > Wrt. the usbnet_status_start() API, looks no good reason to call > it in another queue context, it should be enough to call it in probe() or > bind() if init_status() can be put before info->bind() in usbnet_probe(). We are talking about a generic helper. And the fix is really simple. We just pass mem_flags and all is well. If the API can be made better at next to no cost, we do it. > Then looks the mem_flags isn't needed in both cases, and we should > always take GFP_NOIO inside the API? We cannot. GFP_ATOMIC may be needed. And no, we atre not going to unconditionally use GFP_ATOMIC :-; Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
On Fri, Apr 12, 2013 at 6:02 PM, Oliver Neukum wrote: > On Friday 12 April 2013 17:42:46 Ming Lei wrote: >> On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote: >> >> The work will complete when memory is reclaimed, and the rx/tx path is >> >> still working, so memory reclaim can continue and the deadlock may not >> >> be caused, may it? >> > >> > Only if the memory allocation goes to the same interface. If the blocking >> > interface >> > is storage, something bad happens (data loss not deadlock) >> >> OK, got it, it should be both since reset can't move on, so >> memory reclaim can't complete to satisfy the allocation. >> >> But I am wondering if it is a case which is worth the consideration. > > The remedy is close to trivial, so yes. > >> Almost all USB probe() allocate memory with GFP_KERNEL, then >> the similar scenario(data loss only this time) might happen too. Do we >> need to fix all USB drivers? > > No. We assume that probing happens before the interfaces are used. > Furthermore, if this turns out to be real, we can reuse your fix for the > general (w.o. work queue) reset case. See driver load/bind path(driver_attach()/driver_bound()), both may happen anytime on unbind interface. Yes, we can easily address it with the PF_MEMALLOC_NOIO trick, but can we afford NOIO allocation in probe() path for all drivers? > >> Wrt. the usbnet_status_start() API, looks no good reason to call >> it in another queue context, it should be enough to call it in probe() or >> bind() if init_status() can be put before info->bind() in usbnet_probe(). > > We are talking about a generic helper. And the fix is really simple. > We just pass mem_flags and all is well. If the API can be made better > at next to no cost, we do it. > >> Then looks the mem_flags isn't needed in both cases, and we should >> always take GFP_NOIO inside the API? > > We cannot. GFP_ATOMIC may be needed. And no, we atre not going to > unconditionally use GFP_ATOMIC :-; It depend on the probe() case, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active
Oliver Neukum writes: > On Friday 12 April 2013 17:42:46 Ming Lei wrote: > >> Wrt. the usbnet_status_start() API, looks no good reason to call >> it in another queue context, it should be enough to call it in probe() or >> bind() if init_status() can be put before info->bind() in usbnet_probe(). > > We are talking about a generic helper. And the fix is really simple. > We just pass mem_flags and all is well. If the API can be made better > at next to no cost, we do it. I absolutely agree with this. >> Then looks the mem_flags isn't needed in both cases, and we should >> always take GFP_NOIO inside the API? > > We cannot. GFP_ATOMIC may be needed. And no, we atre not going to > unconditionally use GFP_ATOMIC :-; But I don't think we ever will need GFP_ATOMIC as long as we take a mutex lock anyway. 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
[PATCH 3/4 v2] staging: dwc2: add platform device bindings
This adds a dwc_platform.ko module that can be loaded by using
compatible = "snps,dwc2" in a device tree.
Signed-off-by: Matthijs Kooijman
---
v2: remove useless debug prints
change module author and copyright
use "usb" in devicetree example instead of "otg"
---
Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++
drivers/staging/dwc2/Kconfig | 6 +-
drivers/staging/dwc2/Makefile | 2 +
drivers/staging/dwc2/platform.c| 145 +
4 files changed, 166 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt
create mode 100644 drivers/staging/dwc2/platform.c
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt
b/Documentation/devicetree/bindings/staging/dwc2.txt
new file mode 100644
index 000..a13ffed
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -0,0 +1,15 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-
+
+Required properties:
+- compatible : "snps,dwc2"
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+
+Example:
+
+usb@101c {
+compatible = "ralink,rt3050-otg, snps,dwc2";
+reg = <0x101c 4>;
+interrupts = <18>;
+};
diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig
index 2f75be7..f0b4739 100644
--- a/drivers/staging/dwc2/Kconfig
+++ b/drivers/staging/dwc2/Kconfig
@@ -8,9 +8,11 @@ config USB_DWC2
USB controller based on the DesignWare HSOTG IP Core.
If you choose to build this driver as dynamically linked
- modules, the core module will be called dwc2.ko, and the
+ modules, the core module will be called dwc2.ko, the
PCI bus interface module (if you have a PCI bus system)
- will be called dwc2_pci.ko.
+ will be called dwc2_pci.ko and the platform interface module
+ (for controllers directly connected to the CPU) will be called
+ dwc2_platform.ko.
NOTE: This driver at present only implements the Host mode
of the controller. The existing s3c-hsotg driver supports
diff --git a/drivers/staging/dwc2/Makefile b/drivers/staging/dwc2/Makefile
index 6dccf46..11529d3 100644
--- a/drivers/staging/dwc2/Makefile
+++ b/drivers/staging/dwc2/Makefile
@@ -19,5 +19,7 @@ dwc2-y+= hcd_queue.o
hcd_ddma.o
ifneq ($(CONFIG_PCI),)
obj-$(CONFIG_USB_DWC2) += dwc2_pci.o
endif
+obj-$(CONFIG_USB_DWC2) += dwc2_platform.o
dwc2_pci-y += pci.o
+dwc2_platform-y+= platform.o
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
new file mode 100644
index 000..9662c00
--- /dev/null
+++ b/drivers/staging/dwc2/platform.c
@@ -0,0 +1,145 @@
+/*
+ * platform.c - DesignWare HS OTG Controller platform driver
+ *
+ * Copyright (C) Matthijs Kooijman
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h
Re: [PATCH 4/4] staging: dwc2: load parameters from the devicetree
Hi Marc,
> > /** > > + * dwc2_load_property() - Load a single property from the
> > devicetree
> > + * node into the given variable.
> > + *
> > + * @dev: Platform device
> > + * @res: The variable to put the loaded value into
> > + * @name: The name of the devicetree property to load
> > + */
> > +static void dwc2_load_property(struct platform_device *dev, int *res,
> > + const char *name)
> > +{
> > + int len;
> > + const u32 *val;
> > +
> > + val = of_get_property(dev->dev.of_node, name, &len);
> > + if (!val)
> > + return;
> > +
> > + if (len != sizeof(*val)) {
> > + dev_warn(&dev->dev,
> > +"Invalid value in devicetree for %s property, should
> > be a single integer\n",
> > +name);
> > + return;
> > + }
> > +
> > + *res = be32_to_cpu(*val);
>
> What about using of_property_read_u32() instead of open coding it here?
Apparently I missed that function while looking through of.h, I'll
convert the code. Thanks for pointing it out!
Gr.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] staging: dwc2: load parameters from the devicetree
Hi Paul, > These are the core parameters that I think are needed right now: > > dma_enable > dma_desc_enable > host_rx_fifo_size > host_nperio_tx_fifo_size > host_perio_tx_fifo_size > max_transfer_size > max_packet_count > host_channels > > phy_type > phy_utmi_width > phy_ulpi_ddr > phy_ulpi_ext_vbus > i2c_enable > ulpi_fs_ls > host_support_fs_ls_low_power > host_ls_low_power_phy_clk > > The last 8 are related to the Phy. I wonder if they should be in a > separate Phy dt file? Looking at the dwc3 driver, it can have a "usb-phy" phandle property in its dt node that points to a different phy node in the dt, possibly with a different driver. However, all of the glue drivers default the phy to a nop_usb_xceiv phy driver, which is basically a noop driver AFAICS. I'm not sure if the dwc2 hardware could ever be connected to an external PHY that actually needs a driver? Or does the dwc2 core do all the talking to the PHY and are these parameters just to tell the core how to talk to the PHY? As you might gather from the above, I'm not really in the loop about how the hardware works here, so I don't think I'm qualified to decide on the best approach here... Perhaps I should adapt my patch to just the non-phy related parameters and we can do the phy-stuff later when it is clear how they should work? Gr. Matthijs -- 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: Linux USB file storage gadget with new UDC
On Fri, 12 Apr 2013, victor yeo wrote: > Thanks, i print out additional information in gadget driver and UDC > driver. Here are another problem. In usbmon trace, the time difference > between first SCSI_INQUIRY command and the second TEST_UNIT_READY > command is large. So i check the driver log file. When SCSI_INQUIRY is > received, start_transfer() is called, then UDC ep_queue function is > called, then bulk_out_complete() is called. This sequence is repeated > many times. In fact, this problem starts even _before_ the INQUIRY command is received. The log shows that the UDC driver calls the bulk_out_complete routine over and over, even though no packet was received and ka2000_ack_irq didn't run. The same thing happens after the INQUIRY is received. The UDC driver is not supposed to call bulk_out_complete until a transfer has completed. After the gadget was reset, the problem didn't occur any more. > What is the reason that SCSI_INQUIRY is not processed by > gadget driver? Is it due to some problem in UDC driver? The INQUIRY _was_ processed by the gadget driver. Yes, the UDC driver has a problem; see above. > After that, i can see when the unknown command 0xa1 is received, the > UDC driver sets the Halt feature. Look at line 1339 of the UDC log file: > g_file_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, > Hi=192 > g_file_storage gadget: bulk-in, length 16: > : 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff > [start_transfer] f 40a08 > ept1 in queue len 0x10, buffer 0xc12ac000 > 0: 0xf > 4: 0x40a08 > 8: 0x > c: 0x > ka2000_ack_irq(32) > bulk_in_complete --> 0, 16/16 At this point the gadget driver tries to do a set-halt: > g_file_storage gadget: bulk-in set halt > kagen2_set_halt 1 1 When the Halt feature is set, the UDC is supposed to send a STALL packet to the host -- but it did not. Instead it sent this 13-byte bulk-IN packet. > g_file_storage gadget: bulk-in, length 13: > : 55 53 42 53 08 00 00 00 b0 00 00 00 00 > [start_transfer] 53425355 8 > ept1 in queue len 0xd, buffer 0xc133c000 > 0: 0x53425355 > 4: 0x8 > 8: 0xb0 > bulk_in_complete --> 0, 13/13 The same thing happened when the 0xA1 command was received: > g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, Hi=512 > g_file_storage gadget: bulk-in, length 0: > [start_transfer] 43425355 12 > ept1 in queue len 0x0, buffer 0xc12ac000 > g_file_storage gadget: bulk-in set halt > kagen2_set_halt 1 1 Right here, a STALL packet should have been sent. It wasn't. > g_file_storage gadget: sending command-failure status > g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 > g_file_storage gadget: bulk-in, length 13: > : 55 53 42 53 12 00 00 00 00 02 00 00 01 > [start_transfer] 53425355 12 > ept1 in queue len 0xd, buffer 0xc133c000 > 0: 0x53425355 > 4: 0x12 > 8: 0x200 > bulk_in_complete --> 0, 13/13 Instead this packet was sent. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] staging: dwc2: fix error return code in dwc2_hcd_init()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/staging/dwc2/hcd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index bc9c3c5..7a144c1 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2836,6 +2836,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
goto error2;
/* Create new workqueue and init work */
+ retval = -ENOMEM;
hsotg->wq_otg = create_singlethread_workqueue("dwc2");
if (!hsotg->wq_otg) {
dev_err(hsotg->dev, "Failed to create workqueue\n");
--
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 -next] staging: dwc2: fix error return code in dwc2_hcd_init()
On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote: > Fix to return a negative error code from the error handling > case instead of 0, as returned elsewhere in this function. > > Signed-off-by: Wei Yongjun Patch looks good good to me. Reviewed-by: Matthijs Kooijman Gr. Matthijs -- 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
Fw: [Bug 56521] New: No support of Motorola ZN5 USBnet in zaurus module
Begin forwarded message: Date: Fri, 12 Apr 2013 07:27:18 -0700 From: "bugzilla-dae...@bugzilla.kernel.org" To: "step...@networkplumber.org" Subject: [Bug 56521] New: No support of Motorola ZN5 USBnet in zaurus module https://bugzilla.kernel.org/show_bug.cgi?id=56521 Summary: No support of Motorola ZN5 USBnet in zaurus module Product: Networking Version: 2.5 Kernel Version: 3.7.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: shemmin...@linux-foundation.org ReportedBy: a1ba.oma...@gmail.com Regression: No Created an attachment (id=98391) --> (https://bugzilla.kernel.org/attachment.cgi?id=98391) zaurus.patch I've tried to plug my phone via USBnet, but zaurus module is not loaded, because kernel can't detect it as zaurus-like device. I looked to dmesg and found that: [ 7880.799111] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 7880.957767] usb 1-1: New USB device found, idVendor=22b8, idProduct=6424 [ 7880.957771] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=0 [ 7880.957774] usb 1-1: Product: ZN5 [ 7880.95] usb 1-1: Manufacturer: Motorola Inc. [ 7881.646079] usb 1-1: bad CDC descriptors [ 7881.646100] usbcore: registered new interface driver cdc_ether In source file I don't found my idProduct=6424, but found support of Motorola MOTOMAGX Phones with idProduct=6425 I added in drivers/net/usb/zaurus.c idProduct of my phone and it works perfectly and without any errors or warnings. Attachment contains patch for zaurus.c. Please, add it to kernel. P.S. Sorry for my English, I know it bad. =( -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: Fw: [Bug 56521] New: No support of Motorola ZN5 USBnet in zaurus module
On Fri, Apr 12, 2013 at 08:32:59AM -0700, Stephen Hemminger wrote: > Created an attachment (id=98391) > --> (https://bugzilla.kernel.org/attachment.cgi?id=98391) > zaurus.patch We need a patch in email form. 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: Linux USB file storage gadget with new UDC
Hi, >> Thanks, i print out additional information in gadget driver and UDC >> driver. Here are another problem. In usbmon trace, the time difference >> between first SCSI_INQUIRY command and the second TEST_UNIT_READY >> command is large. So i check the driver log file. When SCSI_INQUIRY is >> received, start_transfer() is called, then UDC ep_queue function is >> called, then bulk_out_complete() is called. This sequence is repeated >> many times. > > In fact, this problem starts even _before_ the INQUIRY command is > received. The log shows that the UDC driver calls the > bulk_out_complete routine over and over, even though no packet was > received and ka2000_ack_irq didn't run. The same thing happens after > the INQUIRY is received. > > The UDC driver is not supposed to call bulk_out_complete until a > transfer has completed. > > After the gadget was reset, the problem didn't occur any more. > >> What is the reason that SCSI_INQUIRY is not processed by >> gadget driver? Is it due to some problem in UDC driver? > > The INQUIRY _was_ processed by the gadget driver. Yes, the UDC driver > has a problem; see above. > >> After that, i can see when the unknown command 0xa1 is received, the >> UDC driver sets the Halt feature. > > Look at line 1339 of the UDC log file: > >> g_file_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, >> Hi=192 >> g_file_storage gadget: bulk-in, length 16: >> : 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff >> [start_transfer] f 40a08 >> ept1 in queue len 0x10, buffer 0xc12ac000 >> 0: 0xf >> 4: 0x40a08 >> 8: 0x >> c: 0x >> ka2000_ack_irq(32) >> bulk_in_complete --> 0, 16/16 > > At this point the gadget driver tries to do a set-halt: > >> g_file_storage gadget: bulk-in set halt >> kagen2_set_halt 1 1 > > When the Halt feature is set, the UDC is supposed to send a STALL > packet to the host -- but it did not. Instead it sent this 13-byte > bulk-IN packet. > >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 08 00 00 00 b0 00 00 00 00 >> [start_transfer] 53425355 8 >> ept1 in queue len 0xd, buffer 0xc133c000 >> 0: 0x53425355 >> 4: 0x8 >> 8: 0xb0 >> bulk_in_complete --> 0, 13/13 > > The same thing happened when the 0xA1 command was received: > >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, >> Hi=512 >> g_file_storage gadget: bulk-in, length 0: >> [start_transfer] 43425355 12 >> ept1 in queue len 0x0, buffer 0xc12ac000 >> g_file_storage gadget: bulk-in set halt >> kagen2_set_halt 1 1 > > Right here, a STALL packet should have been sent. It wasn't. > >> g_file_storage gadget: sending command-failure status >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 >> g_file_storage gadget: bulk-in, length 13: >> : 55 53 42 53 12 00 00 00 00 02 00 00 01 >> [start_transfer] 53425355 12 >> ept1 in queue len 0xd, buffer 0xc133c000 >> 0: 0x53425355 >> 4: 0x12 >> 8: 0x200 >> bulk_in_complete --> 0, 13/13 > > Instead this packet was sent. > > Alan Stern Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it should not be sent at all, and the UDC driver should send the STALL packet instead of this CSW? Just curious, after this 0xa1 is received and bulk-in endpoint is halted. The Linux host tries to send TEST_UNIT_READY command, and UDC driver could not receive it because endpoint is halted and in reset condition. Seems like the set Halt feature is working (but STALL packet is not sent). victor -- 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: Linux USB file storage gadget with new UDC
On Sat, 13 Apr 2013, victor yeo wrote: > > The same thing happened when the 0xA1 command was received: > > > >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, > >> Hi=512 > >> g_file_storage gadget: bulk-in, length 0: > >> [start_transfer] 43425355 12 > >> ept1 in queue len 0x0, buffer 0xc12ac000 > >> g_file_storage gadget: bulk-in set halt > >> kagen2_set_halt 1 1 > > > > Right here, a STALL packet should have been sent. It wasn't. > > > >> g_file_storage gadget: sending command-failure status > >> g_file_storage gadget: sense data: SK x05, ASC x20, ASCQ x00; info x0 > >> g_file_storage gadget: bulk-in, length 13: > >> : 55 53 42 53 12 00 00 00 00 02 00 00 01 > >> [start_transfer] 53425355 12 > >> ept1 in queue len 0xd, buffer 0xc133c000 > >> 0: 0x53425355 > >> 4: 0x12 > >> 8: 0x200 > >> bulk_in_complete --> 0, 13/13 > > > > Instead this packet was sent. > > > > Alan Stern > > Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it > should not be sent at all, and the UDC driver should send the STALL > packet instead of this CSW? No. As long as the Halt feature is set for the bulk-in endpoint, the UDC should send STALL packets. When the host clears the Halt feature, then the UDC should send the CSW packet. > Just curious, after this 0xa1 is received and bulk-in endpoint is > halted. The Linux host tries to send TEST_UNIT_READY command, and UDC > driver could not receive it because endpoint is halted and in reset > condition. That sounds very wrong. The bulk-IN endpoint was halted, but the TEST UNIT READY command is sent to the bulk-OUT endpoint. There should be no problem receiving it. > Seems like the set Halt feature is working (but STALL > packet is not sent). Maybe the UDC driver is halting the wrong endpoint. 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: PROBLEM: EHCI USB device resets and fails
On Tue, Mar 19, 2013 at 12:12:01PM -0400, Alan Stern wrote: > If you want to find out what caused those resets, capture a usbmon > trace for bus 2. It may provide a clue. I've finally captured a usbmon trace at a time when it broke, but I'm not sure what I'm looking at. I'm assuming it's a hardware error at this point, but my question is what kind of error -- device, cable, motherboard, etc. I've uploaded the (hopefully) relevant bits to https://gist.github.com/bruceg/5373595 -- Bruce Guenter http://untroubled.org/ signature.asc Description: Digital signature
RE: [PATCH 3/9] usb/gadget: change sysfs parent device for USB Ethernet
On Fri, 12 Apr 2013, Andrzej Pietrasiewicz wrote: > > > registered with register_netdev. But in order to register it, its > > > parent device must be known and it becomes known only later during > > > gadget's bind. > > > > Why must this happen before the gadget driver is bound? What can't it > > happen after the driver is bound and before the gadget is connected to a > > host? > > > > I am not sure if I understand you well, but bounding the driver happens > after the gadget is connected to a host, not the other way round. > That is, the USB device is enumerated, configuration is selected, functions > (e.g. f_ncm) are bound to USB. Only at this moment is the parent device > known in the g_ncm.ko. Now I'm confused. You say that function drivers don't get bound until the host has enumerated the gadget and installed the gadget's configuration. But if the functions start out being unbound, how can the gadget respond to a Get-Config-Descriptor request during enumeration? The functions' descriptors -- in particular, the endpoint descriptors -- have to be known by that time. How can they be known before the function is bound to USB? But this is getting off the main topic... > Discoverability is one of the key ideas of configfs, this is what > Joel Becker, configfs' author says. So once userspace creates the > ncm.usb0 function, it wants to know what will be the interface name > associated with it. The only way to know it is to have the network device > registered with register_netdev and this requires providing the parent > device. "Discoverability" is a pretty vague term. Is e100 discoverable? If e100 worked the way you describe f_ncm, first you would tell the kernel to load the e100 driver, and afterward you would tell the kernel which Ethernet card to bind to e100. In between, how do you find out what interface name will be associated with this Ethernet card? Answer: You can't. Not until after the binding is set up. Why should f_ncm be any different? Suppose for the sake of argument that f_ncm could be bound to several different types of transport, not just USB. An interface name like "usb0" would be appropriate only when the driver was bound to a USB transport. So before the binding takes place, how can f_ncm know what type of transport will be used and thus what sort of interface name would be appropriate? You could improve the discoverability by providing a readonly configfs attribute that would contain the interface name _after_ the binding to the transport is finished and the interface has been registered. But this shouldn't be necessary; nowadays naming of network interfaces is all handled by udev anyway. > > > This patch adds a /sys/devices/usb_gadget root device, which is > > > registered during module_init of libcomposite, so it is available at > > > any time for all libcomposite users and is used as a parent device for > > > USB Ethernet devices instead of the gadget->dev. > > > > I can't understand the reasoning here. It's like saying I should be able > > to configure the network settings for my ethernet controller before the > > e100 driver is bound to it. > > > > I think the analogy is incorrect. The equivalent of e100 driver is the f_ncm > driver which is loaded at the very moment the ncm.usb0 directory is created. > The binding I am talking about refers to "connecting" the f_ncm to the > underlying transport infrastructure, which is USB and it looks to me more > like > plugging an Ethernet cable to a socket in a network card. Surely plugging an Ethernet cable into a socket on a network card is analagous to plugging a USB cable into a socket on a UDC. There's no trouble configuring a USB-based network interface before the USB cable is plugged in. > > Are you sure this is necessary? > > I assume you are questioning the changing of the parent device of the > network > device. In order to achieve the goals stated above I think it is necessary, > because the network device needs to have a parent device and I am not sure > if net core allows setting it later, after the device is registered. I'm really asking whether it is necessary to provide a network interface name in configfs before the function driver is bound to a transport. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
Hello. On 04/12/2013 04:34 AM, Simon Horman wrote: Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130410' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 (which would have been most convenient probably), and it's probably too late to merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11, unfortunately... Felipe, how would you prefer to handle this? I'm happy for you to take it or to take it myself. please take it yourself, just keep in mind there will be conflicts, I will go over the patches now and give my Acked-by so you can queue them up. Thanks Sergei, it looks like patches 1-7 are clear. #7 & #9 have been refused by Felipe (hence #8 isn't good too). Do you want me to start queueing them up. I was going to repost the whole series soon, adding ACK from Alan It's not as soon as I had hoped but I hope I would be able to do it in several hours... to the patch #2 and resolving issues with patches #7..#9. It's worth waiting for that to happen I think. I am quite happy to wait. One minor comment - there is no need to repost just to fix this - could you consider using lower-case for the socs for consistency with the common practice in patch subject lines. e.g.: ARM: shmobile: r8a7779: setup EHCI Alright, although I have a kind of idiosyncrasy to lowercasing otherwise uppercase names. Or would you rather wait for the issue with patch 6 to be resolved? There's no special issue with patch #6 other than the PHY driver files being renamed in Felipe's tree -- but that concerns all patches touching drivers/usb/phy/rcar-phy.c (some of which precede #6). Sorry, I made an error. I meant #8 and in turn #9. The issues start at patch #7 actually, where the platform data represenation seemed inappropriate to Felipe. I don't know how the rename conflict will be handled (this is really bad coincidence), perhaps I still should have done this patchset against Felipe's 'next' branch and pushed it thru his tree. If the patches will be queued for 3.11 anyway, maybe it's worth doing that -- I'm still of the opinion that his tree would be the one most fitting for this patchset. It seems that git will handle it :) Well, let's hope. There's still an issue with header file name it wouldn't be able to handle but I'll probably leave it as is, as the other PHY files in include/linux/usb/ didn't get renamed in the big rename. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -next] staging: dwc2: fix error return code in dwc2_hcd_init()
> From: Matthijs Kooijman [mailto:matth...@stdin.nl] > Sent: Friday, April 12, 2013 8:21 AM > > On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote: > > Fix to return a negative error code from the error handling > > case instead of 0, as returned elsewhere in this function. > > > > Signed-off-by: Wei Yongjun > > Patch looks good good to me. > > Reviewed-by: Matthijs Kooijman [ Wei, please always CC the maintainer when sending a patch. ] Acked-by: Paul Zimmerman -- 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 -next] staging: dwc2: fix error return code in dwc2_hcd_init()
On Fri, Apr 12, 2013 at 06:52:40PM +, Paul Zimmerman wrote: > > From: Matthijs Kooijman [mailto:matth...@stdin.nl] > > Sent: Friday, April 12, 2013 8:21 AM > > > > On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote: > > > Fix to return a negative error code from the error handling > > > case instead of 0, as returned elsewhere in this function. > > > > > > Signed-off-by: Wei Yongjun > > > > Patch looks good good to me. > > > > Reviewed-by: Matthijs Kooijman > > [ Wei, please always CC the maintainer when sending a patch. ] > > Acked-by: Paul Zimmerman Odd. It was CC'd to your pa...@synopsys.com address. Maybe it just hasn't arrived yet? regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] staging: dwc2: load parameters from the devicetree
> From: Matthijs Kooijman [mailto:matth...@stdin.nl] > > > These are the core parameters that I think are needed right now: > > > > dma_enable > > dma_desc_enable > > host_rx_fifo_size > > host_nperio_tx_fifo_size > > host_perio_tx_fifo_size > > max_transfer_size > > max_packet_count > > host_channels > > > > phy_type > > phy_utmi_width > > phy_ulpi_ddr > > phy_ulpi_ext_vbus > > i2c_enable > > ulpi_fs_ls > > host_support_fs_ls_low_power > > host_ls_low_power_phy_clk > > > > The last 8 are related to the Phy. I wonder if they should be in a > > separate Phy dt file? > > Looking at the dwc3 driver, it can have a "usb-phy" phandle property in > its dt node that points to a different phy node in the dt, possibly with > a different driver. However, all of the glue drivers default the phy to > a nop_usb_xceiv phy driver, which is basically a noop driver AFAICS. > > I'm not sure if the dwc2 hardware could ever be connected to an external > PHY that actually needs a driver? Or does the dwc2 core do all the > talking to the PHY and are these parameters just to tell the core how to > talk to the PHY? The Phy implementation is up to the system designer. But yes, the parameters we are talking about are to tell the core how to talk to the Phy. So maybe they do belong in the core's dt file. (I don't know anything about how the dt stuff is supposed to work.) > As you might gather from the above, I'm not really in the loop about how > the hardware works here, so I don't think I'm qualified to decide on the > best approach here... Perhaps I should adapt my patch to just the > non-phy related parameters and we can do the phy-stuff later when it is > clear how they should work? That won't work. The Phy parameters have to be set according to the type of Phy that is connected, and some of them cannot be autodetected. So they have to be defined somewhere. Felipe, do you have any ideas about this? -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: EHCI USB device resets and fails
On Fri, 12 Apr 2013, Bruce Guenter wrote: > On Tue, Mar 19, 2013 at 12:12:01PM -0400, Alan Stern wrote: > > If you want to find out what caused those resets, capture a usbmon > > trace for bus 2. It may provide a clue. > > I've finally captured a usbmon trace at a time when it broke, but I'm > not sure what I'm looking at. I'm assuming it's a hardware error at this > point, but my question is what kind of error -- device, cable, > motherboard, etc. > > I've uploaded the (hopefully) relevant bits to > https://gist.github.com/bruceg/5373595 It seems to be a device error. The computer was going along as usual, polling each of the logical units in the card reader to see whether any media had been installed. Then suddenly, the reader started responding with STALLs instead of data. The computer issued a USB port reset, after which the card reader stopped responding altogether. The computer then issued a second port reset, which didn't complete, and a third, which ended in failure. It's safe to say that at this point the reader's high-speed USB interface was kaput. The computer and the reader both switched over to the full-speed (USB-1.1) interface, which seemed to work okay. Now, possibly these device errors were ultimately caused by electrical problems involving the cable, or some sort of interference. If so, there's no way to tell. Does the card reader work better when attached to a different computer? Does a different reader work better on this computer? 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: USB Device Hibernation: Wake from resume initiated by host
> From: Pratyush Anand [mailto:pratyush.an...@st.com] > Sent: Friday, April 12, 2013 1:44 AM > > Hi Folks, > > I am trying to understand working of one hibernation scenario wrt to usb > device controller say dwc3. > > 1. Host PC goes to suspend and enters into U3. > 2. Device also enters U3 and generate hibernation event to software. > 3. At this moment system with usb device goes to power save mode > (say suspend to RAM). Everything is off except PMC and USB Phy. > 4. After some time PC with usb host resumes. > 5. U3 exit is detected by device PHY and communicated to PMC. > 6. PMC does the reset and whole system resumes. > > My question is, how does usb device resume in this case? I understand > that there is a limitation > of 20 ms for U3_Exit. How will linux driver be able to do this within > this time limit? 20 ms is quite a long time. But if your system cannot resume that quickly from whatever sleep state it was in, then you may need some special code to do the USB resume early, before the entire system has woken up. But even if you do not meet the 20 ms requirement, I think the worst thing that can happen is that the host will reset the device and re-enumerate it. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4 v2] staging: dwc2: add platform device bindings
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Friday, April 12, 2013 3:42 AM
>
> This adds a dwc_platform.ko module that can be loaded by using
> compatible = "snps,dwc2" in a device tree.
>
> Signed-off-by: Matthijs Kooijman
>
> ---
> v2: remove useless debug prints
> change module author and copyright
> use "usb" in devicetree example instead of "otg"
> ---
> Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++
> drivers/staging/dwc2/Kconfig | 6 +-
> drivers/staging/dwc2/Makefile | 2 +
> drivers/staging/dwc2/platform.c| 145
> +
> 4 files changed, 166 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt
> create mode 100644 drivers/staging/dwc2/platform.c
...
> diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
> new file mode 100644
> index 000..9662c00
...
> +static const struct of_device_id dwc2_of_match_table[] = {
> + { .compatible = "snps,dwc2" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dwc2_otg_match_table);
Did you compile this? dwc2_otg_match_table != dwc2_of_match_table
--
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4 v2] staging: dwc2: add platform device bindings
Hi Paul,
On Fri, Apr 12, 2013 at 09:09:51PM +, Paul Zimmerman wrote:
> > From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> > Sent: Friday, April 12, 2013 3:42 AM
> >
> > This adds a dwc_platform.ko module that can be loaded by using
> > compatible = "snps,dwc2" in a device tree.
> >
> > Signed-off-by: Matthijs Kooijman
> >
> > ---
> > v2: remove useless debug prints
> > change module author and copyright
> > use "usb" in devicetree example instead of "otg"
> > ---
> > Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++
> > drivers/staging/dwc2/Kconfig | 6 +-
> > drivers/staging/dwc2/Makefile | 2 +
> > drivers/staging/dwc2/platform.c| 145
> > +
> > 4 files changed, 166 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt
> > create mode 100644 drivers/staging/dwc2/platform.c
>
> ...
>
> > diff --git a/drivers/staging/dwc2/platform.c
> > b/drivers/staging/dwc2/platform.c
> > new file mode 100644
> > index 000..9662c00
>
> ...
>
> > +static const struct of_device_id dwc2_of_match_table[] = {
> > + { .compatible = "snps,dwc2" },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, dwc2_otg_match_table);
>
> Did you compile this? dwc2_otg_match_table != dwc2_of_match_table
Ah, I didn't try compiling as a module, which is of course an oversight.
I'll see if I can find some time tomorrow, and otherwise monday, to fix
this and actually test the module loading on my hardware.
Gr.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4 v2] staging: dwc2: add platform device bindings
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Friday, April 12, 2013 2:33 PM
>
> On Fri, Apr 12, 2013 at 09:09:51PM +, Paul Zimmerman wrote:
> > > From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> > > Sent: Friday, April 12, 2013 3:42 AM
> > >
> > > This adds a dwc_platform.ko module that can be loaded by using
> > > compatible = "snps,dwc2" in a device tree.
> > >
> > > Signed-off-by: Matthijs Kooijman
> > >
> > > ---
> > > v2: remove useless debug prints
> > > change module author and copyright
> > > use "usb" in devicetree example instead of "otg"
> > > ---
> > > Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++
> > > drivers/staging/dwc2/Kconfig | 6 +-
> > > drivers/staging/dwc2/Makefile | 2 +
> > > drivers/staging/dwc2/platform.c| 145
> > > +
> > > 4 files changed, 166 insertions(+), 2 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt
> > > create mode 100644 drivers/staging/dwc2/platform.c
> >
> > ...
> >
> > > diff --git a/drivers/staging/dwc2/platform.c
> > > b/drivers/staging/dwc2/platform.c
> > > new file mode 100644
> > > index 000..9662c00
> >
> > ...
> >
> > > +static const struct of_device_id dwc2_of_match_table[] = {
> > > + { .compatible = "snps,dwc2" },
> > > + {},
> > > +};
> > > +MODULE_DEVICE_TABLE(of, dwc2_otg_match_table);
> >
> > Did you compile this? dwc2_otg_match_table != dwc2_of_match_table
>
> Ah, I didn't try compiling as a module, which is of course an oversight.
> I'll see if I can find some time tomorrow, and otherwise monday, to fix
> this and actually test the module loading on my hardware.
Also, at the top of dwc2_driver_probe() there is a call to
dwc2_set_all_params(), which is in a different module and thus won't
link. I think that shouldn't be there anyway, since it is already
called in dwc2_hcd_init(). You should also make dwc2_set_all_params()
a static function and remove its declaration from hcd.h.
--
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4 v2] staging: dwc2: add platform device bindings
Hi Paul, > Also, at the top of dwc2_driver_probe() there is a call to > dwc2_set_all_params(), which is in a different module and thus won't > link. Ah, good point. I guess I should have added a EXPORT_SYMBOL_GPL(dwc2_set_all_params) as well when adding the declaration to hcd.h in the previous patch. > I think that shouldn't be there anyway, since it is already called in > dwc2_hcd_init(). It is there on purpose. There are two instances of core_params: The one allocated in platform.c are the "requested" values. These are fixed to -1 in this patch, but get populated with DT data in the next patch. There is a second instance, allocated and initialized to -1 by hcd_init, which stores the actual values used. The various dwc2_set_param_* functions validate the values from the first instance and store them in the second. We can probably merge these into one instance if that is desirable, but that one instance should then be allocated inside platform.c, since it must be writable and needs data from the dt loaded into it (so it cannot be a global const struct shared between all devices, like in pci.c). Gr. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hello. On 04/10/2013 05:31 AM, Kuninori Morimoto wrote: Please add this "tested on xxx" comment on each patch's log area, not only on [0/x]. We need it on "git log" I'm going to post R8A7778/BOCK-W series following this one, and all the patches in 1st series should additionally be tested on BOCK-W. Well, I probably can hold up posting version 3 until I have the second series verified. BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not on BOCK-W board? PHY initialization seems to work with either settings... I can ask it to HW team if you want me. But our local BSP is using "No ferrite bead" settings... I've rummaged thru the BSP I have and found not traces of a ferrite bead (and rcar-phy driver as well) in the patches... Best regards --- Kuninori Morimoto WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
On 04/13/2013 03:07 AM, I wrote: Please add this "tested on xxx" comment on each patch's log area, not only on [0/x]. We need it on "git log" I'm going to post R8A7778/BOCK-W series following this one, and all the patches in 1st series should additionally be tested on BOCK-W. Well, I probably can hold up posting version 3 until I have the second series verified. BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not on BOCK-W board? PHY initialization seems to work with either settings... I can ask it to HW team if you want me. Yes, ask them please. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/9] Reorganize R8A7779/Marzen USB code
Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130412' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file. Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.
Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.
Note also that the board and SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- refreshed the 'board-marzen.c' file.
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c | 178 -
arch/arm/mach-shmobile/include/mach/r8a7779.h |1
arch/arm/mach-shmobile/setup-r8a7779.c| 185 +-
3 files changed, 184 insertions(+), 180 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
#include
#include
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
.num_resources = ARRAY_SIZE(hspi_resources),
};
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70900 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device usb_phy_device = {
- .name = "rcar_usb_phy",
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* LEDS */
static struct gpio_led marzen_leds[] = {
{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
&sdhi0_device,
&thermal_device,
&hspi_device,
- &usb_phy_device,
&leds_device,
};
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
- if (!phy)
- return -EIO;
-
- pm_runtime_enable(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
-
- usb_phy_init(phy);
-
- return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
- if (!phy)
- return;
-
- usb_phy_shutdown(phy);
-
- pm_runtime_put_sync(&pdev->dev);
- pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
- .power_on = usb_power_on,
- .power_off = usb_power_off,
- .power_suspend = usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4c),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci0_device = {
- .name = "ehci-platform",
- .id = 0,
- .dev= {
- .dma_mask = &ehci0_device.dev.coherent_dma_mask,
- .coherent_dma_mask = 0x,
- .platform_data = &ehcix_pdata,
- },
- .num_resources = ARRAY_SIZE(ehci0_resources),
- .resource = ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
- [0] = {
- .start = 0xfff7,
- .end= 0xfff70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4d),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci1_device = {
- .name = "ehci-platform",
- .id = 1,
- .dev= {
- .dma_mask = &ehci1_device.dev.coherent_dma_mask,
- .coherent_dma_mask = 0x,
- .platform_data = &ehcix_pdata,
- },
- .num_resources = ARRAY_SIZE(ehci1_resources),
- .resource = ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
- .power_on = usb_power_on,
- .power_off = usb_power_off,
- .power_suspend = usb_power_off,
-};
-
-static struct resource oh
[PATCH v4 2/9] ehci-platform: add pre_setup() method to platform data
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this purpose...
While at it, add the missing incomplete declaration of 'struct platform_device'
to ...
The patch has been tested on the Marzen and BOCK-W boards.
Suggested-by: Alan Stern
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
Acked-by: Alan Stern
---
Changes since version 3:
- added ACK from Alan Stern.
Changes since version 2:
- replaced #include with incomplete declarations of 'struct platform_device' and
'struct usb_hcd';
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed init() method to pre_setup() with different parameters and call site.
drivers/usb/host/ehci-platform.c |6 ++
include/linux/usb/ehci_pdriver.h |4
2 files changed, 10 insertions(+)
Index: renesas/drivers/usb/host/ehci-platform.c
===
--- renesas.orig/drivers/usb/host/ehci-platform.c
+++ renesas/drivers/usb/host/ehci-platform.c
@@ -46,6 +46,12 @@ static int ehci_platform_reset(struct us
ehci->big_endian_desc = pdata->big_endian_desc;
ehci->big_endian_mmio = pdata->big_endian_mmio;
+ if (pdata->pre_setup) {
+ retval = pdata->pre_setup(hcd);
+ if (retval < 0)
+ return retval;
+ }
+
ehci->caps = hcd->regs + pdata->caps_offset;
retval = ehci_setup(hcd);
if (retval)
Index: renesas/include/linux/usb/ehci_pdriver.h
===
--- renesas.orig/include/linux/usb/ehci_pdriver.h
+++ renesas/include/linux/usb/ehci_pdriver.h
@@ -19,6 +19,9 @@
#ifndef __USB_CORE_EHCI_PDRIVER_H
#define __USB_CORE_EHCI_PDRIVER_H
+struct platform_device;
+struct usb_hcd;
+
/**
* struct usb_ehci_pdata - platform_data for generic ehci driver
*
@@ -50,6 +53,7 @@ struct usb_ehci_pdata {
/* Turn on only VBUS suspend power and hotplug detection,
* turn off everything else */
void (*power_suspend)(struct platform_device *pdev);
+ int (*pre_setup)(struct usb_hcd *hcd);
};
#endif /* __USB_CORE_EHCI_PDRIVER_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- lowercased the SoC name in the subject.
Changes since version 2:
- added #include ;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
patch.
arch/arm/mach-shmobile/setup-r8a7779.c | 16
1 file changed, 16 insertions(+)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -446,10 +447,25 @@ static void usb_power_off(struct platfor
pm_runtime_disable(&pdev->dev);
}
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+ /*
+* Below are recommended values from the datasheet;
+* see [USB :: Setting of EHCI Internal Buffer].
+*/
+ /* EHCI IP internal buffer setting */
+ iowrite32(0x00ff0040, hcd->regs + 0x0094);
+ /* EHCI IP internal buffer enable */
+ iowrite32(0x0001, hcd->regs + 0x009C);
+
+ return 0;
+}
+
static struct usb_ehci_pdata ehcix_pdata = {
.power_on = usb_power_on,
.power_off = usb_power_off,
.power_suspend = usb_power_off,
+ .pre_setup = ehci_init_internal_buffer,
};
static struct resource ehci0_resources[] = {
--
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 v4 4/9] rcar-phy: remove EHCI internal buffer setup
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.
drivers/usb/phy/rcar-phy.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
#define USBEH0 0x080C
#define USBOH0 0x081C
#define USBCTL00x0858
-#define EIIBC1 0x0094
-#define EIIBC2 0x009C
/* USBPCTRL1 */
#define PHY_RST(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
- void __iomem *reg1;
int counter;
};
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy->dev;
void __iomem *reg0 = priv->reg0;
- void __iomem *reg1 = priv->reg1;
int i;
u32 val;
unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
iowrite32(0x, (reg0 + USBPCTRL0));
/*
-* EHCI IP internal buffer setting
-* EHCI IP internal buffer enable
-*
-* These are recommended value of a datasheet
-* see [USB :: EHCI internal buffer setting]
-*/
- iowrite32(0x00ff0040, (reg0 + EIIBC1));
- iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
- iowrite32(0x0001, (reg0 + EIIBC2));
- iowrite32(0x0001, (reg1 + EIIBC2));
-
- /*
* Bus alignment settings
*/
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
static int rcar_usb_phy_probe(struct platform_device *pdev)
{
struct rcar_usb_phy_priv *priv;
- struct resource *res0, *res1;
+ struct resource *res0;
struct device *dev = &pdev->dev;
- void __iomem *reg0, *reg1;
+ void __iomem *reg0;
int ret;
res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res0 || !res1) {
+ if (!res0) {
dev_err(dev, "Not enough platform resources\n");
return -EINVAL;
}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
* this driver can't use devm_request_and_ioremap(dev, res) here
*/
reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
- reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
- if (!reg0 || !reg1) {
+ if (!reg0) {
dev_err(dev, "ioremap error\n");
return -ENOMEM;
}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
}
priv->reg0 = reg0;
- priv->reg1 = reg1;
priv->counter = 0;
priv->phy.dev = dev;
priv->phy.label = dev_name(dev);
--
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 v4 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- lowercased the SoC name in the subject.
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- new patch in this version, split from the previous one.
arch/arm/mach-shmobile/setup-r8a7779.c |5 -
1 file changed, 5 deletions(-)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -406,11 +406,6 @@ static struct resource usb_phy_resources
.end= 0xffe70900 - 1,
.flags = IORESOURCE_MEM,
},
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
};
static struct platform_device usb_phy_device = {
--
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 v4 6/9] rcar-phy: correct base address
The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...
Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/setup-r8a7779.c |2 +-
drivers/usb/phy/rcar-phy.c | 28 ++--
2 files changed, 11 insertions(+), 19 deletions(-)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -402,7 +402,7 @@ static struct platform_device sata_devic
/* USB PHY */
static struct resource usb_phy_resources[] = {
[0] = {
- .start = 0xffe7,
+ .start = 0xffe70800,
.end= 0xffe70900 - 1,
.flags = IORESOURCE_MEM,
},
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
#include
#include
-/* USBH common register */
-#define USBPCTRL0 0x0800
-#define USBPCTRL1 0x0804
-#define USBST 0x0808
-#define USBEH0 0x080C
-#define USBOH0 0x081C
-#define USBCTL00x0858
+/* REGS block */
+#define USBPCTRL0 0x00
+#define USBPCTRL1 0x04
+#define USBST 0x08
+#define USBEH0 0x0C
+#define USBOH0 0x1C
+#define USBCTL00x58
/* USBPCTRL1 */
#define PHY_RST(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
return -EINVAL;
}
- /*
-* CAUTION
-*
-* Because this phy address is also mapped under OHCI/EHCI address area,
-* this driver can't use devm_request_and_ioremap(dev, res) here
-*/
- reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
- if (!reg0) {
- dev_err(dev, "ioremap error\n");
- return -ENOMEM;
- }
+ reg0 = devm_ioremap_resource(dev, res0);
+ if (IS_ERR(reg0))
+ return PTR_ERR(reg0);
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
--
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 v4 7/9] rcar-phy: add platform data
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add file with
the 'struct rcar_phy_platform_data' containing various bit fields describing
USB pin configuration.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- moved USBPCTRL0 register bit #define's to patch #9;
- replaced USBPCTRL0 register value in the platform data structure by a set of
bit fields describing the configuration of the board, rewrote changelog;
Changes since version 2:
- added #include ;
- added ACKs from Simon Horman and Kuninori Morimoto.
include/linux/usb/rcar-phy.h | 26 ++
1 file changed, 26 insertions(+)
Index: renesas/include/linux/usb/rcar-phy.h
===
--- /dev/null
+++ renesas/include/linux/usb/rcar-phy.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __RCAR_PHY_H
+#define __RCAR_PHY_H
+
+#include
+
+struct rcar_phy_platform_data {
+ bool port1_func:1; /* true: port 1 used by function, false: host */
+ unsigned penc1:1; /* Output of the PENC1 pin in function mode */
+ struct {/* Overcurrent pin control for ports 0..2 */
+ bool select_3_3v:1; /* true: USB_OVCn pin, false: OVCn pin */
+ /* Set to false on port 1 in function mode */
+ bool active_high:1; /* true: active high, false: active low */
+ /* Set to true on port 1 in function mode */
+ } ovc_pin[3];
+};
+
+#endif /* __RCAR_PHY_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.
For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.
Note that the board and the SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c |3 +++
arch/arm/mach-shmobile/include/mach/r8a7779.h |2 ++
arch/arm/mach-shmobile/setup-r8a7779.c| 16
3 files changed, 13 insertions(+), 8 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply
REGULATOR_SUPPLY("vdd33a", "smsc911x"),
};
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
/* SMSC LAN89218 */
static struct resource smsc911x_resources[] = {
[0] = {
@@ -231,6 +233,7 @@ static void __init marzen_init(void)
r8a7779_pinmux_init();
r8a7779_add_standard_devices();
+ r8a7779_add_usb_phy_device(&usb_phy_platform_data);
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
}
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
struct platform_device;
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
extern void r8a7779_add_standard_devices(void);
extern void r8a7779_add_standard_devices_dt(void);
extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
extern void r8a7779_init_late(void);
extern void r8a7779_clock_init(void);
extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -408,13 +408,6 @@ static struct resource usb_phy_resources
},
};
-static struct platform_device usb_phy_device = {
- .name = "rcar_usb_phy",
- .id = -1,
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* USB */
static struct usb_phy *phy;
@@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
&scif5_device,
&tmu00_device,
&tmu01_device,
- &usb_phy_device,
};
static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
pdata, sizeof(*pdata));
}
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+ platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
/* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
void __init __weak r8a7779_register_twd(void) { }
--
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 v4 9/9] rcar-phy: handle platform data
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- moved USBPCTRL0 register bit #define's from patch #7, removing the prefixes;
- implemented parsing of the platform data to set USBPCTRL0 register.
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
drivers/usb/phy/rcar-phy.c | 53 +++--
1 file changed, 46 insertions(+), 7 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -1,8 +1,9 @@
/*
* Renesas R-Car USB phy driver
*
- * Copyright (C) 2012 Renesas Solutions Corp.
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
* Kuninori Morimoto
+ * Copyright (C) 2013 Cogent Embedded, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -11,10 +12,11 @@
#include
#include
-#include
#include
#include
#include
+#include
+#include
/* REGS block */
#define USBPCTRL0 0x00
@@ -24,6 +26,25 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* USBPCTRL0 */
+#define OVC2 (1 << 10) /* Switches the OVC input pin for port 2: */
+ /* 1: USB_OVC2, 0: OVC2 */
+#define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
+ /* 1: USB_OVC1, 0: OVC1/VBUS1 */
+ /* Function mode: set to 0 */
+#define OVC0 (1 << 8) /* Switches the OVC input pin for port 0: */
+ /* 1: USB_OVC0 pin, 0: OVC0 */
+#define OVC2_ACT (1 << 6) /* Host mode: OVC2 polarity: */
+ /* 1: active-high, 0: active-low*/
+#define PENC (1 << 4) /* Function mode: output level of PENC1 pin: */
+ /* 1: high, 0: low */
+#define OVC0_ACT (1 << 3) /* Host mode: OVC0 polarity: */
+ /* 1: active-high, 0: active-low*/
+#define OVC1_ACT (1 << 1) /* Host mode: OVC1 polarity: */
+ /* 1: active-high, 0: active-low*/
+ /* Function mode: be sure to set to 1 */
+#define PORT1 (1 << 0) /* Selects port 1 mode:*/
+ /* 1: function, 0: host */
/* USBPCTRL1 */
#define PHY_RST(1 << 2)
#define PLL_ENB(1 << 1)
@@ -55,7 +76,9 @@ static int rcar_usb_phy_init(struct usb_
{
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy->dev;
+ struct rcar_phy_platform_data *pdata = dev->platform_data;
void __iomem *reg0 = priv->reg0;
+ const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
unsigned long flags;
@@ -89,8 +112,21 @@ static int rcar_usb_phy_init(struct usb_
/* (4) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
- /* set platform specific port settings */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ /* Board specific port settings */
+ val = 0;
+ if (pdata->port1_func)
+ val |= PORT1;
+ if (pdata->penc1)
+ val |= PENC;
+ for (i = 0; i < 3; i++) {
+ /* OVCn bits follow each other in the right order */
+ if (pdata->ovc_pin[i].select_3_3v)
+ val |= OVC0 << i;
+ /* OVCn_ACT bits are spaced by irregular intervals */
+ if (pdata->ovc_pin[i].active_high)
+ val |= ovcn_act[i];
+ }
+ iowrite32(val, (reg0 + USBPCTRL0));
/*
* Bus alignment settings
@@ -117,10 +153,8 @@ static void rcar_usb_phy_shutdown(struct
spin_lock_irqsave(&priv->lock, flags);
- if (priv->counter-- == 1) { /* last user */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ if (priv->counter-- == 1) /* last user */
iowrite32(0x, (reg0 + USBPCTRL1));
- }
spin_unlock_irqrest
[PATCH v2 0/4] Add USB support to R8A7778/BOCK-W
Hello. Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130412' tag and the R8A7779/Marzen patchset I've just posted. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/4] rcar-phy: add R8A7778 support [2/4] ARM: shmobile: r8a7778: add USB support [3/4] ARM: shmobile: BOCK-W: add USB support [4/4] ARM: shmobile: BOCK-W: enable USB in defconfig WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] rcar-phy: add R8A7778 support
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.
Also mark in the driver's Kconfig section that R8A7778 is now supported and
generally clarify that section, uppercasing the word "phy", while at it...
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov
---
Changes since the original posting:
- made the necessary changes atop of the R8A7779/Marzen pathset version 4.
drivers/usb/phy/Kconfig |8
drivers/usb/phy/rcar-phy.c | 37 +++--
include/linux/usb/rcar-phy.h |1 +
3 files changed, 36 insertions(+), 10 deletions(-)
Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
SoC.
config USB_RCAR_PHY
- tristate "Renesas R-Car USB phy support"
+ tristate "Renesas R-Car USB PHY support"
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
To compile this driver as a module, choose M here: the
module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,15 +26,21 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
/* USBPCTRL0 */
-#define OVC2 (1 << 10) /* Switches the OVC input pin for port 2: */
+#define OVC2 (1 << 10) /* (R8A7779 only) */
+ /* Switches the OVC input pin for port 2: */
/* 1: USB_OVC2, 0: OVC2 */
#define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
/* 1: USB_OVC1, 0: OVC1/VBUS1 */
/* Function mode: set to 0 */
#define OVC0 (1 << 8) /* Switches the OVC input pin for port 0: */
/* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT (1 << 6) /* Host mode: OVC2 polarity: */
+#define OVC2_ACT (1 << 6) /* (R8A7779 only) */
+ /* Host mode: OVC2 polarity:*/
/* 1: active-high, 0: active-low*/
#define PENC (1 << 4) /* Function mode: output level of PENC1 pin: */
/* 1: high, 0: low */
@@ -59,6 +65,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
+ void __iomem *reg1;
int counter;
};
@@ -78,6 +85,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy->dev;
struct rcar_phy_platform_data *pdata = dev->platform_data;
void __iomem *reg0 = priv->reg0;
+ void __iomem *reg1 = priv->reg1;
const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
@@ -96,7 +104,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
- /* (3) USB module status check */
+ /* (3) set USB-PHY in accord with the conditions of usage */
+ if (reg1) {
+ u32 hsqctl1 = pdata->ferrite_bead ? 0x41 : 0;
+ u32 hsqctl2 = pdata->ferrite_bead ? 0x0d : 7;
+
+ iowrite32(hsqctl1, reg1 + HSQCTL1);
+ iowrite32(hsqctl2, reg1 + HSQCTL2);
+ }
+
+ /* (4) USB module status check */
for (i = 0; i < 1024; i++) {
udelay(10);
val = ioread32(reg0 + USBST);
@@ -109,7 +126,7 @@ static int rcar_usb_phy_init(struct usb_
[PATCH v2 2/4] ARM: shmobile: r8a7778: add USB support
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov
---
Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.
arch/arm/mach-shmobile/Kconfig|2
arch/arm/mach-shmobile/clock-r8a7778.c|4
arch/arm/mach-shmobile/include/mach/r8a7778.h |3
arch/arm/mach-shmobile/setup-r8a7778.c| 108 ++
4 files changed, 117 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+ select USB_ARCH_HAS_EHCI
+ select USB_ARCH_HAS_OHCI
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -104,12 +104,14 @@ static struct clk *main_clks[] = {
enum {
MSTP114,
+ MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
static struct clk mstp_clks[MSTP_NR] = {
[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+ [MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -123,6 +125,8 @@ static struct clk mstp_clks[MSTP_NR] = {
static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
+ CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI
port0/1 */
CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
#define __ASM_R8A7778_H__
#include
+#include
extern void r8a7778_add_standard_devices(void);
extern void r8a7778_add_standard_devices_dt(void);
extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
extern void r8a7778_init_delay(void);
extern void r8a7778_init_irq(void);
extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
&sh_tmu##idx##_platform_data, \
sizeof(sh_tmu##idx##_platform_data))
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+ DEFINE_RES_MEM(0xffe70800, 0x100),
+ DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+ platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+ if (!phy)
+ return -EIO;
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
+ usb_phy_init(phy);
+
+ return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+ if (!phy)
+ return;
+
+ usb_phy_shutdown(phy);
+
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_
[PATCH v2 3/4] ARM: shmobile: BOCK-W: add USB support
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov
---
Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
modified the comment to the 'ferrite_bead' field initializer.
arch/arm/mach-shmobile/board-bockw.c |6 ++
1 file changed, 6 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -53,6 +53,10 @@ static struct resource smsc911x_resource
DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
};
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+ .ferrite_bead = true, /* not sure about this... */
+};
+
#define IRQ0MR 0x30
static void __init bockw_init(void)
{
@@ -61,6 +65,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+ r8a7778_add_usb_phy_device(&usb_phy_platform_data);
fpga = ioremap_nocache(0x1820, SZ_1M);
if (fpga) {
@@ -97,4 +102,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
.init_machine = bockw_init,
.init_time = shmobile_timer_init,
.dt_compat = bockw_boards_compat_dt,
+ .init_late = r8a7778_init_late,
MACHINE_END
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. Enable USB storage driver and SCSI disk driver that it needs as well... Signed-off-by: Sergei Shtylyov --- arch/arm/configs/bockw_defconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) Index: renesas/arch/arm/configs/bockw_defconfig === --- renesas.orig/arch/arm/configs/bockw_defconfig +++ renesas/arch/arm/configs/bockw_defconfig @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # CONFIG_NET_CADENCE is not set # CONFIG_NET_VENDOR_BROADCOM is not set @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 CONFIG_SERIAL_SH_SCI_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_STORAGE=y +CONFIG_USB_RCAR_PHY=y CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=y # CONFIG_IOMMU_SUPPORT is not set -- 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] xhci: fix list access before ini
Ping! :)
On Tue, Apr 09, 2013 at 10:33:31PM +0400, Vladimir Murzin wrote:
> If for whatever reason we fall into fail path in xhci_mem_init()
> before bw table gets initialized we may access the uninitialized lists
> in xhci_mem_cleanup().
>
> Check for bw table before traversing lists in cleanup routine.
>
> Reported-by: Sergey Dyasly
> Tested-by: Sergey Dyasly
> Signed-off-by: Vladimir Murzin
> ---
>
> This patch is generated across
> http://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-linus-queue
>
> Changes since:
> v1 - init for cancel_cmd_list and lpm_failed lists
> is skipped because Sergio has already been working on
> it http://marc.info/?l=linux-usb&m=136509667003716&w=2
> - bw table is checked for existence in xhci_mem_cleanup()
>routine instead of moving bw init code at beginning of
>xhci_mem_init() routine (as it was proposed by Sharah}
>
> drivers/usb/host/xhci-mem.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index ffbdefc..ea44dc9 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1826,6 +1826,9 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
> }
> spin_unlock_irqrestore(&xhci->lock, flags);
>
> + if (!xhci->rh_bw)
> + goto no_bw;
> +
> num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
> for (i = 0; i < num_ports; i++) {
> struct xhci_interval_bw_table *bwt = &xhci->rh_bw[i].bw_table;
> @@ -1844,6 +1847,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
> }
> }
>
> +no_bw:
> xhci->num_usb2_ports = 0;
> xhci->num_usb3_ports = 0;
> xhci->num_active_eps = 0;
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
