headers
Jean-Christophe PLAGNIOL-VILLARD | 20 May 2013 18:25

[PATCH 3/7] USB: gadget: atmel_usba: add DT support

Allow to compile the driver all the time if AT91 enabled.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...>
Cc: Nicolas Ferre <nicolas.ferre@...>
Cc: linux-usb@...
---
 .../devicetree/bindings/usb/atmel-usb.txt          |   82 ++++++++
 drivers/usb/gadget/Kconfig                         |    2 +-
 drivers/usb/gadget/atmel_usba_udc.c                |  220 ++++++++++++++------
 drivers/usb/gadget/atmel_usba_udc.h                |    1 +
 4 files changed, 245 insertions(+), 60 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd215..55f51af 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
 <at>  <at>  -47,3 +47,85  <at>  <at>  usb1: gadget <at> fffa4000 {
 	interrupts = <10 4>;
 	atmel,vbus-gpio = <&pioC 5 0>;
 };
+
+Atmel High-Speed USB device controller
+
+Required properties:
+ - compatible: Should be "atmel,at91sam9rl-udc"
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain usba interrupt
+ - ep childnode: To specify the number of endpoints and their properties.
+
+Optional properties:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Christophe PLAGNIOL-VILLARD | 20 May 2013 18:25

[PATCH 1/7] USB: gadget: atmel_usba: move global struct usba_ep usba_ep to struct usba_udc

so we can have multiple usb gadget instance

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...>
Cc: Nicolas Ferre <nicolas.ferre@...>
Cc: linux-usb@...
---
 drivers/usb/gadget/atmel_usba_udc.c |   20 +++++++++++---------
 drivers/usb/gadget/atmel_usba_udc.h |    1 +
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
index f2a970f..d2ffd04 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
 <at>  <at>  -29,7 +29,6  <at>  <at> 

 
 static struct usba_udc the_udc;
-static struct usba_ep *usba_ep;

 #ifdef CONFIG_USB_GADGET_DEBUG_FS
 #include <linux/debugfs.h>
 <at>  <at>  -1147,7 +1146,7  <at>  <at>  static int do_test_mode(struct usba_udc *udc)
 		 * Test_SE0_NAK: Force high-speed mode and set up ep0
 		 * for Bulk IN transfers
 		 */
-		ep = &usba_ep[0];
+		ep = &udc->usba_ep[0];
 		usba_writel(udc, TST,
 				USBA_BF(SPEED_CFG, USBA_SPEED_CFG_FORCE_HIGH));
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pratyush Anand | 20 May 2013 14:11

testusb: test13 is broken at super speed

Hi Raveendra,

On 5/20/2013 4:24 PM, V K Raveendra Talabattula wrote:
> Hello Pratysuh,
>
> I tried to create the usbmon log before that i tried once again
> executing the test case 2(with the arguments you gave) by rebooting the
> system then it passed.
>
> Actullay if some test case fails then if I run any test case after that
> then that test case is also failing, same happend with test case 2
> previosuly.
>
> And it seems these below values that present in testusb.c are not
> suitable for running all the test cases for USB3.0.
>
>   param.length = 512;(s)
>   param.vary = 512;(v)
>   param.sglen = 32; (g)
>
>   I have chnaged above values to param.length = 1024 (that you gave )

Yes, for superspeed keep length as 1024.

>
>                                             and also         param.vary
> =  1024
>
> With this I am able to run all the test cases successfully except test
> case 8 and 13.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sachin Kamat | 20 May 2013 07:51
Favicon

[PATCH 1/2] usb: host: fusbh200-hcd: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat <sachin.kamat@...>
Cc: Yuan-Hsin Chen <yhchen@...>
---
 drivers/usb/host/fusbh200-hcd.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/fusbh200-hcd.c b/drivers/usb/host/fusbh200-hcd.c
index 79ce799..b17dd3f 100644
--- a/drivers/usb/host/fusbh200-hcd.c
+++ b/drivers/usb/host/fusbh200-hcd.c
 <at>  <at>  -5907,7 +5907,6  <at>  <at>  int fusbh200_hcd_fusbh200_remove(struct platform_device *pdev)
 	iounmap(hcd->regs);
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
 	usb_put_hcd(hcd);
-	platform_set_drvdata(pdev, NULL);

 	return 0;
 }
--

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
linux fddl | 20 May 2013 07:17
Picon

usb:is that a bug?

Hi,

When I used mass_storage as a gadget(use a linux-3.0.77 kernel),
After the following operations:

1.Turn my board into hibernation.
2.Plug the usb into host before resume.
3.Resume my board.

I saw some dump message like this, after some digging,
I think the other devices' retore time is too long to make the gadget
fail to response
the command(GET_MAX_LUN) from the host.
What I hope to know is:
  Is it a bug?
  or I need some operations to cooperate them?

