date:20170818

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

2017-08-18 Thread Felipe Balbi


hi,

Kai-Heng Feng  writes:
> When plugging Logitech C920 webcam, warning messages filled up dmesg:
> [77117.655018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
> needs XHCI_TRUST_TX_LENGTH quirk?
> [77117.659018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
> needs XHCI_TRUST_TX_LENGTH quirk?

have you confirmed this is needed for this controller? Anybody from
Renesas has confirmed it? Do you have an errata document to refer to?

> [77122.622952] handle_tx_event: 541 callbacks suppressed
>
> No more warning messages with XHCI_TRUST_TX_LENGTH applied.
>
> BugLink: https://bugs.launchpad.net/bugs/1710548
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/usb/host/xhci-pci.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 8071c8fdd15e..8566b43e19ba 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -202,8 +202,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   xhci->quirks |= XHCI_BROKEN_STREAMS;
>   }
>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
> - pdev->device == 0x0015)
> + pdev->device == 0x0015) {

unnecessary

>   xhci->quirks |= XHCI_RESET_ON_RESUME;
> + xhci->quirks |= XHCI_TRUST_TX_LENGTH;

xhci->quirks |= XHCI_RESET_ON_RESUME |
XHCI_TRUST_TX_LENGTH;

> + }

unnecessary

-- 
balbi


signature.asc
Description: PGP signature

Re: uvc-gadget for UVC testing doesn't seem to work with vivid

2017-08-18 Thread Felipe Balbi


Hi,

Rail Shafigulin  writes:
> Let me apologize for emailing directly to the list as I'm not one of
> the developers and just starting out with USB and UVC. After searching

 the list is open to anybody and we welcome newcomers :-)

> online for about a week I just couldn't find answers and I hope the
> original authors of the uvc-gadget tool are on the list and can help
> out.
>
> Needed to test a UVC in a custom built kernel (Xilinx petalinux), .
> Followed these directions,
> https://github.com/torvalds/linux/blob/ef954844c7ace62f773f4f23e28d2d915adc419f/Documentation/usb/gadget-testing.txt#L717-L730.
>
> Patches didn't work. Had to look around for correct ones. Found them
> here, 
> http://markmail.org/message/hb7evzvigbuxptz5#query:+page:1+mid:s73fdeffjgb2v2yw+state:results.
>
> Combined and applied the patches into a repo here,
> https://github.com/cyboflash/uvc-gadget.git.
>
> When I ran a test command, given in the instructions above,
> uvc-gadget -u /dev/video -v /dev/video #>
>
> got the following error:
> V4L2_CORE: (jpeg decoder) error while decoding frame
>
> and a black screen.
>
> One thing to note is that I was not using luvcview, but guvcview.
>
> It looks like the error is coming from here,
> https://sourceforge.net/p/guvcview/git-master/ci/master/tree/gview_v4l2core/jpeg_decoder.c#l1503
>
> My thoughts
> 1. I don't think the error is coming from v4l2. I tested it on another
> machine and it worked. But I'm not an expert so I can't say for sure.
> 2. I don't think the error is coming from UVC. I think since I see a
> black screen, it is working. Again, I'm not an expert, so I can't say
> for sure.
> 3. I think the error is due to uvc-gadget test application. It could
> be that the applied patches are outdated, but I just didn't find
> anything else online. But, I'm not an expert so definitely can't say
> for sure.
>
> I would greatly appreciate any help with this as I'm just starting out
> with UVC and USB.

 Which kernel are you using? Which UDC driver are you using?
>>>
>>> Balbi,
>>>
>>> The board is configured as a USB Camera Gadget. Here is the output of uname 
>>> -a
>>> Linux Xilinx-ZCU102-2016_3 4.6.0 #33 SMP Thu Aug 10 11:47:57 PDT 2017
>>> aarch64 GNU/Linux
>>
>> okay, then you need to ask for support from whoever gave you this
>> kernel. 4.6 is a really old release which this forum doesn't support.
>>
>>> When you say UDC (USB Device Controller) driver, what exactly do you mean?
>>
>> which driver is g_webcam binding to? What do you have under
>> /sys/class/udc ?
>
> I have this under /sys/class/udc
>
> fe20.dwc3
>
> under /sys/class/udc/fe20.dwc3

