Re: pl2303 driver regression after commit 61fa8d694b854
On Fri, Oct 25, 2013 at 03:43:03PM +0200, Frank Schäfer wrote: Am 25.10.2013 15:17, schrieb Mika Westerberg: On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote: Tried few other baudrates 115200 and they don't work either. Urgh... has this device ever been working at baud rates 115200 ? I have only used it as a serial console for a device and never tried baud rates higher than 115200 before today. Could you at least test kernel 3.11 ? Tried on v3.11 following rates: 115200, 230400, 460800, and they all work. -- 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 00/14] Add power management support for MXS PHY
On Tue, Oct 22, 2013 at 01:58:34PM +0800, Peter Chen wrote: Hi Felipe, Hi Felipe, would you please give any comments for this patchset? My another patchset chipidea's PM support also depends on this. Thanks. Peter The serial adds power management support for MXS PHY, it includes: - Add three common PHY API, .set_wakeup, .notify_suspend, notify_resume. - Related above API implementation at mxs phy driver - misc changes for mxs phy to support low power mode and wakeup. Changes for v2: - Add missing patches which introduce platform judgement code [1/14,2/14] - re-order the patch sequence, like doc-dts-source file, the reviewers can know the meaning of dt properties before review source - Add description of two IC problems exsiting at mxs PHY; change high speed to HS and non-high speed to FS/LS [5/14] - Change the dt property disconnect-line-without-vbus that the separator should be - not the _, meanwhile, related source code has changed. - Using one local variable to get the function return val to avoid long condition statement. [13/14] Peter Chen (14): usb: doc: phy-mxs: Add more compatible strings usb: phy-mxs: Add platform judgement code usb: phy-mxs: Add auto clock and power setting usb: doc: phy-mxs: update binding for adding anatop phandle ARM: dts: imx6: add anatop phandle for usbphy usb: phy-mxs: Add anatop regmap usb: phy: add notify suspend and resume callback usb: phy-mxs: Add implementation of nofity_suspend and notify_resume usb: phy-mxs: Enable IC fixes for mx6 SoC serial usb: doc: phy-mxs: update binding for adding disconnect line property ARM: dts: imx6: Add disconnect-line-without-vbus property for usbphy usb: phy: Add set_wakeup API usb: phy-mxs: Add implementation of set_wakeup usb: phy-mxs: Add system suspend/resume API Documentation/devicetree/bindings/usb/mxs-phy.txt | 12 +- arch/arm/boot/dts/imx6qdl.dtsi|3 + drivers/usb/phy/phy-mxs-usb.c | 328 - include/linux/usb/phy.h | 39 +++ 4 files changed, 367 insertions(+), 15 deletions(-) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] usb: ehci: add freescale imx28 special write register method
On Fri, Oct 25, 2013 at 02:02:19PM +0800, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Hi Greg, the last two DT patches are not needed at current time.
The first three are OK. Thanks.
Peter
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/host/ehci.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e8f41c5..535aa8b 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -225,6 +225,7 @@ struct ehci_hcd { /* one per controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
+ unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS (3 6)
@@ -728,6 +729,13 @@ static inline unsigned int ehci_readl(const struct
ehci_hcd *ehci,
#endif
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(u32 val32, volatile u32 *addr)
+{
+ __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
+}
+#endif
+
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
@@ -735,6 +743,11 @@ static inline void ehci_writel(const struct ehci_hcd
*ehci,
ehci_big_endian_mmio(ehci) ?
writel_be(val, regs) :
writel(val, regs);
+#elif defined(CONFIG_SOC_IMX28)
+ if (ehci-imx28_write_fix)
+ imx28_ehci_writel(val, regs);
+ else
+ writel(val, regs);
#else
writel(val, regs);
#endif
--
1.7.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
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LTE vodafone K5150 12d1 1f16 ; 12d1 1575 mbim IPV6/ipv4
Thomas Schäfer tschae...@t-online.de writes:
Hi Bjørn,
I tested your patch with the K5150 in mbim-mode
with ipv6 only - ok.
with Ipv4 only - ok.
Yes, I was pretty sure of that since I am able to test IPv4 myself and
the IPv6 solution is based on simply turning of the IFF_NOARP flag.
But I realized that we cannot do it like that after posting the patch.
What will happen if we encounter a device which doesn't respond to IPv6
ND? After all, that's the sane thing to do... Such devices will then
need a similary workaround for ND. And then it makes more sense to just
add that for the buggy devices instead, leaving ARP entirely out of this.
So I guess we have keep the IFF_NOARP flag, and implement whatever is
necessary for dealing with the unexpected IPv6 ND. I made a quick
attempt on that too. I won't have time to finish it any time soon, so I
am sending it to you now in an unfinished state, completely untested! I
haven't even built this yet...
The patch requires v3.12 because of the (ab)use of the vxlan IPv6
support added there. Not sure that was a good idea. We could just mock
up the NA packet and fire it off ourselves. It's not like it needs to
go through any sort of interface selection or neighbour lookup.
I have only one mbim-device, this 5150.
Let me know, if you need further tests.
If you want to test the attached patch, then be warned: This is likely
to crash a few times, until you have cleaned it up, *after* you have
made it build in the first place. And then you have to make it work ;-)
Note that this should be applied instead of the first patch, not on top
of it.
Bjørn
From dcdf1b769fb4305c92f99a4294660149f46f1a37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no
Date: Sun, 27 Oct 2013 12:09:56 +0100
Subject: [PATCH] cdc_mbim: handle IPv6 Neigbor Solicitations directly
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some buggy devices require IPv6 Neighbor Discovery support. This
is incompatible with the IFF_NOARP flag. But ARP is impossible
on MBIM, because the protocol only supports IPv4 or IPv6 packets.
Work around this by handling Neigbor Solicitations in the driver.
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/net/usb/cdc_mbim.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 25ba7ec..05f0a17 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -21,6 +21,8 @@
#include linux/usb/usbnet.h
#include linux/usb/cdc-wdm.h
#include linux/usb/cdc_ncm.h
+#include net/ipv6.h
+#include net/addrconf.h
/* driver specific data - must match cdc_ncm usage */
struct cdc_mbim_state {
@@ -184,6 +186,59 @@ error:
return NULL;
}
+/* Some devices are known to send Neigbor Solicitation messages and
+ * require Neigbor Advertisement replies. The IPv6 core will not
+ * respond since IFF_NOARP is set, so we must handle them ourselves.
+ */
+static bool do_neigh_solicit(struct usbnet *dev, u8 *buf, u16 tci)
+{
+ struct ipv6hdr *iph = (void *)buf;
+ struct nd_msg *msg = (void *)(iph + 1);
+ struct net_device *netdev;
+ struct inet6_dev *in6_dev;
+ bool is_router;
+
+ /* we'll only respond to requests from unicast addresses to
+ * our solicited node addresses
+ */
+ if (!ipv6_addr_is_solict_mult(iph-daddr) ||
+ !(ipv6_addr_type(iph-saddr) IPV6_ADDR_UNICAST))
+ return false;
+
+ /* need to send the NA on the VLAN dev, if any */
+ if (tci)
+ netdev = __vlan_find_dev_deep(dev-net, htons(ETH_P_8021Q), tci);
+ else
+ netdev = dev-net;
+ if (!netdev)
+ return false;
+
+ in6_dev = in6_dev_get(netdev);
+ if (!in6_dev)
+ return false;
+ is_router = !!in6_dev-cnf.forwarding;
+ in6_dev_put(in6_dev);
+
+ /* ipv6_stub != NULL if in6_dev_get returned an inet6_dev */
+ ipv6_stub-ndisc_send_na(netdev, NULL, iph-saddr, msg-target,
+ is_router, true, false, false);
+
+ /* handled - drop the original input datagram */
+ return true;
+}
+
+static bool is_neigh_solicit(u8 *buf, size_t len)
+{
+ struct ipv6hdr *iph = (void *)buf;
+ struct nd_msg *msg = (void *)(iph + 1);
+
+ return (len = sizeof(struct ipv6hdr) + sizeof(struct nd_msg)
+ iph-nexthdr == IPPROTO_ICMPV6
+ msg-icmph.icmp6_code == 0
+ msg-icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION);
+}
+
+
static struct sk_buff *cdc_mbim_process_dgram(struct usbnet *dev, u8 *buf, size_t len, u16 tci)
{
__be16 proto = htons(ETH_P_802_3);
@@ -198,6 +253,9 @@ static struct sk_buff *cdc_mbim_process_dgram(struct usbnet *dev, u8 *buf, size_
proto = htons(ETH_P_IP);
break;
case 0x60:
+ if (is_neigh_solicit(buf, len)
+ do_neigh_solicit(dev, buf, tci))
+goto err;
proto = htons(ETH_P_IPV6);
break;
default:
--
1.7.10.4
Re: [PATCH v3 3/5] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
Hi Shawn,
On Sun, Oct 27, 2013 at 05:25:36PM +0100, Marek Vasut wrote:
+static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+ { .compatible = fsl,imx28-usb, .data = imx28_usb_data},
+ { .compatible = fsl,imx27-usb, .data = imx27_usb_data},
Just a nit-pick, but the order here is wrong ;-)
Oh, no. Before of_match_device() gets improved to find the best match,
we have to sort the table from the most specific entry to the most
generic one.
Oh, thanks for explaining!
Best regards,
Marek Vasut
--
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: 2.6.35 problem with i.mx28 and cdc-acm
On 2013-10-26 19:44, Greg KH wrote: On Fri, Oct 25, 2013 at 05:14:58PM +0200, Robert Hodaszi wrote: Hi, I'm using a Telit modem with an i.mx28 processor. I'm currently running a 2.6.35 kernel on that (I know, it's pretty old, and on an other thread, I'm working on the v3 also). The modem is using the cdc-acm driver. That's really old, and we can't do anything to help you out here with that release at all, sorry. Please try 3.11 and see if that resolves your issue or not. good luck, greg k-h Ok.I thought. I just wanted to give it a try. Thanks! -- 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 2/5] usb: chipidea: add freescale imx28 special write register method
Dear Hector Palacios,
Dear Peter,
On 10/25/2013 08:02 AM, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen
peter.chen-kzfg59tc24xl57midrc...@public.gmane.org ---
Changes for v2:
- Rebase to latest usb-next tree
drivers/usb/chipidea/ci.h| 23 +++
drivers/usb/chipidea/core.c |2 ++
drivers/usb/chipidea/host.c |1 +
include/linux/usb/chipidea.h |1 +
4 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 1c94fc5..4eb61d0 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -173,6 +173,8 @@ struct ci_hdrc {
struct dentry *debugfs;
boolid_event;
boolb_sess_valid_event;
+ /* imx28 needs swp instruction for writing */
+ boolimx28_write_fix;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
ci_hw_regs reg, u32 mask)
return ioread32(ci-hw_bank.regmap[reg]) mask;
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
+{
+ __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
+}
+#endif
+
/**
* hw_write: writes to a hw register
* @reg: register index
@@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci, enum
ci_hw_regs reg,
data = (ioread32(ci-hw_bank.regmap[reg]) ~mask)
| (data mask);
+#ifdef CONFIG_SOC_IMX28
+ if (ci-imx28_write_fix)
+ imx28_ci_writel(data, ci-hw_bank.regmap[reg]);
+ else
+ iowrite32(data, ci-hw_bank.regmap[reg]);
+#else
iowrite32(data, ci-hw_bank.regmap[reg]);
+#endif
}
/**
@@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct ci_hdrc
*ci, enum ci_hw_regs reg,
{
u32 val = ioread32(ci-hw_bank.regmap[reg]) mask;
+#ifdef CONFIG_SOC_IMX28
+ if (ci-imx28_write_fix)
+ imx28_ci_writel(val, ci-hw_bank.regmap[reg]);
+ else
+ iowrite32(val, ci-hw_bank.regmap[reg]);
+#else
iowrite32(val, ci-hw_bank.regmap[reg]);
+#endif
return val;
}
Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
The check is done on the new flag ci-imx28_write_fix which exists for all
platforms, isn't it?.
The SWP instruction is specific to ARM, so you'd need to stub-out the
imx28_ci_writel() with ifdef then.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] usb: musb_dsps: support for suspend and resume
On 10/18/2013 11:59 AM, Sebastian Andrzej Siewior wrote: On 10/18/2013 11:39 AM, Daniel Mack wrote: v3 of my musb_dsps suspend patches. With these patches applied, I can successfully bring an AM335x board to suspend with a USB media connected, and access it again after resume. This works for both PIO mode and CPPI41 enabled configurations, together with Sebasitian's and my cppi41 patches recently posted. Felipe, this work was rebased and now applies cleanly on top of your current 'next' branch. IOW, on top of usb: musb: cppi41: allow to defer probing if DMA isn't yet available. Sounds good. Felipe, do you think that series is good to be taken for 3.13? Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case
On 10/18/2013 11:03 AM, Daniel Mack wrote: Hi Sebastian, On 10/17/2013 04:36 PM, Sebastian Andrzej Siewior wrote: On 10/17/2013 04:23 PM, Daniel Mack wrote: Daniel, could please look if this solves your suspend / resume warnings? Looking very good :) dma: cppi41: add support for suspend and resume dma: cppi41: restore more registers dma: cppi41: use cppi41_pop_desc() where possible dma: cppi41: redo descriptor collection in abort case dma: cppi41: return code 0 of pm_runtime_get_sync() is not an error Tested with those patches applied, and did dozens of sleep/resume cycley - no problem seen. Thanks a bunch again. Vinod, you can add my Tested-by: Daniel Mack zon...@gmail.com if you want. Vinod, in case you're ok with these changes, it would be good to have them for 3.13. Sebastian recently resent them all again (3 from me, 2 from him). Thanks, Daniel -- 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: 2.6.35 problem with i.mx28 and cdc-acm
On 2013-10-28 10:30, Robert Hodaszi wrote: On 2013-10-26 19:44, Greg KH wrote: On Fri, Oct 25, 2013 at 05:14:58PM +0200, Robert Hodaszi wrote: Hi, I'm using a Telit modem with an i.mx28 processor. I'm currently running a 2.6.35 kernel on that (I know, it's pretty old, and on an other thread, I'm working on the v3 also). The modem is using the cdc-acm driver. That's really old, and we can't do anything to help you out here with that release at all, sorry. Please try 3.11 and see if that resolves your issue or not. good luck, greg k-h Ok.I thought. I just wanted to give it a try. Thanks! -- 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 (Sorry, I'm spamming here again, but I was wrong! I messed the two modems, when I wrote the email previously. The cdc-acm driver is working. I have problems with the option + wwan driver... I just wanted to correct myself.) -- 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 5/5] net/usb/r8152: code adjust
-Remove rtl8152_get_stats()
-Fix the wrong name
-Something else
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 46 +-
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 90bc105..d252ff6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -218,7 +218,7 @@
#define POWER_CUT 0x0100
/* USB_PM_CTRL_STATUS */
-#define RWSUME_INDICATE0x0001
+#define RESUME_INDICATE0x0001
/* USB_USB_CTRL */
#define RX_AGG_DISABLE 0x0010
@@ -376,7 +376,8 @@ struct r8152 {
enum rtl_version {
RTL_VER_UNKNOWN = 0,
RTL_VER_01,
- RTL_VER_02
+ RTL_VER_02,
+ RTL_VER_INVALLID = -1
};
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
@@ -422,14 +423,15 @@ int set_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
value, index, tmp, size, 500);
kfree(tmp);
+
return ret;
}
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
void *data, u16 type)
{
- u16 limit = 64;
- int ret = 0;
+ u16 limit = 64;
+ int ret = 0;
if (test_bit(RTL8152_UNPLUG, tp-flags))
return -ENODEV;
@@ -468,9 +470,9 @@ static int generic_ocp_read(struct r8152 *tp, u16 index,
u16 size,
static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
u16 size, void *data, u16 type)
{
- int ret;
- u16 byteen_start, byteen_end, byen;
- u16 limit = 512;
+ int ret;
+ u16 byteen_start, byteen_end, byen;
+ u16 limit = 512;
if (test_bit(RTL8152_UNPLUG, tp-flags))
return -ENODEV;
@@ -763,11 +765,6 @@ static int rtl8152_set_mac_address(struct net_device
*netdev, void *p)
return 0;
}
-static struct net_device_stats *rtl8152_get_stats(struct net_device *dev)
-{
- return dev-stats;
-}
-
static void read_bulk_callback(struct urb *urb)
{
struct net_device *netdev;
@@ -836,6 +833,7 @@ static void read_bulk_callback(struct urb *urb)
static void write_bulk_callback(struct urb *urb)
{
struct net_device_stats *stats;
+ struct net_device *netdev;
unsigned long flags;
struct tx_agg *agg;
struct r8152 *tp;
@@ -849,7 +847,8 @@ static void write_bulk_callback(struct urb *urb)
if (!tp)
return;
- stats = rtl8152_get_stats(tp-netdev);
+ netdev = tp-netdev;
+ stats = netdev-stats;
if (status) {
pr_warn_ratelimited(Tx status %d\n, status);
stats-tx_errors += agg-skb_num;
@@ -862,7 +861,7 @@ static void write_bulk_callback(struct urb *urb)
list_add_tail(agg-list, tp-tx_free);
spin_unlock_irqrestore(tp-tx_lock, flags);
- if (!netif_carrier_ok(tp-netdev))
+ if (!netif_carrier_ok(netdev))
return;
if (!test_bit(WORK_ENABLE, tp-flags))
@@ -1214,7 +1213,7 @@ static void rx_bottom(struct r8152 *tp)
while (urb-actual_length len_used) {
struct net_device *netdev = tp-netdev;
- struct net_device_stats *stats;
+ struct net_device_stats *stats = netdev-stats;
unsigned pkt_len;
struct sk_buff *skb;
@@ -1226,8 +1225,6 @@ static void rx_bottom(struct r8152 *tp)
if (urb-actual_length len_used)
break;
- stats = rtl8152_get_stats(netdev);
-
pkt_len -= 4; /* CRC */
rx_data += sizeof(struct rx_desc);
@@ -1281,7 +1278,7 @@ static void tx_bottom(struct r8152 *tp)
unsigned long flags;
netdev = tp-netdev;
- stats = rtl8152_get_stats(netdev);
+ stats = netdev-stats;
if (res == -ENODEV) {
netif_device_detach(netdev);
@@ -1476,7 +1473,7 @@ static int rtl8152_enable(struct r8152 *tp)
static void rtl8152_disable(struct r8152 *tp)
{
- struct net_device_stats *stats = rtl8152_get_stats(tp-netdev);
+ struct net_device_stats *stats = tp-netdev-stats;
struct sk_buff *skb;
u32 ocp_data;
int i;
@@ -1600,8 +1597,8 @@ static void r8152b_exit_oob(struct r8152 *tp)
static void r8152b_enter_oob(struct r8152 *tp)
{
- u32 ocp_data;
- int i;
+ u32 ocp_data;
+ int i;
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data = ~NOW_IS_OOB;
@@ -1722,7 +1719,6 @@ static int rtl8152_set_speed(struct r8152 *tp, u8
autoneg, u16 speed, u8 duplex)
[PATCH 4/5] net/usb/r8152: fix incorrect type in assignment
Correct some declaration.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a711025..90bc105 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -309,22 +309,22 @@ enum rtl8152_flags {
#define MCU_TYPE_USB 0x
struct rx_desc {
- u32 opts1;
+ __le32 opts1;
#define RX_LEN_MASK0x7fff
- u32 opts2;
- u32 opts3;
- u32 opts4;
- u32 opts5;
- u32 opts6;
+ __le32 opts2;
+ __le32 opts3;
+ __le32 opts4;
+ __le32 opts5;
+ __le32 opts6;
};
struct tx_desc {
- u32 opts1;
+ __le32 opts1;
#define TX_FS (1 31) /* First segment of a packet */
#define TX_LS (1 30) /* Final segment of a packet */
#define TX_LEN_MASK0x3
- u32 opts2;
+ __le32 opts2;
#define UDP_CS (1 31) /* Calculate UDP/IP checksum */
#define TCP_CS (1 30) /* Calculate TCP/IP checksum */
#define IPV4_CS(1 29) /* Calculate IPv4 checksum */
@@ -878,7 +878,7 @@ static void write_bulk_callback(struct urb *urb)
static void intr_callback(struct urb *urb)
{
struct r8152 *tp;
- __u16 *d;
+ __le16 *d;
int status = urb-status;
int res;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] net/usb/r8152: modify the tx flow
Let rtl8152_start_xmit() to queue packet only, and tx_bottom() would
send all of the packets. This simplify the code and make sure all the
packet would be sent by the original order.
Support stopping and waking tx queue. The maximum tx queue length
is 60.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 52 ++---
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 815d890..a711025 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -276,6 +276,8 @@ enum rtl_register_content {
#define INTR_LINK 0x0004
+#define TX_QLEN60
+
#define RTL8152_REQT_READ 0xc0
#define RTL8152_REQT_WRITE 0x40
#define RTL8152_REQ_GET_REGS 0x05
@@ -1174,6 +1176,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
}
+ if (netif_queue_stopped(tp-netdev))
+ netif_wake_queue(tp-netdev);
+
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
agg-head, (int)(tx_data - (u8 *)agg-head),
(usb_complete_t)write_bulk_callback, agg);
@@ -1389,53 +1394,16 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- struct net_device_stats *stats = rtl8152_get_stats(netdev);
- unsigned long flags;
- struct tx_agg *agg = NULL;
- struct tx_desc *tx_desc;
- unsigned int len;
- u8 *tx_data;
- int res;
skb_tx_timestamp(skb);
- /* If tx_queue is not empty, it means at least one previous packt */
- /* is waiting for sending. Don't send current one before it. */
- if (skb_queue_empty(tp-tx_queue))
- agg = r8152_get_tx_agg(tp);
-
- if (!agg) {
- skb_queue_tail(tp-tx_queue, skb);
- return NETDEV_TX_OK;
- }
+ skb_queue_tail(tp-tx_queue, skb);
- tx_desc = (struct tx_desc *)agg-head;
- tx_data = agg-head + sizeof(*tx_desc);
- agg-skb_num = agg-skb_len = 0;
+ if (skb_queue_len(tp-tx_queue) TX_QLEN)
+ netif_stop_queue(netdev);
- len = skb-len;
- r8152_tx_csum(tp, tx_desc, skb);
- memcpy(tx_data, skb-data, len);
- dev_kfree_skb_any(skb);
- agg-skb_num++;
- agg-skb_len += len;
- usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
- agg-head, len + sizeof(*tx_desc),
- (usb_complete_t)write_bulk_callback, agg);
- res = usb_submit_urb(agg-urb, GFP_ATOMIC);
- if (res) {
- /* Can we get/handle EPIPE here? */
- if (res == -ENODEV) {
- netif_device_detach(tp-netdev);
- } else {
- netif_warn(tp, tx_err, netdev,
- failed tx_urb %d\n, res);
- stats-tx_dropped++;
- spin_lock_irqsave(tp-tx_lock, flags);
- list_add_tail(agg-list, tp-tx_free);
- spin_unlock_irqrestore(tp-tx_lock, flags);
- }
- }
+ if (!list_empty(tp-tx_free))
+ tasklet_schedule(tp-tl);
return NETDEV_TX_OK;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] net/usb/r8152: make sure the tx checksum setting is correct
Clear the checksum setting before checking the necessary of hardware
checksum.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5dbfe50..815d890 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1094,6 +1094,7 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
struct sk_buff *skb)
memset(desc, 0, sizeof(*desc));
desc-opts1 = cpu_to_le32((skb-len TX_LEN_MASK) | TX_FS | TX_LS);
+ desc-opts2 = 0;
if (skb-ip_summed == CHECKSUM_PARTIAL) {
__be16 protocol;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] net/usb/r8152: fix tx/rx memory overflow
The tx/rx would access the memory which is out of the desired range.
Modify the method of checking the end of the memory to avoid it.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3fce41..5dbfe50 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
#include linux/ipv6.h
/* Version Information */
-#define DRIVER_VERSION v1.01.0 (2013/08/12)
+#define DRIVER_VERSION v1.02.0 (2013/10/28)
#define DRIVER_AUTHOR Realtek linux nic maintainers nic_s...@realtek.com
#define DRIVER_DESC Realtek RTL8152 Based USB 2.0 Ethernet Adapters
#define MODULENAME r8152
@@ -1136,14 +1136,14 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
struct sk_buff *skb)
static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
{
- u32 remain;
+ int remain;
u8 *tx_data;
tx_data = agg-head;
agg-skb_num = agg-skb_len = 0;
- remain = rx_buf_sz - sizeof(struct tx_desc);
+ remain = rx_buf_sz;
- while (remain = ETH_ZLEN) {
+ while (remain = ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
struct sk_buff *skb;
unsigned int len;
@@ -1152,12 +1152,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
if (!skb)
break;
+ remain -= sizeof(*tx_desc);
len = skb-len;
if (remain len) {
skb_queue_head(tp-tx_queue, skb);
break;
}
+ tx_data = tx_agg_align(tx_data);
tx_desc = (struct tx_desc *)tx_data;
tx_data += sizeof(*tx_desc);
@@ -1167,9 +1169,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
agg-skb_len += len;
dev_kfree_skb_any(skb);
- tx_data = tx_agg_align(tx_data + len);
- remain = rx_buf_sz - sizeof(*tx_desc) -
-(u32)((void *)tx_data - agg-head);
+ tx_data += len;
+ remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
}
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
@@ -1188,7 +1189,6 @@ static void rx_bottom(struct r8152 *tp)
list_for_each_safe(cursor, next, tp-rx_done) {
struct rx_desc *rx_desc;
struct rx_agg *agg;
- unsigned pkt_len;
int len_used = 0;
struct urb *urb;
u8 *rx_data;
@@ -1204,17 +1204,22 @@ static void rx_bottom(struct r8152 *tp)
rx_desc = agg-head;
rx_data = agg-head;
- pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
- while (urb-actual_length = len_used) {
+ while (urb-actual_length len_used) {
struct net_device *netdev = tp-netdev;
struct net_device_stats *stats;
+ unsigned pkt_len;
struct sk_buff *skb;
+ pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
if (pkt_len ETH_ZLEN)
break;
+ len_used += pkt_len;
+ if (urb-actual_length len_used)
+ break;
+
stats = rtl8152_get_stats(netdev);
pkt_len -= 4; /* CRC */
@@ -1234,9 +1239,8 @@ static void rx_bottom(struct r8152 *tp)
rx_data = rx_agg_align(rx_data + pkt_len + 4);
rx_desc = (struct rx_desc *)rx_data;
- pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
len_used = (int)(rx_data - (u8 *)agg-head);
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
}
submit:
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] r8152 bug fixes
These could fix some driver issues. Hayes Wang (5): net/usb/r8152: fix tx/rx memory overflow net/usb/r8152: make sure the tx checksum setting is correct net/usb/r8152: modify the tx flow net/usb/r8152: fix incorrect type in assignment net/usb/r8152: code adjust drivers/net/usb/r8152.c | 145 +++- 1 file changed, 57 insertions(+), 88 deletions(-) -- 1.8.3.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 v2 1/5] phy: Add new Exynos USB PHY driver
Hi Kishon,
Thank you for your review! I will answer your comments below.
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Friday, October 25, 2013 5:40 PM
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add a new driver for the Exynos USB PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-usbphy.txt | 51 +++
drivers/phy/Kconfig| 21 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos-usb.c | 245
++
drivers/phy/phy-exynos-usb.h | 94 ++
drivers/phy/phy-exynos4210-usb.c | 295
+
drivers/phy/phy-exynos4212-usb.c | 343
7 files changed, 1052 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/samsung-usbphy.txt
create mode 100644 drivers/phy/phy-exynos-usb.c create mode 100644
drivers/phy/phy-exynos-usb.h create mode 100644
drivers/phy/phy-exynos4210-usb.c create mode 100644
drivers/phy/phy-exynos4212-usb.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
new file mode 100644
index 000..f112b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
@@ -0,0 +1,51 @@
+Samsung S5P/EXYNOS SoC series USB PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - samsung,exynos4210-usbphy
+ - samsung,exynos4212-usbphy
+- reg : a list of registers used by phy driver
+ - first and obligatory is the location of phy modules registers
+ - second and also required is the location of isolation registers
+ (isolation registers control the physical connection between
the in
+ SoC modules and outside of the SoC, this also can be called
enable
+ control in the documentation of the SoC)
+ - third is the location of the mode switch register, this only
applies
+ to SoCs that have such a feature; mode switching enables to
have
+ both host and device used the same SoC pins and is commonly
used
+ when OTG is supported
+- #phy-cells : from the generic phy bindings, must be 1;
+
+The second cell in the PHY specifier identifies the PHY its meaning
+is SoC dependent. For the currently supported SoCs (Exynos 4210 and
+Exynos 4212) it is as follows:
+ 0 - USB device,
+ 1 - USB host,
+ 2 - HSIC0,
+ 3 - HSIC1,
HSIC is supposedly to be transceiver less no? You have to program
something in the digital side?
You have a single IP that have all these functionalities?
There is a single USB PHY controller for all the above functionalities
(i.e. host, device, hsic 0 and 1).
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4212-usbphy;
+ reg = 0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4;
+ ranges;
+ #address-cells = 1;
+ #size-cells = 1;
The above 3 properties aren't documented? Are they needed here?
My bad. I was working on two branches and corrected it in only one
of them.
+ clocks = clock 305, clock 2, clock 2, clock 2,
+ clock 2;
+ clock-names = phy, device, host, hsic0, hsic1;
+ status = okay;
+ #phy-cells = 1;
+};
+
+Then the PHY can be used in other nodes such as:
+
+ehci@1258 {
+ status = okay;
+ phys = exynos_usbphy 2;
+ phy-names = hsic0;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
349bef2..2f7ac0a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,25 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of
this
framework should select this config.
+config PHY_EXYNOS_USB
+ tristate Samsung USB PHY driver (using the Generic PHY
Framework)
Mentioning *Generic PHY Framework* is not necessary.
*select GENERIC_PHY* here
This was added to distinguish this driver from the ols USB PHY driver.
I agree that in the final version it should be removed. I understand that
the correct way to do this is by removing the old driver when the new gets
merged. Yes?
+ help
+ Enable this to support Samsung USB phy helper driver for
Samsung SoCs.
+ This driver provides common interface to interact, for Samsung
+ USB 2.0 PHY driver.
If it's going to be used only for usb2, name it PHY_EXYNOS_USB2.
I agree.
+
+config PHY_EXYNOS4210_USB
+ bool Support for Exynos 4210
+ depends on
RE: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Hi Kumar Gala,
From: Kumar Gala [mailto:ga...@codeaurora.org]
Sent: Friday, October 25, 2013 11:36 PM
On Oct 25, 2013, at 9:15 AM, Kamil Debski wrote:
Add a new driver for the Exynos USB PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-usbphy.txt | 51 +++
drivers/phy/Kconfig| 21 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos-usb.c | 245
++
drivers/phy/phy-exynos-usb.h | 94 ++
drivers/phy/phy-exynos4210-usb.c | 295
+
drivers/phy/phy-exynos4212-usb.c | 343
7 files changed, 1052 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/samsung-usbphy.txt
create mode 100644 drivers/phy/phy-exynos-usb.c create mode 100644
drivers/phy/phy-exynos-usb.h create mode 100644
drivers/phy/phy-exynos4210-usb.c create mode 100644
drivers/phy/phy-exynos4212-usb.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
new file mode 100644
index 000..f112b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
@@ -0,0 +1,51 @@
+Samsung S5P/EXYNOS SoC series USB PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - samsung,exynos4210-usbphy
+ - samsung,exynos4212-usbphy
+- reg : a list of registers used by phy driver
+ - first and obligatory is the location of phy modules registers
+ - second and also required is the location of isolation registers
+ (isolation registers control the physical connection between
the in
+ SoC modules and outside of the SoC, this also can be called
enable
+ control in the documentation of the SoC)
+ - third is the location of the mode switch register, this only
applies
+ to SoCs that have such a feature; mode switching enables to
have
+ both host and device used the same SoC pins and is commonly
used
+ when OTG is supported
+- #phy-cells : from the generic phy bindings, must be 1;
Please add if clock clock-names are required properties.
Ok, thanks for pointing this out.
+
+The second cell in the PHY specifier identifies the PHY its meaning
+is SoC dependent. For the currently supported SoCs (Exynos 4210 and
+Exynos 4212) it is as follows:
Can we say instead of 'its meaning is SoC dependent...' something like
'its meaning is compatible dependent?
Ok, this sounds better in deed.
+ 0 - USB device,
+ 1 - USB host,
+ 2 - HSIC0,
+ 3 - HSIC1,
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4212-usbphy;
+ reg = 0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4;
+ ranges;
+ #address-cells = 1;
+ #size-cells = 1;
Why do you have ranges, and #address-cells #size-cells here?
As, I mentioned in my reply to Kishon. I worked on two branches
and I forgot to remove this in the one used to generate patches.
+ clocks = clock 305, clock 2, clock 2, clock 2,
+ clock 2;
+ clock-names = phy, device, host, hsic0, hsic1;
+ status = okay;
+ #phy-cells = 1;
+};
+
+Then the PHY can be used in other nodes such as:
+
+ehci@1258 {
+ status = okay;
+ phys = exynos_usbphy 2;
+ phy-names = hsic0;
+};
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
--
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: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi Kishon,
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Friday, October 25, 2013 5:44 PM
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add support for Exynos 5250. This is work-in-progress commit. Not for
merging.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/phy/Kconfig |7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-usb.c | 10 +
drivers/phy/phy-exynos-usb.h |1 +
drivers/phy/phy-exynos5250-usb.c | 411
++
5 files changed, 430 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
2f7ac0a..0f598d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
help
Enable USB PHY support for Exynos 4212
+config PHY_EXYNOS5250_USB
+ bool Support for Exynos 5250
+ depends on PHY_EXYNOS_USB
This should be a separate driver. Not necessary to use PHY_EXYNOS_USB.
+ depends on SOC_EXYNOS5250
+ help
+ Enable USB PHY support for Exynos 5250
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
ca3dc82..0dff0dd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
diff --git a/drivers/phy/phy-exynos-usb.c
b/drivers/phy/phy-exynos-usb.c index d4a26df..172b774 100644
--- a/drivers/phy/phy-exynos-usb.c
+++ b/drivers/phy/phy-exynos-usb.c
@@ -212,6 +212,10 @@ extern const struct uphy_config
exynos4210_uphy_config; extern const struct uphy_config
exynos4212_uphy_config; #endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+extern const struct uphy_config exynos5250_uphy_config; #endif
+
static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
CONFIG_PHY_EXYNOS4210_USB
{
@@ -225,6 +229,12 @@ static const struct of_device_id
exynos_uphy_of_match[] = {
.data = exynos4212_uphy_config,
},
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+ {
+ .compatible = samsung,exynos5250-usbphy,
+ .data = exynos5250_uphy_config,
+ },
+#endif
{ },
};
diff --git a/drivers/phy/phy-exynos-usb.h
b/drivers/phy/phy-exynos-usb.h index f45cb3c..a9febfa 100644
--- a/drivers/phy/phy-exynos-usb.h
+++ b/drivers/phy/phy-exynos-usb.h
@@ -42,6 +42,7 @@ enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
TYPE_EXYNOS4212,
+ TYPE_EXYNOS5250,
No cpu types here.
};
enum uphy_state {
diff --git a/drivers/phy/phy-exynos5250-usb.c
b/drivers/phy/phy-exynos5250-usb.c
new file mode 100644
index 000..156093b
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-usb.c
@@ -0,0 +1,411 @@
+/*
+ * Samsung S5P/EXYNOS SoC series USB PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@samsung.com
+ *
+ * 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.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include phy-exynos-usb.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS_5250_REFCLKSEL_CRYSTAL 0x0
+#define EXYNOS_5250_REFCLKSEL_XO 0x1
+#define EXYNOS_5250_REFCLKSEL_CLKCORE 0x2
+
+#define EXYNOS_5250_FSEL_9MHZ6 0x0
+#define EXYNOS_5250_FSEL_10MHZ 0x1
+#define EXYNOS_5250_FSEL_12MHZ 0x2
+#define EXYNOS_5250_FSEL_19MHZ20x3
+#define EXYNOS_5250_FSEL_20MHZ 0x4
+#define EXYNOS_5250_FSEL_24MHZ 0x5
+#define EXYNOS_5250_FSEL_50MHZ 0x7
+
+/* Normal host */
+#define EXYNOS_5250_HOSTPHYCTRL0 0x0
+
+#define EXYNOS_5250_HOSTPHYCTRL0_PHYSWRSTALL (0x1 31)
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT 19
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_MASK\
+ (0x3 EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT16
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_MASK \
+ (0x7 EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_TESTBURNIN(0x1 11)
+#define
RE: [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Jingoo, From: Jingoo Han [mailto:jg1@samsung.com] Sent: Saturday, October 26, 2013 3:27 AM On Friday, October 25, 2013 11:15 PM, Kamil Debski wrote: Change the phy provider used from the old usb phy specific to a new one using the generic phy framework. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/host/ehci-s5p.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) Hi Kamil Debski, It looks good. :-) Thank you. However, could you re-basing against Greg's 'usb-next' branch? Now, the file name of 'ehci-s5p.c' is renamed to 'ehci-exynos.c'. Also, 'Generic PHY Framework' was already merged to Greg's 'usb-next' branch. Thanks for pointing out this. Thank you. Best regards, Jingoo Han Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Vivek,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Saturday, October 26, 2013 11:41 AM
Hi Kamil,
On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski k.deb...@samsung.com
wrote:
Change the phy provider used from the old usb phy specific to a new
one using the generic phy framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/host/ehci-s5p.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-
s5p.c
index 7cc26e6..76606ff 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
@@ -45,7 +46,7 @@ static struct hc_driver __read_mostly
s5p_ehci_hc_driver;
struct s5p_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
+ struct phy *phy;
struct usb_otg *otg;
struct s5p_ehci_platdata *pdata; }; @@ -77,10 +78,11 @@
static int s5p_ehci_probe(struct platform_device *pdev) {
struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
+ struct phy *phy;
just a nit here:
Lets keep the pointer to 'phy' and 'phy_name' together ?
and move this above phy_name ?
Thanks for pointing this out.
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
- struct usb_phy *phy;
+ const char *phy_name;
int irq;
int err;
@@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct
platform_device *pdev)
return -ENOMEM;
}
s5p_ehci = to_s5p_ehci(hcd);
-
+ phy_name = of_get_property(pdev-dev.of_node, phy-names,
NULL);
+ phy = devm_phy_get(pdev-dev, phy_name);
Below check for exynos5440 was supposed to skip any request phy.
So shouldn't we place above two assignments to the original place where
devm_usb_get_phy() was called ?
May be i am not getting you intention of changing the place.
Hm... You are right - if we want to leave this check and skip phy request
for
5450 then I should leave the order as it was. And if we want to use the new
phy driver for 5450 then the check to skip phy requesting should be simply
removed.
if (of_device_is_compatible(pdev-dev.of_node,
samsung,exynos5440-ehci)) {
s5p_ehci-pdata = empty_platdata;
goto skip_phy;
}
- phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
@@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device
*pdev)
}
} else {
s5p_ehci-phy = phy;
- s5p_ehci-otg = phy-otg;
}
skip_phy:
@@ -166,7 +167,7 @@ skip_phy:
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
Lets remove this line and similar calls to 'set_host()' in the driver,
since we don't have s5p_ehci-otg anymore after the same is removed
above.
Anyways this was helping the old phy-samsung-usb2 driver, and not
needed now.
Ok, I will.
if (s5p_ehci-phy)
- usb_phy_init(s5p_ehci-phy);
+ phy_power_on(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_init)
s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
@@ -188,7 +189,7 @@ skip_phy:
fail_add_hcd:
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
fail_io:
@@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device
*pdev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -244,7 +245,7 @@ static int s5p_ehci_suspend(struct device *dev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -265,7 +266,7 @@ static int s5p_ehci_resume(struct device *dev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if
Re: [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Kamil,
On Mon, Oct 28, 2013 at 7:23 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi Vivek,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Saturday, October 26, 2013 11:41 AM
Hi Kamil,
On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski k.deb...@samsung.com
wrote:
Change the phy provider used from the old usb phy specific to a new
one using the generic phy framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Similar change for ohci-exynos too ?
drivers/usb/host/ehci-s5p.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-
s5p.c
index 7cc26e6..76606ff 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
@@ -45,7 +46,7 @@ static struct hc_driver __read_mostly
s5p_ehci_hc_driver;
struct s5p_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
+ struct phy *phy;
struct usb_otg *otg;
This can also be removed.
struct s5p_ehci_platdata *pdata; }; @@ -77,10 +78,11 @@
static int s5p_ehci_probe(struct platform_device *pdev) {
struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
+ struct phy *phy;
just a nit here:
Lets keep the pointer to 'phy' and 'phy_name' together ?
and move this above phy_name ?
Thanks for pointing this out.
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
- struct usb_phy *phy;
+ const char *phy_name;
int irq;
int err;
@@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct
platform_device *pdev)
return -ENOMEM;
}
s5p_ehci = to_s5p_ehci(hcd);
-
+ phy_name = of_get_property(pdev-dev.of_node, phy-names,
NULL);
Sorry one more doubt here :-)
Now that we have HOST, DEVICE, HSIC0, HSIC1 as different PHYs,
and i think EHCI will be the candidate to request HSIC phy too (once
we have HSIC phy
initialization code available for each SoC);
shouldn't we be using of_count_phandle_with_args() to get HOST, and HSIC phys
and then request multiple phys here ?
+ phy = devm_phy_get(pdev-dev, phy_name);
Below check for exynos5440 was supposed to skip any request phy.
So shouldn't we place above two assignments to the original place where
devm_usb_get_phy() was called ?
May be i am not getting you intention of changing the place.
Hm... You are right - if we want to leave this check and skip phy request
for
5450 then I should leave the order as it was. And if we want to use the new
phy driver for 5450 then the check to skip phy requesting should be simply
removed.
if (of_device_is_compatible(pdev-dev.of_node,
samsung,exynos5440-ehci)) {
s5p_ehci-pdata = empty_platdata;
goto skip_phy;
}
- phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
@@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device
*pdev)
}
} else {
s5p_ehci-phy = phy;
- s5p_ehci-otg = phy-otg;
}
skip_phy:
@@ -166,7 +167,7 @@ skip_phy:
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
Lets remove this line and similar calls to 'set_host()' in the driver,
since we don't have s5p_ehci-otg anymore after the same is removed
above.
Anyways this was helping the old phy-samsung-usb2 driver, and not
needed now.
Ok, I will.
if (s5p_ehci-phy)
- usb_phy_init(s5p_ehci-phy);
+ phy_power_on(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_init)
s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
@@ -188,7 +189,7 @@ skip_phy:
fail_add_hcd:
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
fail_io:
@@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device
*pdev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -244,7 +245,7 @@ static int
Re: Controller's wakeup setting at usb_add_hcd
On Mon, 28 Oct 2013, Peter Chen wrote: Just like you said: The physical wakeup setting is controlled by both the controller driver and the platform driver. But currently, it is controlled (or affected) by hcd layer. It is _initialized_ by the HCD layer. The platform driver can always override this. It's easy; just call device_set_wakeup_enable(dev, 0) after usb_add_hcd(). In fact, your platform driver probably should remember the current wakeup setting when the HC is removed. The next time it is added you should change the wakeup setting to the remembered value. That way, if the user adjusts the setting and switches between host and device mode, the desired setting will persist. Yes, we can do that. But if there is no initializing for wakeup setting at usb_add_hcd, the controller driver needs to do nothing, No matter HC is removed or peripheral switches to HC, the wakeup setting will be totally decided by user, and the default setting is 0. Okay. I'll make a deal with you: You can remove the single device_wakeup_enable() call from usb_add_hcd() provided, in the same patch, you add device_wakeup_enable() calls to every HCD (except yours, obviously). 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: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi Kishon,
On Fri, Oct 25, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add support for Exynos 5250. This is work-in-progress commit. Not
for merging.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/phy/Kconfig |7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-usb.c | 10 +
drivers/phy/phy-exynos-usb.h |1 +
drivers/phy/phy-exynos5250-usb.c | 411
++
5 files changed, 430 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2f7ac0a..0f598d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
help
Enable USB PHY support for Exynos 4212
+config PHY_EXYNOS5250_USB
+ bool Support for Exynos 5250
+ depends on PHY_EXYNOS_USB
This should be a separate driver. Not necessary to use PHY_EXYNOS_USB.
+ depends on SOC_EXYNOS5250
+ help
+ Enable USB PHY support for Exynos 5250
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ca3dc82..0dff0dd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
diff --git a/drivers/phy/phy-exynos-usb.c b/drivers/phy/phy-exynos-usb.c
index d4a26df..172b774 100644
--- a/drivers/phy/phy-exynos-usb.c
+++ b/drivers/phy/phy-exynos-usb.c
@@ -212,6 +212,10 @@ extern const struct uphy_config exynos4210_uphy_config;
extern const struct uphy_config exynos4212_uphy_config;
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+extern const struct uphy_config exynos5250_uphy_config;
+#endif
+
static const struct of_device_id exynos_uphy_of_match[] = {
#ifdef CONFIG_PHY_EXYNOS4210_USB
{
@@ -225,6 +229,12 @@ static const struct of_device_id exynos_uphy_of_match[]
= {
.data = exynos4212_uphy_config,
},
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+ {
+ .compatible = samsung,exynos5250-usbphy,
+ .data = exynos5250_uphy_config,
+ },
+#endif
{ },
};
diff --git a/drivers/phy/phy-exynos-usb.h b/drivers/phy/phy-exynos-usb.h
index f45cb3c..a9febfa 100644
--- a/drivers/phy/phy-exynos-usb.h
+++ b/drivers/phy/phy-exynos-usb.h
@@ -42,6 +42,7 @@ enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
TYPE_EXYNOS4212,
+ TYPE_EXYNOS5250,
No cpu types here.
One question here.
In case we move to single driver for Exynos4 SoCs (4210, 4212 and 4412
later) as well as S5PV210,
there will be certain things changing from one SoC to another, how
should we target that in case we
don't have CPU types ?
May be i am misinterpreting your suggestion ?
};
enum uphy_state {
diff --git a/drivers/phy/phy-exynos5250-usb.c
b/drivers/phy/phy-exynos5250-usb.c
new file mode 100644
index 000..156093b
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-usb.c
@@ -0,0 +1,411 @@
+/*
+ * Samsung S5P/EXYNOS SoC series USB PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@samsung.com
+ *
+ * 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.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include phy-exynos-usb.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS_5250_REFCLKSEL_CRYSTAL0x0
+#define EXYNOS_5250_REFCLKSEL_XO 0x1
+#define EXYNOS_5250_REFCLKSEL_CLKCORE0x2
+
+#define EXYNOS_5250_FSEL_9MHZ6 0x0
+#define EXYNOS_5250_FSEL_10MHZ 0x1
+#define EXYNOS_5250_FSEL_12MHZ 0x2
+#define EXYNOS_5250_FSEL_19MHZ2 0x3
+#define EXYNOS_5250_FSEL_20MHZ 0x4
+#define EXYNOS_5250_FSEL_24MHZ 0x5
+#define EXYNOS_5250_FSEL_50MHZ 0x7
+
+/* Normal host */
+#define EXYNOS_5250_HOSTPHYCTRL0 0x0
+
+#define EXYNOS_5250_HOSTPHYCTRL0_PHYSWRSTALL (0x1 31)
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT 19
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_MASK \
+ (0x3 EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT 16
+#define
Re: [PATCH v2 2/4] usb: usbtest: support usb2 extension descriptor test
On Mon, 28 Oct 2013, Huang Rui wrote:
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
USB2.0 Extension descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.1 of USB 3.0 spec.
This patch adds to support getting usb2.0 extension descriptor test
scenario for USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
+ length = sizeof(*udev-bos-desc);
+ buf = (char *)dev-buf;
+ for (i = 0; i num; i++) {
+ buf += length;
+ if (buf = dev-buf + total)
This should be (buf + sizeof(struct usb_dev_cap_header) dev-buf +
total).
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 v2 2/4] usb: usbtest: support usb2 extension descriptor test
On Mon, Oct 28, 2013 at 10:44:19AM -0400, Alan Stern wrote:
On Mon, 28 Oct 2013, Huang Rui wrote:
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
USB2.0 Extension descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.1 of USB 3.0 spec.
This patch adds to support getting usb2.0 extension descriptor test
scenario for USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
+ length = sizeof(*udev-bos-desc);
+ buf = (char *)dev-buf;
+ for (i = 0; i num; i++) {
+ buf += length;
+ if (buf = dev-buf + total)
This should be (buf + sizeof(struct usb_dev_cap_header) dev-buf +
total).
Oh, you're right! Will update in v3.
Thanks,
Rui
--
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: CSW endpoint status returned STALL after BOT MSC Reset
Be aware that the mailing list doesn't like HTML. Plain-text only, please. On Mon, 28 Oct 2013, zouid abdelhamid wrote: Hi folks, I am testing a USB MSC, device mode, using USBCV2.0 . The device is an ARM based platform with a USB DRD that is running 3.4 kernel, the USB port is configured as �device�. When it comes to �Error recovery test� , it fails showing the following messages: ERRORCSW endpoint status returned STALL after BOT MSC Reset FAIL (5.5.4) The device must support the Bulk-Only Mass Storage Reset. Actually I am a little bit confused if it is a Software issue rather than hardware, and I wonder if there is an existing patch for fixing this in the kernel. It's kind of hard to say, since you didn't tell us what platform and which UDC driver you are using. Why don't you try running an up-to-date kernel, like 3.11, instead? Then if there is an existing patch, you'll find out because the test will succeed. 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] Regression fix revert: Bluetooth: Add missing reset_resume dev_pm_ops
Hi Gustavo, Patch has been applied to bluetooth.git. Thanks. Hmm, I'm not seeing this in 3.12 yet, not only should this be added to 3.12 asap, it should also really get added to 3.11.x soon. The regression this patch fixes is breaking btusb for lots of users, see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213239 https://bugzilla.redhat.com/show_bug.cgi?id=988481 Where lots of people are adding me too comments (and some are building their own kernels with the revert and confirming it fixes things for them). Regards, Hans -- 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 v3 2/4] usb: usbtest: support usb2 extension descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
USB2.0 Extension descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.1 of USB 3.0 spec.
This patch adds to support getting usb2.0 extension descriptor test
scenario for USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 77 ++
1 file changed, 77 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 38ebe1d..d9ac215 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -606,6 +606,28 @@ static int is_good_config(struct usbtest_dev *tdev, int
len)
return 0;
}
+static int is_good_ext(struct usbtest_dev *tdev, char *buf)
+{
+ struct usb_ext_cap_descriptor *ext;
+ u32 attr;
+
+ ext = (struct usb_ext_cap_descriptor *) buf;
+
+ if (ext-bLength != USB_DT_USB_EXT_CAP_SIZE) {
+ ERROR(tdev, bogus usb 2.0 extension descriptor length\n);
+ return 0;
+ }
+
+ attr = le32_to_cpu(ext-bmAttributes);
+ /* bits[1:4] is used and others are reserved */
+ if (attr ~0x1e) { /* reserved == 0 */
+ ERROR(tdev, reserved bits set\n);
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -694,12 +716,67 @@ static int ch9_postconfig(struct usbtest_dev *dev)
* 3.0 spec
*/
if (le16_to_cpu(udev-descriptor.bcdUSB) = 0x0300) {
+ struct usb_bos_descriptor *bos = NULL;
+ struct usb_dev_cap_header *header = NULL;
+ unsigned total, num, length;
+ char *buf;
+
retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev-buf,
sizeof(*udev-bos-desc));
if (retval != sizeof(*udev-bos-desc)) {
dev_err(iface-dev, bos descriptor -- %d\n, retval);
return (retval 0) ? retval : -EDOM;
}
+
+ bos = (struct usb_bos_descriptor *)dev-buf;
+ total = le16_to_cpu(bos-wTotalLength);
+ num = bos-bNumDeviceCaps;
+
+ if (total TBUF_SIZE)
+ total = TBUF_SIZE;
+
+ /*
+* get generic device-level capability descriptors [9.6.2]
+* in USB 3.0 spec
+*/
+ retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev-buf,
+ total);
+ if (retval != total) {
+ dev_err(iface-dev, bos descriptor set -- %d\n,
+ retval);
+ return (retval 0) ? retval : -EDOM;
+ }
+
+ length = sizeof(*udev-bos-desc);
+ buf = (char *)dev-buf;
+ for (i = 0; i num; i++) {
+ buf += length;
+ if (buf + sizeof(struct usb_dev_cap_header)
+ dev-buf + total)
+ break;
+
+ header = (struct usb_dev_cap_header *)buf;
+ length = header-bLength;
+
+ if (header-bDescriptorType !=
+ USB_DT_DEVICE_CAPABILITY) {
+ dev_warn(udev-dev, not device capability
descriptor, skip\n);
+ continue;
+ }
+
+ switch (header-bDevCapabilityType) {
+ case USB_CAP_TYPE_EXT:
+ if (buf + USB_DT_USB_EXT_CAP_SIZE
+ dev-buf + total ||
+ !is_good_ext(dev, buf)) {
+ dev_err(iface-dev, bogus usb 2.0
extension descriptor\n);
+ return -EDOM;
+ }
+ break;
+ default:
+ break;
+ }
+ }
}
/* there's always [9.4.3] at least one config descriptor [9.6.3] */
--
1.7.11.7
--
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 v3 3/4] usb: usbtest: support superspeed device capbility descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
SuperSpeed USB Device Capability descriptor is one of the generic
device-level capbility descriptors which added in section 9.6.2.2 of USB
3.0 spec.
This patch adds to support getting SuperSpeed USB Device Capability
descriptor test scenario for USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index d9ac215..967247c 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -628,6 +628,35 @@ static int is_good_ext(struct usbtest_dev *tdev, char *buf)
return 1;
}
+static int is_good_ss_cap(struct usbtest_dev *tdev, char *buf)
+{
+ struct usb_ss_cap_descriptor *ss;
+
+ ss = (struct usb_ss_cap_descriptor *) buf;
+
+ if (ss-bLength != USB_DT_USB_SS_CAP_SIZE) {
+ ERROR(tdev, bogus superspeed device capability descriptor
length\n);
+ return 0;
+ }
+
+ /*
+* only bit[1] of bmAttributes is used for LTM and others are
+* reserved
+*/
+ if (ss-bmAttributes ~0x02) { /* reserved == 0 */
+ ERROR(tdev, reserved bits set in bmAttributes\n);
+ return 0;
+ }
+
+ /* bits[0:3] of wSpeedSupported is used and others are reserved */
+ if (le16_to_cpu(ss-wSpeedSupported) ~0x0f) { /* reserved == 0 */
+ ERROR(tdev, reserved bits set in wSpeedSupported\n);
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -773,6 +802,14 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return -EDOM;
}
break;
+ case USB_SS_CAP_TYPE:
+ if (buf + USB_DT_USB_SS_CAP_SIZE
+ dev-buf + total ||
+ !is_good_ss_cap(dev, buf)) {
+ dev_err(iface-dev, bogus superspeed
device capability descriptor\n);
+ return -EDOM;
+ }
+ break;
default:
break;
}
--
1.7.11.7
--
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 v3 0/4] usb: usbtest: support usb3.0 bos descriptor set test
Hi all, The following patches implement Binary Device Object Store (BOS) descriptor set tests in section 9.6.2 of USB 3.0 SPEC. At current usbtest module, it only supports USB 2.0 chapter 9 tests, so this updates extend the testing scope to cover the USB 3.0 new descriptors. Changes from v1 - v2: - Update bcdUSB = 0x0300 to support USB 3.1 in Patch 1. - Add if total TBUF_SIZE to avoid buffer overflow. - Add local pointer buf to avoid change dev-buf. - Add if buf = dev-buf + total to avoid to lie beyond the end of the dev-buf. - Add if buf + USB_DT_..._SIZE dev-buf + total to make header pointer always available. Changes from v2 - v3: - Update if buf + sizeof(struct usb_dev_cap_header) dev-buf + total to make buf pointer always available. Thanks, Rui Huang Rui (4): usb: usbtest: support bos descriptor test for usb 3.0 usb: usbtest: support usb2 extension descriptor test usb: usbtest: support superspeed device capbility descriptor test usb: usbtest: support container id descriptor test drivers/usb/misc/usbtest.c | 154 + 1 file changed, 154 insertions(+) -- 1.7.11.7 -- 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 v3 4/4] usb: usbtest: support container id descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
Container ID descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.3 of USB 3.0 spec.
This patch adds to support getting Container ID descriptor test scenario
for USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 967247c..a96c783 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -657,6 +657,25 @@ static int is_good_ss_cap(struct usbtest_dev *tdev, char
*buf)
return 1;
}
+static int is_good_con_id(struct usbtest_dev *tdev, char *buf)
+{
+ struct usb_ss_container_id_descriptor *con_id;
+
+ con_id = (struct usb_ss_container_id_descriptor *) buf;
+
+ if (con_id-bLength != USB_DT_USB_SS_CONTN_ID_SIZE) {
+ ERROR(tdev, bogus container id descriptor length\n);
+ return 0;
+ }
+
+ if (con_id-bReserved) {/* reserved == 0 */
+ ERROR(tdev, reserved bits set\n);
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -810,6 +829,14 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return -EDOM;
}
break;
+ case CONTAINER_ID_TYPE:
+ if (buf + USB_DT_USB_SS_CONTN_ID_SIZE
+ dev-buf + total ||
+ !is_good_con_id(dev, buf)) {
+ dev_err(iface-dev, bogus container
id descriptor\n);
+ return -EDOM;
+ }
+ break;
default:
break;
}
--
1.7.11.7
--
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 v3 1/4] usb: usbtest: support bos descriptor test for usb 3.0
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times. This patch adds to support getting bos descriptor test scenario for
USB 3.0.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3e91d3e9..38ebe1d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -689,6 +689,19 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return (retval 0) ? retval : -EDOM;
}
+ /*
+* there's always [9.4.3] a bos device descriptor [9.6.2] in USB
+* 3.0 spec
+*/
+ if (le16_to_cpu(udev-descriptor.bcdUSB) = 0x0300) {
+ retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev-buf,
+ sizeof(*udev-bos-desc));
+ if (retval != sizeof(*udev-bos-desc)) {
+ dev_err(iface-dev, bos descriptor -- %d\n, retval);
+ return (retval 0) ? retval : -EDOM;
+ }
+ }
+
/* there's always [9.4.3] at least one config descriptor [9.6.3] */
for (i = 0; i udev-descriptor.bNumConfigurations; i++) {
retval = usb_get_descriptor(udev, USB_DT_CONFIG, i,
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] usb: usbtest: support usb3.0 bos descriptor set test
On Mon, 28 Oct 2013, Huang Rui wrote: Hi all, The following patches implement Binary Device Object Store (BOS) descriptor set tests in section 9.6.2 of USB 3.0 SPEC. At current usbtest module, it only supports USB 2.0 chapter 9 tests, so this updates extend the testing scope to cover the USB 3.0 new descriptors. Changes from v1 - v2: - Update bcdUSB = 0x0300 to support USB 3.1 in Patch 1. - Add if total TBUF_SIZE to avoid buffer overflow. - Add local pointer buf to avoid change dev-buf. - Add if buf = dev-buf + total to avoid to lie beyond the end of the dev-buf. - Add if buf + USB_DT_..._SIZE dev-buf + total to make header pointer always available. Changes from v2 - v3: - Update if buf + sizeof(struct usb_dev_cap_header) dev-buf + total to make buf pointer always available. Thanks, Rui Huang Rui (4): usb: usbtest: support bos descriptor test for usb 3.0 usb: usbtest: support usb2 extension descriptor test usb: usbtest: support superspeed device capbility descriptor test usb: usbtest: support container id descriptor test drivers/usb/misc/usbtest.c | 154 + 1 file changed, 154 insertions(+) These patches look okay now. Acked-by: Alan Stern st...@rowland.harvard.edu If we ever come across a device whose extension descriptors take up more than 256 bytes, the code will have to be revised. For now, it should be good. 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: pl2303 driver regression after commit 61fa8d694b854
Am 28.10.2013 09:27, schrieb Mika Westerberg: On Fri, Oct 25, 2013 at 03:43:03PM +0200, Frank Schäfer wrote: Am 25.10.2013 15:17, schrieb Mika Westerberg: On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote: Tried few other baudrates 115200 and they don't work either. Urgh... has this device ever been working at baud rates 115200 ? I have only used it as a serial console for a device and never tried baud rates higher than 115200 before today. Could you at least test kernel 3.11 ? Tried on v3.11 following rates: 115200, 230400, 460800, and they all work. That's weird. Ok, it seems I'll have to order one of these adapters to find out what's going on. ;-) In the meantime, we have to switch back to the old baud rate encoding method/strategy for this chip. I will send a patch later this evening. Thank you for reporting this issue and testing ! Regards, Frank Schäfer -- 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: transmit lockup using smsc95xx ethernet on usb3
We are seeing complete lockups of the transmit side when using the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu. These errors are very intermittent - less than once a day, and it isn't actually clear that they are related to traffic load. ... I would suggest you try with the latest stable kernel, with CONFIG_USB_DEBUG enabled. I've finally got the same failure with a 3.12-0-rc5 kernel. The only change I made was to comment out the 'short packet' trace. The kernel trace contains: (I've shortened the lines by removing the fixed part of the header. I've got the full trace, and the matching usbmon trace, but they are a bit large to post to the mailing lists! All from xhci_hcd :00:14.0 [38704.116936] Transfer error on endpoint [38704.116941] Cleaning up stalled endpoint ring [38704.116944] Finding segment containing stopped TRB. [38704.116946] Finding endpoint context [38704.116948] Finding segment containing last TRB in TD. [38704.116950] Cycle state = 0x0 [38704.116952] New dequeue segment = 880214565660 (virtual) [38704.116954] New dequeue pointer = 0x210cf4ad0 (DMA) [38704.116956] Queueing new dequeue state [38704.116959] Set TR Deq Ptr cmd, new deq seg = 880214565660 (0x210cf4800 dma), new deq ptr = 880210cf4ad0 (0x210cf4ad0 dma), new cycle = 0 [38704.116962] // Ding dong! [38704.116966] Giveback URB 8800d6841d80, len = 0, expected = 18944, status = -71 [38704.116970] Transfer error on endpoint [38704.116973] Cleaning up stalled endpoint ring [38704.116974] Finding segment containing stopped TRB. [38704.116976] Finding endpoint context [38704.116978] Finding segment containing last TRB in TD. [38704.116980] Cycle state = 0x1 [38704.116982] New dequeue segment = 880214565680 (virtual) [38704.116984] New dequeue pointer = 0x210cf47e0 (DMA) [38704.116986] Queueing new dequeue state [38704.116989] Set TR Deq Ptr cmd, new deq seg = 880214565680 (0x210cf4400 dma), new deq ptr = 880210cf47e0 (0x210cf47e0 dma), new cycle = 1 [38704.116991] // Ding dong! [38704.116995] Giveback URB 8802132169c0, len = 1024, expected = 1526, status = -71 [38704.116998] Ignoring reset ep completion code of 1 [38704.117001] Successful Set TR Deq Ptr cmd, deq = @210cf4ad0 [38704.117004] Ignoring reset ep completion code of 1 [38704.117006] Successful Set TR Deq Ptr cmd, deq = @210cf47e1 [38704.240067] Stalled endpoint [38704.240075] Giveback URB 8800d4438900, len = 0, expected = 1526, status = -32 [38704.240112] Cancel URB 8800d4438b40, dev 1.1, ep 0x2, starting at offset 0x210cf4030 [38704.240118] // Ding dong! [38704.240124] Cancel URB 8800d4438cc0, dev 1.1, ep 0x2, starting at offset 0x210cf4040 [38704.240129] Removing canceled TD starting at 0x210cf4030 (dma). [38704.240132] TRB to noop at offset 0x210cf4030 [38704.240134] Removing canceled TD starting at 0x210cf4040 (dma). [38704.240136] TRB to noop at offset 0x210cf4040 [38704.240155] WARN halted endpoint, queueing URB anyway. [38704.240163] WARN halted endpoint, queueing URB anyway. [38704.240170] WARN halted endpoint, queueing URB anyway. [38704.240177] Cancel URB 8800d4438840, dev 1.1, ep 0x2, starting at offset 0x210cf4050 [38704.240179] // Ding dong! [38704.240184] Cancel URB 8800d44389c0, dev 1.1, ep 0x2, starting at offset 0x210cf4060 [38704.240189] Removing canceled TD starting at 0x210cf4050 (dma). [38704.240191] TRB to noop at offset 0x210cf4050 [38704.240193] Removing canceled TD starting at 0x210cf4060 (dma). [38704.240195] TRB to noop at offset 0x210cf4060 [38704.240205] WARN halted endpoint, queueing URB anyway. [38704.240210] WARN halted endpoint, queueing URB anyway. [38704.240216] Cancel URB 8800d4438c00, dev 1.1, ep 0x2, starting at offset 0x210cf4070 [38704.240219] // Ding dong! [38704.240224] Cancel URB 8800d4438a80, dev 1.1, ep 0x2, starting at offset 0x210cf4080 [38704.240228] Removing canceled TD starting at 0x210cf4070 (dma). [38704.240230] TRB to noop at offset 0x210cf4070 [38704.240232] Removing canceled TD starting at 0x210cf4080 (dma). [38704.240234] TRB to noop at offset 0x210cf4080 [38704.240244] WARN halted endpoint, queueing URB anyway. [38704.240249] WARN halted endpoint, queueing URB anyway. [38704.240255] Cancel URB 8800d4438780, dev 1.1, ep 0x2, starting at offset 0x210cf4090 [38704.240257] // Ding dong! [38704.240262] Cancel URB 8800d4438480, dev 1.1, ep 0x2, starting at offset 0x210cf40a0 [38704.240266] Cancel URB 8800d44386c0, dev 1.1, ep 0x2, starting at offset 0x210cf40b0 [38704.240271] Removing canceled TD starting at 0x210cf4090 (dma). [38704.240273] TRB to noop at offset 0x210cf4090 [38704.240275] Removing canceled TD starting at 0x210cf40a0 (dma). [38704.240277] TRB to noop at offset 0x210cf40a0 [38704.240279] Removing canceled TD starting at 0x210cf40b0 (dma). [38704.240281] TRB to noop at offset 0x210cf40b0 [38704.240292] WARN halted endpoint, queueing URB anyway. [38704.240296] WARN halted endpoint, queueing
[PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Mika Westerberg has reported that the fixed+improved divisor based baud rate
encoding method doesn't work anymore with his HXD device.
So until we've found out what's going on, reintroduce the old encoding algorithm
and use it for this and all newer chips for baud rates 115200 baud.
Also switch back to the direct encoding method for baud rates = 115200, because
it's unclear if the old divisor based encoding algorithm works for them.
Reported-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 64 +++
1 Datei geändert, 58 Zeilen hinzugefügt(+), 6 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index bedf8e4..32f0410 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -372,14 +372,14 @@ static int pl2303_baudrate_encode_direct(int baud, enum
pl2303_type type,
return baud;
}
-static int pl2303_baudrate_encode_divisor(int baud, enum pl2303_type type,
+static int pl2303_baudrate_encode_divisor_HX(int baud, enum pl2303_type type,
u8 buf[4])
{
/*
-* Divisor based baud rate encoding method
+* Divisor based baud rate encoding method for HX chips
*
* NOTE: HX clones do NOT support this method.
-* It's not clear if the type_0/1 chips support it.
+* It's not clear if other chips support it.
*
* divisor = 12MHz * 32 / baudrate = 2^A * B
*
@@ -456,6 +456,53 @@ static int pl2303_baudrate_encode_divisor(int baud, enum
pl2303_type type,
return baud;
}
+static int pl2303_baudrate_encode_divisor_HXD(int baud, enum pl2303_type type,
+ u8 buf[4])
+{
+ /*
+* Divisor based baud rate encoding method for HXD chips
+*
+* NOTE: This method has been used since kernel 3.1 for all chips and
+* baud rates 115200. It is very similar to the new (and better)
+* method for HX chips, but it has been reported that the HX method
+* doesn't work at least for HXD chips and baud rates 115200.
+*/
+ unsigned tmp;
+
+ /*
+* NOTE: The Windows driver allows maximum baud rates of 110% of the
+* specified maximium value.
+* Quick tests with early (2004) HX (rev. A) chips suggest, that even
+* higher baud rates (up to the maximum of 24M baud !) are working fine,
+* but that should really be tested carefully in real life scenarios
+* before removing the upper limit completely.
+*
+* Specified max. baud rates:
+* HXD, EA, TB: 12Mbps; RA: 1Mbps; SA: 115200 bps
+*
+* FIXME: as long as we don't know how to distinguish between
+* these chip variants, allow the max. of these values
+*/
+ baud = min_t(int, baud, 1200 * 1.1);
+
+ /* apparently the formula for higher speeds is:
+* baudrate = 12M * 32 / (2^buf[1]) / buf[0]
+*/
+ tmp = 12*1000*1000*32 / baud;
+ buf[3] = 0x80;
+ buf[2] = 0;
+ buf[1] = (tmp = 256);
+ while (tmp = 256) {
+ tmp = 2;
+ buf[1] = 1;
+ }
+ buf[0] = tmp;
+ /* Calculate the actual/resulting baud rate */
+ baud = 1200 * 32 / ((1 buf[1]) * buf[0]);
+
+ return baud;
+}
+
static void pl2303_encode_baudrate(struct tty_struct *tty,
struct usb_serial_port *port,
enum pl2303_type type,
@@ -473,6 +520,9 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
*= supported by all chip types
* 2) Divisor based method: encodes a divisor to a base value (12MHz*32)
*= not supported by HX clones (and likely type_0/1 chips)
+*= supported by HX chips for the whole baud rate range
+*= HXD (and likely also EA, RA, SA, TB chips) support this method
+* only for baud rates 115200
*
* NOTE: Although the divisor based baud rate encoding method is much
* more flexible, some of the standard baud rate values can not be
@@ -480,10 +530,12 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
* the device likely uses the same baud rate generator for both methods
* so that there is likley no difference.
*/
- if (type == type_0 || type == type_1 || type == HX_CLONE)
- baud = pl2303_baudrate_encode_direct(baud, type, buf);
+ if (type == HX_TA)
+ baud = pl2303_baudrate_encode_divisor_HX(baud, type, buf);
+ else if ((type == HXD_EA_RA_SA || type == TB) baud 115200)
+ baud = pl2303_baudrate_encode_divisor_HXD(baud, type, buf);
else
-
Re: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Hi Kamil,
On Monday 28 of October 2013 14:52:19 Kamil Debski wrote:
Hi Kishon,
Thank you for your review! I will answer your comments below.
[snip]
+
+ switch (drv-cfg-cpu) {
+ case TYPE_EXYNOS4210:
+ case TYPE_EXYNOS4212:
Lets not add such cpu checks inside driver.
Some SoC have a special register, which switches the OTG lines between
device and host modes. I understand that it might not be the prettiest
code. I see this as a good compromise between having a single huge
driver for all Exynos SoCs and having a multiple drivers for each SoC
version. PHY IPs in these chips very are similar but have to be handled
differently. Any other ideas to solve this issue?
Maybe adding a flag in drv-cfg called, for example, .has_mode_switch
could solve this problem without having to check the SoC type explicitly?
[snip]
+#ifdef CONFIG_PHY_EXYNOS4210_USB
Do we really need this?
No we don't. The driver can always support all Exynos SoC versions.
These config options were added for flexibility.
+extern const struct uphy_config exynos4210_uphy_config; #endif
+
+#ifdef CONFIG_PHY_EXYNOS4212_USB
Same here.
+extern const struct uphy_config exynos4212_uphy_config; #endif
+
+static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
+CONFIG_PHY_EXYNOS4210_USB
#if not needed here.
If the #ifdef CONFIG_PHY_EXYNOS4210_USB is removed then yes. Otherwise
it is necessary - exynos4210_uphy_config may be undefined.
I believe this and other ifdefs below are needed, otherwise, with support
for one of the SoCs disabled, the driver could still bind to its
compatible value.
Best regards,
Tomasz
--
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: khubd timed out on ep0in len=0/64 with 3.4 kernel
Hi
I tried resetting usb device when it gets ETIMEDOUT during get
descriptor. On second retry, I don't see timeout. Please see this
patch:
Index: linux-3.4/drivers/usb/core/hub.c
===
--- linux-3.4.orig/drivers/usb/core/hub.c
+++ linux-3.4/drivers/usb/core/hub.c
@@ -3213,6 +3213,14 @@ hub_port_init (struct usb_hub *hub, stru
r = -EPROTO;
break;
}
+
+if (r == -ETIMEDOUT) {
+ r = usb_reset_device(hdev);
+ if (r) {
+ dev_dbg(udev-dev, failed to reset usb %d\n, r);
+ }
+ }
+
if (r == 0)
break;
}
Here are debugs (sorry if they are too verbose) where it recovers from
timeout. At 6.632 is the first timeout and at 6.968 it was able to get
bMaxPacketSize0. I couldn't reproduce the issue with this patch.
[1.632081] usb 1-3: new high speed USB device using ehci_hcd and address 2
[6.632092] usb 1-3: khubd timed out on ep0in len=0/64 status -2
[6.632110] usb 1-3: hub_port_init: iter 0 maxpktsize 0 r -110
[6.736140] hub 1-0:1.0: port 3: status 0503 change
[6.736208] usb 1-3: hub_port_init reset usb ret -21
[6.864079] usb 1-3: device descriptor read/64, error -71
[6.968342] usb 1-3: hub_port_init: iter 0 maxpktsize 64 r 18
[7.101325] usb 1-3: default language 0x0409
[7.102201] usb 1-3: udev 2, busnum 1, minor = 1
[7.102205] usb 1-3: New USB device found, idVendor=0e39, idProduct=2b00
[7.102208] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7.102212] usb 1-3: Product: eUSB
[7.102214] usb 1-3: Manufacturer: SMART
[7.102217] usb 1-3: SerialNumber: 3E3B2F01123531050102
[7.102424] usb 1-3: configuration #1 chosen from 1 choice
[7.102674] usb 1-3: adding 1-3:1.0 (config #1, interface 0)
[7.460377] hub 1-0:1.0: state 7 ports 5 chg 0008 evt
[7.460429] hub 1-0:1.0: port 3, status 0503, change , 480 Mb/s
thank you.
On Fri, Oct 25, 2013 at 7:38 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 25 Oct 2013, Prasad Koya wrote:
Resending in plain-text.
On Thu, Oct 24, 2013 at 11:06 PM, Prasad Koya prasad.k...@gmail.com wrote:
Hi
I tried with even unmounting the USB before forcing panic and I see same
time out while getting device descriptor.
A better test would be to unbind usb-storage from the device
beforehand.
Anyway, if the device doesn't allow itself to be reset properly then
the device is buggy. You can test this easily enough by forcing a
device reset by hand; see
http://marc.info/?l=linux-usbm=126028634531290w=2
From debugs, I see that the portstatus is 0x501 to start with ie,
(high-speed attached, power-on, device is attached). After reset I see
wPortStatus and wPortChange bits as expected. However, get descriptor
timesout with status as -ENOENT. If I ignore this error and set
bMaxPacketSize0 to 64, it gets through the initialization but i see
usb-storage driver doing a reset much later.
Pl see the debugs:
You have added so many new debugging messages, I can't tell what they
mean.
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
kernel NULL pointer dereference at (null) - inside hub_disconnect
https://bugzilla.kernel.org/show_bug.cgi?id=63961 Kernel version 3.10.15 [1774469.764676] usb 2-1: new SuperSpeed USB device number 73 using xhci_hcd [1774469.777435] usb 2-1: Parent hub missing LPM exit latency info. Power management will be impacted. [1774469.779805] usb 2-1: New USB device found, idVendor=2109, idProduct=0812 [1774469.779816] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1774469.779820] usb 2-1: Product: USB3.0 Hub [1774469.779823] usb 2-1: Manufacturer: VIA Labs, Inc. [1774469.780433] hub 2-1:1.0: USB hub found [1774469.780924] hub 2-1:1.0: 4 ports detected [1774470.093124] usb 1-1: new high-speed USB device number 116 using xhci_hcd [1774470.106475] usb 1-1: New USB device found, idVendor=2109, idProduct=2812 [1774470.106484] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [1774470.106487] usb 1-1: Product: USB2.0 Hub [1774470.107117] hub 1-1:1.0: USB hub found [1774470.107584] hub 1-1:1.0: 4 ports detected [1774470.285729] usb 2-1.3: new SuperSpeed USB device number 74 using xhci_hcd [1774470.297775] usb 2-1.3: Parent hub missing LPM exit latency info. Power management will be impacted. [1774470.300021] usb 2-1.3: New USB device found, idVendor=2109, idProduct=0812 [1774470.300025] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1774470.300029] usb 2-1.3: Product: USB3.0 Hub [1774470.300032] usb 2-1.3: Manufacturer: VIA Labs, Inc. [1774470.300676] hub 2-1.3:1.0: USB hub found [1774470.301017] hub 2-1.3:1.0: 4 ports detected [1774470.472998] usb 2-1.4: new SuperSpeed USB device number 75 using xhci_hcd [1774470.485465] usb 2-1.4: Parent hub missing LPM exit latency info. Power management will be impacted. [1774470.487729] usb 2-1.4: New USB device found, idVendor=2109, idProduct=0812 [1774470.487735] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1774470.487739] usb 2-1.4: Product: USB3.0 Hub [1774470.487742] usb 2-1.4: Manufacturer: VIA Labs, Inc. [1774470.488401] hub 2-1.4:1.0: USB hub found [1774470.488712] hub 2-1.4:1.0: 4 ports detected [1774470.502838] hub 2-1.3:1.0: hub_port_status failed (err = -71) [1774470.503095] hub 2-1.3:1.0: hub_port_status failed (err = -71) [1774470.503308] hub 2-1.3:1.0: hub_port_status failed (err = -71) [1774470.503558] hub 2-1.3:1.0: hub_port_status failed (err = -71) [1774475.483021] hub 2-1.4:1.0: config failed, can't get hub status (err -110) [1774475.483042] BUG: unable to handle kernel NULL pointer dereference at (null) [1774475.483075] IP: [a019b30e] hub_quiesce+0x4e/0xb0 [usbcore] [1774475.483102] PGD 0 [1774475.483111] Oops: [#1] PREEMPT SMP [1774475.483131] Modules linked in: ip6t_REJECT ip6table_filter ip6_tables x_tables nfnetlink_log nfnetlink nls_utf8 isofs usb_storage fuse netconsole configfs cfq_iosched bridge stp llc ipv6 ftdi_sio cdc_acm hid_generic cp210x usbhid hid usbserial coretemp snd_hda_codec_hdmi evdev snd_hda_codec_realtek hwmon mperf intel_powerclamp kvm_intel kvm psmouse snd_hda_intel xhci_hcd ehci_pci i915 snd_hda_codec ehci_hcd video drm_kms_helper i2c_i801 8250_pci usbcore snd_hwdep drm usb_common snd_pcm e1000e firewire_ohci 8250 8139too tpm_tis ptp tpm mii firewire_core serial_core snd_page_alloc pps_core crc_itu_t snd_timer rtc_cmos button tpm_bios i2c_algo_bit snd ata_generic pata_acpi [1774475.483572] CPU: 1 PID: 1278 Comm: khubd Tainted: GW3.10.15- gentoo #1 [1774475.483592] Hardware name: /DQ67SW, BIOS SWQ6710H.86A.0062.2012.0418.1112 04/18/2012 [1774475.483616] task: 880429092fe0 ti: 880426a12000 task.ti: 880426a12000 [1774475.483636] RIP: 0010:[a019b30e] [a019b30e] hub_quiesce+0x4e/0xb0 [usbcore] [1774475.483666] RSP: 0018:880426a13828 EFLAGS: 00010246 [1774475.483680] RAX: 880423900ee0 RBX: 8803eb68e000 RCX: 88043e28d958 [1774475.483699] RDX: RSI: 7fff RDI: [1774475.483718] RBP: 880426a13848 R08: R09: [1774475.483736] R10: 23c3 R11: R12: 8800370c4800 [1774475.483754] R13: R14: 880342989830 R15: 0096 [1774475.483773] FS: () GS:88043e28() knlGS: [1774475.483794] CS: 0010 DS: ES: CR0: 80050033 [1774475.483808] CR2: CR3: 0180c000 CR4: 000407e0 [1774475.483826] DR0: DR1: DR2: [1774475.483844] DR3: DR6: 0ff0 DR7: 0400 [1774475.483863] Stack: [1774475.483867] 880426a13848 8803eb68e000 8800370c4888 880342989800 [1774475.483898] 880426a13878 a019b629 8803eb68e000 880342989800 [1774475.483928] 8800370c4800 ff92 880426a13918 a019dfd1 [1774475.483959] Call Trace:
[PATCH] USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE
notifications
when sending a message over multiple fragments or when there are unsolicited
messages available.
Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications received
and decrement the count and submit the urb for the next response each time
userspace
completes a read the response.
Signed-off-by: Greg Suarez gsua...@smithmicro.com
---
drivers/usb/class/cdc-wdm.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index d3318a0..589ea58 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -101,6 +101,7 @@ struct wdm_device {
struct work_struct rxwork;
int werr;
int rerr;
+ int resp_count;
struct list_headdevice_list;
int (*manage_power)(struct usb_interface *, int);
@@ -262,9 +263,9 @@ static void wdm_int_callback(struct urb *urb)
}
spin_lock(desc-iuspin);
- clear_bit(WDM_READ, desc-flags);
responding = test_and_set_bit(WDM_RESPONDING, desc-flags);
- if (!responding !test_bit(WDM_DISCONNECTING, desc-flags)
+ if (!desc-resp_count++ !responding
+!test_bit(WDM_DISCONNECTING, desc-flags)
!test_bit(WDM_SUSPENDING, desc-flags)) {
rv = usb_submit_urb(desc-response, GFP_ATOMIC);
dev_dbg(desc-intf-dev, %s: usb_submit_urb %d,
@@ -521,10 +522,36 @@ retry:
desc-length -= cntr;
/* in case we had outstanding data */
- if (!desc-length)
+ if (!desc-length) {
clear_bit(WDM_READ, desc-flags);
- spin_unlock_irq(desc-iuspin);
+ if (--desc-resp_count) {
+ set_bit(WDM_RESPONDING, desc-flags);
+ spin_unlock_irq(desc-iuspin);
+
+ rv = usb_submit_urb(desc-response, GFP_KERNEL);
+ if (rv) {
+ dev_err(desc-intf-dev,
+ %s: usb_submit_urb failed with result
%d\n,
+ __func__, rv);
+ spin_lock_irq(desc-iuspin);
+ clear_bit(WDM_RESPONDING, desc-flags);
+ spin_unlock_irq(desc-iuspin);
+
+ if (rv == -ENOMEM) {
+ rv = schedule_work(desc-rxwork);
+ if (rv)
+ dev_err(desc-intf-dev,
Cannot schedule work\n);
+ } else {
+ spin_lock_irq(desc-iuspin);
+ desc-resp_count = 0;
+ spin_unlock_irq(desc-iuspin);
+ }
+ }
+ } else
+ spin_unlock_irq(desc-iuspin);
+ } else
+ spin_unlock_irq(desc-iuspin);
rv = cntr;
@@ -635,6 +662,9 @@ static int wdm_release(struct inode *inode, struct file
*file)
if (!test_bit(WDM_DISCONNECTING, desc-flags)) {
dev_dbg(desc-intf-dev, wdm_release: cleanup);
kill_urbs(desc);
+ spin_lock_irq(desc-iuspin);
+ desc-resp_count = 0;
+ spin_unlock_irq(desc-iuspin);
desc-manage_power(desc-intf, 0);
} else {
/* must avoid dev_printk here as desc-intf is invalid
*/
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare
Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/usb/gadget/r8a66597-udc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/r8a66597-udc.c
b/drivers/usb/gadget/r8a66597-udc.c
index 68be48d..4728751 100644
--- a/drivers/usb/gadget/r8a66597-udc.c
+++ b/drivers/usb/gadget/r8a66597-udc.c
@@ -1833,7 +1833,7 @@ static int __exit r8a66597_remove(struct platform_device
*pdev)
r8a66597_free_request(r8a66597-ep[0].ep, r8a66597-ep0_req);
if (r8a66597-pdata-on_chip) {
- clk_disable(r8a66597-clk);
+ clk_disable_unprepare(r8a66597-clk);
clk_put(r8a66597-clk);
}
@@ -1931,7 +1931,7 @@ static int __init r8a66597_probe(struct platform_device
*pdev)
ret = PTR_ERR(r8a66597-clk);
goto clean_up;
}
- clk_enable(r8a66597-clk);
+ clk_prepare_enable(r8a66597-clk);
}
if (r8a66597-pdata-sudmac) {
@@ -1996,7 +1996,7 @@ clean_up3:
free_irq(irq, r8a66597);
clean_up2:
if (r8a66597-pdata-on_chip) {
- clk_disable(r8a66597-clk);
+ clk_disable_unprepare(r8a66597-clk);
clk_put(r8a66597-clk);
}
clean_up:
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] usb: r8a66597-hcd: Convert to clk_prepare/unprepare
Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/usb/host/r8a66597-hcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 2ad004a..a2fdd85 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -95,7 +95,7 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
int i = 0;
if (r8a66597-pdata-on_chip) {
- clk_enable(r8a66597-clk);
+ clk_prepare_enable(r8a66597-clk);
do {
r8a66597_write(r8a66597, SCKE, SYSCFG0);
tmp = r8a66597_read(r8a66597, SYSCFG0);
@@ -139,7 +139,7 @@ static void r8a66597_clock_disable(struct r8a66597
*r8a66597)
udelay(1);
if (r8a66597-pdata-on_chip) {
- clk_disable(r8a66597-clk);
+ clk_disable_unprepare(r8a66597-clk);
} else {
r8a66597_bclr(r8a66597, PLLC, SYSCFG0);
r8a66597_bclr(r8a66597, XCKE, SYSCFG0);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] Prepare various SH/R Mobile/Car drivers for CCF migration
Hello, This patch series, based on v3.12-rc7, prepares various Renesas SH-Mobile, R-Mobile and R-Car drivers for migration to CCF by adding clock prepare and unprepare support. The patches are pretty straightforward. Most of the drivers called clk_enable and clk_disable in sleepable context, I've thus just converted them to clk_prepare_enable and clk_disable_unprepare. The clocksource drivers were slightly more complex to handle as clk_enable and clk_disable were called in non-sleepable context. As the clocksource framework architecture doesn't provide any sleepable callback in which clocks could be prepared and unprepared, I've added clk_prepare and clk_unprepare calls in the probe and suspend/resume handlers (clocksources can't be removed so the remove handler doesn't need a clk_unprepare call). I'd like to get all these patches merged in v3.14. As they will need to go through their respective subsystems' trees, I would appreciate if all maintainers involved could notify me when they merge patches from this series in their tree to help me tracking the merge status. I don't plan to send pull requests individually for these patches, and I will repost patches individually if changes are requested during review. Cc: Daniel Lezcano daniel.lezc...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Tejun Heo t...@kernel.org Cc: linux-...@vger.kernel.org Cc: David Airlie airl...@linux.ie Cc: dri-de...@lists.freedesktop.org Cc: Wolfram Sang w...@the-dreams.de Cc: linux-...@vger.kernel.org Cc: Chris Ball c...@laptop.org Cc: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Laurent Pinchart (12): clocksource: sh_cmt: Add clk_prepare/unprepare support clocksource: sh_mtu2: Add clk_prepare/unprepare support clocksource: sh_tmu: Add clk_prepare/unprepare support sata_rcar: Convert to clk_prepare/unprepare drm: shmob_drm: Convert to clk_prepare/unprepare i2c: sh_mobile: Convert to clk_prepare/unprepare mmc: sh_mmcif: Convert to clk_prepare/unprepare mmc: sh_mobile_sdhi: Convert to clk_prepare/unprepare usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare usb: r8a66597-hcd: Convert to clk_prepare/unprepare fbdev: shmobile-hdmi: Convert to clk_prepare/unprepare fbdev: shmobile-lcdcfb: Convert to clk_prepare/unprepare drivers/ata/sata_rcar.c | 10 +- drivers/clocksource/sh_cmt.c | 20 drivers/clocksource/sh_mtu2.c | 16 ++-- drivers/clocksource/sh_tmu.c | 20 +--- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 ++-- drivers/i2c/busses/i2c-sh_mobile.c| 8 drivers/mmc/host/sh_mmcif.c | 12 ++-- drivers/mmc/host/sh_mobile_sdhi.c | 4 ++-- drivers/usb/gadget/r8a66597-udc.c | 6 +++--- drivers/usb/host/r8a66597-hcd.c | 4 ++-- drivers/video/sh_mobile_hdmi.c| 6 +++--- drivers/video/sh_mobile_lcdcfb.c | 4 ++-- 12 files changed, 76 insertions(+), 38 deletions(-) -- Regards, Laurent Pinchart -- 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
[RFC/PATCH 1/2] usb: gadget: re-introduce gadget_is_dwc3()
gadget_is_dwc3() is necessary to check whether we are running on Desineware USB3 DRD controller. This macro was previously removed by commit ed9cbda63d45638b69ce62412e3a3c7b00644835 due to it wasn't needed anymore. We're adding it again as things have changed. Signed-off-by: David Cohen david.a.co...@linux.intel.com --- drivers/usb/gadget/gadget_chips.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/gadget_chips.h b/drivers/usb/gadget/gadget_chips.h index bcd04bc..3186a5e 100644 --- a/drivers/usb/gadget/gadget_chips.h +++ b/drivers/usb/gadget/gadget_chips.h @@ -28,6 +28,7 @@ * do that for you. */ #define gadget_is_at91(g) (!strcmp(at91_udc, (g)-name)) +#define gadget_is_dwc3(g) (!strcmp(dwc3-gadget, (g)-name)) #define gadget_is_goku(g) (!strcmp(goku_udc, (g)-name)) #define gadget_is_musbhdrc(g) (!strcmp(musb-hdrc, (g)-name)) #define gadget_is_net2280(g) (!strcmp(net2280, (g)-name)) -- 1.8.4.rc3 -- 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
[RFC/PATCH 2/2] usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize
DWC3 requires buffer size to be aligned to maxpacketsize of an out
endpoint. ffs_epfile_io() needs to pad epout buffer to match above
condition if DWC3 controller is used.
This patch solves an specific situation but a more generic solution
should be found.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/f_fs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b78..33880e6 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -27,6 +27,7 @@
#include linux/usb/composite.h
#include linux/usb/functionfs.h
+#include gadget_chips.h
#define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
@@ -755,10 +756,12 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file-private_data;
+ struct usb_gadget *gadget = epfile-ffs-gadget;
struct ffs_ep *ep;
char *data = NULL;
ssize_t ret;
int halt;
+ size_t orig_len = len;
goto first_try;
do {
@@ -794,6 +797,22 @@ first_try:
goto error;
}
+ /*
+* DWC3 requires buffer size to be aligned to maxpacketsize
+* of an out endpoint.
+* FIXME: a more generic solution might be necessary.
+*/
+ if (gadget_is_dwc3(gadget) read
+ !IS_ALIGNED(len, ep-ep-desc-wMaxPacketSize)) {
+ size_t old_len = len;
+ len = roundup(orig_len,
+ (size_t)ep-ep-desc-wMaxPacketSize);
+ if (unlikely(data) len old_len) {
+ kfree(data);
+ data = NULL;
+ }
+ }
+
/* Allocate copy */
if (!halt !data) {
data = kzalloc(len, GFP_KERNEL);
--
1.8.4.rc3
--
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
[RFC/PATCH 0/2] patchset to workaround f_fs for DWC3
Hi, These patches are a proposal to workaround f_fs when using DWC3 controller. Since DWC3 requires epout buffer size to be aligned to maxpacketsize, f_fs needs to pad buffer size to match the above case. This change is necessary to make Android's adbd service to work with f_fs instead of out-of-tree android gadget. If this same situation is happening in other still untested places, a more generic solution may be required. --- David Cohen (2): usb: gadget: re-introduce gadget_is_dwc3() usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize drivers/usb/gadget/f_fs.c | 19 +++ drivers/usb/gadget/gadget_chips.h | 1 + 2 files changed, 20 insertions(+) -- 1.8.4.rc3 -- 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
imx27.dtsi usbotg/usbh2 oops in fsl_usb2_mph_dr_of_probe
Hi, when tried to activate the USB-OTG or USBH2 with the FDT the system oops [1.034403] ehci-mxc: Freescale On-Chip EHCI Host driver [1.041158] Unable to handle kernel NULL pointer dereference at virtual address [1.049406] pgd = c0004000 [1.052219] [] *pgd= [1.055868] Internal error: Oops: 5 [#1] ARM [1.060167] Modules linked in: [1.063287] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc7 #2 [1.069429] task: c7836000 ti: c783c000 task.ti: c783c000 [1.074888] PC is at fsl_usb2_mph_dr_of_probe+0x314/0x428 [1.080342] LR is at platform_device_alloc+0x5c/0x6c [1.085362] pc : [c028c3b4]lr : [c021c5c4] psr: a013 [1.085362] sp : c783dd68 ip : fp : c783ddf4 [1.096888] r10: c7872500 r9 : c79ed600 r8 : 0002 [1.102154] r7 : c0564c40 r6 : r5 : c7873110 r4 : c7873100 [1.108722] r3 : r2 : r1 : r0 : c79ed600 [1.115291] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.122643] Control: 0005317f Table: a0004000 DAC: 0017 [1.128427] Process swapper (pid: 1, stack limit = 0xc783c1c0) [1.134299] Stack: (0xc783dd68 to 0xc783e000) [1.138718] dd60: c783dd94 c0564c40 c00dac3c 0001 0001 [1.146962] dd80: 0010 [1.155204] dda0: [1.163452] ddc0: c783dde4 c7873110 c7873144 c0564c00 c058f0b0 [1.171703] dde0: c783c020 c783de04 c783ddf8 c021bde0 c028c0b0 c783de24 c783de08 [1.179953] de00: c021ab48 c021bdd4 c7873110 c7873144 c0564c00 c783de44 c783de28 [1.188204] de20: c021ad40 c021aaac c021acd0 c0564c00 c021acd0 c783de6c c783de48 [1.196457] de40: c02191c4 c021ace0 c7823f4c c786a450 c79f77b4 c0564c00 c055b2b0 c79f7780 [1.204709] de60: c783de7c c783de70 c021a6ac c0219158 c783dea4 c783de80 c021a23c c021a69c [1.212962] de80: c04d71b6 c783de90 c0564c00 c053ae0c c0530264 c0572980 c783debc c783dea8 [1.221213] dea0: c021b384 c021a168 0006 c053ae0c c783decc c783dec0 c021c3a8 c021b2f0 [1.229466] dec0: c783dedc c783ded0 c053027c c021c368 c783df54 c783dee0 c000888c c0530274 [1.237719] dee0: c00d2cb8 c00d29c8 c783df0c c783def8 c051b400 c01c8b84 c069ca87 c069ca8c [1.245969] df00: c783df54 c783df10 c002c26c c051b4d8 c05198fc 0006 0006 [1.254219] df20: 0086 c051909c c00313d0 0006 0006 c053ae0c c053fb70 c0572980 [1.262469] df40: c0572980 0086 c783df94 c783df58 c051bb50 c0008804 0006 0006 [1.270717] df60: c051b4c8 c783df10 0001 01234567 c03f72fc [1.278964] df80: c783dfac c783df98 c03f730c c051ba60 [1.287212] dfa0: c783dfb0 c0009450 c03f730c [1.295453] dfc0: [1.303696] dfe0: 0013 [1.311897] Backtrace: [1.314448] [c028c0a0] (fsl_usb2_mph_dr_of_probe+0x0/0x428) from [c021bde0] (platform_drv_probe+0x1c/0x20) [1.324544] [c021bdc4] (platform_drv_probe+0x0/0x20) from [c021ab48] (driver_probe_device+0xac/0x1e8) [1.334204] [c021aa9c] (driver_probe_device+0x0/0x1e8) from [c021ad40] (__driver_attach+0x70/0x94) [1.343544] r7: r6:c0564c00 r5:c7873144 r4:c7873110 [1.349383] [c021acd0] (__driver_attach+0x0/0x94) from [c02191c4] (bus_for_each_dev+0x7c/0x90) [1.358375] r6:c021acd0 r5:c0564c00 r4: r3:c021acd0 [1.364210] [c0219148] (bus_for_each_dev+0x0/0x90) from [c021a6ac] (driver_attach+0x20/0x28) [1.373026] r6:c79f7780 r5:c055b2b0 r4:c0564c00 [1.377796] [c021a68c] (driver_attach+0x0/0x28) from [c021a23c] (bus_add_driver+0xe4/0x24c) [1.386573] [c021a158] (bus_add_driver+0x0/0x24c) from [c021b384] (driver_register+0xa4/0xe8) [1.395478] r7:c0572980 r6:c0530264 r5:c053ae0c r4:c0564c00 [1.401303] [c021b2e0] (driver_register+0x0/0xe8) from [c021c3a8] (__platform_driver_register+0x50/0x64) [1.411163] r5:c053ae0c r4:0006 [1.414862] [c021c358] (__platform_driver_register+0x0/0x64) from [c053027c] (fsl_usb2_mph_dr_driver_init+0x18/0x20) [1.425812] [c0530264] (fsl_usb2_mph_dr_driver_init+0x0/0x20) from [c000888c] (do_one_initcall+0x98/0x140) [1.435889] [c00087f4] (do_one_initcall+0x0/0x140) from [c051bb50] (kernel_init_freeable+0x100/0x1c4) [1.445488] r9:0086 r8:c0572980 r7:c0572980 r6:c053fb70 r5:c053ae0c r4:0006 [1.453532] [c051ba50] (kernel_init_freeable+0x0/0x1c4) from [c03f730c] (kernel_init+0x10/0xec) [1.462610] r9: r8: r7: r6: r5:c03f72fc r4: [1.470645] [c03f72fc]
Re: [RFC PATCH 00/15] rework port power control
On Sat, Oct 26, 2013 at 7:40 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 25 Oct 2013, Dan Williams wrote: This patch set makes a large number of significant changes to important and subtle aspects of the USB stack. It would be a lot easier to discuss in pieces; I can't possibly review the whole series in a reasonable time. And I wish the basic approach had been discussed beforehand... Some of the ideas are quite nice, but there are a lot of details that need close attention. I wanted to at least have a working implementation that tackled the peer disconnect case, I did not expect 15 patches to fall out of that. However, after talking through this I think it can be abbreviated. Yes. It looks like we're talking about several major changes: Redefining what it means for a port to be in runtime suspend. Rearranging the device model tree. Implementing connectors. Changing the port-power-off policy. The patch set also changes khubd into a workqueue, but now it looks like we don't need to do that (although I'm not ruling it out as a future clean-up). Does this leave anything out? No, but that last one can be subdivided into: - implement hotplug vs hardwired policy - consider/handle connector peers in port power policy In the existing code at usb_port_runtime_resume() time we know the port is off. By calling usb_autopm_get_interface(intf) before turning on the power we are simply causing an unnecessary check of the port status registers. We do have the power_is_on check to block hub_activate() from setting the change_bits, but that was not enough to prevent khubd from triggering a disconnect. In fact, the reason for calling usb_autopm_get_interface was to prevent the hub from being suspended while we change the port's power state. Something like this may still be needed. With the device model change and no longer telling the hub interface device to pm_suspend_ignore_children() the pm subsystem will manage this wake up for us. Have you considered what would happen if the user changed the port's pm_qos setting while the port was suspended? Ideally, such changes should immediately affect the port's power state. For example, if the port was suspended with power off when the user sets the no_power_off flag, we should immediately turn port power back on. I don't know if the PM QoS design permits this sort of thing, though. Yes, every flag change triggers a wake up of the port and, as a pre-requisite, its parent hub. You should also explain at the start of the description what you mean by related (or peer) ports. Then the idea of a connector is clear -- although I got the impression that the implementation may be a little over-engineered. Hence the RFC, yes, not opposed to backing up and simplifying this. Since a port never needs to be connected to more than one other port, you could implement connectors simply by storing a peer pointer in the usb_port structure. Yes, no need to design for the non-existent 3 connection types in a port case now. Another simplification is that a struct usb_domain is currently known to never span a controller boundary. So, rather than adding ports to a usb_connector / usb_domain container hierarchy I think we can simply scan the child devices under the xhci device and look for is_usb_port() instances. In the meantime I am still thinking of the approach to reliably link USB3 hub ports to their peers. The spec mandates that they be labelled the same for this purpose (USB3 spec section 10.3.3). However, to determine peer relationships for downstream hubs I think we will need walk the hierarchy back to the root connector and compare paths. Tier mismatch makes it so we can not look at the path back to the root port. Unless there is some unique way to identify a hub? Also need to think about what to do in the case a hub implementation does not label its ports per the spec Is this intended to be a way for the user to force a USB-3 device to connect at high speed rather than SuperSpeed? If it is, it seems like a rather roundabout way of doing so. I agree. I think a lot of this would become more straightforward if we could make the connector a device. Then all the connector relevant policies (power control, forced connect speeds, hotplug policy) could be specified centrally, but there is no way to make it a parent of a usb_port. It would end up being a child device of the host controller which does not seem right either. My feeling is that we shouldn't worry about most of those things. The only critical item is power policy, in particular, whether to power-down a hardwired port. The question about powering down a hotpluggable port can be left for the future. All the questions about peering hub ports goes away if the policy on those is forced to hotplug only. I think the patch that allows the policy (connect_type) to be updated from
Re: Controller's wakeup setting at usb_add_hcd
On Mon, Oct 28, 2013 at 10:37:52AM -0400, Alan Stern wrote: On Mon, 28 Oct 2013, Peter Chen wrote: Just like you said: The physical wakeup setting is controlled by both the controller driver and the platform driver. But currently, it is controlled (or affected) by hcd layer. It is _initialized_ by the HCD layer. The platform driver can always override this. It's easy; just call device_set_wakeup_enable(dev, 0) after usb_add_hcd(). In fact, your platform driver probably should remember the current wakeup setting when the HC is removed. The next time it is added you should change the wakeup setting to the remembered value. That way, if the user adjusts the setting and switches between host and device mode, the desired setting will persist. Yes, we can do that. But if there is no initializing for wakeup setting at usb_add_hcd, the controller driver needs to do nothing, No matter HC is removed or peripheral switches to HC, the wakeup setting will be totally decided by user, and the default setting is 0. Okay. I'll make a deal with you: You can remove the single device_wakeup_enable() call from usb_add_hcd() provided, in the same patch, you add device_wakeup_enable() calls to every HCD (except yours, obviously). Thanks, Alan. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: Du, Changbin changbinx...@intel.com
In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
be called which calls free_netdev(net). Thus usbnet structure(alloced
with net_device structure) will be freed,too.
So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return
error.
BUG: unable to handle kernel NULL pointer dereference at 0078
EIP is at usbnet_link_change+0x1e/0x80
Call Trace:
[c24bc69a] cdc_ncm_bind+0x3a/0x50
[c24b8d32] usbnet_probe+0x282/0x7d0
[c2167f2c] ? sysfs_new_dirent+0x6c/0x100
[c2821253] ? mutex_lock+0x13/0x40
[c24bb278] cdc_ncm_probe+0x8/0x10
[c24e0ef7] usb_probe_interface+0x187/0x2c0
[c23caa8a] ? driver_sysfs_add+0x6a/0x90
[c23cb290] ? __driver_attach+0x90/0x90
[c23caf14] driver_probe_device+0x74/0x360
[c24e07b1] ? usb_match_id+0x41/0x60
[c24e081e] ? usb_device_match+0x4e/0x90
[c23cb290] ? __driver_attach+0x90/0x90
[c23cb2c9] __device_attach+0x39/0x50
[c23c93f4] bus_for_each_drv+0x34/0x70
[c23cae2b] device_attach+0x7b/0x90
[c23cb290] ? __driver_attach+0x90/0x90
[c23ca38f] bus_probe_device+0x6f/0x90
[c23c8a08] device_add+0x558/0x630
[c24e4821] ? usb_create_ep_devs+0x71/0xd0
[c24dd0db] ? create_intf_ep_devs+0x4b/0x70
[c24df2bf] usb_set_configuration+0x4bf/0x800
[c23cb290] ? __driver_attach+0x90/0x90
[c24e809b] generic_probe+0x2b/0x90
[c24e105c] usb_probe_device+0x2c/0x70
[c23caf14] driver_probe_device+0x74/0x360
Signed-off-by: Du, Changbin changbinx...@intel.com
---
drivers/net/usb/cdc_ncm.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..af37ecf 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
-
- /*
-* We should get an event when network connection is connected or
-* disconnected. Set network connection in disconnected state
-* (carrier is OFF) during attach, so the IP network stack does not
-* start IPv6 negotiation and more.
-*/
- usbnet_link_change(dev, 0, 0);
+ if (!ret) {
+ /*
+* We should get an event when network connection is connected
+* or disconnected. Set network connection in disconnected
+* state (carrier is OFF) during attach, so the IP network stack
+* does not start IPv6 negotiation and more.
+*/
+ usbnet_link_change(dev, 0, 0);
+ }
return ret;
}
--
1.8.3.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 0/5] r8152 bug fixes
From: Hayes Wang hayesw...@realtek.com Date: Mon, 28 Oct 2013 19:58:09 +0800 These could fix some driver issues. Hayes Wang (5): net/usb/r8152: fix tx/rx memory overflow net/usb/r8152: make sure the tx checksum setting is correct net/usb/r8152: modify the tx flow net/usb/r8152: fix incorrect type in assignment net/usb/r8152: code adjust These are not bug fixes, some of them are just cleanups. It is inappropriate to mix real bug fixes and non-bug fixes into a patch series. You must send purely the bug fixes for 'net' tree, and then later the code cleanups and other changes targetting the 'net-next' tree. Also, from patch #5: -Something else That is completely unacceptable. You must say what changes you are making, the above says nothing to me nor the person reading your commit messages in the future. In general, your commit messages are poorly written in that they contain not enough information for the person trying to understand your patches at all. -- 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/3] arm: shmobile: r8a7790: Add USBHS clock support
On Thu, Oct 10, 2013 at 02:14:46AM +0400, Valentine Barshak wrote:
This adds USBHS clock support.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
arch/arm/mach-shmobile/clock-r8a7790.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c
b/arch/arm/mach-shmobile/clock-r8a7790.c
index a64f965..161d44e 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -186,6 +186,7 @@ enum {
MSTP813,
MSTP726, MSTP725, MSTP724, MSTP723, MSTP722, MSTP721, MSTP720,
MSTP717, MSTP716,
+ MSTP704,
MSTP522,
MSTP315, MSTP314, MSTP313, MSTP312, MSTP311, MSTP305, MSTP304,
MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,
@@ -208,6 +209,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP720] = SH_CLK_MSTP32(p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
[MSTP717] = SH_CLK_MSTP32(zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
[MSTP716] = SH_CLK_MSTP32(zs_clk, SMSTPCR7, 16, 0), /* HSCIF1 */
+ [MSTP704] = SH_CLK_MSTP32(mp_clk, SMSTPCR7, 4, 0), /* HSUSB */
[MSTP522] = SH_CLK_MSTP32(extal_clk, SMSTPCR5, 22, 0), /* Thermal */
[MSTP315] = SH_CLK_MSTP32(div6_clks[DIV6_MMC0], SMSTPCR3, 15, 0), /*
MMC0 */
[MSTP314] = SH_CLK_MSTP32(div4_clks[DIV4_SD0], SMSTPCR3, 14, 0), /*
SDHI0 */
@@ -296,6 +298,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(ee22.mmcif, mstp_clks[MSTP305]),
CLKDEV_DEV_ID(sh_mmcif.1, mstp_clks[MSTP305]),
CLKDEV_DEV_ID(sh_cmt.0, mstp_clks[MSTP124]),
+ CLKDEV_DEV_ID(renesas_usbhs, mstp_clks[MSTP704]),
+ CLKDEV_ICK_ID(usbhs, usb_phy_rcar_gen2, mstp_clks[MSTP704]),
};
#define R8A7790_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
Thanks, I have queued this up.
It should appear in the next push of the devel branch of the renesas tree.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm: shmobile: lager: Add USBHS support
On Thu, Oct 10, 2013 at 02:14:47AM +0400, Valentine Barshak wrote: This adds USBHS PHY and registers USBHS device if the driver is enabled. Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Thanks, I notice that Felipe Balbi's has merged the first patch of this series and that it is present in linux-next though not in v3.12-rc7. My assumption is that means it will appear in v3.13-rc1 but not v3.12. With this in mind my current plan is to wait for v3.13-rc1, rebase my branches, and then queue-up this patch for v3.14. -- 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-rcar-gen2-usb: Fix phy initialization
On Fri, Oct 25, 2013 at 09:07:12PM +0400, Valentine Barshak wrote: Add missing USB UGCTRL2 register offset. Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com This seems reasonable to me. Acked-by: Simon Horman horms+rene...@verge.net.au Felipe, please consider applying this change. --- drivers/usb/phy/phy-rcar-gen2-usb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c b/drivers/usb/phy/phy-rcar-gen2-usb.c index a99a695..db3ab34 100644 --- a/drivers/usb/phy/phy-rcar-gen2-usb.c +++ b/drivers/usb/phy/phy-rcar-gen2-usb.c @@ -107,10 +107,10 @@ static void __rcar_gen2_usb_phy_init(struct rcar_gen2_usb_phy_priv *priv) clk_prepare_enable(priv-clk); /* Set USB channels in the USBHS UGCTRL2 register */ - val = ioread32(priv-base); + val = ioread32(priv-base + USBHS_UGCTRL2_REG); val = ~(USBHS_UGCTRL2_USB0_HS | USBHS_UGCTRL2_USB2_SS); val |= priv-ugctrl2; - iowrite32(val, priv-base); + iowrite32(val, priv-base + USBHS_UGCTRL2_REG); } /* Shutdown USB channels */ -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
