[PATCH v2 0/2] Bugfix of uhci_hub_control() and cleanups
Fix the return value of uhci_hub_control() to reflect the length of copied buffer. Remove the OK macro for that function to make code more readable. This series also contains hardcoding-to-macro changes in uhci-debug.c. CHANGES: -- v2 - v1: o Do the bugfix in uhci_hub_control() in addition to the OK macro removal. -- Deng-Cheng Zhu (2): USB/host: Use existing macros instead of hard-coded values in uhci-debug.c USB/host: Bugfix: Return length of copied buffer in uhci_hub_control() drivers/usb/host/uhci-debug.c | 16 drivers/usb/host/uhci-hub.c | 40 2 files changed, 28 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] USB/host: Bugfix: Return length of copied buffer in uhci_hub_control()
From: Deng-Cheng Zhu dengcheng@imgtec.com
In addition to the error statuses -ETIMEDOUT and -EPIPE, uhci_hub_control()
needs to return the length of copied buffer when appropriate, so that the
returned status of -hub_control() in rh_call_control() in the USB core
HCD can be properly handled.
This patch also removes the OK() macro to make the code more readable.
Reviewed-by: James Hogan james.ho...@imgtec.com
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
CHANGES:
v2 - v1:
o Do the bugfix in uhci_hub_control() in addition to the OK macro removal.
drivers/usb/host/uhci-hub.c | 40
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/uhci-hub.c b/drivers/usb/host/uhci-hub.c
index 9189bc9..93e17b1 100644
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -75,8 +75,6 @@ static inline int get_hub_status_data(struct uhci_hcd *uhci,
char *buf)
return !!*buf;
}
-#define OK(x) len = (x); break
-
#define CLR_RH_PORTSTAT(x) \
status = uhci_readw(uhci, port_addr); \
status = ~(RWC_BITS|WZ_BITS); \
@@ -244,7 +242,7 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
u16 wIndex, char *buf, u16 wLength)
{
struct uhci_hcd *uhci = hcd_to_uhci(hcd);
- int status, lstatus, retval = 0, len = 0;
+ int status, lstatus, retval = 0;
unsigned int port = wIndex - 1;
unsigned long port_addr = USBPORTSC1 + 2 * port;
u16 wPortChange, wPortStatus;
@@ -258,7 +256,8 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
case GetHubStatus:
*(__le32 *)buf = cpu_to_le32(0);
- OK(4); /* hub power */
+ retval = 4; /* hub power */
+ break;
case GetPortStatus:
if (port = uhci-rh_numports)
goto err;
@@ -311,13 +310,14 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
*(__le16 *)buf = cpu_to_le16(wPortStatus);
*(__le16 *)(buf + 2) = cpu_to_le16(wPortChange);
- OK(4);
+ retval = 4;
+ break;
case SetHubFeature: /* We don't implement these */
case ClearHubFeature:
switch (wValue) {
case C_HUB_OVER_CURRENT:
case C_HUB_LOCAL_POWER:
- OK(0);
+ break;
default:
goto err;
}
@@ -329,7 +329,7 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
switch (wValue) {
case USB_PORT_FEAT_SUSPEND:
SET_RH_PORTSTAT(USBPORTSC_SUSP);
- OK(0);
+ break;
case USB_PORT_FEAT_RESET:
SET_RH_PORTSTAT(USBPORTSC_PR);
@@ -338,10 +338,10 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
/* USB v2.0 7.1.7.5 */
uhci-ports_timeout = jiffies + msecs_to_jiffies(50);
- OK(0);
+ break;
case USB_PORT_FEAT_POWER:
/* UHCI has no power switching */
- OK(0);
+ break;
default:
goto err;
}
@@ -356,10 +356,10 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
/* Disable terminates Resume signalling */
uhci_finish_suspend(uhci, port, port_addr);
- OK(0);
+ break;
case USB_PORT_FEAT_C_ENABLE:
CLR_RH_PORTSTAT(USBPORTSC_PEC);
- OK(0);
+ break;
case USB_PORT_FEAT_SUSPEND:
if (!(uhci_readw(uhci, port_addr) USBPORTSC_SUSP)) {
@@ -382,32 +382,32 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
uhci-ports_timeout = jiffies +
msecs_to_jiffies(20);
}
- OK(0);
+ break;
case USB_PORT_FEAT_C_SUSPEND:
clear_bit(port, uhci-port_c_suspend);
- OK(0);
+ break;
case USB_PORT_FEAT_POWER:
/* UHCI has no power switching */
goto err;
case USB_PORT_FEAT_C_CONNECTION:
CLR_RH_PORTSTAT(USBPORTSC_CSC);
- OK(0);
+ break;
case USB_PORT_FEAT_C_OVER_CURRENT:
[PATCH v2 1/2] USB/host: Use existing macros instead of hard-coded values in uhci-debug.c
From: Deng-Cheng Zhu dengcheng@imgtec.com Now that UHCI IO registers have been defined in uhci-hcd.h, use them. Reviewed-by: James Hogan james.ho...@imgtec.com Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com --- drivers/usb/host/uhci-debug.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/uhci-debug.c b/drivers/usb/host/uhci-debug.c index 4557375..8e239cd 100644 --- a/drivers/usb/host/uhci-debug.c +++ b/drivers/usb/host/uhci-debug.c @@ -310,14 +310,14 @@ static int uhci_show_status(struct uhci_hcd *uhci, char *buf, int len) unsigned short portsc1, portsc2; - usbcmd= uhci_readw(uhci, 0); - usbstat = uhci_readw(uhci, 2); - usbint= uhci_readw(uhci, 4); - usbfrnum = uhci_readw(uhci, 6); - flbaseadd = uhci_readl(uhci, 8); - sof = uhci_readb(uhci, 12); - portsc1 = uhci_readw(uhci, 16); - portsc2 = uhci_readw(uhci, 18); + usbcmd= uhci_readw(uhci, USBCMD); + usbstat = uhci_readw(uhci, USBSTS); + usbint= uhci_readw(uhci, USBINTR); + usbfrnum = uhci_readw(uhci, USBFRNUM); + flbaseadd = uhci_readl(uhci, USBFLBASEADD); + sof = uhci_readb(uhci, USBSOF); + portsc1 = uhci_readw(uhci, USBPORTSC1); + portsc2 = uhci_readw(uhci, USBPORTSC2); out += sprintf(out, usbcmd= %04x %s%s%s%s%s%s%s%s\n, usbcmd, -- 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
Re: [PATCH] usb: wusbcore: add support for isoc out transfers
On Fri, Oct 04, 2013 at 10:40:45AM -0500, Thomas Pugliese wrote: This patch adds support for isochronous out transfers to the HWA. The primary changes are: 1. Add a isoc_pack_desc_urb field to struct wa_seg. This urb is used to send the isochronous packet info message to the HWA which describes the isoc data segment(s) that will be sent as the payload of the transfer request. 2. Use the URB iso_frame_desc field to populate the isochronous packet info message and data segments sent to the HWA. 3. After the data is sent and transfer result is returned from the HWA, read the isoc packet status message from the HWA. The contents of the isoc packet status message are used to set the iso_frame_desc status and actual_length fields in the original isoc URB. This feature required the addition of a some state tracking variables in struct wahc so the dti_urb knows what type of packet it expects to receive next. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/usb/wusbcore/wa-hc.h | 15 ++ drivers/usb/wusbcore/wa-xfer.c | 493 +++- 2 files changed, 406 insertions(+), 102 deletions(-) Nice job, I've applied this, but I'm getting build warnings again, you should really try to test your changes on a 64bit box: drivers/usb/wusbcore/wa-xfer.c: In function ‘__wa_xfer_setup_sizes’: drivers/usb/wusbcore/wa-xfer.c:475:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat] drivers/usb/wusbcore/wa-xfer.c: In function ‘wa_process_iso_packet_status’: drivers/usb/wusbcore/wa-xfer.c:1924:4: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 4 has type ‘int’ [-Wformat] Can you send a follow-on patch fixing this up? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: serial: option: add support for Inovia SEW858 device
From: Greg Kroah-Hartman gre...@linuxfoundation.org
This patch adds the device id for the Inovia SEW858 device to the option driver.
Reported-by: Pavel Parkhomenko ra85...@gmail.com
Cc: stable sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/option.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -450,6 +450,10 @@ static void option_instat_callback(struc
#define CHANGHONG_VENDOR_ID0x2077
#define CHANGHONG_PRODUCT_CH6900x7001
+/* Inovia */
+#define INOVIA_VENDOR_ID 0x20a6
+#define INOVIA_SEW858 0x1105
+
/* some devices interfaces need special handling due to a number of reasons */
enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -1342,6 +1346,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
+ { USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
--
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: usbserial_generic does not recognize Inovia SEW858 (or TE W120) 3G modem
On Thu, Oct 03, 2013 at 11:13:16AM +0400, Pavel Parkhomenko wrote: Hello world! Greg Kroah-Hartman asked me to post this to linux-usb mailing list. Inovia SEW858 (or TE W120) 3G modem is a device with three virtual serial ports, it has VID=0x20a6 and PID=0x1105. To make use of this modem one have to issue $ sudo modprobe -v usbserial vendor=0x20a6 product=0x1105 It is inconvenient to issue such a command or write udev rule for it. It would be better for kernel USB driver to recognize this modem. I've also filed this bug at https://bugzilla.kernel.org/show_bug.cgi?id=62411 This looks like it should work with the option driver, I'll write up a patch and send it out in a bit. If you could test it out, that would be great. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: mv_u3d_core: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
drivers/usb/gadget/mv_u3d_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index 561b30e..5b06c98 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -1936,7 +1936,7 @@ static int mv_u3d_probe(struct platform_device *dev)
}
u3d-irq = r-start;
if (request_irq(u3d-irq, mv_u3d_irq,
- IRQF_DISABLED | IRQF_SHARED, driver_name, u3d)) {
+ IRQF_SHARED, driver_name, u3d)) {
u3d-irq = 0;
dev_err(dev-dev, Request irq %d for u3d failed\n,
u3d-irq);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: uhci-platform: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com --- drivers/usb/host/uhci-platform.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c index d033a0e..ded842b 100644 --- a/drivers/usb/host/uhci-platform.c +++ b/drivers/usb/host/uhci-platform.c @@ -105,8 +105,7 @@ static int uhci_hcd_platform_probe(struct platform_device *pdev) uhci-regs = hcd-regs; - ret = usb_add_hcd(hcd, pdev-resource[1].start, IRQF_DISABLED | - IRQF_SHARED); + ret = usb_add_hcd(hcd, pdev-resource[1].start, IRQF_SHARED); if (ret) goto err_uhci; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] usb-core: Free bulk streams on interface release
Hi, On 10/04/2013 08:43 PM, Alan Stern wrote: On Fri, 4 Oct 2013, Hans de Goede wrote: + struct usb_host_endpoint *ep, *eps[USB_MAXENDPOINTS]; That's a big array to put on the stack: 30 entries each containing 8 bytes (on a 64-bit arch). I was wondering about this myself when I wrote this. What do you suggest as an alternative, kmalloc an array with intf-cur_altsetting-desc.bNumEndpoints pointers ? Or simply do 30 pointers every time. 240 bytes isn't all that much for kmalloc. Right, the allocating intf-cur_altsetting-desc.bNumEndpoints versus 30 pointers is just an optimization. I was wondering more if it would be ok here to do a kmalloc(..., GPF_KERNEL), or if this code path is ever called under interrupt, or some such ? Also do we allow C-99 style variable length arrays in the kernel ? Then we could just put what ever we need on the stack (which almost always will be way less then 240 bytes). 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
[no subject]
Your transfer has been approved, Contact Western union agent with your Name and Tel. donaldsmith...@ymail.com -- 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/2] USB/host: Bugfix: Return length of copied buffer in uhci_hub_control()
On Sat, 5 Oct 2013, Deng-Cheng Zhu wrote: From: Deng-Cheng Zhu dengcheng@imgtec.com In addition to the error statuses -ETIMEDOUT and -EPIPE, uhci_hub_control() needs to return the length of copied buffer when appropriate, so that the returned status of -hub_control() in rh_call_control() in the USB core HCD can be properly handled. This patch also removes the OK() macro to make the code more readable. Reviewed-by: James Hogan james.ho...@imgtec.com Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com --- CHANGES: v2 - v1: o Do the bugfix in uhci_hub_control() in addition to the OK macro removal. Acked-by: Alan Stern st...@rowland.harvard.edu -- 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/9] usb-core: Free bulk streams on interface release
On Sun, 6 Oct 2013, Hans de Goede wrote: I was wondering about this myself when I wrote this. What do you suggest as an alternative, kmalloc an array with intf-cur_altsetting-desc.bNumEndpoints pointers ? Or simply do 30 pointers every time. 240 bytes isn't all that much for kmalloc. Right, the allocating intf-cur_altsetting-desc.bNumEndpoints versus 30 pointers is just an optimization. I was wondering more if it would be ok here to do a kmalloc(..., GPF_KERNEL), or if this code path is ever called under interrupt, or some such ? GFP_KERNEL will be okay. This code always runs in process context with interrupts enabled. Also do we allow C-99 style variable length arrays in the kernel ? Then we could just put what ever we need on the stack (which almost always will be way less then 240 bytes). I think people try to avoid variable-length arrays. Certainly such arrays in structures are frowned upon. 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] usbnet: smsc95xx: Add device tree input for MAC address
On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy dmur...@ti.com wrote:
If the smsc95xx does not have a valid MAC address stored within
the eeprom then a random number is generated. The MAC can also
be set by uBoot but the smsc95xx does not have a way to read this.
Create the binding for the smsc95xx so that uBoot can set the MAC
and the code can retrieve the MAC from the modified DTB file.
Suppose there are two smsc95xx usbnet devices connected to usb bus, and
one is built-in, another is hotplug device, can your patch handle the situation
correctly?
Signed-off-by: Dan Murphy dmur...@ti.com
---
Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++
drivers/net/usb/smsc95xx.c | 24
2 files changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt
b/Documentation/devicetree/bindings/net/smsc95xx.txt
new file mode 100644
index 000..4c37280
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
@@ -0,0 +1,17 @@
+* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
+
+Required properties:
+None
+
+Optional properties:
+- mac-address - Read the mac address that was stored by uBoot
+- local-address - Read the mac address that was stored by uBoot
+- address - Read the mac address that was stored by uBoot
+
+Examples:
+
+smsc0: smsc95xx@0 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+};
+
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 3f38ba8..baee0bd 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -31,6 +31,9 @@
#include linux/crc32.h
#include linux/usb/usbnet.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_net.h
+
#include smsc95xx.h
#define SMSC_CHIPNAME smsc95xx
@@ -62,6 +65,8 @@
#define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1
| \
SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
+#define SMSC95XX_OF_NAME /smsc95xx@
+
struct smsc95xx_priv {
u32 mac_cr;
u32 hash_hi;
@@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+
+#ifdef CONFIG_OF
+ struct device_node *ap;
+ const char *mac = NULL;
+ char *of_name = SMSC95XX_OF_NAME;
+
+ sprintf(of_name, %s%i, SMSC95XX_OF_NAME, dev-udev-dev.id);
+ ap = of_find_node_by_path(of_name);
+ if (ap) {
+ mac = of_get_mac_address(ap);
+ if (is_valid_ether_addr(mac)) {
+ /* Device tree has a mac for this so use that */
+ memcpy(dev-net-dev_addr, mac, ETH_ALEN);
+ netif_dbg(dev, ifup, dev-net, MAC address read from
DTB\n);
+ return;
+ }
+ }
+#endif
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev-net-dev_addr) == 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
On 10/06/2013 10:05 AM, Ming Lei wrote:
On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy dmur...@ti.com wrote:
If the smsc95xx does not have a valid MAC address stored within
the eeprom then a random number is generated. The MAC can also
be set by uBoot but the smsc95xx does not have a way to read this.
Create the binding for the smsc95xx so that uBoot can set the MAC
and the code can retrieve the MAC from the modified DTB file.
Suppose there are two smsc95xx usbnet devices connected to usb bus, and
one is built-in, another is hotplug device, can your patch handle the
situation
correctly?
Look at this line in the patch below
sprintf(of_name, %s%i, SMSC95XX_OF_NAME, dev-udev-dev.id);
I am appending the dev ID of the device to the of_name here. As long as
init_mac_address is called, the dev.id and the uBoot
entry match then yes.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++
drivers/net/usb/smsc95xx.c | 24
2 files changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt
b/Documentation/devicetree/bindings/net/smsc95xx.txt
new file mode 100644
index 000..4c37280
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
@@ -0,0 +1,17 @@
+* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
+
+Required properties:
+None
+
+Optional properties:
+- mac-address - Read the mac address that was stored by uBoot
+- local-address - Read the mac address that was stored by uBoot
+- address - Read the mac address that was stored by uBoot
+
+Examples:
+
+smsc0: smsc95xx@0 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+};
+
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 3f38ba8..baee0bd 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -31,6 +31,9 @@
#include linux/crc32.h
#include linux/usb/usbnet.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_net.h
+
#include smsc95xx.h
#define SMSC_CHIPNAME smsc95xx
@@ -62,6 +65,8 @@
#define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1
| \
SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
+#define SMSC95XX_OF_NAME /smsc95xx@
+
struct smsc95xx_priv {
u32 mac_cr;
u32 hash_hi;
@@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+
+#ifdef CONFIG_OF
+ struct device_node *ap;
+ const char *mac = NULL;
+ char *of_name = SMSC95XX_OF_NAME;
+
+ sprintf(of_name, %s%i, SMSC95XX_OF_NAME, dev-udev-dev.id);
+ ap = of_find_node_by_path(of_name);
+ if (ap) {
+ mac = of_get_mac_address(ap);
+ if (is_valid_ether_addr(mac)) {
+ /* Device tree has a mac for this so use that */
+ memcpy(dev-net-dev_addr, mac, ETH_ALEN);
+ netif_dbg(dev, ifup, dev-net, MAC address read
from DTB\n);
+ return;
+ }
+ }
+#endif
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev-net-dev_addr) == 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thanks,
--
--
Dan Murphy
--
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: wusbcore: add support for isoc out transfers
On Sat, 5 Oct 2013, Greg KH wrote: On Fri, Oct 04, 2013 at 10:40:45AM -0500, Thomas Pugliese wrote: This patch adds support for isochronous out transfers to the HWA. The primary changes are: 1. Add a isoc_pack_desc_urb field to struct wa_seg. This urb is used to send the isochronous packet info message to the HWA which describes the isoc data segment(s) that will be sent as the payload of the transfer request. 2. Use the URB iso_frame_desc field to populate the isochronous packet info message and data segments sent to the HWA. 3. After the data is sent and transfer result is returned from the HWA, read the isoc packet status message from the HWA. The contents of the isoc packet status message are used to set the iso_frame_desc status and actual_length fields in the original isoc URB. This feature required the addition of a some state tracking variables in struct wahc so the dti_urb knows what type of packet it expects to receive next. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/usb/wusbcore/wa-hc.h | 15 ++ drivers/usb/wusbcore/wa-xfer.c | 493 +++- 2 files changed, 406 insertions(+), 102 deletions(-) Nice job, I've applied this, but I'm getting build warnings again, you should really try to test your changes on a 64bit box: drivers/usb/wusbcore/wa-xfer.c: In function ‘__wa_xfer_setup_sizes’: drivers/usb/wusbcore/wa-xfer.c:475:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat] drivers/usb/wusbcore/wa-xfer.c: In function ‘wa_process_iso_packet_status’: drivers/usb/wusbcore/wa-xfer.c:1924:4: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 4 has type ‘int’ [-Wformat] Can you send a follow-on patch fixing this up? thanks, greg k-h Yes. I really need to switch to using my 64-bit machine by default. I had these fixed but I forgot to merge them before submitting. I will send a follow on patch that fixes the warnings. Thanks, Tom
[PATCH] usb: wusbcore: fix string formatting warnings on 64-bit builds
This patch fixes compile warnings on 64-bit builds that were introduced
by the recent isoc changes.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
---
drivers/usb/wusbcore/wa-xfer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/wusbcore/wa-xfer.c b/drivers/usb/wusbcore/wa-xfer.c
index a5543e9..2dba8b6 100644
--- a/drivers/usb/wusbcore/wa-xfer.c
+++ b/drivers/usb/wusbcore/wa-xfer.c
@@ -470,7 +470,7 @@ static ssize_t __wa_xfer_setup_sizes(struct wa_xfer *xfer,
xfer-segs = DIV_ROUND_UP(urb-transfer_buffer_length,
xfer-seg_size);
if (xfer-segs = WA_SEGS_MAX) {
- dev_err(dev, BUG? oops, number of segments %d bigger
than %d\n,
+ dev_err(dev, BUG? oops, number of segments %zu bigger
than %d\n,
(urb-transfer_buffer_length/xfer-seg_size),
WA_SEGS_MAX);
result = -EINVAL;
@@ -1922,7 +1922,7 @@ static void wa_process_iso_packet_status(struct wahc *wa,
struct urb *urb)
dev_dbg(dev, DTI: isoc packet status %d bytes at %p\n,
urb-actual_length, urb-transfer_buffer);
if (urb-actual_length != expected_size) {
- dev_err(dev, DTI Error: isoc packet status--bad urb length (%d
bytes vs %zu needed)\n,
+ dev_err(dev, DTI Error: isoc packet status--bad urb length (%d
bytes vs %d needed)\n,
urb-actual_length, expected_size);
goto error_parse_buffer;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivers: usb: core: hcd: moved asterix to variable
Hello. On 05-10-2013 18:02, Matthias Beyer wrote: s/asterix/asterisk/. Asterix is a hero of the infamous French movies, asterisk is *. instead of type Don't continue the subject this way in he changelog. Signed-off-by: Matthias Beyer m...@beyermatthias.de WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: g_ffs: fix compilation warning
Hello.
On 05-10-2013 0:30, David Cohen wrote:
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of ‘USB_ETHERNET_MODULE_PARAMETERS’ [-Wimplicit-int]
drivers/usb/gadget/g_ffs.c:81:1: warning: function declaration isn’t a
prototype [-Wstrict-prototypes]
This patch fixes the warning by making USB_ETHERNET_MODULE_PARAMETERS to
be used iff u_ether.h is included, otherwise it is not needed.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/g_ffs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index 5327c82..2344efe 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -76,7 +76,9 @@ struct gfs_ffs_obj {
USB_GADGET_COMPOSITE_OPTIONS();
+#if defined CONFIG_USB_FUNCTIONFS_ETH || defined CONFIG_USB_FUNCTIONFS_RNDIS
I thought the 'defined' operator requires ()?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: g_ffs: fix compilation warning
Hi Sergei,
(replying from my personal e-mail)
On Sun, Oct 6, 2013 at 3:02 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Hello.
On 05-10-2013 0:30, David Cohen wrote:
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of ‘USB_ETHERNET_MODULE_PARAMETERS’ [-Wimplicit-int]
drivers/usb/gadget/g_ffs.c:81:1: warning: function declaration isn’t a
prototype [-Wstrict-prototypes]
This patch fixes the warning by making USB_ETHERNET_MODULE_PARAMETERS to
be used iff u_ether.h is included, otherwise it is not needed.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/g_ffs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index 5327c82..2344efe 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -76,7 +76,9 @@ struct gfs_ffs_obj {
USB_GADGET_COMPOSITE_OPTIONS();
+#if defined CONFIG_USB_FUNCTIONFS_ETH || defined CONFIG_USB_FUNCTIONFS_RNDIS
I thought the 'defined' operator requires ()?
I though the same. But I copied this line from this same file when
it's deciding whether to include u_ether.h or not.
BR, David Cohen
--
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