okay. Test against mainline and I can help you; otherwise you need to go
after Xilinx or whoever gave you this v4.6 kernel.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

2017-08-18 Thread Kai-Heng Feng

Hi,

On Fri, Aug 18, 2017 at 3:22 PM, Felipe Balbi
 wrote:
>
> hi,
>
> Kai-Heng Feng  writes:
>> When plugging Logitech C920 webcam, warning messages filled up dmesg:
>> [77117.655018] xhci_hcd :0c:00.0: WARN Successful completion on short 
>> TX: needs XHCI_TRUST_TX_LENGTH quirk?
>> [77117.659018] xhci_hcd :0c:00.0: WARN Successful completion on short 
>> TX: needs XHCI_TRUST_TX_LENGTH quirk?
>
> have you confirmed this is needed for this controller?
I just found commit d2f48f05cd2a2 ("usb: xhci: ASMedia ASM1042A
chipset need shorts TX quirk") and did the same thing for this
controller.

> Anybody from Renesas has confirmed it?
No, it's a user reported problem, please check the bug report in the link.

> Do you have an errata document to refer to?
No. Probably need Renesas guy to provide it.

>
>> [77122.622952] handle_tx_event: 541 callbacks suppressed
>>
>> No more warning messages with XHCI_TRUST_TX_LENGTH applied.
>>
>> BugLink: https://bugs.launchpad.net/bugs/1710548
>> Signed-off-by: Kai-Heng Feng 
>> ---
>>  drivers/usb/host/xhci-pci.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>> index 8071c8fdd15e..8566b43e19ba 100644
>> --- a/drivers/usb/host/xhci-pci.c
>> +++ b/drivers/usb/host/xhci-pci.c
>> @@ -202,8 +202,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
>> xhci_hcd *xhci)
>>   xhci->quirks |= XHCI_BROKEN_STREAMS;
>>   }
>>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
>> - pdev->device == 0x0015)
>> + pdev->device == 0x0015) {
>
> unnecessary
>
>>   xhci->quirks |= XHCI_RESET_ON_RESUME;
>> + xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>
> xhci->quirks |= XHCI_RESET_ON_RESUME |
> XHCI_TRUST_TX_LENGTH;
>
>> + }
>
> unnecessary

Do you mean that this quirk just hide the warning, it doesn't fix the
root cause?

>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

2017-08-18 Thread Felipe Balbi


Hi,

Kai-Heng Feng  writes:
>>> When plugging Logitech C920 webcam, warning messages filled up dmesg:
>>> [77117.655018] xhci_hcd :0c:00.0: WARN Successful completion on short 
>>> TX: needs XHCI_TRUST_TX_LENGTH quirk?
>>> [77117.659018] xhci_hcd :0c:00.0: WARN Successful completion on short 
>>> TX: needs XHCI_TRUST_TX_LENGTH quirk?
>>
>> have you confirmed this is needed for this controller?
> I just found commit d2f48f05cd2a2 ("usb: xhci: ASMedia ASM1042A
> chipset need shorts TX quirk") and did the same thing for this
> controller.
>
>> Anybody from Renesas has confirmed it?
> No, it's a user reported problem, please check the bug report in the link.
>
>> Do you have an errata document to refer to?
> No. Probably need Renesas guy to provide it.

or confirm it. Yoshihiro, do you know if this is needed?

>>> [77122.622952] handle_tx_event: 541 callbacks suppressed
>>>
>>> No more warning messages with XHCI_TRUST_TX_LENGTH applied.
>>>
>>> BugLink: https://bugs.launchpad.net/bugs/1710548
>>> Signed-off-by: Kai-Heng Feng 
>>> ---
>>>  drivers/usb/host/xhci-pci.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 8071c8fdd15e..8566b43e19ba 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -202,8 +202,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
>>> xhci_hcd *xhci)
>>>   xhci->quirks |= XHCI_BROKEN_STREAMS;
>>>   }
>>>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
>>> - pdev->device == 0x0015)
>>> + pdev->device == 0x0015) {
>>
>> unnecessary
>>
>>>   xhci->quirks |= XHCI_RESET_ON_RESUME;
>>> + xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>>
>> xhci->quirks |= XHCI_RESET_ON_RESUME |
>> XHCI_TRUST_TX_LENGTH;
>>
>>> + }
>>
>> unnecessary
>
> Do you mean that this quirk just hide the warning, it doesn't fix the
> root cause?

