On Fri, 2016-07-22 at 09:59 -0400, Alan Stern wrote:
> On Fri, 22 Jul 2016, Oliver Neukum wrote:
>
> > It is always possible to go back to the usb_device if you know
> > the interface. It is unnecessary to store the device and thus should
> > not be done.
>
> That is not a hard-and-fast law -- th
Hi Greg,
Here are my exceptionally late usb-serial updates for 4.8-rc1. Mostly
clean ups, so there's nothing here (except the device-id patch) which
cannot wait until 4.9 if you prefer to hold off on these instead of
sending a second pull-request to Linus.
All have been in linux-next without any
On Mon, Jul 11, 2016 at 8:47 AM, Peter Chen wrote:
> On Sun, Jul 10, 2016 at 11:25:17AM +0300, Binyamin Sharet wrote:
>> Hi,
>>
>> Could someone please advise whether I should also open a bug in
>> bugzilla for this thing? or if there anything else I'm missing?
>>
>
> It is not necessary, the rela
On Mon, 25 Jul 2016, Oliver Neukum wrote:
> On Fri, 2016-07-22 at 09:59 -0400, Alan Stern wrote:
> > On Fri, 22 Jul 2016, Oliver Neukum wrote:
> >
> > > It is always possible to go back to the usb_device if you know
> > > the interface. It is unnecessary to store the device and thus should
> > >
From: Grant Grundler
In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.
Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.
Reset HW in resume func
From: WK Tsai
The change fixes AX88772x resume failure by
- Restore incorrect AX88772A PHY registers when resetting
- Need to stop MAC operation when suspending
- Need to restart MII when restoring PHY
Signed-off-by: WK Tsai
---
drivers/net/usb/asix_devices.c | 47 +
From: Vincent Palatin
Check the answers from the USB stack and avoid re-sending multiple times
the request if the device has disappeared.
Signed-off-by: Vincent Palatin
---
drivers/net/usb/asix_common.c | 56 +-
drivers/net/usb/asix_devices.c | 2 ++
2
From: Andrew Bresticker
USB host controllers can take a significant amount of time to suspend
and resume, adding several hundred miliseconds to the kernel resume
time. Since the XHCI controller has no outside dependencies (other than
clocks, which are suspended late/resumed early), allow it to su
From: Andrew Bresticker
Enable runtime PM for the xhci-plat device so that the parent device
may implement runtime PM.
Signed-off-by: Andrew Bresticker
---
drivers/usb/host/xhci-plat.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhc
On Mon, Jul 25, 2016 at 02:47:53PM -0400, robert.f...@collabora.com wrote:
> From: Andrew Bresticker
>
> Enable runtime PM for the xhci-plat device so that the parent device
> may implement runtime PM.
>
> Signed-off-by: Andrew Bresticker
Why are you forwarding on patches without adding your s
[as plain text this time...]
Robert,
On Mon, Jul 25, 2016 at 10:40 AM, wrote:
> From: Grant Grundler
For the record, I believe I am not the author of these patches.
I believe the original author is
Signed-off-by: Freddy Xin
as recorded in the following code reviews (and testing) that I
On Mon, Jul 25, 2016 at 10:40 AM, wrote:
> From: Vincent Palatin
>
> Check the answers from the USB stack and avoid re-sending multiple times
> the request if the device has disappeared.
>
> Signed-off-by: Vincent Palatin
The original chromium.org code review:
https://chromium-review.googl
Robert,
This patch content LGTM but isn't including the correct "meta data"
regarding it's origin.
On Mon, Jul 25, 2016 at 10:40 AM, wrote:
> From: WK Tsai
WK Tsai is not the author of this patch.
I believe Allan Chou is the author.
> The change fixes AX88772x resume failure by
> - Restore i
From: Colin Ian King
The assignment ret = ret is redundant and can be removed.
Signed-off-by: Colin Ian King
---
drivers/usb/gadget/udc/core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index ff8685e..48c
Here follows few improvements on the MIDI driver. Those improvements
have been tested for months now, that's why I feel confident to submit
these patches now.
Patches number 1 and 4 contain bug fixes.
Patches number 2 and 3 are not critical but it improves the code and
default configuration, which
This refactor results in a cleaner state machine code and promotes
consistency, readability, and maintanability of this driver.
This refactor state machine was well tested and it is currently running in
production code and devices.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/functio
512 is the value used by wMaxPacketSize, as specified by the USB Spec. This
makes sure this driver uses, by default, the most optimal value for IN and OUT
endpoint requests.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 2 +-
drivers/usb/gadget/legacy/gmidi.c| 2
USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 2 +-
1 file changed, 1 insertion(+), 1
This change makes sure that the ALSA buffers are cleaned if an endpoint
becomes disabled.
Before this change, if the internal ALSA buffer did overflow, the MIDI
function would stop sending MIDI to the host.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 27 +
On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote:
>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol
>>> wrote:
it may break current usecase for some people
>
> And what are the benefits that justify breaking the kernel API?
Main limitation with current f_uac1 design is - it can be
Hi,
On 26 July 2016 at 07:15, Felipe F. Tonello wrote:
> USB spec specifies wMaxPacketSize to be little endian (as other properties),
> so when using this variable in the driver we should convert to the current
> CPU endianness if necessary.
>
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/
Please correct the problems Grant Grundler mentioned in all of these
patches, and resubmit this entire series freshly.
Also, please include a proper "[PATCH 0/3] ..." introduction posting
for the series which explains what this series is about, how it
implements what it is doing, and why it is do
The status workqueue is involved in initializing the Uxxx and polling
the Uxxx until a supported PCMCIA CardBus device is detected.
It then starts the command and respond workqueues and then loads the
module that handles the device, after which it just polls the Uxxx
looking for card ejects.
The c
The workqueue "wq" is involved in controlling the brightness of an
Apple Cinema Display over USB.
It has a single work item(&pdata->work) per appledisplay and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path.
Hence, the singlethreaded workqueue has been replaced
24 matches
Mail list logo
