Re: [PATCH] usbserial: pl2303 tx xon/xoff flow control

Hi, > That looks like an HX device according to the current way we identify > these types (which may be wrong). That at least matches the labeling on the chip, so I guess that might be correct? > Continuation lines (e.g. the broken if statement) should be indented > substantially to the right,

Re: [PATCH] usbserial: pl2303 tx xon/xoff flow control

Hi, > > There are historical reasons for a lot of things, but that's not > > necessarily a reason to continue taking shortcuts. > > But on second thought, I think your approach here makes sense. If > usbserial ever gains generic IXON support, we'd just fall back to the > line-discipline

Re: [PATCH] NFC: pn533: don't send USB data off of the stack

Hi Greg, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

On 17.05.2018 18:06, kbuild test robot wrote: > Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings") > Signed-off-by: kbuild test robot It should be static of course, my bad. Reviewed-by: Andrzej Hajda  -- Regards Andrzej >

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

On 2018-05-17 13:50, Heikki Krogerus wrote: On Wed, May 16, 2018 at 11:11:02PM +0200, Mats Karrman wrote: On 05/16/2018 01:43 PM, Heikki Krogerus wrote: On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote: Hi Heikki, On 05/15/2018 09:30 AM, Heikki Krogerus wrote: Hi Mats, On

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Hi All, On 2018-04-24 14:42, Oliver Neukum wrote: Am Montag, den 23.04.2018, 18:35 +0530 schrieb Tushar Nimkar: hi, On 2018-04-23 18:20, Oliver Neukum wrote: > Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar: > No. But for testing we don't need to. Can you confirm that >

RE: dwc2: Regression on 96Boards Hikey due to enabling power down

Hi Mani, We need some detailed information to perform debugging. 1. Could you please share the documentation of "96Boards HiKey" board, at least dwc core configuration parameters. Or dump of GHWCFG1-4. 2. Could you please share with us full debug log of dwc2 loading and plug the USB device.

Re: [PATCH] usbserial: pl2303 tx xon/xoff flow control

On Thu, May 17, 2018 at 10:29:14AM +0200, Johan Hovold wrote: > On Thu, May 17, 2018 at 05:39:21AM +0200, Florian Zumbiehl wrote: > > Now, I agree that signaling lack of support would be better in general, but > > it does change what the code does for (still) unsupported cases. After all, > >

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

Hi Alan, thanks for reviewing. (This is my first contribution that touches usb-storage, so please bear with me.) > That's kind of weird. Does the drive work under Windows in UAS mode? On the Windows 10 VM that I just spun up for testing this, access to the drive uses "usbstor.inf" (rather

Re: [PATCH] USB: serial: use tty_port_register_device()

On Wed, May 16, 2018 at 11:47:39AM +0200, Greg Kroah-Hartman wrote: > On Wed, May 16, 2018 at 11:42:07AM +0200, Johan Hovold wrote: > > We already have the tty port when probing a usb-serial port so use > > tty_port_register_device() directly instead of tty_port_install() later > > to set up the

Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote: > pdev_nr and rhport can be controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > drivers/usb/usbip/vhci_sysfs.c:238

Re: Renesas uPD720202 USB 3.0

On 16.05.2018 20:38, Christian Brauns wrote: Hi I'm running 4.16.8-1-ARCH and that controller does not work, whereas I remember it was working sometime before. Now I'm travelling, don't have the controller with me, especially because it does not work anymore. This is what a part of dmesg

Re: dwc2: Regression on 96Boards Hikey due to enabling power down

Hi Artur, Thanks for the reply! On Thu, May 17, 2018 at 09:10:06AM +, Artur Petrosyan wrote: > Hi Mani, > > We need some detailed information to perform debugging. > > 1. Could you please share the documentation of "96Boards HiKey" board, at > least dwc core configuration parameters. Or

Re: [PATCH] usbserial: pl2303 tx xon/xoff flow control