no, I meant that you need to add {} if you make a single statement out
of the quirks.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

2017-08-18 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
testing/next
head:   862b43460309779e5814616a68aa36d29a70d6e0
commit: 2b4e4d3c929db0fc7cf99212bfac0570b6902c14 [48/49] usb: gadget: serial: 
fix oops when data rx'd after close
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2b4e4d3c929db0fc7cf99212bfac0570b6902c14
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/usb//gadget/function/u_serial.c: In function 'gs_rx_push':
>> drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to 
>> binary & (have 'unsigned int' and 'struct tty_struct *')
  if (req->actual & tty) {
  ^

vim +540 drivers/usb//gadget/function/u_serial.c

   492  
   493  /*
   494   * RX tasklet takes data out of the RX queue and hands it up to the TTY
   495   * layer until it refuses to take any more data (or is throttled back).
   496   * Then it issues reads for any further data.
   497   *
   498   * If the RX queue becomes full enough that no usb_request is queued,
   499   * the OUT endpoint may begin NAKing as soon as its FIFO fills up.
   500   * So QUEUE_SIZE packets plus however many the FIFO holds (usually two)
   501   * can be buffered before the TTY layer's buffers (currently 64 KB).
   502   */
   503  static void gs_rx_push(unsigned long _port)
   504  {
   505  struct gs_port  *port = (void *)_port;
   506  struct tty_struct   *tty;
   507  struct list_head*queue = &port->read_queue;
   508  booldisconnect = false;
   509  booldo_push = false;
   510  
   511  /* hand any queued data to the tty */
   512  spin_lock_irq(&port->port_lock);
   513  tty = port->port.tty;
   514  while (!list_empty(queue)) {
   515  struct usb_request  *req;
   516  
   517  req = list_first_entry(queue, struct usb_request, list);
   518  
   519  /* leave data queued if tty was rx throttled */
   520  if (tty && tty_throttled(tty))
   521  break;
   522  
   523  switch (req->status) {
   524  case -ESHUTDOWN:
   525  disconnect = true;
   526  pr_vdebug("ttyGS%d: shutdown\n", 
port->port_num);
   527  break;
   528  
   529  default:
   530  /* presumably a transient fault */
   531  pr_warn("ttyGS%d: unexpected RX status %d\n",
   532  port->port_num, req->status);
   533  /* FALLTHROUGH */
   534  case 0:
   535  /* normal completion */
   536  break;
   537  }
   538  
   539  /* push data to (open) tty */
 > 540  if (req->actual & tty) {
   541  char*packet = req->buf;
   542  unsignedsize = req->actual;
   543  unsignedn;
   544  int count;
   545  
   546  /* we may have pushed part of this packet 
already... */
   547  n = port->n_read;
   548  if (n) {
   549  packet += n;
   550  size -= n;
   551  }
   552  
   553  count = tty_insert_flip_string(&port->port, 
packet,
   554  size);
   555  if (count)
   556  do_push = true;
   557  if (count != size) {
   558  /* stop pushing; TTY layer can't handle 
more */
   559  port->n_read += count;
   560  pr_vdebug("ttyGS%d: rx block %d/%d\n",
   561port->port_num, count, 
req->actual);
   562  break;
   563  }
   564  port->n_read = 0;
   565  }
   566  
   567  list_move(&req->list, &port->read_pool);
   568  port->read_started--;
   569  }
   570  
   571  /* Push from tty to ldisc; this is handled by a workqueue,
   572   * so we won't get callbacks and can hold port_lock
   573   */
   574  if (do_push)
   575  tty_flip_buffer_

Re: [balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

2017-08-18 Thread Felipe Balbi


Hi,

kbuild test robot  writes:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> testing/next
> head:   862b43460309779e5814616a68aa36d29a70d6e0
> commit: 2b4e4d3c929db0fc7cf99212bfac0570b6902c14 [48/49] usb: gadget: serial: 
> fix oops when data rx'd after close
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 2b4e4d3c929db0fc7cf99212bfac0570b6902c14
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa 
>
> All errors (new ones prefixed by >>):
>
>drivers/usb//gadget/function/u_serial.c: In function 'gs_rx_push':
>>> drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to 
>>> binary & (have 'unsigned int' and 'struct tty_struct *')
>   if (req->actual & tty) {

fixed locally.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

2017-08-18 Thread Mathias Nyman


On 17.08.2017 06:19, Thang Q. Nguyen wrote:

On Tue, Aug 8, 2017 at 11:27 AM, Thang Q. Nguyen  wrote:

XHCI specification 1.1 does not require xHCI-compliant controllers
to always enable hardware USB2 LPM. However, the current xHCI
driver always enable it when seeing HLC=1.
This patch supports an option for users to control disabling
USB2 Hardware LPM via DT/ACPI attribute.
This option is needed in case user would like to disable this
feature. For example, their xHCI controller has its USB2 HW LPM
broken.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
Acked-by: Rob Herring 
---

...




Do you have any comments about this patch? Thanks.
--


Looks good,
will send forward after 4.14-rc1

Thanks
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb 1-2: 1:1: cannot set freq 44100 to ep 0x81 and potential fix

2017-08-18 Thread Joakim Tjernlund

I have two USB head sethead (Logitech Inc Logitech Stereo H650e and
Jabra Jabra UC VOICE 550a) who both causes lots of:

usb 1-2: 1:1: cannot set freq 44100 to ep 0x81

errors when using them pin pidgin audio chats.

I found that adding a small delay here:
 diff -u sound/usb/clock.c.org  sound/usb/clock.c 
--- sound/usb/clock.c.org   2017-08-18 14:38:05.597977669 +0200
+++ sound/usb/clock.c   2017-08-18 14:20:14.653661513 +0200
@@ -304,6 +304,7 @@
iface, fmt->altsetting, rate, ep);
return err;
}
+msleep(1);
 
/* Don't check the sample rate for devices which we know don't
 * support reading */

it seems one cannot do these settings too fast
Ant better idea fir a fix? kernel 4.9.44

 Jocke--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] usb: xhci: Handle USB transaction error on address command

2017-08-18 Thread Mathias Nyman


On 16.08.2017 05:15, Lu Baolu wrote:

Hi,

On 08/15/2017 07:30 PM, Mathias Nyman wrote:

On 11.08.2017 05:41, Lu Baolu wrote:

Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.

The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a Stall response from a device. Software should issue a Disable
Slot Command for the Device Slot then an Enable Slot Command to
recover from this error.

This patch handles USB transaction errors on address command
completion events. The related discussion threads can be found
through below links.

http://marc.info/?l=linux-usb&m=149362010728921&w=2
http://marc.info/?l=linux-usb&m=149252752825755&w=2

Suggested-by: Mathias Nyman 
Signed-off-by: Lu Baolu 
---
   drivers/usb/host/xhci.c | 5 +
   1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d6b728d..95780f8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
   break;
   case COMP_USB_TRANSACTION_ERROR:
   dev_warn(&udev->dev, "Device not responding to setup %s.\n", act);
+
+ret = xhci_disable_slot(xhci, udev->slot_id);
+if (!ret)
+xhci_alloc_dev(hcd, udev);


Might be a xhci->mutex locking issue here,
both xhci_setup_device() and xhci_alloc_dev() take xhci->mutex



I will apply xhci->mutex in this patch for code consistency, but I think
we can drop xhci->mutex (in a separated patch) anyway.

xhci->mutex was introduced to protect two race sources of xhci->slot_id
and xhci->addr_dev by below commit:

commit a00918d0521df1c7a2ec9143142a3ea998c8526d
 usb: host: xhci: add mutex for non-thread-safe data


c2d3d49 usb: xhci: move slot_id from xhci_hcd to xhci_command structure
87e44f2 usb: xhci: remove the use of xhci->addr_dev

So we don't need xhci->mutex any more. I will try to do this in a separated
patch with more tests. For now, I will add xhci->mutex for code consistency.


Fixing xhci->mutex sounds like a good idea, and you are right, it's no longer
needed for slot_id or addr_dev.
But it's use was extended to protect xhci_stop() and xhci_setup_device()
from racing at fast xhci host hotplug/removes in this patch.

commit 85ac90f8953a58f6a057b727bc9db97721e3fb8e
Author: Roger Quadros 
Date:   Mon Sep 21 17:46:12 2015 +0300

usb: xhci: lock mutex on xhci_stop
 
Else it races with xhci_setup_device


But I think it's safe to remove xhci->mutex  from xhci_alloc_dev()

There's no huurry with the patch 5/5 so would be nice to get that mutex
cleaned up before.

Thanks
Mathias
  
--

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible null pointer dereference in adutux.ko

2017-08-18 Thread Anton Volkov




On 15.08.2017 18:58, Oliver Neukum wrote:

Am Dienstag, den 15.08.2017, 16:38 +0300 schrieb Anton Volkov:

On 15.08.2017 16:20, Oliver Neukum wrote:


Am Dienstag, den 15.08.2017, 15:59 +0300 schrieb Anton Volkov:


Hello.

While searching for races in the Linux kernel I've come across
"drivers/usb/misc/adutux.ko" module. Here is a question that I came up
with while analyzing results. Lines are given using the info from Linux
v4.12.

Consider the following case:

Thread 1:   Thread 2:
adu_release
->adu_release_internal  adu_disconnect
   udev->dev>dev->udev = NULL
   (adutux.c: line 298)  (adutux.c: line 771)
 usb_deregister_dev

Comments in the source code point at the possibility of adu_release()
being called separately from adu_disconnect(). adu_release() and
adu_disconnect() acquire different mutexes, so they are not protected
from one another. If adu_disconnect() changes dev->udev before its value
is read in adu_release_internal() there will be a NULL pointer
dereference on a read attempt. Is this case feasible from your point of
view?

Thank you for your time.


Hi,

your analysis seems correct to me. In fact it looks like

66d4bc30d128e7c7ac4cf64aa78cb76e971cec5b
USB: adutux: remove custom debug macro

more or less broke disconnect on this driver
(the URBs can also finish after dev->udev = NULL)

Do you want to do a fix or do you want me to do it?

Regards
Oliver



Hello, Oliver.

I am not sure about the best way to solve this problem. If you have any
ideas about it then it would probably be better if you could handle the
fix. Or if you share the ideas I can prepare a patch.


Hi,

given the age of the drivers I would suggest to simply remove the debugging 
statements

Regards
Oliver



Hello, Oliver.

Looks like deletion of lots of debug print won't solve the race problem 
because there are other places that could potentially try to dereference 
dev->udev when disconnect has already poisoned it. For example in 
adu_open there are calls to usb_fill_int_urb with dev->udev as a 
parameter to be dereferenced inside the function.


There are other possible solutions, if I understand correctly:
1) although it is described that adutux_mutex should be used to protect 
only open_count, it usually protects the whole body of a function, so we 
could probably place it before the locking of dev->mtx;
2) move poisoning of dev->udev after usb_deregister_dev in order to wait 
for all other callbacks to finish.


What do you think?

Regards,
Anton

-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

2017-08-18 Thread Stephen Warren

Felipe Balbi wrote at Friday, August 18, 2017 3:30 AM:
> Hi,
> 
> kbuild test robot  writes:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> > testing/next
> > head:   862b43460309779e5814616a68aa36d29a70d6e0
> > commit: 2b4e4d3c929db0fc7cf99212bfac0570b6902c14 [48/49] usb: gadget: 
> > serial: fix oops when data rx'd after close
> > config: xtensa-allmodconfig (attached as .config)
> > compiler: xtensa-linux-gcc (GCC) 4.9.0
> > reproduce:
> > wget 
> > https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 2b4e4d3c929db0fc7cf99212bfac0570b6902c14
> > # save the attached .config to linux build tree
> > make.cross ARCH=xtensa
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/usb//gadget/function/u_serial.c: In function 'gs_rx_push':
> >>> drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands 
> >>> to binary & (have 'unsigned int' and 'struct tty_struct *')
> >   if (req->actual & tty) {
> 
> fixed locally.

Sorry about that, and thanks for fixing it. When I moved this between kernel
trees I re-implemented it since it was so trivial, rather than copying the
patch via git mechanisms. That's obviously a very bad idea:-(

-- 
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb 1-2: 1:1: cannot set freq 44100 to ep 0x81 and potential fix

2017-08-18 Thread Greg KH

On Fri, Aug 18, 2017 at 12:40:47PM +, Joakim Tjernlund wrote:
> I have two USB head sethead (Logitech Inc Logitech Stereo H650e and
> Jabra Jabra UC VOICE 550a) who both causes lots of:
> 
> usb 1-2: 1:1: cannot set freq 44100 to ep 0x81
> 
> errors when using them pin pidgin audio chats.
> 
> I found that adding a small delay here:
>  diff -u sound/usb/clock.c.org  sound/usb/clock.c 
> --- sound/usb/clock.c.org 2017-08-18 14:38:05.597977669 +0200
> +++ sound/usb/clock.c 2017-08-18 14:20:14.653661513 +0200
> @@ -304,6 +304,7 @@
>   iface, fmt->altsetting, rate, ep);
>   return err;
>   }
> +msleep(1);
>  
>   /* Don't check the sample rate for devices which we know don't
>* support reading */
> 
> it seems one cannot do these settings too fast
> Ant better idea fir a fix? kernel 4.9.44