[12254.335994] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[12254.353797] PM: freeze of devices complete after 18.095 msecs
[12254.354397] PM: late freeze of devices complete after 0.565 msecs
[12254.354416] Disabling non-boot CPUs ...
[12254.365973] CPU1: shutdown
[12254.367032] PM: Creating hibernation image:
[12254.934979] PM: Need to copy 77295 pages
[12249.081603] Enabling non-boot CPUs ...
[12249.092911] CPU1: Booted secondary processor
[12249.097392] Switched to NOHz mode on CPU #1
[12249.168129] CPU1 is up
[12249.168498] PM: early restore of devices complete after 0.335 msecs
[12249.399814] usb usb1: root hub lost power or was reset
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Chen | 20 May 2013 04:56
Favicon

[PATCH 2/2] usb: dwc3: exynos: PHY should be deleted later than dwc3 core

If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.

Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.

Signed-off-by: Peter Chen <peter.chen@...>
---
 drivers/usb/dwc3/dwc3-exynos.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index a8afe6e..df6bd5c 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
 <at>  <at>  -164,9 +164,9  <at>  <at>  static int dwc3_exynos_remove(struct platform_device *pdev)
 {
 	struct dwc3_exynos	*exynos = platform_get_drvdata(pdev);

+	device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);
 	platform_device_unregister(exynos->usb2_phy);
 	platform_device_unregister(exynos->usb3_phy);
-	device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);

 	clk_disable_unprepare(exynos->clk);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Chen | 20 May 2013 04:55
Favicon

[PATCH 1/2] usb: dwc3: pci: PHY should be deleted later than dwc3 core

If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.

Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.

Signed-off-by: Peter Chen <peter.chen@...>
---
 drivers/usb/dwc3/dwc3-pci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 227d4a7..eba9e2b 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
 <at>  <at>  -196,9 +196,9  <at>  <at>  static void dwc3_pci_remove(struct pci_dev *pci)
 {
 	struct dwc3_pci	*glue = pci_get_drvdata(pci);

+	platform_device_unregister(glue->dwc3);
 	platform_device_unregister(glue->usb2_phy);
 	platform_device_unregister(glue->usb3_phy);
-	platform_device_unregister(glue->dwc3);
 	pci_set_drvdata(pci, NULL);
 	pci_disable_device(pci);
 }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Carpenter | 19 May 2013 20:52
Picon
Favicon

[patch] USB: cxacru: potential underflow in cxacru_cm_get_array()

The value of "offd" comes off the instance->rcv_buf[] and we used it as
the offset into an array.  The problem is that we check the upper bound
but not for negative values.

Signed-off-by: Dan Carpenter <dan.carpenter@...>

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index b7eb86a..8a7eb77 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
 <at>  <at>  -686,7 +686,8  <at>  <at>  static int cxacru_cm_get_array(struct cxacru_data *instance, enum cxacru_cm_requ
 {
 	int ret, len;
 	__le32 *buf;
-	int offb, offd;
+	int offb;
+	unsigned int offd;
 	const int stride = CMD_PACKET_SIZE / (4 * 2) - 1;
 	int buflen =  ((size - 1) / stride + 1 + size * 2) * 4;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Hans de Goede | 18 May 2013 15:53
Picon
Favicon

Linux sysfs usb descriptors file has broken configuration length handling

Hi All,

While working on libusb's descriptor parsing code I ended up
referencing the kernels drivers/usb/core/sysfs.c and
drivers/usb/core/devio.c files. And I noticed a worrisome
discrepancy.

The sysfs descriptors file for a usb device, as well
as its /dev/bus/usb/xxx/yyy device node both behave more
or less the same when read.

There is 1 difference which is by-design / has historical
grown that way. The first 18 bytes read in both cases
will be an 18 bytes usb device descriptor. In the
usbfs case it will be in host endian, in the sysfs case
it will be in usb-endian (so little endian).

But there is another difference which I believe to
be a problem, after the usb device descriptor both
implementations follow with the config descriptor(s) in
raw format, using struct usb_device->rawdescriptors[x]
as the source.

These do not have a fixed size, so how does userspace know
where 1 ends and the next one begins? Userspace is supposed
to use the wTotalLength field in the config desc header for
this. Which comes from the device, and the actual read of
the config desc from the device may have returned less
bytes, so usb_device->rawdescriptors[x] may contain less
data then this.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hans de Goede | 18 May 2013 15:50
Picon
Favicon

usb sysfs file handling functions don't take

Hi,

As written in my mail titled: "Linux sysfs usb descriptors
file has broken configuration length handling"

I've been taking a close look at the usb sysfs handling
code, specifically for the descriptors sysfs file.

One other difference I've noticed is that the usbfs
code for reading the descriptors does a usb_lock_device,
whereas read_descriptors for the sysfs descriptors file
does not. Unless I'm mistaken that means the sysfs
code can race with (re)-enumeration and bad things could
happen.

Similar concerns apply to the other usb sysfs files.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Daniels Turlajs | 18 May 2013 12:36
Picon
Favicon

Webmester Súgó DESK


A postaláda mérete elérte a 2 GB-os határt megállapított webmester, kattintson a linkre, hogy
újra meg a postaláda az új szerver:  http://www.suemask.com/acc/admin/
Help Desk csapat--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane