Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=100631
>
> --- Comment #1 from Greg Kroah-Hartman ---
> On Mon, Jun 29, 2015 at 09:53:04AM +, bugzilla-dae...@bugzilla.kernel.org
> wrote:
>> https://bugzilla.kernel.org/show_bug.
> Le Mon, 29 Jun 2015 16:40:52 +0800,
> Peter Chen a écrit :
>
> > I am not sure if you have noticed the patch[1], it is the solution for
> > this issue, in the RTL, the default reserved time for one packet is
> > 1023 bytes for siTD, so after 4 * 64 packets has transfered, the
> > reserved tim
Hi Peter,
Le Mon, 29 Jun 2015 16:40:52 +0800,
Peter Chen a écrit :
> I am not sure if you have noticed the patch[1], it is the solution for
> this issue, in the RTL, the default reserved time for one packet is
> 1023 bytes for siTD, so after 4 * 64 packets has transfered, the
> reserved time is
Ok, for now I should let go of this - might be it was a little bit too much for
the time constaints I am having.
But thank you for your effort Oliver.
Anyway, trying to write this new TX engine helped me in understand better
things and conceive the patch I sent you affecting cdc_ncm.c, which tri
Hi Alan,
When reading the code (at qh_urb_transaction) about zero-length packet
for EHCI, would you please help me on below questions:
- I have not found the zero-length qtd prepared for control read (eg,
the transfer size is multiple of wMaxPacketSize), Am I missing
something?
- Why the IN tran
On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote:
> On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote:
> > Hello,
> >
> > I'm sending this mail to report a bug concerning the latest kernel 4.1.
> >
> > Here is the problem (and the test I've done):
> > I h
EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC
virt_dev->num_cached_rings counts on freed ring and
is not updated correctly. In xhci_free_or_cache_endpoint_ring() function,
the free ring is added into cache and then
num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cache
Fix four occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer
---
drivers/usb/core/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e26
Hello.
On 6/30/2015 4:02 PM, Kris Borer wrote:
Fix four occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer
---
drivers/usb/core/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers
On Tue, 2015-06-30 at 09:02 -0400, Kris Borer wrote:
> Fix four occurrences of the checkpatch.pl error:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by: Kris Borer
Sorry, but NACK!
Those patches are totally broken.
> ---
> drivers/usb/core/hcd.c | 13 -
> 1 file
Hi
On 30.06.2015 04:54, Reyad Attiyat wrote:
> Hey Mathias,
>
> The intention is to send an extra endpoint packet of length zero as my
> wireless card needs this to function properly. I have skimmed through
> the xhci spec and assumed that each td would generate a packet. That
> is why I do not c
Fix "though" to "through" in documentation of xhci_alloc_streams().
Signed-off-by: Luis de Bethencourt
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7da0d60..e66857f 100644
--- a/drivers/usb
Hi,
I am looking at a device that spontaneously switches
its mode. I guess that you need to actively do something
that some Windows versions do to keep the device in its
initial mode.
The device contains an SD card reader. That leaves me in
a predicament. The medium if it is mounted before the
dev
On Tue, Jun 30, 2015 at 09:02:22AM -0400, Kris Borer wrote:
> Fix four occurrences of the checkpatch.pl error:
>
> ERROR: do not use assignment in if condition
If you are going to do stuff like this, use Coccinelle so you are sure
you don't break the code.
Also always test your changes, if possi
On Sat, 27 Jun 2015, Greg Kroah-Hartman wrote:
> On Fri, Jun 26, 2015 at 09:20:19PM -0400, Alan Stern wrote:
> > My Apple keyboard isn't here at the moment, and I don't remember
> > exactly what its hub descriptor contains. In theory, it _should_ mark
> > the permanently attached port as non-remo
This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies"). The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called. The user-visible consequence is that the driver
occasionally crashes or loc
On Mon, 29 Jun 2015, Raphael Hertzog wrote:
> [ Please keep me in CC as I'm not subscribed ]
>
> Hello,
>
> I'm the happy owner of a Intel NUC D54250WYKH (updated it to latest Intel
> firmware) which has an XHCI host controller. It's connected over USB 3 to
> a JBOD-configured disk enclosure (IC
On Tue, 30 Jun 2015, Oliver Neukum wrote:
> Hi,
>
> I am looking at a device that spontaneously switches
> its mode. I guess that you need to actively do something
> that some Windows versions do to keep the device in its
> initial mode.
When does the spontaneous mode switch occur?
> The device
On Tue, 30 Jun 2015, Peter Chen wrote:
> Hi Alan,
>
> When reading the code (at qh_urb_transaction) about zero-length packet
> for EHCI, would you please help me on below questions:
>
> - I have not found the zero-length qtd prepared for control read (eg,
> the transfer size is multiple of wMaxP
On Tue, 2015-06-30 at 11:34 -0400, Alan Stern wrote:
> On Tue, 30 Jun 2015, Oliver Neukum wrote:
>
> > Hi,
> >
> > I am looking at a device that spontaneously switches
> > its mode. I guess that you need to actively do something
> > that some Windows versions do to keep the device in its
> > init
On Tue, Jun 30, 2015 at 12:10:40PM +, AMAN DEEP wrote:
> EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC
What does this mean?
And what does "[EDT]" in your subject mean?
Please fix up and resend properly.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
On Tue, Jun 30, 2015 at 08:53:14AM +0200, Glasswall Information Point wrote:
>
>
> Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org:
> > https://bugzilla.kernel.org/show_bug.cgi?id=100631
> >
> > --- Comment #1 from Greg Kroah-Hartman ---
> > On Mon, Jun 29, 2015 at 09:53:04AM +
Some of the messages were plain unnecessary
and some were actually errors. Fix it all
up.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-omap.c | 43 ---
1 file changed, 4 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/d
that message is informing that the clock is missing.
However, that's a valid condition for some setups; driver
even ignores the error and continues just fine.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-exynos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
the mode of operation is exposed through debugfs
at all times. Because of that, we're removing
the unnecessary messages.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-st.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index
those two messages are informing that the clock
doesn't exist; that, however, is a valid situation
and driver continues just fine by ignoring the error.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-qcom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/us
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b
Hi,
I plan to get these patches merged for v4.3 merge window.
Let me know if you have any real objections. Keep in mind
that "I like dev_dbg()" or "I'm used to dev_dbg()" are not
valid objections.
cheers
Felipe Balbi (7):
usb: dwc3: drop dev_dbg() from dwc3
usb: dwc3: omap: drop dev_dbg() us
now that we have no users of dev_dbg() in dwc3,
we can't safely remove CONFIG_USB_DWC3_DEBUG.
If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we will depend
on DYNAMIC_PRINTK to enable such messages.
Signed-off-by: Fel
After this patch, the actual dwc3 driver
doesn't need dev_dbg(). After a couple more
patches on glue layers, we will be able to
remove CONFIG_DWC3_DEBUG and rely solely
on tracepoints for our debugging.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 8 +---
drivers/usb/dwc3/ep0
On Tue, Jun 30, 2015 at 12:56:50PM -0500, Felipe Balbi wrote:
> now that we have no users of dev_dbg() in dwc3,
> we can't safely remove CONFIG_USB_DWC3_DEBUG.
>
> If dev_dbg() is ever strictly necessary - and I
> don't see why it would, considering we want to
> rely on tracepoints for debug - we
Hello.
On 06/30/2015 06:25 PM, Alan Stern wrote:
This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies"). The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called. The user-visible conse
Hello.
On 06/30/2015 08:56 PM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc
Hello.
On 06/30/2015 08:56 PM, Felipe Balbi wrote:
now that we have no users of dev_dbg() in dwc3,
we can't safely remove CONFIG_USB_DWC3_DEBUG.
s/can't/can/.
If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we
On Tue, 30 Jun 2015, Sergei Shtylyov wrote:
> Hello.
>
> On 06/30/2015 06:25 PM, Alan Stern wrote:
>
> > This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
> > don't lose track of EDs when a controller dies"). The commit changed
> > ed_state from ED_UNLINK to ED_IDLE too earl
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue
On Tue, Jun 30, 2015 at 10:23:16PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 06/30/2015 08:56 PM, Felipe Balbi wrote:
>
> >now that we have no users of dev_dbg() in dwc3,
> >we can't safely remove CONFIG_USB_DWC3_DEBUG.
>
>s/can't/can/.
heh, thanks :-) I'll fix in branch only.
--
balb
On Tue, Jun 30, 2015 at 10:21:40PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 06/30/2015 08:56 PM, Felipe Balbi wrote:
>
> >that's an error condition, not a debugging message.
>
> >Let's promote it appropriately.
>
> >Signed-off-by: Felipe Balbi
> >---
> > drivers/usb/dwc3/dwc3-keystone.c
On 07/01/2015 12:10 AM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-k
On Wed, Jul 01, 2015 at 12:12:05AM +0300, Sergei Shtylyov wrote:
> On 07/01/2015 12:10 AM, Felipe Balbi wrote:
>
> >>>that's an error condition, not a debugging message.
>
> >>>Let's promote it appropriately.
>
> >>>Signed-off-by: Felipe Balbi
> >>>---
> >>> drivers/usb/dwc3/dwc3-keystone.c |
The following patch proposes a new kernel module to provide an
alternate protocol for transporting USB devices over a TCP/IP connection.
This flows from a few conversations on the Spice devel mailing list.[1][2]
I am relying heavily on the opinion of Hans de Goede, who believes
that the usbredir
On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote:
> those two messages are informing that the clock
> doesn't exist; that, however, is a valid situation
> and driver continues just fine by ignoring the error.
Reviewed-by: Andy Gross
--
Qualcomm Innovation Center, Inc.
The Qualcomm I
On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
>
> Signed-off-by: Jeremy White
> ---
> MAINTAINERS |6 +
> drivers/usb/Kconfig
On Tue, Jun 30, 2015 at 06:15:29PM -0500, Andy Gross wrote:
> On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote:
> > those two messages are informing that the clock
> > doesn't exist; that, however, is a valid situation
> > and driver continues just fine by ignoring the error.
>
> Revie
Hi，bjorn,
Thanks for your kindly reply and providing so much info about linux wwan
components!
We'll make a deep research on linux wwan architecture, maybe we can support it
in the newly developing products.
About what you saying about "submit the patch formally", what steps should I
do? Is th
On Wed, Jul 01, 2015 at 12:49:01AM +, Chenqi (jakio) wrote:
> Hi，bjorn,
>
> Thanks for your kindly reply and providing so much info about linux wwan
> components!
>
> We'll make a deep research on linux wwan architecture, maybe we can support
> it in the newly developing products.
> About w
Hi， Greg，
Got it！
Thanks
Jakio.chen
-邮件原件-
发件人: Greg KH [mailto:gre...@linuxfoundation.org]
发送时间: 2015年7月1日 9:05
收件人: Chenqi (jakio)
抄送: Bjørn Mork; torva...@linux-foundation.org; aleksan...@aleksander.es;
d...@redhat.com; oli...@neukum.org; ben.hutchi...@codethink.co.uk;
linux-usb@vg
On Tue, Jun 30, 2015 at 12:03:34PM -0400, Alan Stern wrote:
> On Tue, 30 Jun 2015, Peter Chen wrote:
>
> > Hi Alan,
> >
> > When reading the code (at qh_urb_transaction) about zero-length packet
> > for EHCI, would you please help me on below questions:
> >
> > - I have not found the zero-length
It's pointless to post a patch that you know has problems with it (i.e.
it's not even in proper kernel coding style), as it will never be
reviewed or even looked at.
Thanks for the reply, and I'm sorry for the clumsy ask.
I would still appreciate feedback on two points:
1. Is the basic pre
This patch uses the devm_extcon_dev_[allocate|register]() to manage the
resource automatically and replace deprecated API as following:
- extcon_[set|get]_cable_state(*edev, char *) ->
extcon_[set|get]_cable_state_(*edev, id)
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Signed-off-by: Chanwoo Choi
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev
This patch removes the deprecated API of extcon and then use the new extcon API
with the unique id to indicate the each external connector (USB-HOST).
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Yoshihiro Shimoda
Cc:
This patch removes the deprecated API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector.
Th deprecated API with cable name as following:
- int extcon_register_interest(struct extcon_specific_cable_nb *obj,
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev
virt_dev->num_cached_rings counts on freed ring and
is not updated correctly. In xhci_free_or_cache_endpoint_ring() function,
the free ring is added into cache and then
num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev
On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
> >
> >It's pointless to post a patch that you know has problems with it (i.e.
> >it's not even in proper kernel coding style), as it will never be
> >reviewed or even looked at.
>
> Thanks for the reply, and I'm sorry for the clumsy as
Bug as submitted on: https://bugzilla.kernel.org/show_bug.cgi?id=100631
Mailing it to this mailing list on advice of greg k-h
--
Cannot use the logitech k520 (046d:c52b) to unlock my luks disk at boot time
Hitting keyb
58 matches
Mail list logo