Try sending this to the alsa developer list, which owns the sound usb
driver (hint, scripts/get_maintainer.pl works on files too.)

Also, 4.9 is really old, try the latest kernel release, this might be
fixed already...

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.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: phy: phy-generic: propagate clk_get error if clock is required

2017-08-18 Thread Lucas Stach

If the clock handle is given in the DT, it means the clock is required
for proper operation of the PHY. In that case a failure to obtain the
clock must be propagated to stop the driver from probing. This fixes
working with clocks, which request probe deferral.

Signed-off-by: Lucas Stach 
---
 drivers/usb/phy/phy-generic.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 89d6e7a5fdb7..1cc02eb3fc65 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -224,7 +224,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop,
int err = 0;
 
u32 clk_rate = 0;
-   bool needs_vcc = false;
+   bool needs_vcc = false, needs_clk = false;
 
if (dev->of_node) {
struct device_node *node = dev->of_node;
@@ -233,6 +233,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop,
clk_rate = 0;
 
needs_vcc = of_property_read_bool(node, "vcc-supply");
+   needs_clk = of_property_read_bool(node, "clocks");
nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
   GPIOD_ASIS);
err = PTR_ERR_OR_ZERO(nop->gpiod_reset);
@@ -275,6 +276,8 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop,
if (IS_ERR(nop->clk)) {
dev_dbg(dev, "Can't get phy clock: %ld\n",
PTR_ERR(nop->clk));
+   if (needs_clk)
+   return PTR_ERR(nop->clk);
}
 
