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 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 interface is up
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 i
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. T
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 pol
On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I
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
> > wrote:
> >> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> >>> On Wed, 20 Mar 2013 14:42:00 +053
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
> w
Signed-off-by: Duncan Sands
On 19/04/13 04:18, Wei Yongjun wrote:
From: Wei Yongjun
The dereference to 'instance' in the debug code should be moved
below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/usb/atm/usbatm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
di
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.
S
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
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 a
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
> e
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 p
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 ne
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 make
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_w
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 em
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.
BTW,
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
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-
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,
> > requirin
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 nee
From: Bjørn Mork
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 if still
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-shmob
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 they
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 purpos
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
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since v
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 Marz
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
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 4:
- refreshed the patch.
Changes
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()...
N
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 file with
the 'struct rcar_phy_platform_data' containing various bit fields describing
USB
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 o
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 arch/arm/mach-shm
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 handle
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 R8A7
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
---
Changes since version 3:
- rem
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 'renesa
On Fri, 2013-04-19 at 17:51 -0400, David Miller wrote:
> From: Bjørn Mork
> 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 s
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.
43 matches
Mail list logo
