Eric Dumazet [mailto:eric.duma...@gmail.com]
Sent: Wednesday, December 03, 2014 3:15 PM
[...]
Have you tried using more concurrent RX flows, in a possibly lossy
environment (so that TCP is forced to queue packets in out of order
queue) ?
I don't do the test. I would check it next time.
skb
2014-12-03 Oliver Neukum wrote:
On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote:
Hi,
After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in
Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with
USB 3.0 port (works fine with USB 2.0 port).
On Wed, 2014-12-03 at 10:41 +0100, Marcin Zajączkowski wrote:
2014-12-03 Oliver Neukum wrote:
On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote:
Hi,
After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in
Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB)
Hi,
thanks for this submission. Looks like an interesting device. However,
some very high level questions first:
+/*
+ * It exposes sysfs entries under the i2c adapter for getting the i2c
transfer
+ * status, reset i2c read/write module, get/set nak and stop bits.
+ */
Yes, I see that.
The at91rm9200, at91sam9260, at91sam9261 and at91sam9263 SoCs have slightly
different UDC IPs.
Those differences were previously handled with cpu_is_at91xx macro which
are about to be dropped for multi-platform support, thus we need to
change compatible strings.
Signed-off-by: Boris Brezillon
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi
b/arch/arm/boot/dts/at91sam9261.dtsi
index 7119f1f..e52ae97 100644
---
Allocate udc structure instead of relying on the statically declared
object.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/usb/gadget/udc/at91_udc.c | 101 ++
1 file changed, 27 insertions(+), 74 deletions(-)
diff --git
Three compatible strings have been added to the at91_udc driver.
Update the documentation accordingly.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/usb/atmel-usb.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
cpu_is_at91xxx are a set of macros defined in mach/cpu.h and are here used
to detect the SoC we are booting on.
Use compatible string + a caps structure to replace those cpu_is_xxx tests.
Remove all mach and asm headers (which are now unused).
Signed-off-by: Boris Brezillon
Hello,
This series reworks the at91_udc driver to prepare at91 for multi-platform
support.
It also include several fixes:
- fix clock names to be consistent with other USB drivers
- document clocks and clock-names properties in atmel-usb DT bindings doc
and some cleanup changes:
- remove
Make use of devm_ functions to simplify probe and remove code.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/usb/gadget/udc/at91_udc.c | 116 +-
1 file changed, 39 insertions(+), 77 deletions(-)
diff --git
Peripheral clock is named pclk and system clock is named hclk (those are
the names expected by the at91_udc driver).
Drop the deprecated usb_clk (formerly used to configure the usb clock rate
which is now directly configurable through hclk).
Signed-off-by: Boris Brezillon
Since non-DT board support has been removed from the at91 architecture we
can safely remove non-DT handling code.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/usb/gadget/udc/Kconfig| 1 +
drivers/usb/gadget/udc/at91_udc.c | 16 ++--
2 files
The at91_udc driver request 2 clocks, and thus need them to be defined in
the device tree.
Document the clocks and clock-names properties so that everybody use the
correct names.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Now that at91 system clocks forward set_rate request to their parent we
can remove the uclk clock and directly call clk_set_rate on fclk.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/usb/gadget/udc/at91_udc.c | 27 +++
The driver is requesting clock by their global name (those declared in the
clk_lookup list), but this only works with !CCF kernels.
Now that all SoCs have moved to CCF, fix the driver to use local names
(hclk and pclk).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
The max packet size within the FS descriptor has to be highest possible
value and _not_ the one that is (or will be) used on FS.
The current code sets wMaxPacketSize of FS interrupt endpoint descriptor
as 64, which is in accordance with
Bestätigen Sie Ihre (€ 500.000,00 Euro) Herzlichen Glückwunsch
Liebe Begünstigte,
Sie haben als einzige Nutznießer der Summe von fünfhunderttausend Euro (€
500.000,00 Euro), die hier in WESTERN UNION OFFICE durch die ONU Organisation
für Sie hinterlegt wurde ausgewählt.
On Mon, Dec 1, 2014 at 3:21 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij linus.wall...@linaro.org
wrote:
Apart from that, there are *again* a lot of Exynos patches flying around and
I start to loose track of them. If they do not apply
From: lyz l...@rock-chips.com
This patche to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module. This
From: lyz l...@rock-chips.com
Add a driver for the Rockchip SoC internal USB2.0 PHY.
This driver currently support RK3288.
Signed-off-by: lyz l...@rock-chips.com
---
.../devicetree/bindings/phy/rockchip-usb-phy.txt | 17 ++
drivers/phy/Kconfig| 7 +
For a complete teardown we have to wait until the teardown descriptor
is returned by the hardware. The g_zero testcase testusb -a -t 9 triggers
the following warning quite reliable:
|[ cut here ]
|WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609
The manual says that we need to (repeatedly) set the TearDown-bit for
the endpoint in order to get the active transfer descriptor released.
Doing this real quick over and over again seems to work but it also
seems that the hardware might not have enough time to breathe. So I
though, hey lets add a
On Wed, 3 Dec 2014, walkrain wrote:
Hi Stern:
Good afternoon !
Messages like this should always be CC'ed to the
linux-usb@vger.kernel.org mailing list.
I am a software engineer in Spreadtrum company in Shanghai,China.
Recently I met a usb issue:
when I plug my mass_storage u-disk to
On Wed, Dec 03, 2014 at 09:46:50PM +0800, LiYunzhi wrote:
From: lyz l...@rock-chips.com
Add a driver for the Rockchip SoC internal USB2.0 PHY.
This driver currently support RK3288.
Signed-off-by: lyz l...@rock-chips.com
Is this the name you use to sign legal documents? That is what you
On Wed, Dec 03, 2014 at 11:11:09AM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
On Monday 01 December 2014 02:14 PM, Kishon Vijay Abraham I wrote:
From: Heikki Krogerus heikki.kroge...@linux.intel.com
The driver does no use it any more.
Signed-off-by: Heikki Krogerus
the following error pops up during testusb -a -t 10
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad
dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc()
On Wed, 3 Dec 2014, Sebastian Andrzej Siewior wrote:
the following error pops up during testusb -a -t 10
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,
f134e000/be842000 (bad dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size.
On 02.12.2014 20:18, Greg KH wrote:
On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
Hmm, Greg.
I seem to get this problem possibly more commonly at boot these days:
usb 1-6: new full-speed USB device number 2 using xhci_hcd
usb 1-6: device descriptor read/64, error -71
Hi,
I'm trying to modify the USB Audio Class 1 (UAC1) audio gadget driver
to make it capable of both sending and receiving audio from the host.
Currently it can only receive audio from the host.
I've been having some issues modifying the driver. Is this the right
mailing list to post questions
On 2014-12-03 10:53, Oliver Neukum wrote:
On Wed, 2014-12-03 at 10:41 +0100, Marcin Zajączkowski wrote:
2014-12-03 Oliver Neukum wrote:
On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote:
Hi,
After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in
Fedora 19) my USB
On Wed, Dec 03, 2014 at 03:07:11PM -0600, Priya S wrote:
Hi,
I'm trying to modify the USB Audio Class 1 (UAC1) audio gadget driver
to make it capable of both sending and receiving audio from the host.
Currently it can only receive audio from the host.
I've been having some issues
Thank you.
I've created 2 endpoints. I've defined the endpoint descriptors in the
driver. The IN bEndpointAddress = 0x80 and the OUT endpoint has
bEndpointAddress = 0x00. These values are being modified in
epautoconf.c to 0x81 and 0x01.
On the Windows host though, I still see that the gadget's
On Wed, 3 Dec 2014, Priya S wrote:
Thank you.
I've created 2 endpoints. I've defined the endpoint descriptors in the
driver. The IN bEndpointAddress = 0x80 and the OUT endpoint has
bEndpointAddress = 0x00. These values are being modified in
epautoconf.c to 0x81 and 0x01.
On the Windows
Alexandre Courbot gnu...@gmail.com writes:
I think what you want to do is explained in the Platform Data
section of Documentation/gpio/board.txt
Ah yeah, already one year and I never checked again this documemtation.
Thanks.
--
Robert
--
To unsubscribe from this list: send the line
Great! That fixes it. Thanks.
Windows is not able to install the driver though. These are the USB
descriptors that I see from the host-side:
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40
On Wed, Dec 03, 2014 at 05:24:22PM -0600, Priya S wrote:
Great! That fixes it. Thanks.
Windows is not able to install the driver though. These are the USB
descriptors that I see from the host-side:
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass:
Hi,
(no top-posting, please)
On Wed, Dec 03, 2014 at 05:24:22PM -0600, Priya S wrote:
Great! That fixes it. Thanks.
Windows is not able to install the driver though. These are the USB
descriptors that I see from the host-side:
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass:
Hi Roy,
Why you send two patches with different commit message but the same
change,
you should use V2 for a new patch.
On 12/03/2014 09:46 PM, LiYunzhi wrote:
From: lyz l...@rock-chips.com
You don't need the From for the patches from yourself.
Add a driver for the Rockchip SoC
Redefine REALTEK_USB_DEVICE for the desired USB interface for probe().
There are three USB interfaces for the device. USB_CLASS_COMM and
USB_CLASS_CDC_DATA are for ECM mode (config #2). USB_CLASS_VENDOR_SPEC
is for the vendor mode (config #1). However, we are not interesting
in USB_CLASS_CDC_DATA
Hello guys!
I am writing this message to hear if there is any progress,
Enrico
On Wed, 3 Dec 2014, Kevin Zhu wrote:
Date: Wed, 3 Dec 2014 07:05:37
From: Kevin Zhu mingying@audiocodes.com
To: Enrico Mioso mrkiko...@gmail.com
Cc: Bjørn Mork bj...@mork.no, Eli Britstein
41 matches
Mail list logo