if (!IS_ERR(nop->clk) && clk_rate) {
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

2017-08-18 Thread Thang Q. Nguyen

From: "Thang Q. Nguyen" 

For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
configuration"), sysdev points to devices known to the system firmware
or hardware for DMA parameters.
However, the parent of the system firmware/hardware device checking
logic does not work in ACPI boot mode. This patch updates the formulation
to check this case in both DT and ACPI.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
Change since v1:
 - Update codes to work with kernel 4.13-rc5
---
 drivers/usb/host/xhci-plat.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index c04144b..1bb9729 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -187,7 +187,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
 */
sysdev = &pdev->dev;
-   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
+   if (sysdev->parent && !is_of_node(sysdev->fwnode) &&
+   !is_acpi_device_node(sysdev->fwnode) &&
+   (is_of_node(sysdev->parent->fwnode) ||
+is_acpi_device_node(sysdev->parent->fwnode)))
sysdev = sysdev->parent;
 #ifdef CONFIG_PCI
else if (sysdev->parent && sysdev->parent->parent &&
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

Re: uvc-gadget for UVC testing doesn't seem to work with vivid

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

Re: [PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

[balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

Re: [balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

Re: [PATCH v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

usb 1-2: 1:1: cannot set freq 44100 to ep 0x81 and potential fix

Re: [PATCH v3 5/5] usb: xhci: Handle USB transaction error on address command

Re: Possible null pointer dereference in adutux.ko

RE: [balbi-usb:testing/next 48/49] drivers/usb//gadget/function/u_serial.c:540:19: error: invalid operands to binary & (have 'unsigned int' and 'struct tty_struct *')

Re: usb 1-2: 1:1: cannot set freq 44100 to ep 0x81 and potential fix

[PATCH] usb: phy: phy-generic: propagate clk_get error if clock is required

[PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

14 matches

Site Navigation

Mail list logo

Footer information