On Thu, May 17, 2018 at 05:39:21AM +0200, Florian Zumbiehl wrote: > Hi, > > > > Note that the patch has only been fully tested with kernel 4.9.28, and > > > test-compiled against 4.16.8. Tested only with the pl2303 adapters I have > > > available (which seem to be type 0 if I interpret the code

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Hi, On Wed, May 16, 2018 at 04:13:31PM +, mario.limoncie...@dell.com wrote: > > > > -Original Message- > > From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com] > > Sent: Wednesday, May 16, 2018 6:58 AM > > To: Greg KH; Paul Menzel > > Cc: linux-usb@vger.kernel.org;

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

On Wed, May 16, 2018 at 11:11:02PM +0200, Mats Karrman wrote: > On 05/16/2018 01:43 PM, Heikki Krogerus wrote: > > > On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote: > >> Hi Heikki, > >> > >> On 05/15/2018 09:30 AM, Heikki Krogerus wrote: > >> > >>> Hi Mats, > >>> > >>> On Fri, May

RE: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

> -Original Message- > From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com] > Sent: Thursday, May 17, 2018 4:00 AM > To: Limonciello, Mario > Cc: g...@kroah.com; pmenzel+linux-...@molgen.mpg.de; linux- > u...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re:

Re: [PATCH 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

On Thu, May 17, 2018 at 01:58:36PM +0100, Marc Zyngier wrote: > This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. > > Now that we can properly reset the uPD72020x without a hard PCI reset, > let's get rid of the existing quirks. > > Signed-off-by: Marc Zyngier

Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

On Wed, May 16, 2018 at 10:55:36PM +0200, Mats Karrman wrote: > Hi, > > On 05/16/2018 02:25 PM, Heikki Krogerus wrote: > > > Hi guys, > > > > On Tue, May 15, 2018 at 10:52:57PM +0200, Mats Karrman wrote: > >> Hi, > >> > >> On 05/14/2018 11:36 AM, Jun Li wrote: > >> > >>> Hi > -Original

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Hi Mario, On Thu, May 17, 2018 at 01:01:20PM +, mario.limoncie...@dell.com wrote: > > > Heikki, > > > > > > I confirmed with internal team that UCSI is implemented on XPS 9370 > > > and was confirmed to be working properly with Windows 10 RS2+. > > > > Just to double check: "UCSI was

ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

Hello. I'm having troubles with this NFC card reader. It seems kernel driver pn533 is not working properly. At this moment I have my work stalled. I need to add NFC support to a software product and I can't get the device to work. NFC tools won't work, the device is not detected. This is what I

RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

Hi > -Original Message- > From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com] > Sent: 2018年5月16日 20:25 > To: Jun Li ; Mats Karrman > Cc: robh...@kernel.org; gre...@linuxfoundation.org; li...@roeck-us.net; > a.ha...@samsung.com;

Re: usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

= (ptrval) [000c] *pgd= Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 4.17.0-rc5-next-20180517 #782 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) Workqueue: events deferred_probe_work_func PC is at usb_ep_alloc_request

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

Am Donnerstag, den 17.05.2018, 01:15 -0700 schrieb Alexander Kappner: > Yes. Without this flag, the device keeps throwing similar errors on > usb-storage. That's the same result I get on a host that doesn't have UAS > compiled in. Here's a dmesg: Hi, this is suspicious. You do not actually

RE: [PATCH v5 01/14] dt-bindings: connector: add properties for typec

Hi > -Original Message- > From: Peter Chen > Sent: 2018年5月16日 15:22 > To: Jun Li ; robh...@kernel.org; gre...@linuxfoundation.org; > heikki.kroge...@linux.intel.com; li...@roeck-us.net > Cc: a.ha...@samsung.com; cw00.c...@samsung.com; > shufan_...@richtek.com;

RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

Hi Mats, > > Uhm, typing too fast again, I am. A better name would be just > typec_find_role(). > What I mean is that the function could be used for any situation when > someone wants to map a string to a TYPEC_{SOURCE,SINK} constant so it is > unnecessary to limit its usage to just preferred

