Hi,
John Youn writes:
> On 1/11/2017 4:22 PM, John Stultz wrote:
>> Just wanted to resend my patches for dwc2 controller on the
>> HiKey board for consideration for the 4.11 merge window.
>>
>> This patchset is the same as v2, only rebased against
>> John's synopsys-usb/next branch.
>>
>> This
Mathias,
On 11/01/17 17:08, Alan Stern wrote:
> On Wed, 11 Jan 2017, Mathias Nyman wrote:
>
>> On 17.11.2016 13:43, Sriram Dash wrote:
>>> From: Arnd Bergmann
>>>
>>> For xhci-hcd platform device, all the DMA parameters are not
>>> configured properly, notably dma ops for dwc3 devices. So, set
>
Xhci spec requires in section 4.23.5.1.1.1 that the RWE bit of USB2
PORTPMSC register should only set for remote wakeup capble devices.
This was suggested by Mathias in the following discussion thread.
http://marc.info/?l=linux-usb&m=148154757829677&w=2
Suggested-by: Mathias Nyman
Signed-off-by:
Am Mittwoch, den 11.01.2017, 21:06 +0200 schrieb Felipe Balbi:
> Hi,
>
> Todd Brandt writes:
> >
> > On Mon, 2017-01-09 at 09:44 +0100, Oliver Neukum wrote:
> > Well my main purpose in getting this out there is to get the seed
> > planted for further optimization. The focus right now is just
>
Hi,
Oliver Neukum writes:
> Am Mittwoch, den 11.01.2017, 21:06 +0200 schrieb Felipe Balbi:
>
>> Hi,
>>
>> Todd Brandt writes:
>> >
>> > On Mon, 2017-01-09 at 09:44 +0100, Oliver Neukum wrote:
>> > Well my main purpose in getting this out there is to get the seed
>> > planted for further optim
On Wed, Jan 11, 2017 at 04:19:53PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-02 22:53:19)
> > On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > > If the phy supports it, call phy_set_mode() to pull up D+ when
> > > required by setting the mode to PHY_MODE_USB_DEVICE.
On Wed, Jan 11, 2017 at 04:32:34PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-03 00:00:31)
> > On Wed, Dec 28, 2016 at 02:56:57PM -0800, Stephen Boyd wrote:
> > > From: Peter Chen
> > >
> > > At some situations, the vbus may already be there before starting
> > > gadget. So we need
Hi Mathias,
On 01/12/2017 04:53 PM, Lu Baolu wrote:
> Xhci spec requires in section 4.23.5.1.1.1 that the RWE bit of USB2
> PORTPMSC register should only set for remote wakeup capble devices.
>
> This was suggested by Mathias in the following discussion thread.
> http://marc.info/?l=linux-usb&m=14
On Thu, Jan 12, 2017 at 11:16:25AM +0200, Felipe Balbi wrote:
> > In addition, they are a much smaller group for which we can hope
> > to get a reasonable testing coverage. A generic white list will always
> > be a fraction of all possibilities.
>
> not true. The full list of certified devices exi
Hi,
Greg KH writes:
> On Thu, Jan 12, 2017 at 11:16:25AM +0200, Felipe Balbi wrote:
>> > In addition, they are a much smaller group for which we can hope
>> > to get a reasonable testing coverage. A generic white list will always
>> > be a fraction of all possibilities.
>>
>> not true. The full
On Thu, Jan 12, 2017 at 12:44:53PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Greg KH writes:
> > On Thu, Jan 12, 2017 at 11:16:25AM +0200, Felipe Balbi wrote:
> >> > In addition, they are a much smaller group for which we can hope
> >> > to get a reasonable testing coverage. A generic white list wi
Hi,
On 12/26/2016 05:53 AM, Nobuo Iwata wrote:
> This patch adds recovery from false busy state on concurrent attach
> operation.
>
> The procedure of attach operation is as below.
>
> 1) Find an unused port in /sys/devices/platform/vhci_hcd/status.
> (userspace)
>
> 2) Request attach found p
On 12/26/2016 08:08 AM, Nobuo Iwata wrote:
> This patch set implements operations to export and unexport device
> using pre-defined but un-used export and un-export request and reply.
>
> This patch modifies export and un-export reply in
> tools/usb/usbip/src/usbip_network.h. The 'returncode'
From: William wu
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] x
William,
On 12/01/17 14:03, William Wu wrote:
> From: William wu
>
> On some platforms(e.g. rk3399 board), we can call hcd_add/remove
> consecutively without calling usb_put_hcd/usb_create_hcd in between,
> so hcd->flags can be stale.
>
> If the HC dies due to whatever reason then without this
On 12/26/2016 08:08 AM, Nobuo Iwata wrote:
> Modifications to host driver wrapper and its related operations (i.e.
> bind/unbind).
>
> usbip_get_device() method was not used. The implementation of the
> method searches a bound devices list by list index. The position in the
> list is meaningl
Hi,
On 12/26/2016 08:08 AM, Nobuo Iwata wrote:
> Implementation of new connect operation. This is linked as a part of
> usbip command. With this patch, usbip command has following operations.
>
> bind
> unbind
> list (local/remote)
> attach
> detach
> port
> connect ... this patch
>
>
On 12/26/2016 08:08 AM, Nobuo Iwata wrote:
> Implementation of new disconnect operation. This is linked as a part of
> usbip command. With this patch, usbip command has following operations.
>
> bind
> unbind
> list (local/remote)
> attach
> detach
> port
> connect ... previous patch
>
On 12/26/2016 08:08 AM, Nobuo Iwata wrote:
> Refactoring to the daemon to reuse common portion for new application
> side daemon. It's divided into two portions.
>
> usbipd.c : common code for both device and application side daemon.
> usbipd_dev.c : device-side specific code extracted from usb
From: Wei Yongjun
Fixes the following sparse warning:
drivers/usb/host/xhci-mem.c:988:6: warning:
symbol 'xhci_free_virt_devices_depth_first' was not declared. Should it be
static?
Signed-off-by: Wei Yongjun
---
drivers/usb/host/xhci-mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
Hi.
This is basically from:
https://bugzilla.kernel.org/show_bug.cgi?id=108341
respectively
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805903
the later in which Ben Hutchings recommended me to ping this list as
well.
I bought a USB3.0 ExpressCard from StarTech[0] which is apparently[1]
ba
From: Wei Yongjun
Fixes the following sparse warning:
drivers/net/usb/cdc_ether.c:469:6: warning:
symbol 'usbnet_cdc_zte_status' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/net/usb/cdc_ether.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Make sure to detect short control transfers and return zero on success
when retrieving the modem status.
This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB:
spcp8x5: add proper modem-status support") has returned TIOCM_LE on
successful retrieval, and avoids leaking bits from the
Make sure to detect short control-message transfers rather than continue
with zero-initialised data when retrieving modem status and during
device initialisation.
Fixes: 52af95459939 ("USB: add USB serial ssu100 driver")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ssu100.c | 31 ++
Exynos is DT-only, so there's no need for a platform MODALIAS.
Signed-off-by: Javier Martinez Canillas
---
drivers/usb/dwc3/dwc3-exynos.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e27899bb5706..2e555a69c8ab 100644
--
Make sure to detect short responses when reading the latency timer to
avoid using stale buffer data.
Note that no heap data would currently leak through sysfs as
ASYNC_LOW_LATENCY is set by default.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi
Make sure to log an error on short transfers when reading a device
register.
Also clear the provided buffer (which if often an uninitialised
automatic variable) on errors as the driver currently does not bother to
check for errors.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7720.c |
Make sure to detect and return an error on zero-length control-message
transfers when reading from the device.
This addresses a potential failure to detect an empty transmit buffer
during close.
Also remove a redundant check for short transfer when sending a command.
Fixes: 1da177e4c3f4 ("Linux-
Remove code that allocated but never used a buffer during open.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/iuu_phoenix.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/usb/serial/iuu_phoenix.c b/drivers/usb/serial/iuu_phoenix.c
index d57fb5199
Make sure to detect short control-message transfers and log an error
when reading incomplete manufacturer and boot descriptors.
Note that the default all-zero descriptors will now be used after a
short transfer is detected instead of partially initialised ones.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-
Make sure to detect short transfers when reading a device register.
The modem-status handling had sufficient error checks in place, but move
handling of short transfers into the register accessor function itself
for consistency.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 19
Make sure to return an error on zero-length transfers when retrieving
the line settings even if the driver currently ignores the return value.
Also remove a redundant check for short transfer when setting the line
settings.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/pl2303.c | 8 ++-
Use a dedicated buffer for the DMA transfer and make sure to detect
short transfers to avoid parsing a corrupt descriptor.
Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_edgeport.c | 24 ++--
1 fil
Make sure to detect short control-message transfers so that errors are
logged when reading the modem status at open.
Note that while this also avoids initialising the modem status using
uninitialised heap data, these bits could not leak to user space as they
are currently not used.
Fixes: 1da177e
Fix open error handling which failed to detect errors when reading the
MSR and LSR registers, something which could lead to the shadow
registers being initialised from errnos.
Note that calling the generic close implementation is sufficient in the
error paths as the interrupt urb has not yet been
Make sure to detect short responses when fetching the modem status in
order to avoid parsing uninitialised buffer data and having bits of it
leak to user space.
Note that we still allow for short 1-byte responses.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
-
Make sure to detect short control-message transfers when fetching
modem and line state in open and when retrieving registers.
This specifically makes sure that an errno is returned to user space on
errors in TIOCMGET instead of a zero bitmask.
Also drop the unused getdevice function which also la
Several USB serial drivers failed to detect short control transfers,
something which could lead to uninitialised data leaking to user space
or being treated as valid input.
The two information-leak fixes are marked for stable, and so is the
spcp8x5 modem-status fix.
Included is also a clean up re
The current implementation failed to detect short transfers, something
which could lead to bits of the uninitialised heap transfer buffer
leaking to user space.
Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for
new ark3116 driver.")
Fixes: f4c1e8d597d1 ("USB: ark3116: Make ex
On Mon, Jan 09, 2017 at 02:51:59PM +0100, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 09:49:00PM +0100, Johan Hovold wrote:
> > On Tue, Dec 20, 2016 at 12:09:55PM -0800, Russell Senior wrote:
> > > On Tue, Dec 20, 2016 at 8:07 AM, Johan Hovold wrote:
> > >
> > > > Perhaps we should determine wh
Hi Greg,
Here are my fixes for -rc4. All have been in linux-next.
Thanks,
Johan
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jo
On Wed, Jan 11, 2017 at 10:06:38PM +0100, Maxime Ripard wrote:
> On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> > >
> > >
> > > 11.01.2017, 04:24, "Bin Liu" :
> > > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Z
USBTrdTim must be programmed to 0x5 when phy has a UTMI+ 16-bit wide
interface or 0x9 when it has a 8-bit wide interface.
GUSBCFG reset value (Value After Reset: 0x1400) sets USBTrdTim to 0x5.
In case of 8-bit UTMI+, without clearing GUSBCFG.USBTRDTIM mask, USBTrdTim
results in 0xD (0x5 | 0x9).
Tha
This problem was spotted during code review. It appears that USBTrdTim value
is not correctly set in case of 8-bit UTMI+ phy, because it is ORed with
USBCFG.USBTRDTIM reset value, which is 0x5.
I have no hardware to test it.
Amelie Delaunay (1):
usb: dwc2: gadget: Fix GUSBCFG.USBTRDTIM value
d
er here ?
This needs to be clarified by someone that knows the details and history
of this device/driver.
Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
Patch is aginast 4.10-rc3 (localversion-next is next-20170112)
drivers/usb/dwc2/core.c | 2 +-
1 file changed, 1 insertion(+),
Hello,
I'm Dr. Gertjan Vlieghe (Bank Of England),we have an inheritance of a
deceased client with your surname Contact Dr. Gertjan Vlieghe With
your: Full Name, Tel Number, Age, Occupation and Address through
email: d.vlie...@yahoo.com
Thanks
Dr. Gertjan Vlieghe
-
On Thu, 12 Jan 2017, Roger Quadros wrote:
> William,
>
> On 12/01/17 14:03, William Wu wrote:
> > From: William wu
> >
> > On some platforms(e.g. rk3399 board), we can call hcd_add/remove
> > consecutively without calling usb_put_hcd/usb_create_hcd in between,
> > so hcd->flags can be stale.
>
On 12/01/17 17:33, Alan Stern wrote:
> On Thu, 12 Jan 2017, Roger Quadros wrote:
>
>> William,
>>
>> On 12/01/17 14:03, William Wu wrote:
>>> From: William wu
>>>
>>> On some platforms(e.g. rk3399 board), we can call hcd_add/remove
>>> consecutively without calling usb_put_hcd/usb_create_hcd in b
Hi all,
Sorry, I did not see Pengcheng Li patch which is exactly the same:
https://patchwork.kernel.org/patch/9347979/
Regards
On 01/12/2017 04:36 PM, Amelie Delaunay wrote:
USBTrdTim must be programmed to 0x5 when phy has a UTMI+ 16-bit wide
interface or 0x9 when it has a 8-bit wide interface.
amp;descriptor, dev, fmt, \
^
drivers/usb/dwc2/hcd.c:4492:8: note: 'pipetype' was declared here
char *pipetype;
^
Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2=m +
CONFIG_USB_DWC2_VERBOSE=y
Patch is against 4.10-rc3 (localversion-next is next-20170112)
drive
Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
Patch is against 4.10-rc3 (localversion-next is next-20170112)
drivers/usb/dwc2/hcd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 9f66777
ested with: x86_64_defconfig + CONFIG_USB_DWC2
(1 sparse and 6 coccinelle warning - preparing separate patches for that)
Patch is against 4.10-rc3 (localversion-next is next-20170112)
drivers/usb/dwc2/hcd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dw
From: Wei Yongjun
Date: Thu, 12 Jan 2017 13:43:47 +
> From: Wei Yongjun
>
> Fixes the following sparse warning:
>
> drivers/net/usb/cdc_ether.c:469:6: warning:
> symbol 'usbnet_cdc_zte_status' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun
Applied.
--
To unsubscr
On Thu, Jan 12, 2017 at 04:54:38PM +0100, Nicholas Mc Guire wrote:
> Signed-off-by: Nicholas Mc Guire
> ---
> Problem reported by sparse
> drivers/usb/dwc2/hcd.c: In function 'dwc2_dump_urb_info':
> ./include/linux/dynamic_debug.h:134:3: warning: 'pipetype' may be used
> uninitialized in this fun
^
Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2=m +
CONFIG_USB_DWC2_VERBOSE=y
Patch is against 4.10-rc3 (localversion-next is next-20170112)
drivers/usb/dwc2/hcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
i
On Thu, Jan 12, 2017 at 05:25:00PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 12, 2017 at 04:54:38PM +0100, Nicholas Mc Guire wrote:
> > Signed-off-by: Nicholas Mc Guire
> > ---
> > Problem reported by sparse
> > drivers/usb/dwc2/hcd.c: In function 'dwc2_dump_urb_info':
> > ./include/linux/dyn
On 01/12/2017 12:26 AM, Felipe Balbi wrote:
>
> Hi,
>
> Shuah Khan writes:
>> During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from
>> xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding
>> the platform device.
>>
>> dwc3_host_init() was changed to not
* Tony Lindgren [170109 10:35]:
> Hi,
>
> * Alexandre Bailon [170109 09:04]:
> > Sometime, a transfer may not be queued due to a race between runtime pm
> > and cppi41_dma_issue_pending().
> > Sometime, cppi41_runtime_resume() may be interrupted right before to
> > update device PM state to RESU
Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.
Note that the macro-mode buffer was larger than necessary.
Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable
Signed-off-by: Johan Hov
These patches fix DMA buffers on stack and information leaks in the
corsair HID driver.
Note that this series has only been compile tested.
Johan
Johan Hovold (2):
HID: corsair: fix DMA buffers on stack
HID: corsair: fix control-transfer error handling
drivers/hid/hid-corsair.c | 60 +
On Thu, Jan 12, 2017 at 02:56:08PM +0100, Johan Hovold wrote:
> Several USB serial drivers failed to detect short control transfers,
> something which could lead to uninitialised data leaking to user space
> or being treated as valid input.
>
> The two information-leak fixes are marked for stable,
On Thu, Jan 12, 2017 at 03:54:01PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Here are my fixes for -rc4. All have been in linux-next.
Pulled and pushed out, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.
On 01/12/2017 11:09 AM, Tony Lindgren wrote:
> * Tony Lindgren [170109 10:35]:
>> Hi,
>>
>> * Alexandre Bailon [170109 09:04]:
>>> Sometime, a transfer may not be queued due to a race between runtime pm
>>> and cppi41_dma_issue_pending().
>>> Sometime, cppi41_runtime_resume() may be interrupted
On Thu, Jan 12, 2017 at 02:33:36PM +0100, Christoph Anton Mitterer wrote:
> Hi.
>
> This is basically from:
> https://bugzilla.kernel.org/show_bug.cgi?id=108341
> respectively
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805903
> the later in which Ben Hutchings recommended me to ping this
On 09.01.2017 18:42, Mathias Nyman wrote:
On 09.01.2017 16:23, Patrice Chotard wrote:
On 01/09/2017 01:30 PM, Mathias Nyman wrote:
On 09.01.2017 11:51, Patrice Chotard wrote:
Hi Mathias, Greg
Hi
I am working on ARM STi platform, since v4.10-rc1, when booting B2260 or B2120
STi boards pl
On Thu, Jan 12, 2017 at 06:19:53PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 12, 2017 at 02:56:08PM +0100, Johan Hovold wrote:
> > Several USB serial drivers failed to detect short control transfers,
> > something which could lead to uninitialised data leaking to user space
> > or being treate
On 01/12/2017 06:23 PM, Grygorii Strashko wrote:
>
>
> On 01/12/2017 11:09 AM, Tony Lindgren wrote:
>> * Tony Lindgren [170109 10:35]:
>>> Hi,
>>>
>>> * Alexandre Bailon [170109 09:04]:
Sometime, a transfer may not be queued due to a race between runtime pm
and cppi41_dma_issue_pendin
Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.
Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than
Hi Nobuo,
On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> This patch set implements operations to export and unexport device
> using pre-defined but un-used export and un-export request and reply.
Get rid of the above from the changelog.
>
> This patch modifies export and un-export reply in
> to
* Grygorii Strashko [170112 09:24]:
> On 01/12/2017 11:09 AM, Tony Lindgren wrote:
> > Below is what seems to fix issues for me, not seeing any more warnings
> > either.
> >
> > Care to give it a try with your USB headset?
>
> This looks more close to what is provided in
> Documentation\power\r
* Alexandre Bailon [170112 09:42]:
> This solves the issue but I still have a bad playback quality.
> I don't remember if I have spoken about it so I will describe it.
> When I play audio (with your patch or mine), the music cut a lot.
> The issue go away when the MUSB driver is built in PIO mode
Hi Bin,
On Thu, Jan 12, 2017 at 08:50:14AM -0600, Bin Liu wrote:
> On Wed, Jan 11, 2017 at 10:06:38PM +0100, Maxime Ripard wrote:
> > On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> > > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> > > >
> > > >
> > > > 11.01.2017,
On Thu, 2017-01-12 at 18:24 +0100, Greg KH wrote:
> What kworker process causes this? Does it have a name?
How do I find out? Or do you mean the /0:3 which is contained in the
top output below?
> > # perf top -p 2359 gives something like that:
> > Samples: 64K of event 'cycles:ppp', Event count
On 1/12/2017 12:07 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> On 1/11/2017 4:22 PM, John Stultz wrote:
>>> Just wanted to resend my patches for dwc2 controller on the
>>> HiKey board for consideration for the 4.11 merge window.
>>>
>>> This patchset is the same as v2, only rebased
On Thu, Jan 12, 2017 at 12:05 AM, Felipe Balbi
wrote:
>
> Hi,
>
> John Youn writes:
>> On 1/11/2017 4:22 PM, John Stultz wrote:
>>> Just wanted to resend my patches for dwc2 controller on the
>>> HiKey board for consideration for the 4.11 merge window.
>>>
>>> This patchset is the same as v2, onl
On Thu, Jan 12, 2017 at 08:06:46PM +0100, Christoph Anton Mitterer wrote:
> On Thu, 2017-01-12 at 18:24 +0100, Greg KH wrote:
> > What kworker process causes this? Does it have a name?
> How do I find out? Or do you mean the /0:3 which is contained in the
> top output below?
Yes, thanks, I saw it
Hello Johan Hovold,
The patch 7a6ee2b02751: "USB: opticon: switch to generic read
implementation" from Nov 18, 2012, leads to the following static
checker warning:
drivers/usb/serial/opticon.c:146 opticon_open()
info: return a literal instead of 'res'
drivers/usb/serial/opticon.c
From: Sudip Mukherjee
The variable Newblk was only being assigned some value but was never
used after that.
Signed-off-by: Sudip Mukherjee
---
v2: added From: line
drivers/usb/storage/ene_ub6250.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers
On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Modifications to host driver wrapper and its related operations (i.e.
> bind/unbind).
Way too many changes in this one patch.
>
> usbip_get_device() method was not used. The implementation of the
> method searches a bound devices list by list index.
From: Sudip Mukherjee
The variable live was assigned the host controller running status but
it was never used or checked after that.
Signed-off-by: Sudip Mukherjee
---
v2: added From: tag
drivers/usb/host/oxu210hp-hcd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/host/ox
Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
together with recent MUSB changes allowed USB and DMA on BeagleBone to idle
when no cable is connected. But looks like few corner case issues still
remain.
Looks like just by repluging USB cable about ten or so times on Beagle
We can now configure the PMIC interrupt to provide us VBUS
events. In that case we don't need to constantly poll the
status and can make it optional. This is only wired up
for the mini-B interface on beaglebone.
Note that eventually we should get also the connect status
for the host interface when
On 1/11/2017 11:51 PM, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
When dwc3 controller acts as host role with attaching slow speed device
(like mouse or keypad). Then if we plugged out the slow speed device,
it will timeout to run the deconfigurat
On 01/12/2017 03:30 PM, Tony Lindgren wrote:
> Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
> together with recent MUSB changes allowed USB and DMA on BeagleBone to idle
> when no cable is connected. But looks like few corner case issues still
> remain.
>
> Looks like
* Grygorii Strashko [170112 13:54]:
> On 01/12/2017 03:30 PM, Tony Lindgren wrote:
>
> Sry, but even if it looks better it might still race with PM runtime :(
>
> > - if (likely(pm_runtime_active(cdd->ddev.dev)))
> > + if (likely(atomic_read(&cdd->active)))
> > push_desc_queue(c);
On Thu, 2017-01-12 at 21:33 +0100, Greg KH wrote:
> > Shall I forward it to linux-acpi?
> Please do.
FYI: done, https://www.spinics.net/lists/linux-acpi/msg71326.html
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On 01/12/2017 04:19 PM, Tony Lindgren wrote:
> * Grygorii Strashko [170112 13:54]:
>> On 01/12/2017 03:30 PM, Tony Lindgren wrote:
>>
>> Sry, but even if it looks better it might still race with PM runtime :(
>>
>>> - if (likely(pm_runtime_active(cdd->ddev.dev)))
>>> + if (likely(atomic_read
* Grygorii Strashko [170112 14:53]:
>
>
> On 01/12/2017 04:19 PM, Tony Lindgren wrote:
> > * Grygorii Strashko [170112 13:54]:
> >> On 01/12/2017 03:30 PM, Tony Lindgren wrote:
> >>
> >> Sry, but even if it looks better it might still race with PM runtime :(
> >>
> >>> - if (likely(pm_runtime_a
On 01/12/2017 05:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko [170112 14:53]:
>>
>>
>> On 01/12/2017 04:19 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko [170112 13:54]:
On 01/12/2017 03:30 PM, Tony Lindgren wrote:
Sry, but even if it looks better it might still race with
On 1/12/2017 7:41 AM, Amelie DELAUNAY wrote:
> Hi all,
> Sorry, I did not see Pengcheng Li patch which is exactly the same:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9347979_&d=DgIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA&m=6V
* Grygorii Strashko [170112 15:43]:
> @@ -457,38 +449,36 @@ static void push_desc_queue(struct cppi41_channel *c)
> cppi_writel(reg, cdd->qmgr_mem + QMGR_QUEUE_D(c->q_num));
> }
>
> -static void pending_desc(struct cppi41_channel *c)
> +static void cppi41_dma_issue_pending(struct dma_ch
On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Implementation of new connect operation. This is linked as a part of
> usbip command. With this patch, usbip command has following operations.
>
> bind
> unbind
> list (local/remote)
> attach
> detach
> port
> connect ... this patch
Don't inclu
On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Implementation of new disconnect operation. This is linked as a part of
> usbip command. With this patch, usbip command has following operations.
>
> bind
> unbind
> list (local/remote)
> attach
> detach
> port
> connect ... previous patch
> di
On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> This patch adds function and usage of new connect operation, disconnect
> operation and application(vhci)-side daemon to README and manuals.
This should be the first patch for the series. That would have saved
me lot of time. Please move this patch up.
mt, \
>^
> drivers/usb/dwc2/hcd.c:4492:8: note: 'pipetype' was declared here
> char *pipetype;
> ^
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2=m +
> CONFIG_USB_DWC2_VERBOSE=y
>
> Patch is against 4.10-rc3 (localversion-next is
2: Add functions to set and clear force mode")
> so not sure if I am not overlooking some reason for the highrestimer here ?
>
> This needs to be clarified by someone that knows the details and history
> of this device/driver.
>
> Patch was compile tested with: x86_64_defcon
; Signed-off-by: Nicholas Mc Guire
> ---
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
> (1 sparse and 6 coccinelle warning - preparing separate patches for that)
>
> Patch is against 4.10-rc3 (localversion-next is next-20170112)
>
> drivers/usb/
ING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:3299:1-21: WARNING: Assignment of bool to 0/1
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
>
> Patch is against 4.10-rc3 (localversion-next is next-20170112)
>
> drivers/usb/dwc2/hcd.c | 12
Hi Roger，
在 2017年01月12日 23:38, Roger Quadros 写道:
On 12/01/17 17:33, Alan Stern wrote:
On Thu, 12 Jan 2017, Roger Quadros wrote:
William,
On 12/01/17 14:03, William Wu wrote:
From: William wu
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb
From: William wu
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] x
1 - 100 of 102 matches
Mail list logo
