Without reset functionality in reset_resume, iperf connection does not
establish after suspend/resume however ping works at the same time.
iperf connection fails with wrong checksum error shown by tcpdump.
reset function inside reset_resume solves above bug. We have verified
this issue on ASIX bas
>From d178065c9e3cfa8a45ef537fae7412775339beb0 Mon Sep 17 00:00:00 2001
From: Vivek Kumar Bhagat
Date: Thu, 11 Jun 2015 07:23:46 -0700
Subject: [PATCH] ax88179_178a: add reset functionality in reset_resume
Without reset functionality in reset_resume, iperf connection does not
establish after susp
On Fri, Jun 12, 2015 at 05:51:12PM -0700, John Stultz wrote:
> I'm not super sure what the right fix is, but if do something like the
> following (sorry, whitespace corrupted via copy/paste), I don't seem
> to run into the problem.
Looks sane. Which tree would you prefer it to go through, vfs or
Am 21.06.2015 um 00:12 schrieb Stefan Agner:
There are three GPIO modes supported by FTDI devices:
1. Asynchronous Bit Bang Mode (used in Sacha's patch)
2. Synchronous Bit Bang Mode (used in Philipp's patch)
3. CBUS Bit Bang Mode (used in Philipp's patch and this patchset)
1. No idea, could be
On Fri, 2015-06-19 at 19:43 +0200, Fab Stz wrote:
> Oh ! I just realized my mistake. Actually it is not the kernel that is faulty
> but my configuration (since I migrated from debian wheezy to jessie).
>
> I had connection/disconnection issues because of conflicts between gammu and
> ModemManage
> "Tom" == Tom Yan writes:
Tom> I know they all use VPDs, but the main point is whether those
Tom> hardware RAIDs or so are handled by sd_mod, and whether those
Tom> "transfer lengths" info are still important when it's just a simple
Tom> drive. To me they look like to be of different nature.
Stefan Agner wrote:
> libftdi requires to detach the kernel driver to get access to the device
Control transfers ought to be possible without a detach.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Add interface to allow CBUS access. The functions set_bitmode and
read_pins use control transfers only hence should not interfere
with the serial operation mode.
Signed-off-by: Stefan Agner
---
drivers/usb/serial/ftdi_sio.c | 41 +
drivers/usb/serial/ftdi_
This driver allows to use the CBUS pins, e.g. CBUS 0-3 on FT232R
type of devices. Note that the pins need to be configured first
by using I/O mode signal option in the EEPROM. This is _not_ the
factory default configuration of any of the four pins.
See also FTDI's Application Note AN_232R-01.
Sig
Yet another FTDI GPIO patchset. Yet somewhat different to previous
implementations...
There are three GPIO modes supported by FTDI devices:
1. Asynchronous Bit Bang Mode (used in Sacha's patch)
2. Synchronous Bit Bang Mode (used in Philipp's patch)
3. CBUS Bit Bang Mode (used in Philipp's patch an
Dear All,
Attached patch fix iperf connection problem after reset resume of
ethernet to usb dongle.
Without reset functionality, i see ping works after reset resume but
iperf connection fails with wrong checksum error message shown by
tcpdump.
Attached patch fix above issue.
Thanks,
Vivek
00
I was not saying RAIDs are virtual devices. I just mentioned it
because I saw things like virtio-blk or zram use blk_queue_io_opt().
I know they all use VPDs, but the main point is whether those hardware
RAIDs or so are handled by sd_mod, and whether those "transfer
lengths" info are still importa
Hans-Peter Jansen writes:
> just a heads up: retesting with 4.0.4 revealed, that this issue isn't
fixed
Thanks for the heads up; I'll stop trying to figure out the "clean" way to
upgrade my Debian box that far ahead of their packages. :)
> This behavior persists since Linux 3.16.x (where I se
Also simplify the code a bit by specify direction and initial value for
output in devm_gpiod_get_optional function.
Signed-off-by: Axel Lin
Acked-by: Heikki Krogerus
Acked-by: Kishon Vijay Abraham I
---
Hi
This patch was sent on https://lkml.org/lkml/2015/5/31/221 with ACKs.
It's still not in l
14 matches
Mail list logo