RE: [PATCH v5 12/14] staging: typec: tcpci: keep the not connecting cc line open

> -Original Message- > From: Peter Chen > Sent: 2018年5月16日 16:36 > To: Jun Li ; robh...@kernel.org; gre...@linuxfoundation.org; > heikki.kroge...@linux.intel.com; li...@roeck-us.net > Cc: a.ha...@samsung.com; cw00.c...@samsung.com; > shufan_...@richtek.com;

RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

Hi Mats > I reread this patch and tried to see it more in the context of the other > patches > and the existing code. The naming of the existing string tables doesn't help > in > getting this right, however I have a proposal: > > typec_find_port_power_role() to get to TYPEC_PORT_SRC/SNK/DRP >

[PATCH 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue

Back around the 4.13 timeframe, we tried to address a rather bad issue with the Renesas uPD72020x USB3 controller family, that have a horrible issue with the programming of the base addresses which tend to stick on XHCI reset. This makes transitionning from 64bit to 32bit addresses completely

[PATCH 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. Now that we can properly reset the uPD72020x without a hard PCI reset, let's get rid of the existing quirks. Signed-off-by: Marc Zyngier --- drivers/usb/host/pci-quirks.c | 20

[PATCH 1/3] xhci: Allow more than 32 quirks

We now have 32 different quirks, and the field that holds them is full. Let's bump it up to the next stage so that we can handle some more... The type is now an unsigned long long, which is 64bit on most architectures. Signed-off-by: Marc Zyngier ---

[PATCH 2/3] xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

Some Renesas controllers get into a weird state if they are reset while programmed with 64bit addresses (they will preserve the top half of the address in internal, non visible registers). You end up with half the address coming from the kernel, and the other half coming from the firmware. Also,

Re: [PATCH 1/3] xhci: Allow more than 32 quirks

On Thu, May 17, 2018 at 01:58:34PM +0100, Marc Zyngier wrote: > We now have 32 different quirks, and the field that holds them > is full. Let's bump it up to the next stage so that we can handle > some more... The type is now an unsigned long long, which is 64bit > on most architectures. > >

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Am Donnerstag, den 17.05.2018, 12:29 +0530 schrieb Tushar Nimkar: > Those commands issued from different layers say: sd.. uas.. scsi.. > so making them to go one after other. Once REPORT_LUN done go with > READ_CAPACITY_16. > This is only for the UAS devices. I believe no disturb to BOT behavior.

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote: > Hello. > I'm having troubles with this NFC card reader. It seems kernel driver > pn533 is not working properly. > At this moment I have my work stalled. I need to add NFC support to a > software product and I can't get the

RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

Hi Heikki, > > I reread this patch and tried to see it more in the context of the > > other patches and the existing code. The naming of the existing string > > tables doesn't help in getting this right, however I have a proposal: > > > > typec_find_port_power_role() to get to

Re: usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

5 [#1] PREEMPT SMP ARM > Modules linked in: > CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 4.17.0-rc5-next-20180517 #782 > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > Workqueue: events deferred_probe_work_func > PC is at usb_ep_alloc_request+0x1c/0x200 > LR is at co

[linux-next:master 7522/8111] drivers/usb/dwc3/drd.c:443:19: sparse: symbol 'dwc3_get_extcon' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: fbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1 commit: 5f0b74e54890c354d6ac0124ea7a96adf22845d0 [7522/8111] USB: dwc3: get extcon device by OF graph bindings reproduce: # apt-get install sparse

[RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings") Signed-off-by: kbuild test robot --- drd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c index 2706824..218371f 100644 ---

Re: [usb-storage] Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

On Thu, 17 May 2018, Alexander Kappner wrote: > Hi Alan, > > thanks for reviewing. (This is my first contribution that touches > usb-storage, so please bear with me.) > > > That's kind of weird. Does the drive work under Windows in UAS mode? > > On the Windows 10 VM that I just spun up for

[PATCH 01/12] usb: usbtmc: Remove rigol_quirk

All T instruments should also work with rigol_quirk = 1 code path. So remove unnecessary code in rigol_quirk = 0 code path to simplify the driver. Tested-by: Dave Penkler Reviewed-by: Steve Bayless Signed-off-by: Guido Kiener

[PATCH 07/12] usb: usbtmc: Add ioctl USBTMC488_IOCTL_WAIT_SRQ

Wait until an SRQ (service request) is received on the interrupt pipe or until the given period of time is expired. In contrast to the poll() function this ioctl does not return when other (a)synchronous I/O operations fail with EPOLLERR. Signed-off-by: Guido Kiener

[PATCH 06/12] usb: usbtmc: Add vendor specific/asynchronous read/write ioctls

- ioctl USBTMC_IOCTL_WRITE sends an (a)synchronous generic message to bulk OUT. The message is split into chunks of 4k (page size). Message size is aligned to 32 bit boundaries. With flag USBTMC_FLAG_ASYNC the ioctl is non blocking. With flag USBTMC_FLAG_APPEND additional urbs are queued

[PATCH 09/12] usb: usbtmc: Fix ioctl USBTMC_IOCTL_CLEAR

Insert a sleep of 50 ms between subsequent CHECK_CLEAR_STATUS control requests to avoid stressing the instrument with repeated requests. Some instruments need time to cleanup internal I/O buffers. Polling and repeated requests slow down the response time of devices. Signed-off-by: Guido Kiener

[PATCH 11/12] usb: usbtmc: Add ioctls to abort with specific tags

- fix ioctls USBTMC_IOCTL_ABORT_BULK_OUT/IN - add ioctls USBTMC_IOCTL_ABORT_BULK_OUT_TAG and USBTMC_IOCTL_ABORT_BULK_IN_TAG for test purpose. Useful for testing devices and client applications: The ioctls allow to test the abort mechanism and the response of the device when using

[PATCH 12/12] usb: usbtmc: Add ioctl to return API version of usbtmc driver

- add ioctl USBTMC_IOCTL_API_VERSION to get current API version - add info message to show API version - replace USBTMC_TIMEOUT macros with common used USB_CTRL_GET_TIMEOUT or USB_CTRL_SET_TIMEOUT macros. - delete some superfluous code lines. - update ioctl-number.txt Signed-off-by: Guido

[PATCH 08/12] usb: usbtmc: Optimize read/write and add ioctls for auto_abort

- Optimize read/write functions for better bandwidth and fixes reading of long transfers - add ioctl USBTMC_IOCTL_AUTO_ABORT to configure auto_abort for each specific file handle. - add ioctl USBTMC_IOCTL_MSG_IN_ATTR that returns the specific bmTransferAttributes field of the last

[PATCH 10/12] usb: usbtmc: Add test functions to set HALT Feature (Stall)

The ioctls USBTMC_IOCTL_SET_OUT_HALT or USBTMC_IOCTL_SET_IN_HALT send a SET_FEATURE(HALT) request to the corresponding OUT or IN pipe. Useful for testing devices and client applications: The ioctls force the device to simulate the error state at the specified pipe. Signed-off-by: Guido Kiener

RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

Hi > -Original Message- > From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com] > Sent: 2018年5月17日 22:24 > To: Jun Li > Cc: Mats Karrman ; robh...@kernel.org; > gre...@linuxfoundation.org; li...@roeck-us.net; a.ha...@samsung.com; >

Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

On Thu, May 17, 2018 at 02:05:41PM +, Jun Li wrote: > Hi Heikki, > > > > I reread this patch and tried to see it more in the context of the > > > other patches and the existing code. The naming of the existing string > > > tables doesn't help in getting this right, however I have a proposal:

Re: [PATCH 02/12] usb: usbtmc: Support Read Status Byte with SRQ per file handle

On Thu, May 17, 2018 at 07:03:26PM +0200, Guido Kiener wrote: > - Add 'struct usbtmc_file_data' for each file handle to cache last > srq_byte (=Status Byte with SRQ) received by usbtmc_interrupt(..) > > - usbtmc488_ioctl_read_stb returns cached srq_byte when available for > each file handle

Re: [PATCH 04/12] usb: usbtmc: Add ioctls for trigger, EOM bit and TermChar

On Thu, May 17, 2018 at 07:03:28PM +0200, Guido Kiener wrote: > - add USBTMC488_IOCTL_TRIGGER to send TRIGGER Bulk-OUT header > according to Subclass USB488 Specification > > The usbtmc trigger command is equivalent to the IEEE 488 GET (Group > Execute Trigger) action. While the "*TRG"

[PATCH 00/12] usb: usbtmc: Changes needed for compatible IVI/VISA library

The working group "VISA for Linux" of the IVI Foundation www.ivifoundation.org specifies common rules, shared libraries and drivers to implement the specification of "VPP-4.3: The VISA Library" on Linux to be compatible with implementations on other operating systems. The USBTMC protocol is part

[PATCH 02/12] usb: usbtmc: Support Read Status Byte with SRQ per file handle

- Add 'struct usbtmc_file_data' for each file handle to cache last srq_byte (=Status Byte with SRQ) received by usbtmc_interrupt(..) - usbtmc488_ioctl_read_stb returns cached srq_byte when available for each file handle to avoid race conditions of concurrent applications. - SRQ now sets

[PATCH 05/12] usb: usbtmc: Add ioctl for generic requests on control pipe

Add USBTMC_IOCTL_CTRL_REQUEST to send arbitrary requests on the control pipe. Used by specific applications of IVI Foundation, Inc. to implement VISA API functions: viUsbControlIn/Out. Signed-off-by: Guido Kiener Reviewed-by: Steve Bayless

[PATCH 04/12] usb: usbtmc: Add ioctls for trigger, EOM bit and TermChar

- add USBTMC488_IOCTL_TRIGGER to send TRIGGER Bulk-OUT header according to Subclass USB488 Specification The usbtmc trigger command is equivalent to the IEEE 488 GET (Group Execute Trigger) action. While the "*TRG" command can be sent as data to perform the same operation, in some

[PATCH 03/12] usb: usbtmc: Add ioctls to set/get usb timeout

Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to get/set I/O timeout for specific file handle. Different operations on an instrument can take different lengths of time thus it is important to be able to set the timeout slightly longer than the expected duration of each operation

Re: [PATCH 02/12] usb: usbtmc: Support Read Status Byte with SRQ per file handle

On 05/17/2018 09:20 AM, Greg KH wrote: >> +file_data = kzalloc(sizeof(*file_data), GFP_KERNEL); >> +if (!file_data) >> +return -ENOMEM; >> + >> +pr_debug("%s - called\n", __func__); > Please do not add "tracing" functions like this. The kernel has a > wonderful built-in

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

On Thu, May 17, 2018 at 03:17:01PM +0100, Carlos Manuel Santos wrote: > Thank you for you quick reply. I didn't have the opportunity to test > with older kernels, I'm afraid. > I never built a kernel patch but I can give it a try! :) Let's drag this back on the mailing list, it's better that way,

Re: USB, Help, Keyboard being dropped

Did I not say it right? Or perhaps a kernel or some other issue? = (no need to CC I'm subscribed to list), Hello, My USB keyboard is being dropped by the kernel at various times and I cannot figure out how to fix this. Maybe I have messed up somewhere but I think I'm reading the

Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

Hi Greg, On 05/17/2018 01:51 AM, Greg Kroah-Hartman wrote: On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote: pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

Adding the network and NFC developers as this really is a NFC driver bug, not a USB core issue... On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote: > On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote: > > Hello. > > I'm having troubles with this NFC card reader. It seems

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

On Thu, May 17, 2018 at 06:40:04PM +0200, Greg KH wrote: > Adding the network and NFC developers as this really is a NFC driver > bug, not a USB core issue... > > On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote: > > On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote: > >

Re: linux-next: Tree for May 17 (usb/gadget/udc/aspeed-vhub/)

On 05/17/2018 12:06 AM, Stephen Rothwell wrote: > > The usb-gadget tree gained a conflict against the usb tree. > on x86_64: drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request': hub.c:(.text+0x3a7): undefined reference to `usb_gadget_get_string'

Re: [PATCH 02/12] usb: usbtmc: Support Read Status Byte with SRQ per file handle

On Thu, May 17, 2018 at 09:44:40AM -0700, Randy Dunlap wrote: > On 05/17/2018 09:20 AM, Greg KH wrote: > >> + file_data = kzalloc(sizeof(*file_data), GFP_KERNEL); > >> + if (!file_data) > >> + return -ENOMEM; > >> + > >> + pr_debug("%s - called\n", __func__); > > Please do not add

Re: [PATCH 00/12] usb: usbtmc: Changes needed for compatible IVI/VISA library

On Thu, May 17, 2018 at 07:03:24PM +0200, Guido Kiener wrote: > The working group "VISA for Linux" of the IVI Foundation > www.ivifoundation.org specifies common rules, shared libraries and > drivers to implement the specification of "VPP-4.3: The VISA Library" > on Linux to be compatible with

Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

On 05/17/2018 02:15 PM, Greg Kroah-Hartman wrote: Shouldn't we just do this in one place, in the valid_port() function? That way it keeps the range checking logic in one place (now it is in 3 places in the function), which should make maintenance much simpler. Yep, I thought about that,

[PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis'

Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

On Thu, May 17, 2018 at 12:57:49PM -0500, Gustavo A. R. Silva wrote: > Hi Greg, > > On 05/17/2018 01:51 AM, Greg Kroah-Hartman wrote: > > On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote: > > > pdev_nr and rhport can be controlled by user-space, hence leading to > > > a

[PATCH v3 0/1] usb: gadget: udc: fsl: Introduce FSL_USB2_PHY_UTMI_DUAL

Initialization for SoCs with dual role phy is being bypassed since FSL_USB2_PHY_UTMI_DUAL macro is not being evaluated in the FSL gadget driver. In this state a controller configured in peripheral mode will not work as a gadget. This patch addresses this issue. Tested on 4.14.32 using a hardware

[PATCH v3 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

From: Nikhil Badola Introduce FSL_USB2_PHY_UTMI_DUAL in gadget driver for setting phy in SOCs with utmi dual phy Signed-off-by: Nikhil Badola Tested-by: Tiago Brusamarello --- Changes since v2: * Reformatted the

RE: [PATCH v3 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

> -Original Message- > From: Tiago Brusamarello [mailto:tbr...@gmail.com] > Sent: Thursday, May 17, 2018 4:29 PM > To: Leo Li > Cc: linux-usb@vger.kernel.org; Nikhil Badola > Subject: [PATCH v3 1/1] drivers: usb: Introduce

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

Oliver and Alan, thank for investigating. > this is suspicious. You do not actually whether US_FL_NO_WP_DETECT > by itself would make the device work. Can you please test that? US_FL_NO_WP_DETECT without US_FL_IGNORE_UAS does not make a difference, even with the patch you included applied: [

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

On Thu, 17 May 2018, Alexander Kappner wrote: > Oliver and Alan, > > thank for investigating. > > > this is suspicious. You do not actually whether US_FL_NO_WP_DETECT > > by itself would make the device work. Can you please test that? > > US_FL_NO_WP_DETECT without US_FL_IGNORE_UAS does not

Re: Fwd: Enabling USB (auto)suspend for xHCI controllers incurs random device failures since kernel 4.15

Hello Thanks for your quick response. I'll be away on holidays for the coming two weeks, but after that I'll certainly try taking the patch for a test drive for a couple of days (as the issue seemed intermittent). I'll also notify the users on the Arch linux forum of the patch, as there