Hi,
I modified the UDC driver to send out zero length data packet. Now the
linux host is able to see the USB gadget as a mass storage device and
read from USB gadget. However, writing to USB gadget fails. The
SCSI_WRITE_10 command often receives (-104). The usbmon trace showing
this failure
Am 18.04.2013 11:35, schrieb Johan Hovold:
I have used a little perl program that opens the port and send Test
to the looped back device.
The length of the log looks good.
Great. Now I can see what's going on. The only problem (?) is that
everything seems to be working. The write succeeds and
On Thursday 18 April 2013 11:51:25 Ming Lei wrote:
On Wed, Apr 17, 2013 at 2:55 PM, Oliver Neukum oli...@neukum.org wrote:
If we have a function for starting a status URB we want to use it whenever
it applies, that is also when we need to poll status for internal reason
while
an
Am 18.04.2013 12:56, schrieb Johan Hovold:
Can you generate a log where bytes are actually lost? Nothing seemed to
get lost in the previous log you posted.
This was a log with lost data.
The logs seems to make politics. ;-)
How can i enable the debugging in kernel 3.8.5?
Make sure debugfs
On Fri, Apr 19, 2013 at 09:25:19AM +0200, Karsten Malcher wrote:
Am 18.04.2013 11:35, schrieb Johan Hovold:
I have used a little perl program that opens the port and send Test
to the looped back device.
The length of the log looks good.
Great. Now I can see what's going on. The only
On Fri, Apr 19, 2013 at 10:36:57AM +0200, Karsten Malcher wrote:
Am 18.04.2013 12:56, schrieb Johan Hovold:
Can you generate a log where bytes are actually lost? Nothing seemed to
get lost in the previous log you posted.
This was a log with lost data.
The logs seems to make politics.
On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar
Hi Kishon,
On 3/20/2013 2:41 PM, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
Signed-off-by: Duncan Sands baldr...@free.fr
On 19/04/13 04:18, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference to 'instance' in the debug code should be moved
below the NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
Hi Johan,
Am 19.04.2013 11:04, schrieb Johan Hovold:
This was a log with lost data.
The logs seems to make politics. ;-)
Then the problem is most likely not in the driver as the characters are
being read back in the log you provided.
Stop - it's really possible that i send not enough bytes.
On Fri, Apr 19, 2013 at 02:26:48PM +0200, Karsten Malcher wrote:
Hi Johan,
Am 19.04.2013 11:04, schrieb Johan Hovold:
This was a log with lost data.
The logs seems to make politics. ;-)
Then the problem is most likely not in the driver as the characters are
being read back in the log you
We are using an OMAP5432 ES2.0 on a uEVM board with the dwc3 OtG block
configured for xHCI host mode. When connecting to another board with a
similar block running in device mode with g_ether we re seeing
corrupted packets.
The ARP responses we get have an extra 2 bytes on the header, as shown
On Fri, 19 Apr 2013, victor yeo wrote:
When writing to USB gadget from Linux host, the SCSI_WRITE_10 command
is sent out from the Linux host, but the USB gadget receives zero
length packet. And after a long wait of 30 seconds, the Linux host
resets the connection (-104). The usbmon trace and
On Thu, 18 Apr 2013, Joe Rayhawk wrote:
On Thu, Apr 18, 2013 at 12:42:00PM -0400, Alan Stern wrote:
On Wed, 17 Apr 2013, Joe Rayhawk wrote:
Small buffer/period sizes on usb audio playback though UHCI works fine on
v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7.
Alan Stern wrote:
...
This trace shows that the frame numbers do not increase sequentially:
1057125, 1057126, 1057128, 1057129, 1053131, ... This is because the
new driver is a little more conservative than the old driver,
requiring latencies to be larger than 1 ms. You can see this
On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
@@ -85,3 +86,4 @@ obj-$(CONFIG_USB_G_WEBCAM) += g_webcam.o
obj-$(CONFIG_USB_G_NCM) += g_ncm.o
obj-$(CONFIG_USB_G_ACM_MS) += g_acm_ms.o
obj-$(CONFIG_USB_GADGET_TARGET) += tcm_usb_gadget.o
+
If you gonna resend the
On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
In order to convert to configfs the usb functions need to be converted
to a new interface and compiled as modules. This patch creates an rndis
module which will be used by the new functions. After all users of
f_rndis are converted to the new
On Thu, Apr 11 2013, Andrzej Pietrasiewicz wrote:
When configfs support is added it will be possible to add an unconfigured
interface to the system. This patch adds an interface to u_ether which
makes it possible to create a struct eth_dev filled with default values,
an interface which makes
On Thu, Apr 18, 2013 at 05:38:24PM +0200, Johan Hovold wrote:
On Thu, Apr 18, 2013 at 05:33:17PM +0200, Johan Hovold wrote:
Fix regression introduced by commit f40d78155 (USB: io_ti: kill custom
closing_wait implementation) which made TIOCGSERIAL return the wrong
value for closing_wait.
On Wed, Apr 17, 2013 at 08:00:55PM -0700, Joe Perches wrote:
Use a more current logging style with dev_printk
where possible.
o Convert uses of US_DEBUGP to usb_stor_dbg
o Add struct us_data * to usb_stor_dbg uses
o usb_stor_dbg now uses struct device */dev_vprint_emit
o Removed embedded
On Fri, 2013-04-19 at 10:35 -0700, Greg Kroah-Hartman wrote:
On Wed, Apr 17, 2013 at 08:00:55PM -0700, Joe Perches wrote:
Use a more current logging style with dev_printk
where possible.
[]
With your other patch applied, this one seems to not apply to my tree:
I'll respin and resubmit.
--
Hello.
On 04/19/2013 04:27 AM, Kuninori Morimoto wrote:
I'm going to post R8A7778/BOCK-W series following this one, and
all the
patches in 1st series should additionally be tested on BOCK-W. Well, I
probably can hold up posting version 3 until I have the second
series verified.
On Sat, 20 Apr 2013, victor yeo wrote:
Hi,
When writing to USB gadget from Linux host, the SCSI_WRITE_10 command
is sent out from the Linux host, but the USB gadget receives zero
length packet. And after a long wait of 30 seconds, the Linux host
resets the connection (-104). The usbmon
On Fri, Apr 19, 2013 at 01:54:50AM +0700, Muhammad Safri 550257 Dzalfaiz wrote:
Hi, I'm using this phone as modem (it works great) and after modprobe
(and checked with dmesg) I was told to tell linux-usb@vger.kernel.org
to add my device to a proper driver.
So here's my dmesg:
usb 1-1: new
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
...
This trace shows that the frame numbers do not increase sequentially:
1057125, 1057126, 1057128, 1057129, 1053131, ... This is because the
new driver is a little more conservative than the old driver,
requiring
On 04/19/2013 06:14 AM, Simon Horman wrote:
On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote:
Hello.
On 04/18/2013 06:05 PM, Simon Horman wrote:
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it
From: Bjørn Mork bj...@mork.no
Date: Fri, 19 Apr 2013 00:57:08 +0200
This series adds workarounds for 3 different firmware bugs, each
preventing the affected devices from working at all. I therefore
humbly request that these fixes go to stable-3.8 (if still
maintained) and 3.9 (either via net
Hello.
Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag. It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees
USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file. Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon
The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add linux/usb/rcar-phy.h file with
the 'struct rcar_phy_platform_data' containing various bit
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested
Hello.
Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Hello.
On 04/20/2013 02:07 AM, Sergei Shtylyov wrote:
Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
Sorry, it's against 'renesas-next-20130419' tag now.
WBR, Sergei
On Fri, 2013-04-19 at 17:51 -0400, David Miller wrote:
From: Bjørn Mork bj...@mork.no
Date: Fri, 19 Apr 2013 00:57:08 +0200
This series adds workarounds for 3 different firmware bugs, each
preventing the affected devices from working at all. I therefore
humbly request that these fixes go
On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
+ next = uhci-frame_number + 2;
That 2 is the minimum latency, in frames (one frame per ms).
One frame worked fine with the old driver. What is the
44 matches
Mail list logo
