Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support
On Tue, 2014-01-28 at 16:36 +0800, liujunliang_...@163.com wrote:
From: Liu Junliang liujunliang_...@163.com
trivial comments...
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
[]
+static int sr_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
[]
+ if (size != ((~header 16) 0x07ff)) {
+ netdev_err(dev-net,
+sr_rx_fixup() Bad Header Length\n);
printks with embedded functions names are
generally better using %s: , __func__
netdev_err(dev-net, %s: Bad header length\n,
__func__);
[]
+ netdev_err(dev-net,
+sr_rx_fixup() Bad RX Length %d\n, size);
etc.
+ if (skb-len != offset) {
+ netdev_err(dev-net, sr_rx_fixup() Bad SKB Length %d\n,
+skb-len);
etc.
[]
+static inline int sr9800_set_default_mode(struct usbnet *dev)
+{
rather a big function to inline
[]
+ if (ret 0) {
+ netdev_dbg(dev-net, Write IPG,IPG1,IPG2 failed: %d, ret);
missing newline terminations
+ netdev_dbg(dev-net, RX_CTL is 0x%04x after all initializations,
+rx_ctl);
etc...
--
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] tools: usb: aio example applications
This patch adds two example applications showing usage of Asynchronous I/O API
of FunctionFS. First one (aio_simple) is simple example of bidirectional data
transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
may to be used in high performance applications.
Both examples contains userspace applications for device and for host.
It needs libaio library on the device, and libusb library on host.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
tools/usb/aio_multibuff/device_app/aio_multibuff.c | 270
tools/usb/aio_multibuff/host_app/test.c| 122 +
tools/usb/aio_simple/device_app/aio_simple.c | 246 ++
tools/usb/aio_simple/host_app/test.c | 124 +
4 files changed, 762 insertions(+)
create mode 100644 tools/usb/aio_multibuff/device_app/aio_multibuff.c
create mode 100644 tools/usb/aio_multibuff/host_app/test.c
create mode 100644 tools/usb/aio_simple/device_app/aio_simple.c
create mode 100644 tools/usb/aio_simple/host_app/test.c
diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
new file mode 100644
index 000..df1db84
--- /dev/null
+++ b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
@@ -0,0 +1,270 @@
+#define _BSD_SOURCE /* for endian.h */
+
+#include endian.h
+#include errno.h
+#include fcntl.h
+#include stdarg.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include sys/ioctl.h
+#include sys/stat.h
+#include sys/types.h
+#include sys/poll.h
+#include unistd.h
+#include libaio.h
+
+#include linux/usb/functionfs.h
+
+/ Descriptors and Strings ***/
+
+static const struct {
+ struct usb_functionfs_descs_head header;
+ struct {
+ struct usb_interface_descriptor intf;
+ struct usb_endpoint_descriptor_no_audio bulk_sink;
+ struct usb_endpoint_descriptor_no_audio bulk_source;
+ } __attribute__((packed)) fs_descs, hs_descs;
+} __attribute__((packed)) descriptors = {
+ .header = {
+ .magic = htole32(FUNCTIONFS_DESCRIPTORS_MAGIC),
+ .length = htole32(sizeof descriptors),
+ .fs_count = 3,
+ .hs_count = 3,
+ },
+ .fs_descs = {
+ .intf = {
+ .bLength = sizeof descriptors.fs_descs.intf,
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints = 2,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .iInterface = 1,
+ },
+ .bulk_sink = {
+ .bLength = sizeof descriptors.fs_descs.bulk_sink,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 1 | USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ .bulk_source = {
+ .bLength = sizeof descriptors.fs_descs.bulk_source,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 2 | USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ },
+ .hs_descs = {
+ .intf = {
+ .bLength = sizeof descriptors.hs_descs.intf,
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints = 2,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .iInterface = 1,
+ },
+ .bulk_sink = {
+ .bLength = sizeof descriptors.hs_descs.bulk_sink,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 1 | USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ .bulk_source = {
+ .bLength = sizeof descriptors.hs_descs.bulk_source,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 2 | USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ },
+};
+
+#define STR_INTERFACE AIO Test
+
+static const struct {
+ struct usb_functionfs_strings_head header;
+ struct {
+ __le16 code;
+ const char str1[sizeof STR_INTERFACE];
+ } __attribute__((packed)) lang0;
+} __attribute__((packed)) strings = {
+ .header = {
+ .magic = htole32(FUNCTIONFS_STRINGS_MAGIC),
+ .length = htole32(sizeof strings),
+ .str_count = htole32(1),
+ .lang_count = htole32(1),
+ },
+ .lang0 = {
+ htole16(0x0409), /* en-us */
+ STR_INTERFACE,
+ },
+};
+
+/ Endpoints handling ***/
+
+#define
RE: [PATCH] tools: usb: aio example applications
From: Robert Baldyga This patch adds two example applications showing usage of Asynchronous I/O API of FunctionFS. First one (aio_simple) is simple example of bidirectional data transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which may to be used in high performance applications. Can we have ANSI C with consistent and sensible whtespace? David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tools: usb: aio example applications
On Tue, Jan 28 2014, David Laight david.lai...@aculab.com wrote: From: Robert Baldyga This patch adds two example applications showing usage of Asynchronous I/O API of FunctionFS. First one (aio_simple) is simple example of bidirectional data transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which may to be used in high performance applications. Can we have ANSI C Uhm… I would advise against it since ANSI C does not have named structure initialisers. with consistent and sensible whtespace? But yes, spacing is somehow weird in several places. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH] tools: usb: aio example applications
On Tue, Jan 28 2014, Robert Baldyga wrote:
diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
new file mode 100644
index 000..df1db84
--- /dev/null
+++ b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
+#define USBFFS_DIR usbffs/
Uh?
+int ready = 0;
static bool ready;
+
+static void handle_ep0(int ep0) {
+ struct usb_functionfs_event event;
+ int ret;
+
+ struct pollfd pfds[1];
+ pfds[0].fd = ep0;
+ pfds[0].events = POLLIN;
+
+ poll(pfds, 1, 0);
You should check return code of the function.
+
+ if((pfds[0].revents POLLIN)) {
+ ret = read(ep0, event, sizeof(struct usb_functionfs_event));
+ if(!ret)
+ return;
+ display_event(event);
+ if (event.type == FUNCTIONFS_SETUP) {
+ if (event.u.setup.bRequestType USB_DIR_IN)
+ write(ep0, NULL, 0);
+ else
+ read(ep0, NULL, 0);
+ }
+ if (event.type == FUNCTIONFS_ENABLE)
+ } else if (event.type == FUNCTIONFS_ENABLE) {
It's more obvious what's happening here with else-if.
+ ready = 1;
+ }
Furthermore, you should also handle FUNCTIONFS_DISABLE.
+ }
+}
+
+#define BUF_LEN 8192
+#define BUFS_MAX 128
+#define AIO_MAX BUFS_MAX*2
+
+struct iocb *iocb1[AIO_MAX];
+struct iocb *iocb2[AIO_MAX];
+
+unsigned char *buf1[AIO_MAX];
+unsigned char *buf2[AIO_MAX];
Only half of those buffers are initialised in init_buffs.
+
+void init_bufs() {
+ int i, j;
+ for (i=0; iBUFS_MAX; ++i) {
for (i = 0; i sizeof(buf1) / sizeof(*buf1); ++i) {
Applies for all other for loops.
+ buf1[i] = malloc(BUF_LEN);
+ buf2[i] = malloc(BUF_LEN);
+ for (j=0; jBUF_LEN; ++j) {
+ buf1[i][j] = j%64;
+ buf2[i][j] = j%64;
Is “% 64” really needed here for anything? Why not let it wrap around
256 automatically?
+ }
+ }
+ for (i=0; iAIO_MAX; ++i) {
+ iocb1[i] = malloc(sizeof(struct iocb));
+ iocb2[i] = malloc(sizeof(struct iocb));
+ iocb1[i] = malloc(sizeof(**iocb1));
+ iocb2[i] = malloc(sizeof(**iocb2));
+ }
+}
+int main() {
+ int i, ret;
+ char ep_path[64];
Magic number. “char ep_path[sizeof(USBFFS_DIR) + 3 /* ep# */];” would
be much better.
+
+ int ep0;
+ int ep[2];
+
+ io_context_t ctx;
+
+ int requested1 = 0;
+ int requested2 = 0;
+
+ /* open endpoint files */
+ if((ep0 = open(USBFFS_DIRep0, O_RDWR)) 0) printf(unable to open
ep0\n);
USBFFS_DIR should be taken as argument or assumed to be “./”. Why
“usbffs/”? What if someone wished to mount two FFS gadgets and run this
program twice.
+ if(write(ep0, (void*)descriptors, sizeof descriptors) 0)
printf(unable do write descriptors\n);
+ if(write(ep0, (void*)strings, sizeof strings) 0) printf(unable to
write strings\n);
This is C, there's no need to cast to (void *).
Also, you should probably “return 1” on error instead of continuing, not
to mention that it would be nice to actually see the returned code.
perror may be your friend here. Applies to other places as well.
+ for(i=0; i2; ++i) {
+ sprintf(ep_path, USBFFS_DIRep%d, i+1);
snprintf!
+ if((ep[i] = open(ep_path, O_RDWR | O_NONBLOCK, 0)) 0)
+ printf(unable to open ep%d\n, i+1);
+ }
+
+ memset(ctx, 0, sizeof(ctx));
+ io_setup(AIO_MAX, ctx); /* setup aio context to handle up to AIO_MAX
requests */
+
+ init_bufs();
+
+ while(1) {
+ handle_ep0(ep0);
+ /* we are waiting for function ENABLE */
+ if(!ready) continue;
It would be much better if handle_ep0 took pointer to ready as an
argument. This would avoid unnecessary global variable.
+ /*
+ * when we're preparing new data to submit,
+ * second buffer being transmitted
+ */
+ if (!requested1) { /* if all req's from iocb1 completed */
+ for(i=0; iBUFS_MAX; ++i) /* prepare requests */
+ io_prep_pwrite(iocb1[i], ep[0], buf1[i],
BUF_LEN, 0);
+ /* submit table of requests */
+ ret = io_submit(ctx, BUFS_MAX, iocb1);
+ requested1 = ret;
+ printf(submit: %d requests from buf 1\n, ret);
+ }
+ if (!requested2) { /* if all req's from iocb2 completed */
+ for(i=0; iBUFS_MAX; ++i) /* prepare requests */
+ io_prep_pwrite(iocb2[i], ep[0], buf2[i],
BUF_LEN, 0);
+ /* submit
[PATCH v3] usb: phy: move some error messages to debug
the PHY layer is supposed to be optional,
considering some PHY have no control bus
for SW to poke around.
After commit 1ae5799 (usb: hcd: Initialize
USB phy if needed) any HCD which didn't provide
a PHY driver would emit annoying error messages.
In this patch we're decreasing those messages
to debugging only and we also add a PHY prefix
or use dev_dbg so we know where they're coming from.
Reported-by: Josh Boyer jwbo...@fedoraproject.org
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Josh Boyer jwbo...@fedoraproject.org
---
v3: Use a prefix+pr_debug where dev_dbg won't easily work
drivers/usb/phy/phy.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index e6f61e4..8afa813 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -130,7 +130,7 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
phy = __usb_find_phy(phy_list, type);
if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
- pr_err(unable to find transceiver of type %s\n,
+ pr_debug(PHY: unable to find transceiver of type %s\n,
usb_phy_type_string(type));
goto err0;
}
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8
index)
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
- pr_err(unable to find transceiver\n);
+ dev_dbg(dev, unable to find transceiver\n);
goto err0;
}
@@ -424,10 +424,8 @@ int usb_bind_phy(const char *dev_name, u8 index,
unsigned long flags;
phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
- if (!phy_bind) {
- pr_err(phy_bind(): No memory for phy_bind);
+ if (!phy_bind)
return -ENOMEM;
- }
phy_bind-dev_name = dev_name;
phy_bind-phy_dev_name = phy_dev_name;
--
1.8.5.3
--
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] tools: usb: aio example applications
From: Michal Nazarewicz
On Tue, Jan 28 2014, David Laight david.lai...@aculab.com wrote:
From: Robert Baldyga
This patch adds two example applications showing usage of Asynchronous I/O
API
of FunctionFS. First one (aio_simple) is simple example of bidirectional
data
transfer. Second one (aio_multibuff) shows multi-buffer data transfer,
which
may to be used in high performance applications.
Can we have ANSI C
Uhm… I would advise against it since ANSI C does not have named
structure initialisers.
I was thinking of the bits that are KR C.
Like:
int foo() {
David
Re: [PATCH] HID: usbhid: quirk for CY-TM75 75 inch Touch Overlay
On Mon, 27 Jan 2014, Yufeng Shen wrote:
There is timeout error during initialization:
kernel: [ 11.733104] hid-multitouch 0003:1870:0110.0001:
usb_submit_urb(ctrl) failed: -1
kernel: [ 11.734093] hid-multitouch 0003:1870:0110.0001: timeout
initializing reports
Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
Signed-off-by: Yufeng Shen mile...@chromium.org
Applied.
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..ece2997 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -636,6 +636,7 @@
#define USB_VENDOR_ID_NEXIO 0x1870
#define USB_DEVICE_ID_NEXIO_MULTITOUCH_420 0x010d
+#define USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750 0x0110
#define USB_VENDOR_ID_NEXTWINDOW 0x1926
#define USB_DEVICE_ID_NEXTWINDOW_TOUCHSCREEN 0x0003
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 0db9a67..be5270a 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -74,6 +74,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
HID_QUIRK_NO_INIT_REPORTS },
--
1.8.5.3
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: quirk for CY-TM75 75 inch Touch Overlay
On Mon, 27 Jan 2014, Benjamin Tissoires wrote: There is timeout error during initialization: kernel: [ 11.733104] hid-multitouch 0003:1870:0110.0001: usb_submit_urb(ctrl) failed: -1 kernel: [ 11.734093] hid-multitouch 0003:1870:0110.0001: timeout initializing reports Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem. Could you please test the quirk HID_QUIRK_NO_INIT_INPUT_REPORTS instead? The patch is perfectly fine, but usually when it fails, only the input reports are non-readable, whereas features should. This way, you will still get the value of the features, which _may_ be sensible for the maxcontact information. BTW, HID_QUIRK_NO_INIT_INPUT_REPORTS has been introduced in v3.12 and is the default for Win 8 certified devices. Ah, I have noticed this only after pushing the patch out. Good point. Yufeng, if you test with HID_QUIRK_NO_INIT_INPUT_REPORTS successfully, please let me know, and I'll apply a followup patch on top. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: chipidea: udc: add maximum-speed = full-speed option
This patch makes it possible to set the chipidea udc into full-speed only mode.
It is set by the oftree property maximum-speed = full-speed.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt | 2 ++
drivers/usb/chipidea/bits.h | 2 ++
drivers/usb/chipidea/core.c | 11 +++
include/linux/usb/chipidea.h | 1 +
4 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
index b4b5b79..a6a32cb 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
@@ -18,6 +18,7 @@ Optional properties:
- vbus-supply: regulator for vbus
- disable-over-current: disable over current detect
- external-vbus-divider: enables off-chip resistor divider for Vbus
+- maximum-speed: limit the maximum connection speed to full-speed.
Examples:
usb@02184000 { /* USB OTG */
@@ -28,4 +29,5 @@ usb@02184000 { /* USB OTG */
fsl,usbmisc = usbmisc 0;
disable-over-current;
external-vbus-divider;
+ maximum-speed = full-speed;
};
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index a857131..83d06c1 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -50,12 +50,14 @@
#define PORTSC_PTC(0x0FUL 16)
#define PORTSC_PHCD(d) ((d) ? BIT(22) : BIT(23))
/* PTS and PTW for non lpm version only */
+#define PORTSC_PFSC BIT(24)
#define PORTSC_PTS(d) \
(u32)d) 0x3) 30) | (((d) 0x4) ? BIT(25) : 0))
#define PORTSC_PTWBIT(28)
#define PORTSC_STSBIT(29)
/* DEVLC */
+#define DEVLC_PFSCBIT(23)
#define DEVLC_PSPD(0x03UL 25)
#define DEVLC_PSPD_HS (0x02UL 25)
#define DEVLC_PTW BIT(27)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 33f22bc..e813bf1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -64,6 +64,7 @@
#include linux/usb/otg.h
#include linux/usb/chipidea.h
#include linux/usb/of.h
+#include linux/of.h
#include linux/phy.h
#include linux/regulator/consumer.h
@@ -298,6 +299,13 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
if (ci-platdata-flags CI_HDRC_DISABLE_STREAMING)
hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
+ if (ci-platdata-flags CI_HDRC_FORCE_FULLSPEED) {
+ if (ci-hw_bank.lpm)
+ hw_write(ci, OP_DEVLC, DEVLC_PFSC, DEVLC_PFSC);
+ else
+ hw_write(ci, OP_PORTSC, PORTSC_PFSC, PORTSC_PFSC);
+ }
+
/* USBMODE should be configured step by step */
hw_write(ci, OP_USBMODE, USBMODE_CM, USBMODE_CM_IDLE);
hw_write(ci, OP_USBMODE, USBMODE_CM, mode);
@@ -412,6 +420,9 @@ static int ci_get_platdata(struct device *dev,
}
}
+ if (of_usb_get_maximum_speed(dev-of_node) == USB_SPEED_FULL)
+ platdata-flags |= CI_HDRC_FORCE_FULLSPEED;
+
return 0;
}
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 708bd11..bbe779f 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -25,6 +25,7 @@ struct ci_hdrc_platform_data {
*/
#define CI_HDRC_DUAL_ROLE_NOT_OTG BIT(4)
#define CI_HDRC_IMX28_WRITE_FIXBIT(5)
+#define CI_HDRC_FORCE_FULLSPEEDBIT(6)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
--
1.8.5.3
--
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] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
Hi, On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: Why would you need to know if the PHY drivers are needed or not explicitly in your controller driver? because, one way or another, they all do need it. Except for quirky ones like AM437x where a USB3 IP was hardwired into USB2-only mode, so it really lacks a USB3 PHY. The Baytrail board I deal with has completely autonomous PHYs. But my question is, why would you need to care about the PHYs in your controller driver? Why can't you leave the responsibility of them to the upper layers and trust what they tell you? If there is no USB3 PHY for dwc3 then, the driver gets something like -ENODEV and just continues. There is no need to know about the details. For the controller drivers the PHYs are just a resource like any other. The controller drivers can't have any responsibility of them. They should not care if PHY drivers are available for them or not, or even if the PHY framework is available or not. But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. that's different from what I heard. I don't know where you got that impression, but it's not true. The Baytrail SoCs for example don't have internal USB PHYs, which means the manufacturers using it can select what they want. So we have boards where PHY driver(s) is needed and boards where it isn't. The problem is that we just don't always know all the details about the platform. If the PHY is ULPI PHY, we can do runtime detection, but we can't even rely on always having ULPI. Are we talking about the old USB PHY library or the new PHY framework with the no-op PHY driver? Well, in any case, I don't understand what is the purpose of the no-op PHY driver. What are you drying to achieve with that? I'm trying to avoid supporting 500 different combinations for a single driver. We already support old USB PHY layer and generic PHY layer, now they both need to be made optional. This is really good to get. We have some projects where we are dealing with more embedded environments, like IVI, where the kernel should be stripped of everything useless. Since the PHYs are autonomous, we should be able to disable the PHY libraries/frameworks. But I still don't understand what is the benefit in the no-op? You really need to explain this. What you have now in dwc3 is expectations regarding the PHY, which put a lot of pressure on upper layers to satisfy the driver. The no-op is just an extra thing that you have to provide when you fail to determine if the system requires a PHY driver or not, or if you know that it doesn't, plus an additional check for the case where the PHY lib/framework is not enabled. I don't see the value in it. The old USB PHY layer also provides a no-op, now called phy-generic, which is actually pretty useful. On top of all that, I'm sure you'll subscribe to the idea of preventing dwc3 from becoming another MUSB which supports several different configurations and none work correctly. I much prefer to take baby steps which are well thought-out and very well exercised, so I'll be very pedantic about proof of testing. I think our goals are the same. I just want to also minimize the need for any platform specific extra work from the upper layers regarding the PHYs. Thanks, -- heikki -- 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] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
Hi, On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote: On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: Why would you need to know if the PHY drivers are needed or not explicitly in your controller driver? because, one way or another, they all do need it. Except for quirky ones like AM437x where a USB3 IP was hardwired into USB2-only mode, so it really lacks a USB3 PHY. The Baytrail board I deal with has completely autonomous PHYs. But my question is, why would you need to care about the PHYs in your controller driver? Why can't you leave the responsibility of them to the upper layers and trust what they tell you? If there is no USB3 PHY for dwc3 then, the driver gets something like -ENODEV and just continues. There is no need to know about the details. it's a little more complicated than that. We could get -EPROBE_DEFER meaning we should try probing at a later time because the PHY isn't available yet. But sure, if we can very easily differentiate between those two conditions in a way that error report from PHY layer (whichever it is), then we can certainly do that. For the controller drivers the PHYs are just a resource like any other. The controller drivers can't have any responsibility of them. They should not care if PHY drivers are available for them or not, or even if the PHY framework is available or not. huh? If memory isn't available you don't continue probing, right ? If your IORESOURCE_MEM is missing, you also don't continue probing, if your IRQ line is missing, you bail too. Those are also nothing but resources to the driver, what you're asking here is to treat PHY as a _different_ resource; which might be fine, but we need to make sure we don't continue probing when a PHY is missing in a platform that certainly needs a PHY. But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. that's different from what I heard. I don't know where you got that impression, but it's not true. The Baytrail SoCs for example don't have internal USB PHYs, which means the manufacturers using it can select what they want. So we have boards where PHY driver(s) is needed and boards where it isn't. alright, that explains it ;-) So you have external USB2 and USB3 PHYs ? You have an external PIPE3 interface ? That's quite an achievement, kudos to your HW designers. Getting timing closure on PIPE3 is a difficult task. The problem is that we just don't always know all the details about the platform. If the PHY is ULPI PHY, we can do runtime detection, but we can't even rely on always having ULPI. right, we've had that before on n900 ;-) Are we talking about the old USB PHY library or the new PHY framework with the no-op PHY driver? Well, in any case, I don't understand what is the purpose of the no-op PHY driver. What are you drying to achieve with that? I'm trying to avoid supporting 500 different combinations for a single driver. We already support old USB PHY layer and generic PHY layer, now they both need to be made optional. This is really good to get. We have some projects where we are dealing with more embedded environments, like IVI, where the kernel should be stripped of everything useless. Since the PHYs are autonomous, we should be able to disable the PHY libraries/frameworks. hmmm, in that case it's a lot easier to treat. We can use ERR_PTR(-ENXIO) as an indication that the framework is disabled, or something like that. The difficult is really reliably supporting e.g. OMAP5 (which won't work without a PHY) and your BayTrail with autonomous PHYs. What can we use as an indication ? I mean, I need to know that a particular platform depends on a PHY driver before I decide to return -EPROBE_DEFER or just assume the PHY isn't needed ;-) But I still don't understand what is the benefit in the no-op? You really need to explain this. What you have now in dwc3 is expectations regarding the PHY, which put a lot of pressure on upper layers to satisfy the driver. The no-op is just an extra thing that you have to provide when you fail to determine if the system requires a PHY driver or not, or if you know that it doesn't, plus an additional check for the case where the PHY lib/framework is not enabled. I don't see the value in it. it solves the difficulty above. If everybody has to provide a PHY driver, the problem is a lot simpler don't you think ? ;-) The old USB PHY layer also provides
Re: [PATCH v2 1/1] USB: EHCI: wait more than 3ms until the device enters full-speed idle
On Tue, 28 Jan 2014, Peter Chen wrote:
It sounds like this is a bug in your EHCI hardware. The
wake-on-disconnect logic should never take effect until after the port
goes into full-speed idle.
Where EHCI spec said that? I can't find it at 2.3.9 and 4.3.
It doesn't say that. Not explicitly.
On the other hand, it doesn't say that you have to wait for the port to
enter full-speed idle after turning on the Suspend bit before you can
turn on WKDSCNNT_E bit.
@@ -301,6 +301,18 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
if (t1 != t2) {
ehci_writel(ehci, t2, reg);
+ if ((t2 PORT_WKDISC_E)
+ (ehci_port_speed(ehci, t2) ==
+ USB_PORT_STAT_HIGH_SPEED)) {
+ /*
+ * If the high-speed device has not switched
+ * to full-speed idle before WKDISC_E has
+ * effected, there will be a WKDISC event.
+ */
+ spin_unlock_irq(ehci-lock);
+ usleep_range(3500, 4000);
+ spin_lock_irq(ehci-lock);
+ }
This doesn't look like it will do what you want. t2 already has the
PORT_WKDISC_E bit set, so once the
ehci_writel(ehci, t2, reg);
has executed, it is already too late. Instead, you should write (t2
~PORT_WKDISC_E), then wait a few ms, and then write t2.
Yes, it is safe for writing suspendM first, wait 3-4ms, then write
PORT_WKDISC_E. The reason why my proposal change is ok is the wakeup logic
has still not taken effect before the PHY enters low power mode.
What happens if you start putting a different PHY on the board, one
that takes longer to enter low-power mode?
Since this bug seems to affect only a few EHCI controllers, we should
have a quirk flag for it. There's no need to make everybody wait 3.5-4
ms just for the sake of a few pieces of buggy hardware.
OK, I will add the quirk if you can point me it is not a standard ehci
operation.
So far I have not seen any complaints about this happening from any
user except you. I just tried doing the experiment on my own computer
(enable wakeup for the root hub, plug in a high-speed device, and
suspend the computer). It worked correctly.
Also, there already is a 5-ms sleep just below the code you changed.
It depends on ehci-has_tdi_phy_lpm. Is that flag set for your system?
If it isn't, you could simply remove the test for has_tdi_phy_lpm.
That should have the same effect as your patch.
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] tools: usb: aio example applications
On Tue, Jan 28 2014, David Laight wrote:
I was thinking of the bits that are KR C.
Like:
int foo() {
For that I think the code should stick to Linux style guide (even though
in this particular instance, I do not agree with it).
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH 1/1] usb: chipidea: udc: refine ep operation at isr_tr_complete_handler
On Mon, Jan 27, 2014 at 08:58:15AM +0800, Peter Chen wrote:
- delete the warning message at interrupt handler, and adds judgement at
ep_enable, if non-ep0 requests ctrl transfer, it will indicate an error.
- delete hw_test_and_clear_setup_status which is a broken code
- Tested with g_mass_storage, g_ncm, g_ether
Cc: matthieu.cas...@parrot.com
Reported-by: Michael Grzeschik m...@pengutronix.de
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c | 28
1 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 0a61c66..0dc56ae 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -178,19 +178,6 @@ static int hw_ep_get_halt(struct ci_hdrc *ci, int num,
int dir)
}
/**
- * hw_test_and_clear_setup_status: test clear setup status (execute without
- * interruption)
- * @n: endpoint number
- *
- * This function returns setup status
- */
-static int hw_test_and_clear_setup_status(struct ci_hdrc *ci, int n)
-{
- n = ep_to_bit(ci, n);
- return hw_test_and_clear(ci, OP_ENDPTSETUPSTAT, BIT(n));
-}
-
-/**
* hw_ep_prime: primes endpoint (execute without interruption)
* @num: endpoint number
* @dir: endpoint direction
@@ -997,14 +984,10 @@ __acquires(ci-lock)
}
}
- if (hwep-type != USB_ENDPOINT_XFER_CONTROL ||
- !hw_test_and_clear_setup_status(ci, i))
- continue;
-
- if (i != 0) {
- dev_warn(ci-dev, ctrl traffic at endpoint %d\n, i);
+ /* Only handle setup packet below */
+ if (i != 0 ||
+ !hw_test_and_clear(ci, OP_ENDPTSETUPSTAT, BIT(0)))
continue;
- }
/*
* Flush data and handshake transactions of previous
@@ -1193,6 +1176,11 @@ static int ep_enable(struct usb_ep *ep,
hwep-qh.ptr-td.next |= cpu_to_le32(TD_TERMINATE); /* needed? */
+ if (hwep-num != 0 hwep-type == USB_ENDPOINT_XFER_CONTROL) {
+ dev_err(hwep-ci-dev, Set control xfer at non-ep0\n);
+ retval = -EINVAL;
+ }
+
/*
* Enable endpoints in the HW other than ep0 as ep0
* is always enabled
--
1.7.8
Acked-by: Michael Grzeschik m...@pengutronix.de
Tested-by: Michael Grzeschik m...@pengutronix.de
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] tools: usb: aio example applications
Nice to have a complete kernel+userspace example. Thanks!
Robert Baldyga wrote:
+++ b/tools/usb/aio_multibuff/host_app/test.c
@@ -0,0 +1,122 @@
+#include libusb-1.0/libusb.h
Please don't do this.
Please always #include libusb.h and call some combination of:
pkg-config --cflags libusb-1.0
pkg-config --libs libusb-1.0
in the host application Makefile to get the correct compiler and
linker flags.
This allows your example Makefile to compile the application
correctly across all platforms supported by libusb, and perhaps even
more importantly it allows the host application to be cross-compiled
simply by setting PKG_CONFIG_LIBDIR appropriately for the
cross-compile toolchain.
Using pkg-config solves a whole bunch of problems - but it only works
if it's actually used, so please do. ;)
+int test_init(struct test_state *state) {
+ int ret, i;
+ ssize_t cnt;
+
+ state-found = NULL;
+ state-ctx = NULL;
+ state-handle = NULL;
+ state-attached = 0;
+
+ libusb_init(state-ctx);
Please check the return value. Suggest:
if (libusb_init(state-ctx) != LIBUSB_SUCCESS) {
..
Also, create an exit path for the case that libusb returns an error
in test_init() so that your example demonstrates how to properly free
all libusb resources.
The current flow makes errors bubble up to main() which does a
return 1; and will leak if the code is copypasted into a larger
program as opposed to being used as a standalone example.
But I may be exaggerating this problem if nobody copypastes.. ;)
+ if(libusb_kernel_driver_active(state-handle ,0)) {
+ printf(device busy.. deatching\n);
typo, detaching, but..
+ libusb_detach_kernel_driver(state-handle, 0);
+ state-attached = 1;
+ }
+ else
+ printf(device free from kernel\n);
+
+ if(ret = libusb_claim_interface(state-handle, 0)) {
+ printf(failed to claim interface\n);
+ return 1;
+ }
..this construct is unneccessarily racy. I suggest to directly call
_claim_interface() after libusb_open() and on failure then call
_detach_kernel_driver() and after that _claim_interface() a second
time.
If the second claim also fails then give up, clean up, tell user to
sort it out and exit.
+ else {
+ printf(no devices found\n);
+ libusb_free_device_list(state-list, 1);
+ libusb_exit(state-ctx);
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * test_exit - cleanup test program
+ */
+
+void test_exit(struct test_state *state) {
+ if(state-attached == 1)
+ libusb_attach_kernel_driver(state-handle, 0);
+ libusb_close(state-handle);
+ libusb_free_device_list(state-list, 1);
+ libusb_exit(state-ctx);
+}
I would call libusb_free_device_list() within test_init() *after*
having called libusb_open() on the device. There's no real reason
to keep the device list within struct test_state.
//Peter
--
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/1] usbip/userspace/libsrc/names.c: memory leak
From: Heinrich Schuchardt xypron.g...@gmx.de
revised patch
p is freed if NULL.
p is leaked if second calloc fails.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
drivers/staging/usbip/userspace/libsrc/names.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/names.c
b/drivers/staging/usbip/userspace/libsrc/names.c
index 3c8d28b..81ff852 100644
--- a/drivers/staging/usbip/userspace/libsrc/names.c
+++ b/drivers/staging/usbip/userspace/libsrc/names.c
@@ -169,14 +169,14 @@ static void *my_malloc(size_t size)
struct pool *p;
p = calloc(1, sizeof(struct pool));
- if (!p) {
- free(p);
+ if (!p)
return NULL;
- }
p-mem = calloc(1, size);
- if (!p-mem)
+ if (!p-mem) {
+ free(p);
return NULL;
+ }
p-next = pool_head;
pool_head = p;
--
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
Help testing for USB ethernet/xHCI regression
Hi Mark,
You reported that you had an issue with a USB ethernet device on 3.12,
and that updating to 3.13-rc4 (which included commit 587194873820 xhci:
convert TRB_CYCLE to le32 before using it to set Link TRB's cycle bit)
fixed the issue for you. Later you said applying that patch on top of
3.12 didn't fix your issue. It was unclear whether your issue was fixed
by another patch in 3.13-rc4.
That particular commit is causing regressions in the storage
layer (which we've fixed) and now also the usbfs layer (which has a
potential solution). It also causes issues with 0.96 ASMedia xHCI hosts
(which also has a potential solution).
I'm concerned that there will be further regressions as well. Before
applying additional regression fixes for David's patch, I'd like to slow
down and double check that the patch actually solved the issue it set
out to.
Can you please pull this branch, which contains a 3.13 kernel with
David's patch reverted, and test whether your USB ethernet device works
or fails?
git clone -b 3.13-td-changes-reverted
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
If it fails, please turn on xHCI debugging:
# echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control
trigger the failure, and send me the resulting dmesg, along with the
procedure/commands you used to make the device fail.
Also, please double check to see if vanilla 3.13 works or fails.
David, please do the same and send me dmesg.
I know the log will be large due to untransferred length message, but
I need those messages, so please compress the files or stick the dmesg
up on pastebin.
Thanks,
Sarah Sharp
On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote:
On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote:
The following changes since commit
c24cb6c8b501ebdf1aacec7960110a9741a45ced:
Merge tag 'fixes-for-v3.13-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
(2013-11-27 09:49:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
tags/for-usb-linus-2013-12-02
Pulled and pushed out, thanks.
Did this commit make it into linux-3.12.3 ?
I ask, because the NIC still locks up with that kernel,
and even with the patch I had been using from David Laight.
Reverting the change that originally broke it still works though.
Could we please get this reverted until such time as a reworked
patch can be prepared for it?
This is what I am reverting locally to make it all work
as it did prior to linux-3.12 was released. Unmangled copy also attached:
--- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0
-0500
+++ linux/drivers/net/usb/ax88179_178a.c 2013-11-17 13:23:39.525734277
-0500
@@ -1177,18 +1177,31 @@
int frame_size = dev-maxpacket;
int mss = skb_shinfo(skb)-gso_size;
int headroom;
+ int tailroom;
tx_hdr1 = skb-len;
tx_hdr2 = mss;
if (((skb-len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000; /* Enable padding */
- headroom = skb_headroom(skb) - 8;
+ headroom = skb_headroom(skb);
+ tailroom = skb_tailroom(skb);
- if ((skb_header_cloned(skb) || headroom 0)
- pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) {
+ if (!skb_header_cloned(skb)
+ !skb_cloned(skb)
+ (headroom + tailroom) = 8) {
+ if (headroom 8) {
+ skb-data = memmove(skb-head + 8, skb-data, skb-len);
+ skb_set_tail_pointer(skb, skb-len);
+ }
+ } else {
+ struct sk_buff *skb2;
+
+ skb2 = skb_copy_expand(skb, 8, 0, flags);
dev_kfree_skb_any(skb);
- return NULL;
+ skb = skb2;
+ if (!skb)
+ return NULL;
}
skb_push(skb, 4);
--- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0
-0500
+++ linux/drivers/net/usb/ax88179_178a.c 2013-11-17 13:23:39.525734277
-0500
@@ -1177,18 +1177,31 @@
int frame_size = dev-maxpacket;
int mss = skb_shinfo(skb)-gso_size;
int headroom;
+ int tailroom;
tx_hdr1 = skb-len;
tx_hdr2 = mss;
if (((skb-len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000; /* Enable padding */
- headroom = skb_headroom(skb) - 8;
+ headroom = skb_headroom(skb);
+ tailroom = skb_tailroom(skb);
- if ((skb_header_cloned(skb) || headroom 0)
- pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) {
+ if (!skb_header_cloned(skb)
+ !skb_cloned(skb)
+ (headroom + tailroom) = 8) {
+ if (headroom 8) {
+ skb-data = memmove(skb-head + 8, skb-data, skb-len);
+ skb_set_tail_pointer(skb,
[PATCH v3] usb: core: Fix potential memory leak adding dyn USBdevice IDs
Fix a memory leak in the usb_store_new_id() error paths. When bailing out
due to sanity checks, the function left the already allocated usb_dynid
struct in place. This regression was introduced by the following commits:
c63fe8f6 (usb: core: add sanity checks when using bInterfaceClass with new_id)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)
Detected by Coverity: CID 1162604.
Signed-off-by: Christian Engelmayer cenge...@gmx.at
---
v2: Added changes suggested by Sergei Shtylyov:
* Fixed coding style violation regarding usage of braces in if-statements
if only one branch of a conditional statement is a single statement.
* Keep the information on commits introducing the issue in the changelog.
v3: Added changes suggested by Wolfram Sang:
* Change the function to use a centralized exit and cleanup path.
---
drivers/usb/core/driver.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 5d01558..ab90a01 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -63,8 +63,10 @@ ssize_t usb_store_new_id(struct usb_dynids *dynids,
dynid-id.idProduct = idProduct;
dynid-id.match_flags = USB_DEVICE_ID_MATCH_DEVICE;
if (fields 2 bInterfaceClass) {
- if (bInterfaceClass 255)
- return -EINVAL;
+ if (bInterfaceClass 255) {
+ retval = -EINVAL;
+ goto fail;
+ }
dynid-id.bInterfaceClass = (u8)bInterfaceClass;
dynid-id.match_flags |= USB_DEVICE_ID_MATCH_INT_CLASS;
@@ -73,17 +75,21 @@ ssize_t usb_store_new_id(struct usb_dynids *dynids,
if (fields 4) {
const struct usb_device_id *id = id_table;
- if (!id)
- return -ENODEV;
+ if (!id) {
+ retval = -ENODEV;
+ goto fail;
+ }
for (; id-match_flags; id++)
if (id-idVendor == refVendor id-idProduct ==
refProduct)
break;
- if (id-match_flags)
+ if (id-match_flags) {
dynid-id.driver_info = id-driver_info;
- else
- return -ENODEV;
+ } else {
+ retval = -ENODEV;
+ goto fail;
+ }
}
spin_lock(dynids-lock);
@@ -95,6 +101,10 @@ ssize_t usb_store_new_id(struct usb_dynids *dynids,
if (retval)
return retval;
return count;
+
+fail:
+ kfree(dynid);
+ return retval;
}
EXPORT_SYMBOL_GPL(usb_store_new_id);
--
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 v3] usb: core: Fix potential memory leak adding dyn USBdevice IDs
On Tue, Jan 28, 2014 at 10:22:27PM +0100, Christian Engelmayer wrote: Fix a memory leak in the usb_store_new_id() error paths. When bailing out due to sanity checks, the function left the already allocated usb_dynid struct in place. This regression was introduced by the following commits: c63fe8f6 (usb: core: add sanity checks when using bInterfaceClass with new_id) 1b9fb31f (usb: core: check for valid id_table when using the RefId feature) 52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id) Detected by Coverity: CID 1162604. Signed-off-by: Christian Engelmayer cenge...@gmx.at Acked-by: Wolfram Sang w...@the-dreams.de signature.asc Description: Digital signature
Re: [PATCH] xhci: Limit TD fragments to 1.0 xHCI hosts only.
On 01/27/2014 03:49 PM, Sarah Sharp wrote: Walt reports that the PCI add-in card for his 0.96 ASMedia host dies in a particular machine. This symptom goes away when commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB must not occur within a USB payload burst is reverted. Only 1.0 xHCI hosts actually need TD fragments, so limit that patch to only work on 1.0 hosts. Leave the scatter-gather entry length limitation in tact, to ensure consistent buffer limitation lengths across host controller versions. Otherwise we'll have some very confused driver writers. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: walt w41...@gmail.com Cc: sta...@vger.kernel.org # 3.12 Cc: David Laight david.lai...@aculab.com --- Walt, will you please put your ASMedia host into the system it failed on, and test this patch on 3.13 (or the last vanilla kernel it failed on)? Thanks, Sarah Sharp drivers/usb/host/xhci-ring.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index a0b248c34526..bdda69fd1651 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2971,6 +2971,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring, TRBS_PER_SEGMENT - 1 - trb; u32 nop_cmd; + if (xhci-hci_version 0x100) + break; /* * Section 4.11.7.1 TD Fragments states that a link * TRB must only occur at the boundary between I unintentionally replied to Sarah's email. This is a cc to the list that the above patch restores normal behavior to my ASMedia adapter. -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com log.gz Description: GNU Zip compressed data
Re: Help testing for USB ethernet/xHCI regression
On 14-01-28 11:30 PM, Mark Lord wrote: On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. Vanilla 3.13 does not appear to have the USB3 ethernet lockup issue, and even USB3 hot-plug appears to be working again (was not working in 3.13-rc4). Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.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: Help testing for USB ethernet/xHCI regression
Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. Regards, Will Trives -- 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: Help testing for USB ethernet/xHCI regression
just to add I have a vantec 2 bay usb 3.0 disk dock that has appeared to always work fine connected to the asmedia 1042 with version 3.13 and with 3.14 (with the writeq reversion and transciever fix) On Wednesday 29 January 2014 16:21:00 you wrote: Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. Regards, Will Trives -- 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] phy-rcar-usb-gen2: add device tree support
On Mon, Jan 27, 2014 at 07:06:26PM +, Ben Dooks wrote:
On 27/01/14 18:23, Sergei Shtylyov wrote:
Hello.
On 01/26/2014 08:05 PM, Ben Dooks wrote:
[snip]
+static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
+{ .compatible = renesas,usb-phy-r8a7790, },
+{ .compatible = renesas,rcar-gen2-usb-phy, },
Frankly speaking, I don't understand the need for the clearly
duplicate entries.
Thanks, will look into remove it.
Anyone else have any comments on this?
I would like you to leave it there.
As we know the r8a7790 is an R-Car Gen2 SoC. But there are other R-Car
Gen2 SoCs, such as the r8a7791, they it could plausibly make use of
rcar-gen2-usb-phy until the driver is updated with a usb-phy-r8a7791 entry.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] usb: gadget: functionfs: replace FFS_SETUP_STATUS with an inline function
From: Michal Nazarewicz min...@mina86.com
The FFS_SETUP_STATUS macro could be trivialy replaced with an static
inline function but more importantly its name was tad confusing.
The name suggested it was a simple accessor macro but it actually
did change the state of the ffs_data structure perfomring
a FFS_SETUP_CANCELLED - FFS_NO_SETUP transition. The name of the
function -- ffs_setup_state_clear_cancelled -- should better
describe what the function actually does.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/f_fs.c | 22 --
drivers/usb/gadget/u_fs.h |7 +++
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 4010332..6267fb0 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -99,6 +99,14 @@ static struct ffs_function *ffs_func_from_usb(struct
usb_function *f)
}
+static inline enum ffs_setup_state
+ffs_setup_state_clear_cancelled(struct ffs_data *ffs)
+{
+ return (enum ffs_setup_state)
+ cmpxchg(ffs-setup_state, FFS_SETUP_CANCELLED, FFS_NO_SETUP);
+}
+
+
static void ffs_func_eps_disable(struct ffs_function *func);
static int __must_check ffs_func_eps_enable(struct ffs_function *func);
@@ -244,7 +252,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
+ if (ffs_setup_state_clear_cancelled(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -310,7 +318,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* rather then _irqsave
*/
spin_lock_irq(ffs-ev.waitq.lock);
- switch (FFS_SETUP_STATE(ffs)) {
+ switch (ffs_setup_state_clear_cancelled(ffs)) {
case FFS_SETUP_CANCELLED:
ret = -EIDRM;
goto done_spin;
@@ -355,7 +363,8 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* transition can be performed and it's protected by
* mutex.
*/
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
+ if (ffs_setup_state_clear_cancelled(ffs) ==
+ FFS_SETUP_CANCELLED) {
ret = -EIDRM;
done_spin:
spin_unlock_irq(ffs-ev.waitq.lock);
@@ -421,7 +430,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
+ if (ffs_setup_state_clear_cancelled(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -441,7 +450,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
*/
spin_lock_irq(ffs-ev.waitq.lock);
- switch (FFS_SETUP_STATE(ffs)) {
+ switch (ffs_setup_state_clear_cancelled(ffs)) {
case FFS_SETUP_CANCELLED:
ret = -EIDRM;
break;
@@ -489,7 +498,8 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(ffs-ev.waitq.lock);
/* See ffs_ep0_write() */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
+ if (ffs_setup_state_clear_cancelled(ffs) ==
+ FFS_SETUP_CANCELLED) {
ret = -EIDRM;
break;
}
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index 3c0cd3f..ab3de01 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -174,13 +174,12 @@ struct ffs_data {
* happens only in ep0 i/o which is P: mutex
* + FFS_SETUP_PENDING - FFS_SETUP_CANCELLED -- P: ev.waitq.lock
* + FFS_SETUP_CANCELLED - FFS_NO_SETUP-- cmpxchg
+*
+* This field should never be accessed directly and instead
+* ffs_setup_state_clear_cancelled function should be used.
*/
enum ffs_setup_statesetup_state;
-#define FFS_SETUP_STATE(ffs) \
- ((enum ffs_setup_state)cmpxchg((ffs)-setup_state, \
- FFS_SETUP_CANCELLED, FFS_NO_SETUP))
-
/* Events such. */
struct {
u8 types[4];
--
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 v4 0/5] usb: gadget: f_fs: add asynchronous I/O support
Hello, This is fourth version of patches containing improvements for FunctionFS which allows to use it with asynchronous I/O interface. It also adds poll function for ep0, to make it usable without creating additional thread, needed by blocking I/O. From last version I have fixed few nit's, and made some modifications improving request completion handling. This patchset contains two patches with fixes, created by Michal Nazarewicz. More details in commit messages. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v4: - move completion code into worker to make cancel function asynchronous v3: http://www.spinics.net/lists/linux-usb/msg101324.html - clean up code - add allocation result checks - fix FFS_SETUP_CANCELLED state handling in ffs_ep0_poll() function - aio_complete() function is not called if request was cancelled v2: http://www.spinics.net/lists/linux-usb/msg101104.html - fix style problems - add error handling in ffs_user_copy_worker() - fix paremeters of aio_complete() in ffs_epfile_async_io_complete() - in ffs_epfile_io() do copy_from_user() calls with spinlock unlocked - in ffs_ep0_poll() remove default from switch-case block and add case for each enum value - fix returned value in __ffs_ep0_queue_wait() funcion v1: http://www.spinics.net/lists/linux-usb/msg100969.html - initial proposal Michal Nazarewicz (2): usb: gadget: functionfs: fix typo in the enum variable usb: gadget: functionfs: replace FFS_SETUP_STATUS with an inline function Michal Nazarewicz (2): usb: gadget: functionfs: fix typo in the enum variable usb: gadget: functionfs: replace FFS_SETUP_STATUS with an inline function Robert Baldyga (3): usb: gadget: f_fs: fix setup request handling usb: gadget: f_fs: add poll for endpoint 0 usb: gadget: f_fs: add aio support drivers/usb/gadget/f_fs.c | 337 - drivers/usb/gadget/u_fs.h | 18 ++- 2 files changed, 308 insertions(+), 47 deletions(-) -- 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 v4 1/5] usb: gadget: functionfs: fix typo in the enum variable
From: Michal Nazarewicz min...@mina86.com
Since “cancelled” is spelled with two “l”s, rename FFS_SETUP_CANCELED
to FFS_SETUP_CANCELLED.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/f_fs.c | 16
drivers/usb/gadget/u_fs.h | 12 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 306a2b5..4010332 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -244,7 +244,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED)
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -311,7 +311,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
*/
spin_lock_irq(ffs-ev.waitq.lock);
switch (FFS_SETUP_STATE(ffs)) {
- case FFS_SETUP_CANCELED:
+ case FFS_SETUP_CANCELLED:
ret = -EIDRM;
goto done_spin;
@@ -346,7 +346,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
/*
* We are guaranteed to be still in FFS_ACTIVE state
* but the state of setup could have changed from
-* FFS_SETUP_PENDING to FFS_SETUP_CANCELED so we need
+* FFS_SETUP_PENDING to FFS_SETUP_CANCELLED so we need
* to check for that. If that happened we copied data
* from user space in vain but it's unlikely.
*
@@ -355,7 +355,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* transition can be performed and it's protected by
* mutex.
*/
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED) {
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
ret = -EIDRM;
done_spin:
spin_unlock_irq(ffs-ev.waitq.lock);
@@ -421,7 +421,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED)
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -442,7 +442,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(ffs-ev.waitq.lock);
switch (FFS_SETUP_STATE(ffs)) {
- case FFS_SETUP_CANCELED:
+ case FFS_SETUP_CANCELLED:
ret = -EIDRM;
break;
@@ -489,7 +489,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(ffs-ev.waitq.lock);
/* See ffs_ep0_write() */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED) {
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
ret = -EIDRM;
break;
}
@@ -1784,7 +1784,7 @@ static void __ffs_event_add(struct ffs_data *ffs,
* the source does nothing.
*/
if (ffs-setup_state == FFS_SETUP_PENDING)
- ffs-setup_state = FFS_SETUP_CANCELED;
+ ffs-setup_state = FFS_SETUP_CANCELLED;
switch (type) {
case FUNCTIONFS_RESUME:
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index bc2d371..3c0cd3f 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -125,7 +125,7 @@ enum ffs_setup_state {
* setup. If this state is set read/write on ep0 return
* -EIDRM. This state is only set when adding event.
*/
- FFS_SETUP_CANCELED
+ FFS_SETUP_CANCELLED
};
struct ffs_data {
@@ -168,18 +168,18 @@ struct ffs_data {
/*
* Possible transitions:
-* + FFS_NO_SETUP - FFS_SETUP_PENDING -- P: ev.waitq.lock
+* + FFS_NO_SETUP- FFS_SETUP_PENDING -- P: ev.waitq.lock
* happens only in ep0 read which is P: mutex
-* + FFS_SETUP_PENDING - FFS_NO_SETUP -- P: ev.waitq.lock
+* + FFS_SETUP_PENDING - FFS_NO_SETUP -- P: ev.waitq.lock
* happens only in ep0 i/o which is P: mutex
-* + FFS_SETUP_PENDING - FFS_SETUP_CANCELED -- P: ev.waitq.lock
-* + FFS_SETUP_CANCELED - FFS_NO_SETUP -- cmpxchg
+* + FFS_SETUP_PENDING - FFS_SETUP_CANCELLED -- P: ev.waitq.lock
+* + FFS_SETUP_CANCELLED - FFS_NO_SETUP-- cmpxchg
*/
enum ffs_setup_statesetup_state;
#define FFS_SETUP_STATE(ffs) \
((enum
[PATCH v4 5/5] usb: gadget: f_fs: add aio support
This patch adds asynchronous I/O support for FunctionFS endpoint files.
It adds ffs_epfile_aio_write() and ffs_epfile_aio_read() functions responsible
for preparing AIO operations.
It also modifies ffs_epfile_io() function, adding aio handling code. Instead
of extending list of parameters of this function, there is new struct
ffs_io_data which contains all information needed to perform I/O operation.
Pointer to this struct replaces buf and len parameters of ffs_epfile_io()
function. Allocated buffer is freed immediately only after sync operation,
because in async IO it's freed in complete funcion. For each async operation
an USB request is allocated, because it allows to have more than one request
queued on single endpoint.
According to changes in ffs_epfile_io() function, functions ffs_epfile_write()
and ffs_epfile_read() are updated to use new API.
For asynchronous I/O operations there is new request complete function named
ffs_epfile_async_io_complete(), which completes AIO operation, and frees
used memory.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 265 -
1 file changed, 239 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 7d04050..21b660f 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -28,6 +28,8 @@
#include linux/usb/composite.h
#include linux/usb/functionfs.h
+#include linux/aio.h
+#include linux/mmu_context.h
#include linux/poll.h
#include u_fs.h
@@ -158,6 +160,25 @@ struct ffs_epfile {
unsigned char _pad;
};
+/* ffs_io_data structure ***/
+
+struct ffs_io_data {
+ bool aio;
+ bool read;
+
+ struct kiocb *kiocb;
+ const struct iovec *iovec;
+ unsigned long nr_segs;
+ char __user *buf;
+ size_t len;
+
+ struct mm_struct *mm;
+ struct work_struct work;
+
+ struct usb_ep *ep;
+ struct usb_request *req;
+};
+
static int __must_check ffs_epfiles_create(struct ffs_data *ffs);
static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count);
@@ -631,8 +652,52 @@ static void ffs_epfile_io_complete(struct usb_ep *_ep,
struct usb_request *req)
}
}
-static ssize_t ffs_epfile_io(struct file *file,
-char __user *buf, size_t len, int read)
+static void ffs_user_copy_worker(struct work_struct *work)
+{
+ struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
+ work);
+ int ret = io_data-req-status ? io_data-req-status :
+io_data-req-actual;
+
+ if (io_data-read ret 0) {
+ int i;
+ size_t pos = 0;
+ use_mm(io_data-mm);
+ for (i = 0; i io_data-nr_segs; i++) {
+ if (unlikely(copy_to_user(io_data-iovec[i].iov_base,
+io_data-buf[pos],
+io_data-iovec[i].iov_len))) {
+ ret = -EFAULT;
+ break;
+ }
+ pos += io_data-iovec[i].iov_len;
+ }
+ unuse_mm(io_data-mm);
+ }
+
+ aio_complete(io_data-kiocb, ret, ret);
+
+ usb_ep_free_request(io_data-ep, io_data-req);
+
+ io_data-kiocb-private = NULL;
+ if (io_data-read)
+ kfree(io_data-iovec);
+ kfree(io_data-buf);
+ kfree(io_data);
+}
+
+static void ffs_epfile_async_io_complete(struct usb_ep *_ep,
+struct usb_request *req)
+{
+ struct ffs_io_data *io_data = req-context;
+
+ ENTER();
+
+ INIT_WORK(io_data-work, ffs_user_copy_worker);
+ schedule_work(io_data-work);
+}
+
+static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
{
struct ffs_epfile *epfile = file-private_data;
struct usb_gadget *gadget = epfile-ffs-gadget;
@@ -663,7 +728,7 @@ static ssize_t ffs_epfile_io(struct file *file,
}
/* Do we halt? */
- halt = !read == !epfile-in;
+ halt = (!io_data-read == !epfile-in);
if (halt epfile-isoc) {
ret = -EINVAL;
goto error;
@@ -675,15 +740,32 @@ static ssize_t ffs_epfile_io(struct file *file,
* Controller may require buffer size to be aligned to
* maxpacketsize of an out endpoint.
*/
- data_len = read ? usb_ep_align_maybe(gadget, ep-ep, len) : len;
+ data_len = io_data-read ?
+ usb_ep_align_maybe(gadget, ep-ep, io_data-len) :
+ io_data-len;
data = kmalloc(data_len,
[PATCH v4 3/5] usb: gadget: f_fs: fix setup request handling
This patch fixes __ffs_ep0_queue_wait() function, which now returns number of
bytes transferred in USB request or error code in case of failure. This is
needed by ffs_ep0_read() function, when read data is copied to userspace.
It also cleans up code by removing usused variable ep0req_status.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c |2 +-
drivers/usb/gadget/u_fs.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 6267fb0..853f88a 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -226,7 +226,7 @@ static int __ffs_ep0_queue_wait(struct ffs_data *ffs, char
*data, size_t len)
}
ffs-setup_state = FFS_NO_SETUP;
- return ffs-ep0req_status;
+ return req-status ? req-status : req-actual;
}
static int __ffs_ep0_stall(struct ffs_data *ffs)
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index ab3de01..bccfe5b 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -156,7 +156,6 @@ struct ffs_data {
*/
struct usb_request *ep0req;/* P: mutex */
struct completion ep0req_completion; /* P: mutex */
- int ep0req_status; /* P: mutex */
/* reference counter */
atomic_tref;
--
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 v4 4/5] usb: gadget: f_fs: add poll for endpoint 0
This patch adds poll function for file representing ep0.
Ability of read from or write to ep0 file is related with actual state of ffs:
- When desctiptors or strings are not written yet, POLLOUT flag is set.
- If there is any event to read, POLLIN flag is set.
- If setup request was read, POLLIN and POLLOUT flag is set, to allow
send response (by performing I/O operation consistent with setup request
direction) or set stall (by performing I/O operation opposite setup
request direction).
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 853f88a..7d04050 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -28,6 +28,8 @@
#include linux/usb/composite.h
#include linux/usb/functionfs.h
+#include linux/poll.h
+
#include u_fs.h
#include configfs.h
@@ -568,6 +570,43 @@ static long ffs_ep0_ioctl(struct file *file, unsigned
code, unsigned long value)
return ret;
}
+static unsigned int ffs_ep0_poll(struct file *file, poll_table *wait)
+{
+ struct ffs_data *ffs = file-private_data;
+ unsigned int mask = POLLWRNORM;
+ int ret;
+
+ ret = ffs_mutex_lock(ffs-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret 0))
+ return mask;
+
+ switch (ffs-state) {
+ case FFS_READ_DESCRIPTORS:
+ case FFS_READ_STRINGS:
+ mask |= POLLOUT;
+ break;
+
+ case FFS_ACTIVE:
+ switch (ffs-setup_state) {
+ case FFS_NO_SETUP:
+ if (ffs-ev.count)
+ mask |= POLLIN;
+ break;
+
+ case FFS_SETUP_PENDING:
+ case FFS_SETUP_CANCELLED:
+ mask |= (POLLIN | POLLOUT);
+ break;
+ }
+ case FFS_CLOSING:
+ break;
+ }
+
+ mutex_unlock(ffs-mutex);
+
+ return mask;
+}
+
static const struct file_operations ffs_ep0_operations = {
.llseek = no_llseek,
@@ -576,6 +615,7 @@ static const struct file_operations ffs_ep0_operations = {
.read = ffs_ep0_read,
.release = ffs_ep0_release,
.unlocked_ioctl = ffs_ep0_ioctl,
+ .poll = ffs_ep0_poll,
};
--
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] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support
From: Liu Junliang liujunliang_...@163.com
Signed-off-by: Liu Junliang liujunliang_...@163.com
---
drivers/net/usb/Kconfig | 16 +
drivers/net/usb/Makefile |1 +
drivers/net/usb/sr9800.c | 874 ++
drivers/net/usb/sr9800.h | 202 +++
4 files changed, 1093 insertions(+)
create mode 100644 drivers/net/usb/sr9800.c
create mode 100644 drivers/net/usb/sr9800.h
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 47b0f73..2551bf6 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -291,6 +291,22 @@ config USB_NET_SR9700
This option adds support for CoreChip-sz SR9700 based USB 1.1
10/100 Ethernet adapters.
+config USB_NET_SR9800
+ tristate CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices
+ depends on USB_USBNET
+ select CRC32
+ default y
+ ---help---
+ Say Y if you want to use one of the following 100Mbps USB Ethernet
+ device based on the CoreChip-sz SR9800 chip.
+
+ This driver makes the adapter appear as a normal Ethernet interface,
+ typically on eth0, if it is the only ethernet device, or perhaps on
+ eth1, if you have a PCI or ISA ethernet card installed.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sr9800.
+
config USB_NET_SMSC75XX
tristate SMSC LAN75XX based USB 2.0 gigabit ethernet devices
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index b17b5e8..433f0a0 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_USB_NET_CDCETHER)+= cdc_ether.o r815x.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
obj-$(CONFIG_USB_NET_SR9700) += sr9700.o
+obj-$(CONFIG_USB_NET_SR9800) += sr9800.o
obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
obj-$(CONFIG_USB_NET_GL620A) += gl620a.o
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
new file mode 100644
index 000..ab15973
--- /dev/null
+++ b/drivers/net/usb/sr9800.c
@@ -0,0 +1,874 @@
+/* CoreChip-sz SR9800 one chip USB 2.0 Ethernet Devices
+ *
+ * Author : Liu Junliang liujunliang_...@163.com
+ *
+ * Based on asix_common.c, asix_devices.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.*
+ */
+
+#include linux/module.h
+#include linux/kmod.h
+#include linux/init.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/ethtool.h
+#include linux/workqueue.h
+#include linux/mii.h
+#include linux/usb.h
+#include linux/crc32.h
+#include linux/usb/usbnet.h
+#include linux/slab.h
+#include linux/if_vlan.h
+
+#include sr9800.h
+
+static int sr_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
+ u16 size, void *data)
+{
+ int err;
+
+ err = usbnet_read_cmd(dev, cmd, SR_REQ_RD_REG, value, index,
+ data, size);
+ if ((err != size) (err = 0))
+ err = -EINVAL;
+
+ return err;
+}
+
+static int sr_write_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
+u16 size, void *data)
+{
+ int err;
+
+ err = usbnet_write_cmd(dev, cmd, SR_REQ_WR_REG, value, index,
+ data, size);
+ if ((err != size) (err = 0))
+ err = -EINVAL;
+
+ return err;
+}
+
+static void
+sr_write_cmd_async(struct usbnet *dev, u8 cmd, u16 value, u16 index,
+ u16 size, void *data)
+{
+ usbnet_write_cmd_async(dev, cmd, SR_REQ_WR_REG, value, index, data,
+ size);
+}
+
+static int sr_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ int offset = 0;
+
+ while (offset + sizeof(u32) skb-len) {
+ struct sk_buff *sr_skb;
+ u16 size;
+ u32 header = get_unaligned_le32(skb-data + offset);
+
+ offset += sizeof(u32);
+ /* get the packet length */
+ size = (u16) (header 0x7ff);
+ if (size != ((~header 16) 0x07ff)) {
+ netdev_err(dev-net,
+ sr_rx_fixup() Bad Header Length\n);
+ return 0;
+ }
+
+ if ((size dev-net-mtu + ETH_HLEN + VLAN_HLEN) ||
+ (size + offset skb-len)) {
+ netdev_err(dev-net,
+ sr_rx_fixup() Bad RX Length %d\n, size);
+ return 0;
+ }
+ sr_skb = netdev_alloc_skb_ip_align(dev-net, size);
+ if (!sr_skb)
+ return 0;
+
+ skb_put(sr_skb, size);
+
