[PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
On some HP platform, when usb driver inits the iLo Virtual USB Controller,
there may be a warning Controller not stopped yet!. It is because driver does
not wait enough time.
This patch adds more time waiting and retries.
Signed-off-by: Li, Zhen-Hua zhen-h...@hp.com
---
drivers/usb/host/uhci-hcd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..514e9d7 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -277,6 +277,9 @@ static int global_suspend_mode_is_broken(struct uhci_hcd
*uhci)
uhci-global_suspend_mode_is_broken(uhci) : 0;
}
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
+
static void suspend_rh(struct uhci_hcd *uhci, enum uhci_rh_state new_state)
__releases(uhci-lock)
__acquires(uhci-lock)
@@ -284,6 +287,7 @@ __acquires(uhci-lock)
int auto_stop;
int int_enable, egsm_enable, wakeup_enable;
struct usb_device *rhdev = uhci_to_hcd(uhci)-self.root_hub;
+ u16 try, stopped;
auto_stop = (new_state == UHCI_RH_AUTO_STOPPED);
dev_dbg(rhdev-dev, %s%s\n, __func__,
@@ -355,7 +359,17 @@ __acquires(uhci-lock)
if (uhci-dead)
return;
}
- if (!(uhci_readw(uhci, USBSTS) USBSTS_HCH))
+
+ for (try = 0; try UHCI_SUSPENDRH_RETRY_MAX; try++) {
+ /*
+* Sometimes we may need to wait more time and try again.
+*/
+ stopped = uhci_readw(uhci, USBSTS) USBSTS_HCH;
+ if (stopped)
+ break;
+ udelay(UHCI_SUSPENDRH_RETRY_DELAY);
+ }
+ if (!stopped)
dev_warn(uhci_dev(uhci), Controller not stopped yet!\n);
uhci_get_current_frame_number(uhci);
--
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
Re: Linux USB file storage gadget with new UDC
Hi,
Here is a full log from the beginning which shows another problem.
When the SCSI_READ_10 command below is received, there is a disconnect
or port reset which causes the (-32) broken pipe problem.
You really need to fix the old problems before worrying about new
problems. The set_halt still isn't working, and the UDC continues to
continues to call bulk_out_complete multiple times without receiving
any packets.
I change that in UDC driver queue function, adding in a length check:
if (len 0)
{
ka_req-req.complete(ka_ep-ep, ka_req-req);
list_del_init(ka_req-queue);
}
However, i still observe the SCSI command being received by UDC and
gadget driver, but not processed by gadget driver.
For the UDC and gadget driver log, it looks like the flow cannot get
past get_next_command() of fsg_main_thread(). The log is attached.
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
The same SCSI command as seen on usbmon log:
f2f4fe40 3842078083 S Bo:2:050:1 -115 31 = 55534243 0900
0600 00
f2f4fe40 3842078159 C Bo:2:050:1 0 31
f2f4fe40 3842078182 S Bi:2:050:1 -115 13
f2f4fe40 3872633965 C Bi:2:050:1 -104 0
It would be easier to maintain a stable link if the UDC connected at
high speed in the first place. The usbmon log shows that the
connection was at full speed (12 Mb/s), not high speed (480 Mb/s) --
which means that this line:
g_file_storage gadget: high-speed config #1
in the gadget log indicates another bug in the UDC driver. It told the
gadget driver that the connection was high speed, but the connection
really was full speed.
How to read from usbmon log that the connection was at full speed?
Thanks,
victor
# dmesg
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
usb: ralink: Is it right that usb_hcd_link_urb_to_ep() returns -EPERM?
Recently, I test my usb host driver(not ehci or any widely used usb host) with a Ralink's wifi device(use a linux-3.0.39 kernel). But, if transferring data through FTP for a long time, I found that usb_hcd_link_urb_to_ep() (It is called by hcd's urb_enqueue function) returns -EPERM sometimes. After digging Ralink's wifi driver, I found, it seems that my host driver some time try to link a killing urb to ep. (The calling path of usb_kill_urb() is: rt2x00usb_watchdog()-rt2x00usb_dma_timeout()-rt2x00queue_dma_timeout()-rt2x00usb_watchdog_tx_dma()-rt2x00queue_flush_queue()-rt2x00usb_flush_queue()-rt2x00queue_for_each_entry()-rt2x00usb_flush_entry()-usb_kill_urb() ) What I hope to know is: it a right result? or it seems there is a bug in my driver?or because my driver's speed is not high enough(It seems that it happends more frequently in a low speed)? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. Why do you think it is necessary to have a minimum latency of 2 ms? Again, the old algorithm worked fine. While such short queues are not used by default, they are necessary to get low latencies for real-time audio applications. Keeping this change would keep this regression for quite a few people. In any case, it would be best What criteria are you using to evaluate the benefit of this? Do you want to reduce the chance of queue underruns? Interrupts? Power usage? if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Why is having a queue of two URB with one packet each suddenly not allowed? Regards, Clemens -- 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 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Thu, Apr 18, 2013 at 05:20:11PM +0530, Kishon Vijay Abraham I wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
wrong indentation, also, I'm not sure we should allow calls with NULL
pointers. Perhaps a WARN() so we get API offenders early enough ?
True, bad coding style :-(
We should be handling dev_err with a NULL pointer.
Will just keep here:
if (WARN_ON(!x-dev))
return ;
right, but I guess:
if (WARN(!x || !x-dev, Invalid parameters\n))
return -EINVAL;
would be better ??
btw, shouldn't it be IS_ERR(x)?
not in this case, since we're trying to catch users passing NULL to as
the phy argument.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget/uvc: Implement videobuf2 .wait_prepare and .wait_finish operations
Hi, On Mon, Apr 15, 2013 at 02:45:39PM +0200, Laurent Pinchart wrote: Those optional operations are used to release and reacquire the queue lock when videobuf2 needs to perform operations that sleep for a long time, such as waiting for a buffer to be complete. Implement them to avoid blocking qbuf or streamoff calls when a dqbuf is in progress. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've taken the patch in my tree and will wait for v4 of [1] before pushing it upstream. i think that patch can be applied now! :) Oops, my bad. I had applied the patch in a wrong branch and forgot about it :-/ Sorry about that. Felipe, can you pick this one up, or would you like a pull request ? too late for v3.10 for me, sorry -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5 v4] USB: regroup all depends on USB within an if USB block
On Tue, Apr 09, 2013 at 02:29:25PM +0200, Florian Fainelli wrote: This patch removes the depends on USB from all config symbols in drivers/usb/host/Kconfig and replace that with an if USB / endif block as suggested by Alan Stern. Some source ... Kconfig lines have been shuffled around to permit a better regroupment of the Kconfig files depending on config USB item. No functionnal change is introduced. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Florian Fainelli flor...@openwrt.org for drivers/usb/musb/: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget/uvc: Implement videobuf2 .wait_prepare and .wait_finish operations
On Tuesday 23 April 2013 14:16:56 Felipe Balbi wrote: On Mon, Apr 15, 2013 at 02:45:39PM +0200, Laurent Pinchart wrote: Those optional operations are used to release and reacquire the queue lock when videobuf2 needs to perform operations that sleep for a long time, such as waiting for a buffer to be complete. Implement them to avoid blocking qbuf or streamoff calls when a dqbuf is in progress. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've taken the patch in my tree and will wait for v4 of [1] before pushing it upstream. i think that patch can be applied now! :) Oops, my bad. I had applied the patch in a wrong branch and forgot about it :-/ Sorry about that. Felipe, can you pick this one up, or would you like a pull request ? too late for v3.10 for me, sorry Can you pick it up for v3.11 ? -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
[GIT PULL] USB patches for v3.10 (urgent fixes)
Hi Greg, Here are a few urgent fixes for my latest pull request. Good to know people have been testing. With these we will have a rather good -rc1 and anything else can be fixed during the -rc cycle. Let me know if you would prefer to wait until -rc1 to apply these commits. cheers The following changes since commit 9b192de60b5a584ee4ed967fb6758773c75e4643: usb: gadget: nokia: include f_ecm.c (2013-04-03 21:02:47 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.10-part2 for you to fetch changes up to added5fce61e97087a4a25270694c542c5ed1ba9: ARM: mxs_defconfig: add CONFIG_USB_PHY (2013-04-23 14:18:54 +0300) usb: urgent fixes for v3.10 merge window Here are some late urgent fixes for v3.10 merge window. All of these errors were introduced by recent commits which are in linux-next. f_obex, multi and cdc2 gadget drivers have learned to return a proper error code when something goes wrong. usb_bind_phy() was mistakenly placed into .init.text section which caused Section mismatch warnings and undefined reference compile errors. f_source_sink had a copy-paste error which is now corrected. g_zero got a memory leak plugged. Two defconfigs got fixed to enable the newly introduced CONFIG_USB_PHY. Andrzej Pietrasiewicz (2): usb: gadget: f_sourcesink.c: correct a copy-paste misnomer usb: gadget: zero: put function instances on unbind Denis Efremov (1): usb: phy: remove exported function from __init section Shawn Guo (2): ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY ARM: mxs_defconfig: add CONFIG_USB_PHY Wei Yongjun (3): usb: gadget: f_obex: fix error return code in obex_bind() usb: gadget: multi: fix error return code in rndis_do_config() usb: gadget: cdc2: fix error return code in cdc_do_config() arch/arm/configs/imx_v6_v7_defconfig | 1 + arch/arm/configs/mxs_defconfig | 1 + drivers/usb/gadget/cdc2.c| 4 +++- drivers/usb/gadget/f_obex.c | 1 + drivers/usb/gadget/f_sourcesink.c| 4 ++-- drivers/usb/gadget/multi.c | 4 +++- drivers/usb/gadget/zero.c| 2 ++ drivers/usb/phy/phy.c| 2 +- 8 files changed, 14 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] usb/gadget: f_ncm: use usb_gstrings_attach
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_ncm.c | 26 ++
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index 229be2b..bdb431e 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1158,6 +1158,7 @@ static int ncm_bind(struct usb_configuration *c, struct
usb_function *f)
{
struct usb_composite_dev *cdev = c-cdev;
struct f_ncm*ncm = func_to_ncm(f);
+ struct usb_string *us;
int status;
struct usb_ep *ep;
struct f_ncm_opts *ncm_opts;
@@ -1170,20 +1171,15 @@ static int ncm_bind(struct usb_configuration *c, struct
usb_function *f)
status = gether_register_netdev(ncm_opts-net);
if (status)
return status;
- if (ncm_string_defs[0].id == 0) {
- status = usb_string_ids_tab(c-cdev, ncm_string_defs);
- if (status 0)
- return status;
- ncm_control_intf.iInterface =
- ncm_string_defs[STRING_CTRL_IDX].id;
-
- status = ncm_string_defs[STRING_DATA_IDX].id;
- ncm_data_nop_intf.iInterface = status;
- ncm_data_intf.iInterface = status;
-
- ecm_desc.iMACAddress = ncm_string_defs[STRING_MAC_IDX].id;
- ncm_iad_desc.iFunction = ncm_string_defs[STRING_IAD_IDX].id;
- }
+ us = usb_gstrings_attach(cdev, ncm_strings,
+ARRAY_SIZE(ncm_string_defs));
+ if (IS_ERR(us))
+ return PTR_ERR(us);
+ ncm_control_intf.iInterface = us[STRING_CTRL_IDX].id;
+ ncm_data_nop_intf.iInterface = us[STRING_DATA_IDX].id;
+ ncm_data_intf.iInterface = us[STRING_DATA_IDX].id;
+ ecm_desc.iMACAddress = us[STRING_MAC_IDX].id;
+ ncm_iad_desc.iFunction = us[STRING_IAD_IDX].id;
/* allocate instance-specific interface IDs */
status = usb_interface_id(c, f);
@@ -1322,7 +1318,6 @@ static void ncm_unbind(struct usb_configuration *c,
struct usb_function *f)
DBG(c-cdev, ncm unbind\n);
- ncm_string_defs[0].id = 0;
usb_free_all_descriptors(f);
kfree(ncm-notify_req-buf);
@@ -1357,7 +1352,6 @@ struct usb_function *ncm_alloc(struct
usb_function_instance *fi)
ncm-port.is_fixed = true;
ncm-port.func.name = cdc_network;
- ncm-port.func.strings = ncm_strings;
/* descriptors are per-instance copies */
ncm-port.func.bind = ncm_bind;
ncm-port.func.unbind = ncm_unbind;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] Equivalent of g_ncm.ko with configfs
Here I present the conversion of everthing that is required to provide the equivalent of g_ncm.ko with configfs. This is the second version of the series after discussion with Alan and Michal's review - thank you guys. A branch will be available here (from 24th April 2013): git://git.infradead.org/users/kmpark/linux-samsung usb-gadget-configfs v1..v2: - delayed registering a network interface until gadgets's bind (per Alan's request) - created a helper macro to define USB Ethernet modules' parameters (Michal's review) - fixed and simplified some helper functions (Michal's review) - changed hostaddr variable name to host_mac in several modules (Michal's review) BACKWARD COMPATIBILITY == Please note that the old g_ncm.ko is still available and works. USING THE NEW GADGET == Please refer to this post: http://www.spinics.net/lists/linux-usb/msg76388.html for general information from Sebastian on how to use configfs-based gadgets (*). Here is the description specific to using g_ncm.ko equivalent. The old g_ncm.ko offered three parameters: qmult - queue length multiplier for high/super -speed devices dev_addr - device's MAC address host_addr - host's MAC address With configfs the procedure is as follows, compared to the information mentioned above (*): instead of mkdir functions/acm.ttyS1 do mkdir functions/ncm.instance name e.g. mkdir functions/ncm.usb0 In functions/ncm.instance name there will be the following attribute files: qmult dev_addr host_addr ifname and after creating the functions/ncm.instance name they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. Except for ifname they can be written to until the function is linked to a configuration. The ifname is read-only and contains the name of the interface which was assigned by the net core, e. g. usb0. The rest of the procedure (*) remains the same. After unbinding the gadget with echo UDC the symbolic links in the configuration directory can be removed, the strings/* subdirectories in the configuration directory can be removed, the strings/* subdirectories at the gadget level can be removed and the configs/* subdirectories can be removed. The functions/* subdirectories can be removed. After that the gadget directory can be removed. After that the respective modules can be unloaded. TESTING THE FUNCTIONS (actually there is just one) == ncm) On the device: ping host's IP On the host: ping device's IP Andrzej Pietrasiewicz (8): usb/gadget: u_ether: convert into module usb/gadget: rndis: convert into module usb/gadget: u_ether: construct with default values and add setters/getters usb/gadget: f_ncm: convert to new function interface with backward compatibility usb/gadget: ncm: convert to new function interface usb/gadget: f_ncm: remove compatibility layer usb/gadget: f_ncm: use usb_gstrings_attach usb/gadget: f_ncm: add configfs support drivers/usb/gadget/Kconfig | 20 +++ drivers/usb/gadget/Makefile |5 + drivers/usb/gadget/cdc2.c| 10 +- drivers/usb/gadget/ether.c | 18 ++- drivers/usb/gadget/f_ncm.c | 323 +- drivers/usb/gadget/g_ffs.c | 15 ++- drivers/usb/gadget/multi.c | 15 ++- drivers/usb/gadget/ncm.c | 58 +--- drivers/usb/gadget/nokia.c | 11 +- drivers/usb/gadget/rndis.c | 16 ++ drivers/usb/gadget/rndis.h |1 + drivers/usb/gadget/u_ether.c | 223 ++--- drivers/usb/gadget/u_ether.h | 155 +++- drivers/usb/gadget/u_ncm.h | 35 + 14 files changed, 765 insertions(+), 140 deletions(-) create mode 100644 drivers/usb/gadget/u_ncm.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 v2 2/8] usb/gadget: rndis: convert into module
In order to convert to configfs the usb functions need to be converted
to a new interface and compiled as modules. This patch creates an rndis
module which will be used by the new functions. After all users of
f_rndis are converted to the new interface, this module can be
merged with f_rndis module.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/Kconfig |6 ++
drivers/usb/gadget/Makefile |2 ++
drivers/usb/gadget/ether.c |4 +++-
drivers/usb/gadget/g_ffs.c |2 +-
drivers/usb/gadget/multi.c |2 +-
drivers/usb/gadget/rndis.c | 16
drivers/usb/gadget/rndis.h |1 +
7 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 1b5b89b..84167fa 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -509,6 +509,9 @@ config USB_U_SERIAL
config USB_U_ETHER
tristate
+config USB_U_RNDIS
+ tristate
+
config USB_F_SERIAL
tristate
@@ -606,6 +609,7 @@ config USB_ETH
depends on NET
select USB_LIBCOMPOSITE
select USB_U_ETHER
+ select USB_U_RNDIS
select CRC32
help
This driver implements Ethernet style communication, in one of
@@ -731,6 +735,7 @@ config USB_FUNCTIONFS_RNDIS
bool Include configuration with RNDIS (Ethernet)
depends on USB_FUNCTIONFS NET
select USB_U_ETHER
+ select USB_U_RNDIS
help
Include a configuration with RNDIS function (Ethernet) and the
Filesystem.
@@ -878,6 +883,7 @@ config USB_G_MULTI
select USB_LIBCOMPOSITE
select USB_U_SERIAL
select USB_U_ETHER
+ select USB_U_RNDIS
select USB_F_ACM
help
The Multifunction Composite Gadget provides Ethernet (RNDIS
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index b6c2bf7..7a0463e 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_USB_F_SERIAL)+= usb_f_serial.o
usb_f_obex-y := f_obex.o
obj-$(CONFIG_USB_F_OBEX) += usb_f_obex.o
obj-$(CONFIG_USB_U_ETHER) += u_ether.o
+u_rndis-y := rndis.o
+obj-$(CONFIG_USB_U_RNDIS) += u_rndis.o
#
# USB gadget drivers
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 75418c7..6bff24f 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -91,6 +91,8 @@ static inline bool has_rndis(void)
#endif
}
+#include linux/module.h
+
/*-*/
/*
@@ -104,7 +106,7 @@ static inline bool has_rndis(void)
#include f_subset.c
#ifdef USB_ETH_RNDIS
#include f_rndis.c
-#include rndis.c
+#include rndis.h
#endif
#include f_eem.c
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index 45f26be..fbfdb53 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -32,7 +32,7 @@
# include f_subset.c
# ifdef USB_ETH_RNDIS
#include f_rndis.c
-#include rndis.c
+#include rndis.h
# endif
# include u_ether.h
diff --git a/drivers/usb/gadget/multi.c b/drivers/usb/gadget/multi.c
index d0dd603..b8222c4 100644
--- a/drivers/usb/gadget/multi.c
+++ b/drivers/usb/gadget/multi.c
@@ -47,7 +47,7 @@ MODULE_LICENSE(GPL);
#include f_subset.c
#ifdef USB_ETH_RNDIS
# include f_rndis.c
-# include rndis.c
+# include rndis.h
#endif
#include u_ether.h
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index d9297ee..1ce6bae 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -761,6 +761,7 @@ int rndis_signal_connect(int configNr)
return rndis_indicate_status_msg(configNr,
RNDIS_STATUS_MEDIA_CONNECT);
}
+EXPORT_SYMBOL(rndis_signal_connect);
int rndis_signal_disconnect(int configNr)
{
@@ -769,6 +770,7 @@ int rndis_signal_disconnect(int configNr)
return rndis_indicate_status_msg(configNr,
RNDIS_STATUS_MEDIA_DISCONNECT);
}
+EXPORT_SYMBOL(rndis_signal_disconnect);
void rndis_uninit(int configNr)
{
@@ -783,11 +785,13 @@ void rndis_uninit(int configNr)
while ((buf = rndis_get_next_response(configNr, length)))
rndis_free_response(configNr, buf);
}
+EXPORT_SYMBOL(rndis_uninit);
void rndis_set_host_mac(int configNr, const u8 *addr)
{
rndis_per_dev_params[configNr].host_mac = addr;
}
+EXPORT_SYMBOL(rndis_set_host_mac);
/*
* Message Parser
@@ -870,6 +874,7 @@ int rndis_msg_parser(u8 configNr, u8 *buf)
return -ENOTSUPP;
}
+EXPORT_SYMBOL(rndis_msg_parser);
int rndis_register(void (*resp_avail)(void *v), void *v)
{
@@ -891,6 +896,7 @@ int rndis_register(void (*resp_avail)(void *v), void *v)
[PATCH v2 4/8] usb/gadget: f_ncm: convert to new function interface with backward compatibility
Converting ncm to the new function interface requires converting
the USB ncm's function code and its users.
This patch converts the f_ncm.c to the new function interface.
The file is now compiled into a separate usb_f_ncm.ko module.
The old function interface is provided by means of a preprocessor
conditional directives. After all users are converted, the old interface
can be removed.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |3 +
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/f_ncm.c | 183 ++
drivers/usb/gadget/ncm.c|1 +
drivers/usb/gadget/u_ncm.h | 26 ++
5 files changed, 180 insertions(+), 35 deletions(-)
create mode 100644 drivers/usb/gadget/u_ncm.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 84167fa..276b1ba 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -518,6 +518,9 @@ config USB_F_SERIAL
config USB_F_OBEX
tristate
+config USB_F_NCM
+ tristate
+
choice
tristate USB Gadget Drivers
default USB_ETH
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 7a0463e..34b117e 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_USB_F_OBEX) += usb_f_obex.o
obj-$(CONFIG_USB_U_ETHER) += u_ether.o
u_rndis-y := rndis.o
obj-$(CONFIG_USB_U_RNDIS) += u_rndis.o
+usb_f_ncm-y:= f_ncm.o
+obj-$(CONFIG_USB_F_NCM)+= usb_f_ncm.o
#
# USB gadget drivers
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index ee19bc8..839d316 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -16,6 +16,7 @@
*/
#include linux/kernel.h
+#include linux/module.h
#include linux/device.h
#include linux/etherdevice.h
#include linux/crc32.h
@@ -23,6 +24,7 @@
#include linux/usb/cdc.h
#include u_ether.h
+#include u_ncm.h
/*
* This function is a CDC Network Control Model (CDC NCM) Ethernet link.
@@ -125,7 +127,7 @@ static struct usb_cdc_ncm_ntb_parameters ntb_parameters = {
#define NCM_STATUS_INTERVAL_MS 32
#define NCM_STATUS_BYTECOUNT 16 /* 8 byte header + data */
-static struct usb_interface_assoc_descriptor ncm_iad_desc __initdata = {
+static struct usb_interface_assoc_descriptor ncm_iad_desc = {
.bLength = sizeof ncm_iad_desc,
.bDescriptorType = USB_DT_INTERFACE_ASSOCIATION,
@@ -139,7 +141,7 @@ static struct usb_interface_assoc_descriptor ncm_iad_desc
__initdata = {
/* interface descriptor: */
-static struct usb_interface_descriptor ncm_control_intf __initdata = {
+static struct usb_interface_descriptor ncm_control_intf = {
.bLength = sizeof ncm_control_intf,
.bDescriptorType = USB_DT_INTERFACE,
@@ -151,7 +153,7 @@ static struct usb_interface_descriptor ncm_control_intf
__initdata = {
/* .iInterface = DYNAMIC */
};
-static struct usb_cdc_header_desc ncm_header_desc __initdata = {
+static struct usb_cdc_header_desc ncm_header_desc = {
.bLength = sizeof ncm_header_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
.bDescriptorSubType = USB_CDC_HEADER_TYPE,
@@ -159,7 +161,7 @@ static struct usb_cdc_header_desc ncm_header_desc
__initdata = {
.bcdCDC = cpu_to_le16(0x0110),
};
-static struct usb_cdc_union_desc ncm_union_desc __initdata = {
+static struct usb_cdc_union_desc ncm_union_desc = {
.bLength = sizeof(ncm_union_desc),
.bDescriptorType = USB_DT_CS_INTERFACE,
.bDescriptorSubType = USB_CDC_UNION_TYPE,
@@ -167,7 +169,7 @@ static struct usb_cdc_union_desc ncm_union_desc __initdata
= {
/* .bSlaveInterface0 = DYNAMIC */
};
-static struct usb_cdc_ether_desc ecm_desc __initdata = {
+static struct usb_cdc_ether_desc ecm_desc = {
.bLength = sizeof ecm_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
.bDescriptorSubType = USB_CDC_ETHERNET_TYPE,
@@ -182,7 +184,7 @@ static struct usb_cdc_ether_desc ecm_desc __initdata = {
#define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
-static struct usb_cdc_ncm_desc ncm_desc __initdata = {
+static struct usb_cdc_ncm_desc ncm_desc = {
.bLength = sizeof ncm_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
.bDescriptorSubType = USB_CDC_NCM_TYPE,
@@ -194,7 +196,7 @@ static struct usb_cdc_ncm_desc ncm_desc __initdata = {
/* the default data interface has no endpoints ... */
-static struct usb_interface_descriptor ncm_data_nop_intf __initdata = {
+static struct usb_interface_descriptor ncm_data_nop_intf = {
.bLength = sizeof ncm_data_nop_intf,
.bDescriptorType =
[PATCH v2 3/8] usb/gadget: u_ether: construct with default values and add setters/getters
Add an interface to create a struct netdev_dev filled with default values,
an interface to fill the struct with useful values and an interface to
read the values set.
The patch also adds an interface to register the net device associated
with an ethernet-over-usb link.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/u_ether.c | 185 +-
drivers/usb/gadget/u_ether.h | 123
2 files changed, 307 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 5f9dacf..6d3ccdc 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -78,6 +78,7 @@ struct eth_dev {
boolzlp;
u8 host_mac[ETH_ALEN];
+ u8 dev_mac[ETH_ALEN];
};
/*-*/
@@ -716,6 +717,17 @@ static int get_ether_addr(const char *str, u8 *dev_addr)
return 1;
}
+static int get_ether_addr_str(u8 dev_addr[ETH_ALEN], char *str, int len)
+{
+ if (len 18)
+ return -EINVAL;
+
+ snprintf(str, len, %02x:%02x:%02x:%02x:%02x:%02x,
+dev_addr[0], dev_addr[1], dev_addr[2],
+dev_addr[3], dev_addr[4], dev_addr[5]);
+ return 18;
+}
+
static const struct net_device_ops eth_netdev_ops = {
.ndo_open = eth_open,
.ndo_stop = eth_stop,
@@ -796,7 +808,8 @@ struct eth_dev *gether_setup_name(struct usb_gadget *g,
INFO(dev, MAC %pM\n, net-dev_addr);
INFO(dev, HOST MAC %pM\n, dev-host_mac);
- /* two kinds of host-initiated state changes:
+ /*
+* two kinds of host-initiated state changes:
* - iff DATA transfer is active, carrier is on
* - tx queueing enabled if open *and* carrier is on
*/
@@ -807,6 +820,176 @@ struct eth_dev *gether_setup_name(struct usb_gadget *g,
}
EXPORT_SYMBOL(gether_setup_name);
+struct net_device *gether_setup_name_default(const char *netname)
+{
+ struct net_device *net;
+ struct eth_dev *dev;
+
+ net = alloc_etherdev(sizeof(*dev));
+ if (!net)
+ return ERR_PTR(-ENOMEM);
+
+ dev = netdev_priv(net);
+ spin_lock_init(dev-lock);
+ spin_lock_init(dev-req_lock);
+ INIT_WORK(dev-work, eth_work);
+ INIT_LIST_HEAD(dev-tx_reqs);
+ INIT_LIST_HEAD(dev-rx_reqs);
+
+ skb_queue_head_init(dev-rx_frames);
+
+ /* network device setup */
+ dev-net = net;
+ dev-qmult = QMULT_DEFAULT;
+ snprintf(net-name, sizeof(net-name), %s%%d, netname);
+
+ eth_random_addr(dev-dev_mac);
+ pr_warn(using random %s ethernet address\n, self);
+ eth_random_addr(dev-host_mac);
+ pr_warn(using random %s ethernet address\n, host);
+
+ net-netdev_ops = eth_netdev_ops;
+
+ SET_ETHTOOL_OPS(net, ops);
+ SET_NETDEV_DEVTYPE(net, gadget_type);
+
+ return net;
+}
+EXPORT_SYMBOL(gether_setup_name_default);
+
+int gether_register_netdev(struct net_device *net)
+{
+ struct eth_dev *dev;
+ struct usb_gadget *g;
+ struct sockaddr sa;
+ int status;
+
+ if (!net-dev.parent)
+ return -EINVAL;
+ dev = netdev_priv(net);
+ g = dev-gadget;
+ status = register_netdev(net);
+ if (status 0) {
+ dev_dbg(g-dev, register_netdev failed, %d\n, status);
+ return status;
+ } else {
+ INFO(dev, HOST MAC %pM\n, dev-host_mac);
+
+ /* two kinds of host-initiated state changes:
+* - iff DATA transfer is active, carrier is on
+* - tx queueing enabled if open *and* carrier is on
+*/
+ netif_carrier_off(net);
+ }
+ sa.sa_family = net-type;
+ memcpy(sa.sa_data, dev-dev_mac, ETH_ALEN);
+ rtnl_lock();
+ status = dev_set_mac_address(net, sa);
+ rtnl_unlock();
+ if (status)
+ pr_warn(cannot set self ethernet address: %d\n, status);
+ else
+ INFO(dev, MAC %pM\n, dev-dev_mac);
+
+ return status;
+}
+EXPORT_SYMBOL(gether_register_netdev);
+
+void gether_set_gadget(struct net_device *net, struct usb_gadget *g)
+{
+ struct eth_dev *dev;
+
+ dev = netdev_priv(net);
+ dev-gadget = g;
+ SET_NETDEV_DEV(net, g-dev);
+}
+EXPORT_SYMBOL(gether_set_gadget);
+
+int gether_set_dev_addr(struct net_device *net, const char *dev_addr)
+{
+ struct eth_dev *dev;
+ u8 new_addr[ETH_ALEN];
+
+ dev = netdev_priv(net);
+ if (get_ether_addr(dev_addr, new_addr))
+ return -EINVAL;
+ memcpy(dev-dev_mac, new_addr, ETH_ALEN);
+
[PATCH v2 5/8] usb/gadget: ncm: convert to new function interface
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/ncm.c | 57 +++-
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 276b1ba..1571f27 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -686,6 +686,7 @@ config USB_G_NCM
depends on NET
select USB_LIBCOMPOSITE
select USB_U_ETHER
+ select USB_F_NCM
select CRC32
help
This driver implements USB CDC NCM subclass standard. NCM is
diff --git a/drivers/usb/gadget/ncm.c b/drivers/usb/gadget/ncm.c
index e2f97ee..81956fe 100644
--- a/drivers/usb/gadget/ncm.c
+++ b/drivers/usb/gadget/ncm.c
@@ -24,23 +24,12 @@
#include linux/usb/composite.h
#include u_ether.h
+#include u_ncm.h
#define DRIVER_DESCNCM Gadget
/*-*/
-/*
- * Kbuild is not very cooperative with respect to linking separately
- * compiled library objects into one module. So for now we won't use
- * separate compilation ... ensuring init/exit sections work to shrink
- * the runtime footprint, and giving us at least some parts of what
- * a gcc --combine ... part1.c part2.c part3.c ... build would.
- */
-#define USB_FNCM_INCLUDED
-#include f_ncm.c
-
-/*-*/
-
/* DO NOT REUSE THESE IDs with a protocol-incompatible driver!! Ever!!
* Instead: allocate your own, using normal USB-IF procedures.
*/
@@ -113,13 +102,15 @@ static struct usb_gadget_strings *dev_strings[] = {
NULL,
};
-struct eth_dev *the_dev;
-static u8 host_mac[ETH_ALEN];
+static struct usb_function_instance *f_ncm_inst;
+static struct usb_function *f_ncm;
/*-*/
static int __init ncm_do_config(struct usb_configuration *c)
{
+ int status;
+
/* FIXME alloc iConfiguration string, set it in c-strings */
if (gadget_is_otg(c-cdev-gadget)) {
@@ -127,7 +118,19 @@ static int __init ncm_do_config(struct usb_configuration
*c)
c-bmAttributes |= USB_CONFIG_ATT_WAKEUP;
}
- return ncm_bind_config(c, host_mac, the_dev);
+ f_ncm = usb_get_function(f_ncm_inst);
+ if (IS_ERR(f_ncm)) {
+ status = PTR_ERR(f_ncm);
+ return status;
+ }
+
+ status = usb_add_function(c, f_ncm);
+ if (status 0) {
+ usb_put_function(f_ncm);
+ return status;
+ }
+
+ return 0;
}
static struct usb_configuration ncm_config_driver = {
@@ -143,13 +146,20 @@ static struct usb_configuration ncm_config_driver = {
static int __init gncm_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev-gadget;
+ struct f_ncm_opts *ncm_opts;
int status;
- /* set up network link layer */
- the_dev = gether_setup(cdev-gadget, dev_addr, host_addr, host_mac,
- qmult);
- if (IS_ERR(the_dev))
- return PTR_ERR(the_dev);
+ f_ncm_inst = usb_get_function_instance(ncm);
+ if (IS_ERR(f_ncm_inst))
+ return PTR_ERR(f_ncm_inst);
+
+ ncm_opts = container_of(f_ncm_inst, struct f_ncm_opts, func_inst);
+
+ gether_set_qmult(ncm_opts-net, qmult);
+ if (!gether_set_host_addr(ncm_opts-net, host_addr))
+ pr_info(using host ethernet address: %s, host_addr);
+ if (!gether_set_dev_addr(ncm_opts-net, dev_addr))
+ pr_info(using self ethernet address: %s, dev_addr);
/* Allocate string descriptor numbers ... note that string
* contents can be overridden by the composite_dev glue.
@@ -172,13 +182,16 @@ static int __init gncm_bind(struct usb_composite_dev
*cdev)
return 0;
fail:
- gether_cleanup(the_dev);
+ usb_put_function_instance(f_ncm_inst);
return status;
}
static int __exit gncm_unbind(struct usb_composite_dev *cdev)
{
- gether_cleanup(the_dev);
+ if (!IS_ERR_OR_NULL(f_ncm))
+ usb_put_function(f_ncm);
+ if (!IS_ERR_OR_NULL(f_ncm_inst))
+ usb_put_function_instance(f_ncm_inst);
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] usb/gadget: f_ncm: add configfs support
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_ncm.c | 166
drivers/usb/gadget/u_ncm.h |9 +++
2 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index bdb431e..795d702 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1167,8 +1167,10 @@ static int ncm_bind(struct usb_configuration *c, struct
usb_function *f)
return -EINVAL;
ncm_opts = container_of(f-fi, struct f_ncm_opts, func_inst);
+ mutex_lock(ncm_opts-lock);
gether_set_gadget(ncm_opts-net, cdev-gadget);
status = gether_register_netdev(ncm_opts-net);
+ mutex_unlock(ncm_opts-lock);
if (status)
return status;
us = usb_gstrings_attach(cdev, ncm_strings,
@@ -1280,6 +1282,159 @@ fail:
return status;
}
+static inline struct f_ncm_opts *to_f_ncm_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct f_ncm_opts,
+ func_inst.group);
+}
+
+CONFIGFS_ATTR_STRUCT(f_ncm_opts);
+CONFIGFS_ATTR_OPS(f_ncm_opts);
+
+static void ncm_attr_release(struct config_item *item)
+{
+ struct f_ncm_opts *opts = to_f_ncm_opts(item);
+
+ usb_put_function_instance(opts-func_inst);
+}
+
+static struct configfs_item_operations ncm_item_ops = {
+ .release= ncm_attr_release,
+ .show_attribute = f_ncm_opts_attr_show,
+ .store_attribute = f_ncm_opts_attr_store,
+};
+
+static ssize_t ncm_opts_dev_addr_show(struct f_ncm_opts *opts, char *page)
+{
+ int result;
+
+ mutex_lock(opts-lock);
+ result = gether_get_dev_addr(opts-net, page, PAGE_SIZE);
+ mutex_unlock(opts-lock);
+
+ return result;
+}
+
+static ssize_t ncm_opts_dev_addr_store(struct f_ncm_opts *opts,
+ const char *page, size_t len)
+{
+ int ret;
+
+ mutex_lock(opts-lock);
+ if (opts-refcnt) {
+ mutex_unlock(opts-lock);
+ return -EBUSY;
+ }
+
+ ret = gether_set_dev_addr(opts-net, page);
+ mutex_unlock(opts-lock);
+ if (!ret)
+ ret = len;
+ return ret;
+}
+
+static struct f_ncm_opts_attribute f_ncm_opts_dev_addr =
+ __CONFIGFS_ATTR(dev_addr, S_IRUGO | S_IWUSR, ncm_opts_dev_addr_show,
+ ncm_opts_dev_addr_store);
+
+static ssize_t ncm_opts_host_addr_show(struct f_ncm_opts *opts, char *page)
+{
+ int result;
+
+ mutex_lock(opts-lock);
+ result = gether_get_host_addr(opts-net, page, PAGE_SIZE);
+ mutex_unlock(opts-lock);
+
+ return result;
+}
+
+static ssize_t ncm_opts_host_addr_store(struct f_ncm_opts *opts,
+ const char *page, size_t len)
+{
+ int ret;
+
+ mutex_lock(opts-lock);
+ if (opts-refcnt) {
+ mutex_unlock(opts-lock);
+ return -EBUSY;
+ }
+
+ ret = gether_set_host_addr(opts-net, page);
+ mutex_unlock(opts-lock);
+ if (!ret)
+ ret = len;
+ return ret;
+}
+
+static struct f_ncm_opts_attribute f_ncm_opts_host_addr =
+ __CONFIGFS_ATTR(host_addr, S_IRUGO | S_IWUSR, ncm_opts_host_addr_show,
+ ncm_opts_host_addr_store);
+
+static ssize_t ncm_opts_qmult_show(struct f_ncm_opts *opts, char *page)
+{
+ unsigned qmult;
+
+ mutex_lock(opts-lock);
+ qmult = gether_get_qmult(opts-net);
+ mutex_unlock(opts-lock);
+ return sprintf(page, %d, qmult);
+}
+
+static ssize_t ncm_opts_qmult_store(struct f_ncm_opts *opts,
+ const char *page, size_t len)
+{
+ u8 val;
+ int ret;
+
+ mutex_lock(opts-lock);
+ if (opts-refcnt) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ ret = kstrtou8(page, 0, val);
+ if (ret)
+ goto out;
+
+ gether_set_qmult(opts-net, val);
+ ret = len;
+out:
+ mutex_unlock(opts-lock);
+ return ret;
+}
+
+static struct f_ncm_opts_attribute f_ncm_opts_qmult =
+ __CONFIGFS_ATTR(qmult, S_IRUGO | S_IWUSR, ncm_opts_qmult_show,
+ ncm_opts_qmult_store);
+
+static ssize_t ncm_opts_ifname_show(struct f_ncm_opts *opts, char *page)
+{
+ int ret;
+
+ mutex_lock(opts-lock);
+ ret = gether_get_ifname(opts-net, page, PAGE_SIZE);
+ mutex_unlock(opts-lock);
+
+ return ret;
+}
+
+static struct f_ncm_opts_attribute f_ncm_opts_ifname =
+ __CONFIGFS_ATTR_RO(ifname, ncm_opts_ifname_show);
+
+static struct configfs_attribute *ncm_attrs[] = {
+ f_ncm_opts_dev_addr.attr,
+ f_ncm_opts_host_addr.attr,
+ f_ncm_opts_qmult.attr,
+ f_ncm_opts_ifname.attr,
+ NULL,
+};
+
+static struct config_item_type ncm_func_type = {
+ .ct_item_ops= ncm_item_ops,
+ .ct_attrs =
[PATCH 1/2] USB:ftdi_sio: correct ST Micro Connect Lite PIDs
The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB UART
FTDI chip. It is also possible to drive STM reference targets populated with an
on-board JTAG debugger based on the FT2232H chip with the same
STMicroelectronics tools.
For this reason, the ST Micro Connect Lite PIDs should be
ST_STMCLT_2232_PID: 0x3746
ST_STMCLT_4232_PID: 0x3747
Signed-off-by: Adrian Thomasset adrian.thomas...@st.com
---
drivers/usb/serial/ftdi_sio.c | 4 +++-
drivers/usb/serial/ftdi_sio_ids.h | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 9886180..6be5853 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -870,7 +870,9 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_DOTEC_PID) },
{ USB_DEVICE(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID),
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
- { USB_DEVICE(ST_VID, ST_STMCLT1030_PID),
+ { USB_DEVICE(ST_VID, ST_STMCLT_2232_PID),
+ .driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
+ { USB_DEVICE(ST_VID, ST_STMCLT_4232_PID),
.driver_info = (kernel_ulong_t)ftdi_stmclite_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_RF_R106) },
{ USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e79861e..04cb340 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1150,7 +1150,8 @@
* STMicroelectonics
*/
#define ST_VID 0x0483
-#define ST_STMCLT1030_PID 0x3747 /* ST Micro Connect Lite STMCLT1030 */
+#define ST_STMCLT_2232_PID 0x3746
+#define ST_STMCLT_4232_PID 0x3747
/*
* Papouch products (http://www.papouch.com/)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB:ftdi_sio: enable two UART ports on ST Microconnect Lite
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
Signed-off-by: Adrian Thomasset adrian.thomas...@st.com
---
drivers/usb/serial/ftdi_sio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 6be5853..6553920 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1794,20 +1794,24 @@ static int ftdi_8u2232c_probe(struct usb_serial *serial)
}
/*
- * First and second port on STMCLiteadaptors is reserved for JTAG interface
- * and the forth port for pio
+ * First two ports on JTAG adaptors using an FT4232 such as
STMicroelectronics's
+ * ST Micro Connect Lite are reserved for JTAG or other non-UART interfaces and
+ * can be accessed from userspace.
+ * The next two ports are enabled as UARTs by default, where port 2 is
+ * a conventional RS-232 UART.
*/
static int ftdi_stmclite_probe(struct usb_serial *serial)
{
struct usb_device *udev = serial-dev;
struct usb_interface *interface = serial-interface;
- if (interface == udev-actconfig-interface[2])
- return 0;
-
+ if (interface == udev-actconfig-interface[0] ||
+ interface == udev-actconfig-interface[1]) {
dev_info(udev-dev, Ignoring serial port reserved for JTAG\n);
-
return -ENODEV;
+ }
+
+ return 0;
}
/*
--
1.8.1.2
--
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 01/11] usb: phy: Add APIs for runtime power management
Hi, On Thu, Apr 4, 2013 at 8:16 PM, Alan Stern st...@rowland.harvard.edu wrote: Apologies for delay in replying. On Thu, 4 Apr 2013, Felipe Balbi wrote: Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. sounds a bit 'fishy' to me... So a separate entity would call pm_runtime_get_sync(), even when we don't have registered dev_pm_ops, I don't know what you mean by separate entity. The PHY's subsystem would handle this. After all, the subsystem has to handle registering the PHY in the first place. If the PHY doesn't have a dev_pm_ops, why are you talking about doing runtime PM on it? That doesn't make any sense. then drivers need to check if runtime_pm is enabled and call pm_runtime_put*() conditionally before returning from probe(). One They don't have to check. If CONFIG_PM_RUNTIME isn't set or the target is runtime-PM-disabled then pm_runtime_put* is essentially a no-op (in the disabled case it decrements the usage counter but doesn't do anything else). One possible complication I did not mention: The scheme described above assumes the device that uses the PHY will always be registered on the same type of bus. If the device can be used on multiple bus types (and hence in multiple subsystems) then things aren't so simple, because some of the subsystems might support runtime PM and others might not. (You may very well run into this problem with USB controllers that are sometimes on a PCI bus and sometimes on a platform bus.) In this case, the driver needs to adapt to the subsystem's capabilities. Presumably the bus-glue part of the driver takes care of this. remove, we might have another issue: device is already runtime_suspended (due to e.g. autosuspend) when module is removed, a call to pm_runtime_put_sync() will be unbalanced. No ? No. I left out some of the details. For one thing, the subsystem is careful to do a runtime resume before calling the driver's remove method. (Also, if you look over my original description carefully, you'll see that there are no unbalanced calls -- even if the device is already runtime suspended when the driver is unbound.) For another, the subsystem needs to check before calling the driver's runtime-PM methods. There are two brief windows during which the driver isn't in charge of the device even though dev-driver is set. Those windows occur in the subsystem's probe routine (before it calls the driver's probe method) and in the subsystem's remove routine (after it calls the driver's remove method). At such times, the subsystem's runtime-PM handlers must be careful _not_ to call the driver's runtime-PM routines. May be i am misinterpreting !! If PHYs are runtime-PM enabled (PHY probe calls *runtime_enable*), then the consumers need to call pm_runtime_get_sync whever they want to access PHY. No, because in addition to being runtime-PM enabled, the PHY should automatically be runtime resumed when the consumer registers itself as a user of the PHY. Therefore the consumer doesn't need to do anything at all -- which is good for consumers that aren't runtime-PM aware. Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. Basically right. Help me to understand the overall situation a little better: What code registers the PHY initially? PHY is added to global list by PHY drivers (like phy-samsung-usb2.c/phy-omap-usb2.c) by usb_add_phy() API What routine does the DWC3 driver call to register itself as a consumer of the PHY? I think DWC3 doesn't registers itself as consumer of PHY, rather it gets that PHY from the list using devm_usb_get_phy()/devm_usb_get_phy_by_phandle() API. DWC3 can now call PHY's initialization sequence using usb_phy_init(). So, before DWC3 initializes the PHY, PHYs should be in active state. Likewise, what routine does it call to unregister itself? Once DWC3's remove() is called PHYs are put. -- Best Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
What is that bug number? Where can it be referenced? If you are going
to put it in a public place (like a kernel changelog), it needs to be
publicly accessible.
On some HP platform, when usb driver inits the iLo Virtual USB Controller,
there may be a warning Controller not stopped yet!. It is because driver
does not wait enough time.
What happened to your line endings?
This patch adds more time waiting and retries.
Why not only do this for your device?
Signed-off-by: Li, Zhen-Hua zhen-h...@hp.com
---
drivers/usb/host/uhci-hcd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..514e9d7 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -277,6 +277,9 @@ static int global_suspend_mode_is_broken(struct uhci_hcd
*uhci)
uhci-global_suspend_mode_is_broken(uhci) : 0;
}
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
+
static void suspend_rh(struct uhci_hcd *uhci, enum uhci_rh_state new_state)
__releases(uhci-lock)
__acquires(uhci-lock)
@@ -284,6 +287,7 @@ __acquires(uhci-lock)
int auto_stop;
int int_enable, egsm_enable, wakeup_enable;
struct usb_device *rhdev = uhci_to_hcd(uhci)-self.root_hub;
+ u16 try, stopped;
auto_stop = (new_state == UHCI_RH_AUTO_STOPPED);
dev_dbg(rhdev-dev, %s%s\n, __func__,
@@ -355,7 +359,17 @@ __acquires(uhci-lock)
if (uhci-dead)
return;
}
- if (!(uhci_readw(uhci, USBSTS) USBSTS_HCH))
+
+ for (try = 0; try UHCI_SUSPENDRH_RETRY_MAX; try++) {
+ /*
+ * Sometimes we may need to wait more time and try again.
+ */
Sometimes? Please be more specific. Also, a multi-line comment isn't
needed, make it one line please.
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: How to safe recover USB driver from broken hardware situation
On Tue, 23 Apr 2013, Peter Chen wrote: On Mon, Apr 22, 2013 at 11:26:05AM -0400, Alan Stern wrote: On Mon, 22 Apr 2013, Peter Chen wrote: Hi all, Recently, I have several customers troubled in safe recover USB function during the ESD situation (or some other situations, like short dp/dm, ground dp/dm, etc). I designed the ESD detect and recovery process, but I met some sync problems between host controller driver (eg, ehci) and class driver (eg, mass storage). For example, when khubd tries to disconnect usb device, it will try to stop thread usb-storage, but usb-storage is waiting some transfers to finish, qTD and QH operation may be finished (usb_submit_urb does not return error), but no watchdog timer and completion interrupt are occurred. I have: esd_detect_process and esd_recovery_process at host controller driver. At esd_detect_porcess It will disable usb interrupt and judge ASE and PSE, etc. At esd_recovery_process: It needs to reset controller (usbcmd.rst, and toggle portsc.pp bit, etc) I would like to have some synchronization mechanism between usb_submit_urb or (ehci_urb_enqueue) and my esd_detect_process and esd_recovery_process. But still not find a safe one, eg, I still met khubd's status changes D problem described above. Any suggestions are appreciated, Thanks. Your recovery process should not need to make all these changes to ehci-hcd. Simply carry out the same actions as the dead: statement label in ehci_irq() -- that is, do the same thing as if an interrupt occurred with the STS_FATAL bit set. That code is all properly synchronized. Sometimes, there are no STS_FATAL and STA_ERR when ESD occurs. So, you suggest do the same thing for STS_FATAL at my esd_recovery_process? Yes. Then unbind the driver from the controller and rebind it. Rebinding will reset the controller. You mean unbind the controller driver? Any existed API can be called? I can't do rmmod at that time. You can call device_release_driver, after locking both the controller's parent and the controller itself. See driver_unbind() in drivers/base/bus.c. Or, if you are doing this in userspace, you can write the controllers device name to /sys/bus/.../drivers/.../unbind. 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: ralink: Is it right that usb_hcd_link_urb_to_ep() returns -EPERM?
On Tue, 23 Apr 2013, linux fddl wrote: Recently, I test my usb host driver(not ehci or any widely used usb host) with a Ralink's wifi device(use a linux-3.0.39 kernel). But, if transferring data through FTP for a long time, I found that usb_hcd_link_urb_to_ep() (It is called by hcd's urb_enqueue function) returns -EPERM sometimes. After digging Ralink's wifi driver, I found, it seems that my host driver some time try to link a killing urb to ep. (The calling path of usb_kill_urb() is: rt2x00usb_watchdog()-rt2x00usb_dma_timeout()-rt2x00queue_dma_timeout()-rt2x00usb_watchdog_tx_dma()-rt2x00queue_flush_queue()-rt2x00usb_flush_queue()-rt2x00queue_for_each_entry()-rt2x00usb_flush_entry()-usb_kill_urb()� ) What I hope to know is: it a right result? or it seems there is a bug in my driver?or because my driver's speed is not high enough(It seems that it happends more frequently in a low speed)? It is correct for usb_hcd_link_urb_to_ep() to return -EPERM while the URB is being killed. I don't know if there are any bugs in your driver. 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: Linux USB file storage gadget with new UDC
On Tue, 23 Apr 2013, victor yeo wrote:
Hi,
Here is a full log from the beginning which shows another problem.
When the SCSI_READ_10 command below is received, there is a disconnect
or port reset which causes the (-32) broken pipe problem.
You really need to fix the old problems before worrying about new
problems. The set_halt still isn't working, and the UDC continues to
continues to call bulk_out_complete multiple times without receiving
any packets.
I change that in UDC driver queue function, adding in a length check:
if (len 0)
{
ka_req-req.complete(ka_ep-ep,
ka_req-req);
list_del_init(ka_req-queue);
}
What is len? Is it the packet size? If it is then this check is
wrong, because the UDC driver must accept zero-length packets.
However, i still observe the SCSI command being received by UDC and
gadget driver, but not processed by gadget driver.
You need to figure out why this code is getting called at the wrong
time. Here's one way to do it.
In your UDC driver, add a new global variable outside of any function:
static int victor_test;
In the interrupt handler, add a line that does:
victor_test = 1;
Just before the line that calls ka_req-req.complete, add:
WARN_ON(!victor_test);
victor_test = 0;
Then you'll get a stack dump every time the completion routine is
called without an interrupt occurring first. The stack dump will help
you to figure out why this is going wrong and where the problem is.
For the UDC and gadget driver log, it looks like the flow cannot get
past get_next_command() of fsg_main_thread(). The log is attached.
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
The same SCSI command as seen on usbmon log:
f2f4fe40 3842078083 S Bo:2:050:1 -115 31 = 55534243 0900
0600 00
This does not look like the same command. The last three bytes are
different: f8 7e 34 as opposed to 00 00 00.
It would be easier to maintain a stable link if the UDC connected at
high speed in the first place. The usbmon log shows that the
connection was at full speed (12 Mb/s), not high speed (480 Mb/s) --
which means that this line:
g_file_storage gadget: high-speed config #1
in the gadget log indicates another bug in the UDC driver. It told the
gadget driver that the connection was high speed, but the connection
really was full speed.
How to read from usbmon log that the connection was at full speed?
The port status data from the hub that the gadget is plugged into
contains a lot of information, including the speed of the connection.
Here's an example. This shows the port status immediately after the
first port reset in the April 22 usbmon trace:
f2f4f740 1985276053 S Ci:2:002:0 s a3 00 0004 0004 4
f2f4f740 1985276154 C Ci:2:002:0 0 4 = 03011000
The 01 in the second byte of the response indicates full speed. If
the connection were high speed, the second byte would be 05. See
Section 11.24.2.7 in the USB-2.0 specification, and especially the
description of bit 10 in Table 11-21 and 11.24.2.7.1.8.
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: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Tue, 23 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. Why do you think it is necessary to have a minimum latency of 2 ms? To avoid underruns. Perhaps this is unnecessary caution on my part. Again, the old algorithm worked fine. While such short queues are not used by default, they are necessary to get low latencies for real-time audio applications. Keeping this change would keep this regression for quite a few people. Okay, I will change the 2 to 1 since you think that is best. In any case, it would be best What criteria are you using to evaluate the benefit of this? Do you want to reduce the chance of queue underruns? Interrupts? Power usage? Chance of underruns. if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. 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 05/10] usb: musb: ux500: attempt to find channels by name before using pdata
If we can ever get to a state where we can solely search for DMA channels
by name, this will almost completely alleviate the requirement to pass
copious amounts of information though platform data. Here we take the
first step towards this. The next step will be to enable Device Tree
complete with name-event_line mapping.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/musb/ux500_dma.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 02b4a6e..6eef449 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -33,6 +33,11 @@
#include linux/platform_data/usb-musb-ux500.h
#include musb_core.h
+static const char *iep_chan_names[] = { iep_1_9, iep_2_10, iep_3_11,
iep_4_12,
+ iep_5_13, iep_6_14, iep_7_15,
iep_8 };
+static const char *oep_chan_names[] = { oep_1_9, oep_2_10, oep_3_11,
oep_4_12,
+ oep_5_13, oep_6_14, oep_7_15,
oep_8 };
+
struct ux500_dma_channel {
struct dma_channel channel;
struct ux500_dma_controller *controller;
@@ -289,6 +294,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
struct musb_hdrc_platform_data *plat = dev-platform_data;
struct ux500_musb_board_data *data;
struct dma_channel *dma_channel = NULL;
+ char **chan_names;
u32 ch_num;
u8 dir;
u8 is_tx = 0;
@@ -310,6 +316,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
/* Prepare the loop for RX channels */
channel_array = controller-rx_channel;
param_array = (data) ? data-dma_rx_param_array : NULL;
+ chan_names = (char **)iep_chan_names;
for (dir = 0; dir 2; dir++) {
for (ch_num = 0;
@@ -325,9 +332,15 @@ static int ux500_dma_controller_start(struct
dma_controller *c)
dma_channel-status = MUSB_DMA_STATUS_FREE;
dma_channel-max_len = SZ_16M;
- ux500_channel-dma_chan = dma_request_channel(mask,
- data-dma_filter,
- param_array[ch_num]);
+ ux500_channel-dma_chan =
+ dma_request_slave_channel(dev,
chan_names[ch_num]);
+
+ if (!ux500_channel-dma_chan)
+ ux500_channel-dma_chan =
+ dma_request_channel(mask,
+ data-dma_filter,
+
param_array[ch_num]);
+
if (!ux500_channel-dma_chan) {
ERR(Dma pipe allocation error dir=%d ch=%d\n,
dir, ch_num);
@@ -343,6 +356,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
/* Prepare the loop for TX channels */
channel_array = controller-tx_channel;
param_array = (data) ? data-dma_tx_param_array : NULL;
+ chan_names = (char **)oep_chan_names;
is_tx = 1;
}
--
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
[PATCH 04/10] usb: musb: ux500: harden checks for platform data
In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/musb/ux500_dma.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index c75e07a..02b4a6e 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -287,7 +287,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
struct musb *musb = controller-private_data;
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *plat = dev-platform_data;
- struct ux500_musb_board_data *data = plat-board_data;
+ struct ux500_musb_board_data *data;
struct dma_channel *dma_channel = NULL;
u32 ch_num;
u8 dir;
@@ -297,14 +297,19 @@ static int ux500_dma_controller_start(struct
dma_controller *c)
struct ux500_dma_channel *channel_array;
dma_cap_mask_t mask;
+ if (!plat) {
+ dev_err(musb-controller, No platform data\n);
+ return -EINVAL;
+ }
+ data = plat-board_data;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
/* Prepare the loop for RX channels */
channel_array = controller-rx_channel;
- param_array = data-dma_rx_param_array;
+ param_array = (data) ? data-dma_rx_param_array : NULL;
for (dir = 0; dir 2; dir++) {
for (ch_num = 0;
@@ -337,7 +342,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
/* Prepare the loop for TX channels */
channel_array = controller-tx_channel;
- param_array = data-dma_tx_param_array;
+ param_array = (data) ? data-dma_tx_param_array : NULL;
is_tx = 1;
}
--
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
[PATCH 01/10] usb: musb: ux500: move channel number knowledge into the driver
For all ux500 based platforms the maximum number of end-points are used.
Move this knowledge into the driver so we can relinquish the burden from
platform data. This also removes quite a bit of complexity from the driver
and will aid us when we come to enable the driver for Device Tree.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/mach-ux500/usb.c| 14 ++--
drivers/usb/musb/ux500_dma.c | 30 --
include/linux/platform_data/usb-musb-ux500.h |5 +
3 files changed, 16 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 821703d..8aff9a4 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -22,7 +22,7 @@
.dir = STEDMA40_MEM_TO_PERIPH, \
}
-static struct stedma40_chan_cfg musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_CHANNELS]
+static struct stedma40_chan_cfg
musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS]
= {
MUSB_DMA40_RX_CH,
MUSB_DMA40_RX_CH,
@@ -34,7 +34,7 @@ static struct stedma40_chan_cfg
musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_CHANNELS]
MUSB_DMA40_RX_CH
};
-static struct stedma40_chan_cfg musb_dma_tx_ch[UX500_MUSB_DMA_NUM_TX_CHANNELS]
+static struct stedma40_chan_cfg
musb_dma_tx_ch[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS]
= {
MUSB_DMA40_TX_CH,
MUSB_DMA40_TX_CH,
@@ -46,7 +46,7 @@ static struct stedma40_chan_cfg
musb_dma_tx_ch[UX500_MUSB_DMA_NUM_TX_CHANNELS]
MUSB_DMA40_TX_CH,
};
-static void *ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_CHANNELS] = {
+static void *ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS] = {
musb_dma_rx_ch[0],
musb_dma_rx_ch[1],
musb_dma_rx_ch[2],
@@ -57,7 +57,7 @@ static void
*ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_CHANNELS] = {
musb_dma_rx_ch[7]
};
-static void *ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_TX_CHANNELS] = {
+static void *ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS] = {
musb_dma_tx_ch[0],
musb_dma_tx_ch[1],
musb_dma_tx_ch[2],
@@ -71,8 +71,6 @@ static void
*ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_TX_CHANNELS] = {
static struct ux500_musb_board_data musb_board_data = {
.dma_rx_param_array = ux500_dma_rx_param_array,
.dma_tx_param_array = ux500_dma_tx_param_array,
- .num_rx_channels = UX500_MUSB_DMA_NUM_RX_CHANNELS,
- .num_tx_channels = UX500_MUSB_DMA_NUM_TX_CHANNELS,
.dma_filter = stedma40_filter,
};
@@ -119,7 +117,7 @@ static inline void ux500_usb_dma_update_rx_ch_config(int
*dev_type)
{
u32 idx;
- for (idx = 0; idx UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
+ for (idx = 0; idx UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; idx++)
musb_dma_rx_ch[idx].dev_type = dev_type[idx];
}
@@ -127,7 +125,7 @@ static inline void ux500_usb_dma_update_tx_ch_config(int
*dev_type)
{
u32 idx;
- for (idx = 0; idx UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
+ for (idx = 0; idx UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; idx++)
musb_dma_tx_ch[idx].dev_type = dev_type[idx];
}
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 039e567d..c75e07a 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -47,10 +47,8 @@ struct ux500_dma_channel {
struct ux500_dma_controller {
struct dma_controller controller;
- struct ux500_dma_channel rx_channel[UX500_MUSB_DMA_NUM_RX_CHANNELS];
- struct ux500_dma_channel tx_channel[UX500_MUSB_DMA_NUM_TX_CHANNELS];
- u32 num_rx_channels;
- u32 num_tx_channels;
+ struct ux500_dma_channel rx_channel[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS];
+ struct ux500_dma_channel tx_channel[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS];
void *private_data;
dma_addr_t phy_base;
};
@@ -142,19 +140,15 @@ static struct dma_channel
*ux500_dma_channel_allocate(struct dma_controller *c,
struct ux500_dma_channel *ux500_channel = NULL;
struct musb *musb = controller-private_data;
u8 ch_num = hw_ep-epnum - 1;
- u32 max_ch;
- /* Max 8 DMA channels (0 - 7). Each DMA channel can only be allocated
+ /* 8 DMA channels (0 - 7). Each DMA channel can only be allocated
* to specified hw_ep. For example DMA channel 0 can only be allocated
* to hw_ep 1 and 9.
*/
if (ch_num 7)
ch_num -= 8;
- max_ch = is_tx ? controller-num_tx_channels :
- controller-num_rx_channels;
-
- if (ch_num = max_ch)
+ if (ch_num = UX500_MUSB_DMA_NUM_RX_TX_CHANNELS)
return NULL;
ux500_channel = is_tx ? (controller-tx_channel[ch_num]) :
@@ -262,7 +256,7 @@ static int ux500_dma_controller_stop(struct dma_controller
*c)
struct dma_channel
[PATCH 02/10] usb: musb: ux500: move the MUSB HDRC configuration into the driver
The MUSB HDRC configuration never changes between each of the ux500
supported platforms, so there's little point passing it though platform
data. If we set it in the driver instead, we can make good use of it
when booting with either ATAGs or Device Tree.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/mach-ux500/usb.c |8
drivers/usb/musb/ux500.c |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 8aff9a4..4f68a9c 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -76,16 +76,8 @@ static struct ux500_musb_board_data musb_board_data = {
static u64 ux500_musb_dmamask = DMA_BIT_MASK(32);
-static struct musb_hdrc_config musb_hdrc_config = {
- .multipoint = true,
- .dyn_fifo = true,
- .num_eps= 16,
- .ram_bits = 16,
-};
-
static struct musb_hdrc_platform_data musb_platform_data = {
.mode = MUSB_OTG,
- .config = musb_hdrc_config,
.board_data = musb_board_data,
};
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 13a3929..4a8f5c9 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -29,6 +29,13 @@
#include musb_core.h
+static struct musb_hdrc_config ux500_musb_hdrc_config = {
+ .multipoint = true,
+ .dyn_fifo = true,
+ .num_eps= 16,
+ .ram_bits = 16,
+};
+
struct ux500_glue {
struct device *dev;
struct platform_device *musb;
@@ -123,6 +130,7 @@ static int ux500_probe(struct platform_device *pdev)
glue-clk = clk;
pdata-platform_ops = ux500_ops;
+ pdata-config = ux500_musb_hdrc_config;
platform_set_drvdata(pdev, glue);
--
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
[PATCH 03/10] usb: musb: ux500: take the dma_mask from coherent_dma_mask
The dma_mask will always be the same as the coherent_dma_mask, so let's
cut down on the platform_data burden and set it as such in the driver.
This also saves us from supporting it separately when we come to enable
this driver for Device Tree.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/mach-ux500/usb.c |3 ---
drivers/usb/musb/ux500.c |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 4f68a9c..e6c4a05 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -74,8 +74,6 @@ static struct ux500_musb_board_data musb_board_data = {
.dma_filter = stedma40_filter,
};
-static u64 ux500_musb_dmamask = DMA_BIT_MASK(32);
-
static struct musb_hdrc_platform_data musb_platform_data = {
.mode = MUSB_OTG,
.board_data = musb_board_data,
@@ -98,7 +96,6 @@ struct platform_device ux500_musb_device = {
.id = 0,
.dev = {
.platform_data = musb_platform_data,
- .dma_mask = ux500_musb_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
.num_resources = ARRAY_SIZE(usb_resources),
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 4a8f5c9..7ddb132 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -122,7 +122,7 @@ static int ux500_probe(struct platform_device *pdev)
}
musb-dev.parent= pdev-dev;
- musb-dev.dma_mask = pdev-dev.dma_mask;
+ musb-dev.dma_mask = pdev-dev.coherent_dma_mask;
musb-dev.coherent_dma_mask = pdev-dev.coherent_dma_mask;
glue-dev = pdev-dev;
--
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
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: On Tue, 23 Apr 2013, Clemens Ladisch wrote: Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. This flag was needed to avoid having to set urb-start_frame. With the changed queueing API, the audio driver needs to change too. I'll look into this ... Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On Tue, 23 Apr 2013, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
What is that bug number? Where can it be referenced? If you are going
to put it in a public place (like a kernel changelog), it needs to be
publicly accessible.
On some HP platform, when usb driver inits the iLo Virtual USB Controller,
there may be a warning Controller not stopped yet!. It is because driver
does not wait enough time.
What happened to your line endings?
This patch adds more time waiting and retries.
Why not only do this for your device?
It won't hurt to do it for all devices, because the wait loop will
terminate as soon as the controller goes into suspend. For normal
controllers this will be on the first iteration.
Signed-off-by: Li, Zhen-Hua zhen-h...@hp.com
---
drivers/usb/host/uhci-hcd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..514e9d7 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -277,6 +277,9 @@ static int global_suspend_mode_is_broken(struct
uhci_hcd *uhci)
uhci-global_suspend_mode_is_broken(uhci) : 0;
}
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
Why is the delay set to 100 us? Isn't that excessively large? How
long does it take for this controller to go into suspend?
static void suspend_rh(struct uhci_hcd *uhci, enum uhci_rh_state new_state)
__releases(uhci-lock)
__acquires(uhci-lock)
@@ -284,6 +287,7 @@ __acquires(uhci-lock)
int auto_stop;
int int_enable, egsm_enable, wakeup_enable;
struct usb_device *rhdev = uhci_to_hcd(uhci)-self.root_hub;
+ u16 try, stopped;
Why are these variables u16? Why not int?
Anyway, a better approach would be not to add a delay loop at all.
Instead, change this test:
if (!auto_stop !(uhci_readw(uhci, USBSTS) USBSTS_HCH)) {
uhci-rh_state = UHCI_RH_SUSPENDING;
spin_unlock_irq(uhci-lock);
msleep(1);
spin_lock_irq(uhci-lock);
if (uhci-dead)
return;
}
When the iLo controller is present, make the if statement always
succeed. Then you'll get a whole 1-ms delay.
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 v6 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-20130422' 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 Felipe, please ACK or NAK the rcar-phy patches ASAP. It's time consuming for me to keep all these patches fresh atop of ever changing 'next' branch 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 06/10] usb: musb: ux500: add device tree probing support
On Tuesday 23 April 2013, Lee Jones wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do - mode : Should be 3 to represent OTG. 1 signifies HOST and 2 represents PERIPHERAL. Or you match fsl-usb.txt and nvidia,tegra20-ehci.txt, defining - dr_mode : dual role mode. Indicates the working mode to controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. +Optional properties: + - dmas : A list of dma channels; +dma-controller, event-line, fixed-channel, flags + - dma-names : An ordered list of channel names affiliated to the above Please list the exact dma-names that are required. Arnd -- 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 v6 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 r8a7779_late_devices[]
to r8a7779_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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 5:
- fixed typos in the changelog.
Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.
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 linux/mmc/host.h
#include linux/mmc/sh_mobile_sdhi.h
#include linux/mfd/tmio.h
-#include linux/usb/otg.h
-#include linux/usb/ehci_pdriver.h
-#include linux/usb/ohci_pdriver.h
-#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/r8a7779.h
#include mach/common.h
@@ -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,
-
Re: [PATCH 06/10] usb: musb: ux500: add device tree probing support
On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote: On Tuesday 23 April 2013, Lee Jones wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do there is dr_mode which other folks are using. Let's use the same thing. -- balbi signature.asc Description: Digital signature
[PATCH v6 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 linux/usb/ehci_pdriver.h...
The patch has been tested on the Marzen and BOCK-W boards.
Suggested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Alan Stern st...@rowland.harvard.edu
---
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 v6 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 4:
- refreshed the patch.
Changes since version 3:
- lowercased the SoC name in the subject.
Changes since version 2:
- added #include linux/usb/hcd.h;
- 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 linux/sh_timer.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
+#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
#include linux/usb/ohci_pdriver.h
#include linux/pm_runtime.h
@@ -435,10 +436,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
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Tue, 23 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: On Tue, 23 Apr 2013, Clemens Ladisch wrote: Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. This flag was needed to avoid having to set urb-start_frame. Ah, okay. It is now unnecessary to set urb-start_frame; in fact that field is now output-only. (To be fair, I haven't checked _all_ the HCDs in this regard, just uhci-hcd, ohci-hcd, and ehci-hcd. However, if any other HCD requires urb-start_frame to be set then that HCD should be considered buggy and should be fixed.) With the changed queueing API, the audio driver needs to change too. I'll look into this ... Let me know if you have any questions. 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 v6 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
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
Re: [PATCH 06/10] usb: musb: ux500: add device tree probing support
On Tuesday 23 April 2013, Felipe Balbi wrote: On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote: On Tuesday 23 April 2013, Lee Jones wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do there is dr_mode which other folks are using. Let's use the same thing. On that topic, should we support the same property in am35x.c and musbhsdma.c? They currently use an integer rather than a string. Arnd -- 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 v6 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 4:
- refreshed the patch.
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
@@ -395,11 +395,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
Re: [PATCH 06/10] usb: musb: ux500: add device tree probing support
Hi, On Tue, Apr 23, 2013 at 05:27:10PM +0200, Arnd Bergmann wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do there is dr_mode which other folks are using. Let's use the same thing. On that topic, should we support the same property in am35x.c and musbhsdma.c? They currently use an integer rather than a string. certainly :) I also plan to add dr_mode support for dwc3. -- balbi signature.asc Description: Digital signature
[PATCH v6 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 4:
- refreshed the patch.
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
@@ -391,7 +391,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 linux/spinlock.h
#include linux/module.h
-/* 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 v6 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 linux/usb/rcar-phy.h file with
the 'struct rcar_phy_platform_data' containing various bit fields describing
USB pin configuration.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
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 linux/types.h;
- 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 linux/types.h
+
+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 v6 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 involves 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 5:
- annotated USB PHY resources and platform data as '__initdata' since they're
kmemdup()'ed while registering the platform device anyway;
- fixed typo in the changelog.
Changes since version 4:
- refreshed the patch.
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| 18 +-
3 files changed, 14 insertions(+), 9 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 __initdata;
+
/* SMSC LAN89218 */
static struct resource smsc911x_resources[] = {
[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
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 linux/sh_clk.h
#include linux/pm_domain.h
#include linux/sh_eth.h
+#include linux/usb/rcar-phy.h
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
@@ -389,7 +389,7 @@ static struct platform_device sata_devic
};
/* USB PHY */
-static struct resource usb_phy_resources[] = {
+static struct resource usb_phy_resources[] __initdata = {
[0] = {
.start = 0xffe70800,
.end= 0xffe70900 - 1,
@@ -397,13 +397,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;
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
scif5_device,
tmu00_device,
tmu01_device,
- usb_phy_device,
};
static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,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,
+
[PATCH v6 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 sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
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 kuninori.morimoto...@renesas.com
+ * 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 linux/delay.h
#include linux/io.h
-#include linux/usb/otg.h
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/module.h
+#include linux/usb/otg.h
+#include linux/usb/rcar-phy.h
/* 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
[PATCH v5 0/3] Add USB support to R8A7778/BOCK-W
Hello. Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130422' tag and the R8A7779/Marzen patchset I've 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/3] rcar-phy: add R8A7778 support [2/3] ARM: shmobile: r8a7778: add USB support [3/3] ARM: shmobile: BOCK-W: add USB support The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been already merged, is not reposted. 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] ARM: allmodconfig regressions in linux-next
Hi everyone, These are a couple of simple patches to fix bugs that break allyesconfig and that are only present in linux-next at the moment. Please apply to the appropriate trees or provide feedback! Arnd Bergmann (5): mfd: ab8500: remove broken ab8500_debug_register_interrupt logic usb: phy: phy core cannot yet be a module ASoC: don't call of_dma_request_slave_channel directly hwrng: bcm2835: fix MODULE_LICENSE tag clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change drivers/char/hw_random/bcm2835-rng.c | 2 +- drivers/clocksource/bcm_kona_timer.c | 15 --- drivers/mfd/ab8500-debugfs.c | 10 -- drivers/usb/phy/Kconfig | 2 +- sound/soc/soc-generic-dmaengine-pcm.c | 9 + 5 files changed, 11 insertions(+), 27 deletions(-) Cc: Christian Daudt c...@broadcom.com Cc: Dom Cobley popcorn...@gmail.com Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Herbert Xu herb...@gondor.apana.org.au Cc: John Stultz john.stu...@linaro.org Cc: Jonas ABERG jonas.ab...@stericsson.com Cc: Lars-Peter Clausen l...@metafoo.de Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@stericsson.com Cc: Lubomir Rintel lkund...@v3.sk Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Matt Mackall m...@selenic.com Cc: Mattias WALLIN mattias.wal...@stericsson.com Cc: Per FORLIN per.for...@stericsson.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Shawn Guo shawn@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: alsa-de...@alsa-project.org Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-usb@vger.kernel.org Cc: srinidhi kasagar srinidhi.kasa...@stericsson.com -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: phy core cannot yet be a module
A lot of platform code calls into the usb phy core at the moment, which does not work if it is built as a loadable module. This will hopefully change when those platforms are all converted to DT based probing, but for now, the easiest solution is to change it from tristate to bool. This solves at least these ARM allmodconfig build errors: arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create': arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create' arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' drivers/built-in.o: In function `ab8500_charger_probe': drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy' drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy' drivers/built-in.o: In function `ab8500_charger_remove': drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy' Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- drivers/usb/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 21153d1..371d0e7 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -2,7 +2,7 @@ # Physical Layer USB driver configuration # menuconfig USB_PHY - tristate USB Physical Layer drivers + bool USB Physical Layer drivers help USB controllers (those which are host, device or DRD) need a device to handle the physical layer signalling, commonly called -- 1.8.1.2 -- 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 v5 1/3] 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 sergei.shtyl...@cogentembedded.com
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since version 3:
- removed stray debugging printk() call.
Changes since version 2:
- moved 'ferrite_bead' bitfield to the start of 'struct rcar_phy_platform_data'
which allowed to cut the size of the structure from 8 bytes back to 4;
- added a comment about only 2 USB ports on R8A7778'
- added an ACK from Felipe Balbi.
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 |4 +++-
3 files changed, 38 insertions(+), 11 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;
+
+
[PATCH v5 2/3] 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 sergei.shtyl...@cogentembedded.com
---
Changes since version 4:
- annotated USB resources and '[eo]hci_info' as '__initdata' since they're
kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.
Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.
Changes since version 2:
- refreshed the patch.
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
@@ -41,6 +41,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
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
enum {
MSTP323, MSTP322, MSTP321,
MSTP114,
+ MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(p_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(p_clk, MSTPCR3, 21, 0), /* SDHI2 */
[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 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(sh_mobile_sdhi.1, mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID(sh_mobile_sdhi.2, mstp_clks[MSTP321]), /* SDHI2 */
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
@@ -20,10 +20,13 @@
#include linux/mmc/sh_mobile_sdhi.h
#include linux/sh_eth.h
+#include linux/usb/rcar-phy.h
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
@@ -30,6 +30,12 @@
#include linux/irqchip.h
#include linux/serial_sci.h
#include linux/sh_timer.h
+#include linux/pm_runtime.h
+#include linux/usb/phy.h
+#include linux/usb/hcd.h
+#include linux/usb/ehci_pdriver.h
+#include linux/usb/ohci_pdriver.h
+#include linux/dma-mapping.h
#include mach/irqs.h
#include mach/r8a7778.h
#include mach/common.h
@@ -89,6 +95,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[] __initdata = {
+ DEFINE_RES_MEM(0xffe70800, 0x100),
+ DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init
[PATCH v5 3/3] 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 sergei.shtyl...@cogentembedded.com
---
Changes since version 4:
- annotated 'usb_phy_platform_data' as '__initdata' since it's kmemdup()'ed
while registering the platform device anyway;
- refreshed the patch.
Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.
Changes since version 2:
- refreshed the patch.
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 |4
1 file changed, 4 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
@@ -63,6 +63,8 @@ static struct sh_mobile_sdhi_info sdhi0_
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
};
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT(sh-sci.0, pfc-r8a7778,
@@ -91,6 +93,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);
pinctrl_register_mappings(bockw_pinctrl_map,
ARRAY_SIZE(bockw_pinctrl_map));
@@ -146,4 +149,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
Re: [PATCH] usb: phy: phy core cannot yet be a module
Hi, On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote: A lot of platform code calls into the usb phy core at the moment, which does not work if it is built as a loadable module. This will hopefully change when those platforms are all converted to DT based probing, but for now, the easiest solution is to change it from tristate to bool. This solves at least these ARM allmodconfig build errors: arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create': arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create' arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' drivers/built-in.o: In function `ab8500_charger_probe': drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy' drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy' drivers/built-in.o: In function `ab8500_charger_remove': drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy' Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- drivers/usb/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 21153d1..371d0e7 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -2,7 +2,7 @@ # Physical Layer USB driver configuration # menuconfig USB_PHY - tristate USB Physical Layer drivers + bool USB Physical Layer drivers looks like this is the only way, indeed. Do you need on the merge window on can this wait until -rc1 ? I just sent a pull request to Greg with urgent fixes for the merge window. Greg, if you want to take this one as a patch, go for it: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: phy core cannot yet be a module
On Tuesday 23 April 2013, Felipe Balbi wrote: looks like this is the only way, indeed. Do you need on the merge window on can this wait until -rc1 ? I just sent a pull request to Greg with urgent fixes for the merge window. Greg, if you want to take this one as a patch, go for it: Acked-by: Felipe Balbi ba...@ti.com It's not relevant for real-life scenarios, it's fine as long as this makes it into 3.10. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: phy core cannot yet be a module
Hi, On Tue, Apr 23, 2013 at 06:11:35PM +0200, Arnd Bergmann wrote: On Tuesday 23 April 2013, Felipe Balbi wrote: looks like this is the only way, indeed. Do you need on the merge window on can this wait until -rc1 ? I just sent a pull request to Greg with urgent fixes for the merge window. Greg, if you want to take this one as a patch, go for it: Acked-by: Felipe Balbi ba...@ti.com It's not relevant for real-life scenarios, it's fine as long as this makes it into 3.10. sure, I can take this on -rc1 then. -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] USB patches for v3.10 (urgent fixes)
On Tue, Apr 23, 2013 at 02:38:20PM +0300, Felipe Balbi wrote: Hi Greg, Here are a few urgent fixes for my latest pull request. Good to know people have been testing. With these we will have a rather good -rc1 and anything else can be fixed during the -rc cycle. Let me know if you would prefer to wait until -rc1 to apply these commits. cheers The following changes since commit 9b192de60b5a584ee4ed967fb6758773c75e4643: usb: gadget: nokia: include f_ecm.c (2013-04-03 21:02:47 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.10-part2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: phy core cannot yet be a module
On Tue, Apr 23, 2013 at 07:07:59PM +0300, Felipe Balbi wrote: Hi, On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote: A lot of platform code calls into the usb phy core at the moment, which does not work if it is built as a loadable module. This will hopefully change when those platforms are all converted to DT based probing, but for now, the easiest solution is to change it from tristate to bool. This solves at least these ARM allmodconfig build errors: arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create': arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create' arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' drivers/built-in.o: In function `ab8500_charger_probe': drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy' drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy' drivers/built-in.o: In function `ab8500_charger_remove': drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy' Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- drivers/usb/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 21153d1..371d0e7 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -2,7 +2,7 @@ # Physical Layer USB driver configuration # menuconfig USB_PHY - tristate USB Physical Layer drivers + bool USB Physical Layer drivers looks like this is the only way, indeed. Do you need on the merge window on can this wait until -rc1 ? I just sent a pull request to Greg with urgent fixes for the merge window. Greg, if you want to take this one as a patch, go for it: Acked-by: Felipe Balbi ba...@ti.com I'll take this now, 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
[PATCH 00/21] ARM build fixes for 3.10
Hi everyone, This is a set of bug fixes for build errors and warnings I am seeing in the various defconfigs and/or allmodconfig builds on linux-next. The majority of these showed up because we now include a lot more platforms in allmodconfig than we used to. Please apply to appropriate maintainer trees or provide feedback, I can take care of the rest sending those through arm-soc that I get no feedback on. Arnd Arnd Bergmann (21): Turn off -Wmaybe-uninitialized when building with -Os ARM: compressed/head.S: work around new binutils warning ARM: use optimized do_div only for EABI ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7 ARM: tegra: call cpu_do_idle from C code ARM: tegra: unify tegra_idle_device definitions ASoC: ux500: forward declare msp_i2s_platform_data spi/sirf: fix MODULE_DEVICE_TABLE ssb: fix alignment of struct bcma_device_id drm/tilcdc: use only a single module device table mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE misc: mark spear13xx-pcie-gadget as broken staging: nvec: allow modular build staging: comedi/dawboard2000: use mdelay for large delays staging/zsmalloc: don't use pgtable-mapping from modules tty/serial/sirf: fix MODULE_DEVICE_TABLE usb: phy: tegra: don't call into tegra-ehci directly usb: phy: don't mark usb_bind_phy as __init MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly mtd: omap2: allow bulding as a module Makefile | 2 +- arch/arm/boot/compressed/Makefile | 2 +- arch/arm/boot/compressed/head.S | 12 arch/arm/include/asm/div64.h | 2 +- arch/arm/kvm/Kconfig | 6 +++--- arch/arm/mach-omap2/Kconfig | 5 + arch/arm/mach-tegra/cpuidle-tegra114.c| 5 ++--- arch/arm/mach-tegra/cpuidle-tegra20.c | 4 +--- arch/arm/mach-tegra/cpuidle-tegra30.c | 4 +--- arch/arm/mach-tegra/cpuidle.c | 2 ++ arch/arm/mach-tegra/cpuidle.h | 4 arch/arm/mach-tegra/pm.c | 5 + arch/arm/mach-tegra/sleep-tegra20.S | 2 +- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 - drivers/mfd/ab8500-gpadc.c| 2 +- drivers/misc/Kconfig | 2 +- drivers/mmc/host/sdhci-tegra.c| 2 +- drivers/mtd/nand/Kconfig | 2 +- drivers/spi/spi-sirf.c| 2 +- drivers/staging/comedi/drivers/daqboard2000.c | 14 +++--- drivers/staging/nvec/Kconfig | 10 +- drivers/staging/zsmalloc/zsmalloc-main.c | 2 +- drivers/tty/serial/sirfsoc_uart.c | 2 +- drivers/usb/host/ehci-tegra.c | 10 +- drivers/usb/otg/otg.c | 2 +- drivers/usb/phy/tegra_usb_phy.c | 13 + include/linux/mod_devicetable.h | 5 +++-- include/linux/usb/tegra_usb_phy.h | 10 +- sound/soc/ux500/ux500_msp_i2s.h | 1 + 31 files changed, 82 insertions(+), 55 deletions(-) -- 1.8.1.2 Cc: Alan Stern st...@rowland.harvard.edu Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com Cc: Chris Ball c...@laptop.org Cc: Dave Airlie airl...@linux.ie Cc: David Woodhouse dw...@infradead.org Cc: Felipe Balbi ba...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Mark Brown broo...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Samuel Ortiz sa...@linux.intel.com Cc: Stephen Warren swar...@nvidia.com Cc: Tony Lindgren t...@atomide.com Cc: Viresh Kumar viresh.ku...@st.com Cc: alsa-de...@alsa-project.org Cc: dri-de...@lists.freedesktop.org Cc: linux-...@lists.infradead.org Cc: linux-usb@vger.kernel.org Cc: spi-devel-gene...@lists.sourceforge.net -- 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 18/21] usb: phy: tegra: don't call into tegra-ehci directly
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to
`tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_clk_enable':
drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to
`tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_power_on':
drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'
This turns the interface into a one-way dependency by letting the tegra ehci
driver pass two function pointers for callbacks that need to be called by
the phy driver.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Venu Byravarasu vbyravar...@nvidia.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Stephen Warren swar...@nvidia.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ehci-tegra.c | 10 +-
drivers/usb/phy/tegra_usb_phy.c | 13 +
include/linux/usb/tegra_usb_phy.h | 10 +-
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 568aecc..07419e4 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -610,7 +610,7 @@ static const struct dev_pm_ops tegra_ehci_pm_ops = {
/* Bits of PORTSC1, which will get cleared by writing 1 into them */
#define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
+static void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
{
unsigned long val;
struct usb_hcd *hcd = bus_to_hcd(x-otg-host);
@@ -621,9 +621,8 @@ void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
val |= TEGRA_USB_PORTSC1_PTS(pts_val 3);
writel(val, base + TEGRA_USB_PORTSC1);
}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_pts);
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
+static void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
{
unsigned long val;
struct usb_hcd *hcd = bus_to_hcd(x-otg-host);
@@ -636,7 +635,6 @@ void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
val = ~TEGRA_USB_PORTSC1_PHCD;
writel(val, base + TEGRA_USB_PORTSC1);
}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_phcd);
static u64 tegra_ehci_dma_mask = DMA_BIT_MASK(32);
@@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
tegra-phy = tegra_usb_phy_open(pdev-dev, instance, hcd-regs,
pdata-phy_config,
- TEGRA_USB_PHY_MODE_HOST);
+ TEGRA_USB_PHY_MODE_HOST,
+ tegra_ehci_set_pts,
+ tegra_ehci_set_phcd);
if (IS_ERR(tegra-phy)) {
dev_err(pdev-dev, Failed to open USB phy\n);
err = -ENXIO;
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
index 5487d38..17d8112 100644
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c
@@ -299,7 +299,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
val = ~USB_SUSP_SET;
writel(val, base + USB_SUSP_CTRL);
} else
- tegra_ehci_set_phcd(phy-u_phy, true);
+ phy-set_phcd(phy-u_phy, true);
if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) 0)
pr_err(%s: timeout waiting for phy to stabilize\n, __func__);
@@ -321,7 +321,7 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
val = ~USB_SUSP_CLR;
writel(val, base + USB_SUSP_CTRL);
} else
- tegra_ehci_set_phcd(phy-u_phy, false);
+ phy-set_phcd(phy-u_phy, false);
if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
USB_PHY_CLK_VALID))
@@ -444,7 +444,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
utmi_phy_clk_enable(phy);
if (!phy-is_legacy_phy)
- tegra_ehci_set_pts(phy-u_phy, 0);
+ phy-set_pts(phy-u_phy, 0);
return 0;
}
@@ -688,7 +688,10 @@ static int tegra_usb_phy_suspend(struct usb_phy *x, int
suspend)
}
struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
- void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode)
+ void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode,
+ void (*set_pts)(struct usb_phy *x, u8 pts_val),
+ void (*set_phcd)(struct usb_phy *x, bool enable))
+
{
struct tegra_usb_phy *phy;
unsigned long parent_rate;
@@ -707,6 +710,8 @@ struct tegra_usb_phy
Re: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
On Tue, 23 Apr 2013, Arnd Bergmann wrote: Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one, which does not work if one of them or both are loadable modules, resulting in an error like: drivers/built-in.o: In function `utmi_phy_clk_disable': drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd' drivers/built-in.o: In function `utmi_phy_clk_enable': drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd' drivers/built-in.o: In function `utmi_phy_power_on': drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts' This turns the interface into a one-way dependency by letting the tegra ehci driver pass two function pointers for callbacks that need to be called by the phy driver. @@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev) tegra-phy = tegra_usb_phy_open(pdev-dev, instance, hcd-regs, pdata-phy_config, - TEGRA_USB_PHY_MODE_HOST); + TEGRA_USB_PHY_MODE_HOST, + tegra_ehci_set_pts, + tegra_ehci_set_phcd); Does the compiler warn about the unnecessary ''? In any case, it looks strange to have one function pointer with an '' and another without. Aside from that minor detail, the ehci-tegra.c changes are fine. 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 01/11] usb: phy: Add APIs for runtime power management
On Tue, 23 Apr 2013, Vivek Gautam wrote: Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. Basically right. Help me to understand the overall situation a little better: What code registers the PHY initially? PHY is added to global list by PHY drivers (like phy-samsung-usb2.c/phy-omap-usb2.c) by usb_add_phy() API Then this routine should initialize the PHY. The initialized state could be either active or suspended, your choice. Suspended would be best, in case the PHY never gets used. What routine does the DWC3 driver call to register itself as a consumer of the PHY? I think DWC3 doesn't registers itself as consumer of PHY, rather it gets that PHY from the list using devm_usb_get_phy()/devm_usb_get_phy_by_phandle() API. DWC3 can now call PHY's initialization sequence using usb_phy_init(). So, before DWC3 initializes the PHY, PHYs should be in active state. Then usb_phy_init should make sure the PHY is in the active state. If usb_add_phy() left the PHY suspended, then this routine should call pm_runtime_get_sync(). After DWC3 (or any other driver) has acquired the PHY, it can call pm_runtime_put/get() however it likes, so long as the calls balance properly. If the driver isn't runtime-PM aware then it won't use any of these calls, and the PHY will remain active the entire time. Likewise, what routine does it call to unregister itself? Once DWC3's remove() is called PHYs are put. Is there a routine analogous to usb_phy_init() that gets called when PHY is released? That routine would do the opposite of usb_phy_init(), putting the PHY back into its initialized state. 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 2/2] USB:ftdi_sio: enable two UART ports on ST Microconnect Lite
On Tue, Apr 23, 2013 at 12:46:30PM +0100, Adrian Thomasset wrote:
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
Signed-off-by: Adrian Thomasset adrian.thomas...@st.com
---
drivers/usb/serial/ftdi_sio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 6be5853..6553920 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1794,20 +1794,24 @@ static int ftdi_8u2232c_probe(struct usb_serial
*serial)
}
/*
- * First and second port on STMCLiteadaptors is reserved for JTAG interface
- * and the forth port for pio
+ * First two ports on JTAG adaptors using an FT4232 such as
STMicroelectronics's
+ * ST Micro Connect Lite are reserved for JTAG or other non-UART interfaces
and
+ * can be accessed from userspace.
+ * The next two ports are enabled as UARTs by default, where port 2 is
+ * a conventional RS-232 UART.
*/
static int ftdi_stmclite_probe(struct usb_serial *serial)
{
struct usb_device *udev = serial-dev;
struct usb_interface *interface = serial-interface;
- if (interface == udev-actconfig-interface[2])
- return 0;
-
+ if (interface == udev-actconfig-interface[0] ||
+ interface == udev-actconfig-interface[1]) {
dev_info(udev-dev, Ignoring serial port reserved for JTAG\n);
-
return -ENODEV;
+ }
+
You didn't run this patch through 'scripts/checkpatch.pl', did you?
Please fix up the formatting errors and resend.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
On Tue, Apr 23, 2013 at 06:30:50PM +0200, Arnd Bergmann wrote: Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one, which does not work if one of them or both are loadable modules, resulting in an error like: drivers/built-in.o: In function `utmi_phy_clk_disable': drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd' drivers/built-in.o: In function `utmi_phy_clk_enable': drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd' drivers/built-in.o: In function `utmi_phy_power_on': drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts' This turns the interface into a one-way dependency by letting the tegra ehci driver pass two function pointers for callbacks that need to be called by the phy driver. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Venu Byravarasu vbyravar...@nvidia.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Stephen Warren swar...@nvidia.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ehci-tegra.c | 10 +- drivers/usb/phy/tegra_usb_phy.c | 13 + include/linux/usb/tegra_usb_phy.h | 10 +- 3 files changed, 19 insertions(+), 14 deletions(-) Not all of these files are in my usb-next tree, so I can't take this patch, sorry. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/21] usb: phy: don't mark usb_bind_phy as __init
On Tue, Apr 23, 2013 at 06:30:51PM +0200, Arnd Bergmann wrote: It makes no sense for a symbol to be both exported and marked __init, because any users in modules would be calling this function after it gets discarded. Further, this patch revolves a section mismatch warning from usbhs_init_phys(), which is intentionally not marked __init: WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from the function usbhs_init_phys() to the function .init.text:usb_bind_phy() Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- drivers/usb/otg/otg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) What tree has this file? It's not mine :( -- 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 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Hello. On 04/22/2013 08:00 AM, Simon Horman wrote: 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 sergei.shtyl...@cogentembedded.com I realise that this is not going to be useful until the rest of the series has been merged. But regardless I have pre-emptively queued it up for v3.11 in the defconfig-bockw branch. --- 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 Unfortunately, you've made a mistake in this last line of the patch: you've truncated it to just CONFIG_USB_RCAR. :-( Will you correct it? Sorry about that, I will fix it. Sorry to say, but you fixed it the wrong way; now it's: +CONFIG_USB_RCAR=y instead of: +CONFIG_USB_RCAR_PHY=y Sorry for my carelessness. I will forcibly push the following: From 26b78f5c9ad1e4809f6d0a5547e4eab222f53f23 Mon Sep 17 00:00:00 2001 From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Date: Wed, 17 Apr 2013 01:35:09 +0400 Subject: [PATCH] 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 sergei.shtyl...@cogentembedded.com Signed-off-by: Simon Horman horms+rene...@verge.net.au Third time's a charm, as they say. :-) 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] usb: storage: Convert US_DEBUGP to usb_stor_dbg
On Mon, 2013-04-22 at 12:35 -0700, David Rientjes wrote:
On Fri, 19 Apr 2013, Joe Perches wrote:
@@ -966,11 +934,13 @@ static int realtek_cr_autosuspend_setup(struct
us_data *us)
static void realtek_cr_destructor(void *extra)
{
struct rts51x_chip *chip = (struct rts51x_chip *)extra;
-
- US_DEBUGP(%s: ---\n, __func__);
+ struct us_data *us;
if (!chip)
return;
+
+ us = chip-us;
+
#ifdef CONFIG_REALTEK_AUTOPM
if (ss_en) {
del_timer(chip-rts51x_suspend_timer);
From linux-next:
drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor':
drivers/usb/storage/realtek_cr.c:942:11: error: 'struct rts51x_chip' has no
member named 'us'
chip-us here is only defined when CONFIG_REALTEK_AUTOPM is enabled.
Thanks.
I'll fix it, but it'll likely be a couple of weeks
until I can.
--
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 01/11] usb: phy: Add APIs for runtime power management
Hi, On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 23 Apr 2013, Vivek Gautam wrote: Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. Basically right. Help me to understand the overall situation a little better: What code registers the PHY initially? PHY is added to global list by PHY drivers (like phy-samsung-usb2.c/phy-omap-usb2.c) by usb_add_phy() API Then this routine should initialize the PHY. The initialized state could be either active or suspended, your choice. Suspended would be best, in case the PHY never gets used. Fair enough. What routine does the DWC3 driver call to register itself as a consumer of the PHY? I think DWC3 doesn't registers itself as consumer of PHY, rather it gets that PHY from the list using devm_usb_get_phy()/devm_usb_get_phy_by_phandle() API. DWC3 can now call PHY's initialization sequence using usb_phy_init(). So, before DWC3 initializes the PHY, PHYs should be in active state. Then usb_phy_init should make sure the PHY is in the active state. If usb_add_phy() left the PHY suspended, then this routine should call pm_runtime_get_sync(). Right After DWC3 (or any other driver) has acquired the PHY, it can call pm_runtime_put/get() however it likes, so long as the calls balance properly. If the driver isn't runtime-PM aware then it won't use any of these calls, and the PHY will remain active the entire time. Alright, so DWC3 (or any other consumer of PHY) should do minimal to handle runtime state of PHYs; get() when accessing PHY and put() when it's done with it. Likewise, what routine does it call to unregister itself? Once DWC3's remove() is called PHYs are put. Is there a routine analogous to usb_phy_init() that gets called when PHY is released? That routine would do the opposite of usb_phy_init(), putting the PHY back into its initialized state. Yes, ofcourse there's a routine usb_phy_shutdown(). So this will be calling put_sync() to put PHYs back to its initialized state. Right ? -- Best Regards Vivek -- 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 01/11] usb: phy: Add APIs for runtime power management
On Tue, 23 Apr 2013, Vivek Gautam wrote: Hi, On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 23 Apr 2013, Vivek Gautam wrote: Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. Basically right. Help me to understand the overall situation a little better: What code registers the PHY initially? PHY is added to global list by PHY drivers (like phy-samsung-usb2.c/phy-omap-usb2.c) by usb_add_phy() API Then this routine should initialize the PHY. The initialized state could be either active or suspended, your choice. Suspended would be best, in case the PHY never gets used. Fair enough. What routine does the DWC3 driver call to register itself as a consumer of the PHY? I think DWC3 doesn't registers itself as consumer of PHY, rather it gets that PHY from the list using devm_usb_get_phy()/devm_usb_get_phy_by_phandle() API. DWC3 can now call PHY's initialization sequence using usb_phy_init(). So, before DWC3 initializes the PHY, PHYs should be in active state. Then usb_phy_init should make sure the PHY is in the active state. If usb_add_phy() left the PHY suspended, then this routine should call pm_runtime_get_sync(). Right After DWC3 (or any other driver) has acquired the PHY, it can call pm_runtime_put/get() however it likes, so long as the calls balance properly. If the driver isn't runtime-PM aware then it won't use any of these calls, and the PHY will remain active the entire time. Alright, so DWC3 (or any other consumer of PHY) should do minimal to handle runtime state of PHYs; get() when accessing PHY and put() when it's done with it. Yes. The first operation will generally be a put, because usb_phy_init() will leave the PHY in an active state. Likewise, what routine does it call to unregister itself? Once DWC3's remove() is called PHYs are put. Is there a routine analogous to usb_phy_init() that gets called when PHY is released? That routine would do the opposite of usb_phy_init(), putting the PHY back into its initialized state. Yes, ofcourse there's a routine usb_phy_shutdown(). So this will be calling put_sync() to put PHYs back to its initialized state. Right ? Correct. 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: linux-next: Tree for Apr 23 (usb storage)
On 04/23/13 01:00, Stephen Rothwell wrote: Hi all, Changes since 20130422: on i386, when CONFIG_PM_RUNTIME is not enabled so REALTEK_AUTOPM is not enabled: drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor': drivers/usb/storage/realtek_cr.c:942:11: error: 'struct rts51x_chip' has no member named 'us' -- ~Randy -- 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 18/21] usb: phy: tegra: don't call into tegra-ehci directly
On Tuesday 23 April 2013, Alan Stern wrote: On Tue, 23 Apr 2013, Arnd Bergmann wrote: @@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev) tegra-phy = tegra_usb_phy_open(pdev-dev, instance, hcd-regs, pdata-phy_config, - TEGRA_USB_PHY_MODE_HOST); + TEGRA_USB_PHY_MODE_HOST, + tegra_ehci_set_pts, + tegra_ehci_set_phcd); Does the compiler warn about the unnecessary ''? No, AFAIK, both variants are equally acceptable C. In any case, it looks strange to have one function pointer with an '' and another without. Yes, that was certainly not intentional. I've removed the '' now. Aside from that minor detail, the ehci-tegra.c changes are fine. Ok, thanks for the feedback. Arnd -- 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] usb: phy: tegra: don't call into tegra-ehci directly
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to
`tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_clk_enable':
drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to
`tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_power_on':
drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'
This turns the interface into a one-way dependency by letting the tegra ehci
driver pass two function pointers for callbacks that need to be called by
the phy driver.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Venu Byravarasu vbyravar...@nvidia.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Stephen Warren swar...@nvidia.com
Cc: linux-usb@vger.kernel.org
---
On Tuesday 23 April 2013, Greg Kroah-Hartman wrote:
drivers/usb/host/ehci-tegra.c | 10 +-
drivers/usb/phy/tegra_usb_phy.c | 13 +
include/linux/usb/tegra_usb_phy.h | 10 +-
3 files changed, 19 insertions(+), 14 deletions(-)
Not all of these files are in my usb-next tree, so I can't take this
patch, sorry.
Right. I created the patch again linux-next but then rebased the series
to 3.9-rc8 for submission. I had not realized that the files got renamed
between the trees.
Arnd
drivers/usb/host/ehci-tegra.c | 10 +-
drivers/usb/phy/phy-tegra-usb.c | 13 +
include/linux/usb/tegra_usb_phy.h | 10 +-
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index ed201ae..e3eddc3 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -611,7 +611,7 @@ static const struct dev_pm_ops tegra_ehci_pm_ops = {
/* Bits of PORTSC1, which will get cleared by writing 1 into them */
#define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
+static void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
{
unsigned long val;
struct usb_hcd *hcd = bus_to_hcd(x-otg-host);
@@ -622,9 +622,8 @@ void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
val |= TEGRA_USB_PORTSC1_PTS(pts_val 3);
writel(val, base + TEGRA_USB_PORTSC1);
}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_pts);
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
+static void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
{
unsigned long val;
struct usb_hcd *hcd = bus_to_hcd(x-otg-host);
@@ -637,7 +636,6 @@ void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
val = ~TEGRA_USB_PORTSC1_PHCD;
writel(val, base + TEGRA_USB_PORTSC1);
}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_phcd);
static u64 tegra_ehci_dma_mask = DMA_BIT_MASK(32);
@@ -738,7 +736,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
tegra-phy = tegra_usb_phy_open(pdev-dev, instance, hcd-regs,
pdata-phy_config,
- TEGRA_USB_PHY_MODE_HOST);
+ TEGRA_USB_PHY_MODE_HOST,
+ tegra_ehci_set_pts,
+ tegra_ehci_set_phcd);
if (IS_ERR(tegra-phy)) {
dev_err(pdev-dev, Failed to open USB phy\n);
err = -ENXIO;
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 5487d38..17d8112 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -299,7 +299,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
val = ~USB_SUSP_SET;
writel(val, base + USB_SUSP_CTRL);
} else
- tegra_ehci_set_phcd(phy-u_phy, true);
+ phy-set_phcd(phy-u_phy, true);
if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) 0)
pr_err(%s: timeout waiting for phy to stabilize\n, __func__);
@@ -321,7 +321,7 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
val = ~USB_SUSP_CLR;
writel(val, base + USB_SUSP_CTRL);
} else
- tegra_ehci_set_phcd(phy-u_phy, false);
+ phy-set_phcd(phy-u_phy, false);
if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
USB_PHY_CLK_VALID))
@@ -444,7 +444,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
utmi_phy_clk_enable(phy);
if (!phy-is_legacy_phy)
- tegra_ehci_set_pts(phy-u_phy, 0);
+ phy-set_pts(phy-u_phy, 0);
return 0;
}
@@ -688,7 +688,10 @@ static int
[PATCH v2] usb: phy: don't mark usb_bind_phy as __init
It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from usbhs_init_phys(), which is intentionally not marked
__init:
WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
the function usbhs_init_phys() to the function .init.text:usb_bind_phy()
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
---
v2: rebased on linux-next
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f52c006..a9984c7 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -413,7 +413,7 @@ EXPORT_SYMBOL_GPL(usb_remove_phy);
*
* To be used by platform specific initialization code.
*/
-int __init usb_bind_phy(const char *dev_name, u8 index,
+int usb_bind_phy(const char *dev_name, u8 index,
const char *phy_dev_name)
{
struct usb_phy_bind *phy_bind;
--
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] usb: phy: don't mark usb_bind_phy as __init
On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote: It makes no sense for a symbol to be both exported and marked __init, because any users in modules would be calling this function after it gets discarded. Further, this patch revolves a section mismatch warning from usbhs_init_phys(), which is intentionally not marked __init: WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from the function usbhs_init_phys() to the function .init.text:usb_bind_phy() Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- v2: rebased on linux-next not needed, Greg already has a patch doing exactly this in usb-next. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: phy: don't mark usb_bind_phy as __init
On Tuesday 23 April 2013, Felipe Balbi wrote: On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote: It makes no sense for a symbol to be both exported and marked __init, because any users in modules would be calling this function after it gets discarded. Further, this patch revolves a section mismatch warning from usbhs_init_phys(), which is intentionally not marked __init: WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from the function usbhs_init_phys() to the function .init.text:usb_bind_phy() Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- v2: rebased on linux-next not needed, Greg already has a patch doing exactly this in usb-next. Right, I see it now. I had checked today's linux-next but not usb-next or any of the other trees for stuff that was just applied today. Arnd -- 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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On Mon, Apr 22, 2013 at 02:38:57PM -0400, Tony Camuso wrote: On 04/18/2013 05:12 PM, Sarah Sharp wrote: On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote: Sarah, This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. I can attach the S3_Suspend_message.log, if you like, but here are the last few lines. Is it hanging on suspend or on resume? Does S3 work on 3.9-rc7 with your original patch (without the new comp_timer_running variable)? Does S3 work on the effected system with vanilla 3.9-rc7? Sarah, Just to let you know I haven't forgotten you ... I have been sidetracked by hardware or firmware problems. I need to try a different system. All right, thanks for letting me know. Sarah Sharp -- 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 04/10] usb: musb: ux500: harden checks for platform data
Hello.
On 04/23/2013 07:03 PM, Lee Jones wrote:
In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/musb/ux500_dma.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index c75e07a..02b4a6e 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -287,7 +287,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
struct musb *musb = controller-private_data;
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *plat = dev-platform_data;
- struct ux500_musb_board_data *data = plat-board_data;
+ struct ux500_musb_board_data *data;
struct dma_channel *dma_channel = NULL;
u32 ch_num;
u8 dir;
@@ -297,14 +297,19 @@ static int ux500_dma_controller_start(struct
dma_controller *c)
[...]
/* Prepare the loop for RX channels */
channel_array = controller-rx_channel;
- param_array = data-dma_rx_param_array;
+ param_array = (data) ? data-dma_rx_param_array : NULL;
Why enclose a simple variable in parens?
for (dir = 0; dir 2; dir++) {
for (ch_num = 0;
@@ -337,7 +342,7 @@ static int ux500_dma_controller_start(struct dma_controller
*c)
/* Prepare the loop for TX channels */
channel_array = controller-tx_channel;
- param_array = data-dma_tx_param_array;
+ param_array = (data) ? data-dma_tx_param_array : NULL;
Again, why?
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 2/2] USB:ftdi_sio: enable two UART ports on ST Microconnect Lite
Hello.
On 04/23/2013 03:46 PM, Adrian Thomasset wrote:
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
Signed-off-by: Adrian Thomasset adrian.thomas...@st.com
---
drivers/usb/serial/ftdi_sio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 6be5853..6553920 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1794,20 +1794,24 @@ static int ftdi_8u2232c_probe(struct usb_serial *serial)
}
/*
- * First and second port on STMCLiteadaptors is reserved for JTAG interface
- * and the forth port for pio
+ * First two ports on JTAG adaptors using an FT4232 such as
STMicroelectronics's
+ * ST Micro Connect Lite are reserved for JTAG or other non-UART interfaces and
+ * can be accessed from userspace.
+ * The next two ports are enabled as UARTs by default, where port 2 is
+ * a conventional RS-232 UART.
*/
static int ftdi_stmclite_probe(struct usb_serial *serial)
{
struct usb_device *udev = serial-dev;
struct usb_interface *interface = serial-interface;
- if (interface == udev-actconfig-interface[2])
- return 0;
-
+ if (interface == udev-actconfig-interface[0] ||
+ interface == udev-actconfig-interface[1]) {
dev_info(udev-dev, Ignoring serial port reserved for JTAG\n);
-
return -ENODEV;
You should indent the code inside {}.
+ }
+
+ return 0;
}
/*
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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On 04/18/2013 05:12 PM, Sarah Sharp wrote: On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote: Sarah, This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. = snip = Is it hanging on suspend or on resume? 3.9.0-rc8 hangs in both suspend and resume on a hp z620 running F18, with or without the old and new patch. Meanwhile, 3.8.0 has the problem for which we originally devised this patch... ... BUT your revised patch fixes the problem in 3.8.0. If you like, I can bisect between 3.8.0 and 3.9.0-rc7 (where I first detected the new problem). Does S3 work on 3.9-rc7 with your original patch (without the new comp_timer_running variable)? Does S3 work on the effected system with vanilla 3.9-rc7? It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8. Neither the new patch nor the old patch helps. The full log with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING would be helpful. The logs are large, so I've posted them here. http://people.redhat.com/tcamuso/xhci-logs/ Logs were created with 3.9.0-rc8 commit 824282ca7d250bd7c301f221c3cd902ce906d731 Merge: f83b293 3b5e50e Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Apr 22 15:00:59 2013 -0700 -- 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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote: On 04/18/2013 05:12 PM, Sarah Sharp wrote: On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote: Sarah, This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. = snip = Is it hanging on suspend or on resume? 3.9.0-rc8 hangs in both suspend and resume on a hp z620 running F18, with or without the old and new patch. Meanwhile, 3.8.0 has the problem for which we originally devised this patch... ... BUT your revised patch fixes the problem in 3.8.0. If you like, I can bisect between 3.8.0 and 3.9.0-rc7 (where I first detected the new problem). That would be great! Does S3 work on 3.9-rc7 with your original patch (without the new comp_timer_running variable)? Does S3 work on the effected system with vanilla 3.9-rc7? It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8. Neither the new patch nor the old patch helps. It might be unrelated to USB then. Let's see what the bisect shows. The full log with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING would be helpful. The logs are large, so I've posted them here. http://people.redhat.com/tcamuso/xhci-logs/ Logs were created with 3.9.0-rc8 Ok, I'll take a look at those tomorrow. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: ehci: Only sleep for post-resume handover if devices use persist
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the companion controller can actually see it during its
own resume path.
However, if the device doesn't use persist, this is entirely
unnecessary. We might just as well ignore it and have the normal device
detection/reset/handoff code handle it asynchronously when it eventually
shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/ehci-hub.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 7d06e77..2507afb 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -29,6 +29,8 @@
/*-*/
#include linux/usb/otg.h
+#include ../core/usb.h
+
#definePORT_WAKE_BITS (PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E)
#ifdef CONFIG_PM
@@ -42,6 +44,18 @@ static int ehci_hub_control(
u16 wLength
);
+
+static int companion_persist(struct device *dev, void *unused)
+{
+ struct usb_device *udev = container_of(dev, struct usb_device, dev);
+
+ if (!is_usb_device(dev))
+ return 0; /* Filter out struct usb_interface on the same bus */
+
+ return !udev-maxchild udev-persist_enabled
+ udev-bus-root_hub-speed USB_SPEED_HIGH;
+}
+
/* After a power loss, ports that were owned by the companion must be
* reset so that the companion can still own them.
*/
@@ -56,6 +70,13 @@ static void ehci_handover_companion_ports(struct ehci_hcd
*ehci)
if (!ehci-owned_ports)
return;
+ /* Check if any USB 1.1 controller in the system uses a non-hub device
+* with persist enabled. If they don't, the device will get reenumerated
+* anyway and there is no need to slow resume down to wait for it.
+*/
+ if (!bus_for_each_dev(usb_bus_type, NULL, NULL, companion_persist))
+ return;
+
/* Make sure the ports are powered */
port = HCS_N_PORTS(ehci-hcs_params);
while (port--) {
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On 04/23/2013 10:07 PM, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
Sorry for the bug number. Please ignore this line.
What is that bug number? Where can it be referenced? If you are going
to put it in a public place (like a kernel changelog), it needs to be
publicly accessible.
On some HP platform, when usb driver inits the iLo Virtual USB Controller, there may be a
warning Controller not stopped yet!. It is because driver does not wait
enough time.
What happened to your line endings?
This patch adds more time waiting and retries.
Why not only do this for your device?
Signed-off-by: Li, Zhen-Hua zhen-h...@hp.com
---
drivers/usb/host/uhci-hcd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..514e9d7 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -277,6 +277,9 @@ static int global_suspend_mode_is_broken(struct uhci_hcd
*uhci)
uhci-global_suspend_mode_is_broken(uhci) : 0;
}
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
+
static void suspend_rh(struct uhci_hcd *uhci, enum uhci_rh_state new_state)
__releases(uhci-lock)
__acquires(uhci-lock)
@@ -284,6 +287,7 @@ __acquires(uhci-lock)
int auto_stop;
int int_enable, egsm_enable, wakeup_enable;
struct usb_device *rhdev = uhci_to_hcd(uhci)-self.root_hub;
+ u16 try, stopped;
auto_stop = (new_state == UHCI_RH_AUTO_STOPPED);
dev_dbg(rhdev-dev, %s%s\n, __func__,
@@ -355,7 +359,17 @@ __acquires(uhci-lock)
if (uhci-dead)
return;
}
- if (!(uhci_readw(uhci, USBSTS) USBSTS_HCH))
+
+ for (try = 0; try UHCI_SUSPENDRH_RETRY_MAX; try++) {
+ /*
+* Sometimes we may need to wait more time and try again.
+*/
Sometimes? Please be more specific. Also, a multi-line comment isn't
needed, make it one line please.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On Wed, Apr 24, 2013 at 07:55:18AM +0800, ZhenHua wrote: On 04/23/2013 10:07 PM, Greg KH wrote: On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote: From: Li, Zhen-Hua zhen-h...@hp.com This patch is trying to fix bug QXCR1001261767. Sorry for the bug number. Please ignore this line. I don't want to ignore it, I want it to point to something that I, and others, can reference in the future. Is there a url you can use for it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
I did not found any url you can visit. And we will file a bug on SLES bugzilla site if possible. I paste the bug discription here: When booting SLES 11 SP2 on our server , messages like the following are logged during boot: [ 254.087187] uhci_hcd :07:00.4: Controller not stopped yet! Thanks Zhen-Hua On 04/24/2013 09:57 AM, Greg KH wrote: On Wed, Apr 24, 2013 at 07:55:18AM +0800, ZhenHua wrote: On 04/23/2013 10:07 PM, Greg KH wrote: On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote: From: Li, Zhen-Hua zhen-h...@hp.com This patch is trying to fix bug QXCR1001261767. Sorry for the bug number. Please ignore this line. I don't want to ignore it, I want it to point to something that I, and others, can reference in the future. Is there a url you can use for it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
