v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and then
adds the flag as quirks for the device at issue. This allows the G-Drive to work
under both UAS and usb-storage.
Alexander Kappner (2):
[usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver
[usb-stora
The "G-Drive" (sold by G-Technology) external USB 3.0 drive
hangs on write access under UAS and usb-storage:
[ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[ 136.079152]
The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS
and is required to work around devices that become unstable upon being
queried for cache. This code is taken straight from:
drivers/usb/storage/scsiglue.c:284
Signed-off-by: Alexander Kappner
---
drivers/usb/storage/
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'
drivers/usb/usbip/vhci_sys
In 4.17-rc, commit 03ea6d6e9e1f ("usb: dwc2: Enable power down")
caused the HiKey board to not correctly handle switching between
usb-gadget and usb-host mode.
Unplugging the OTG port would result in:
[ 42.240973] dwc2 f72c.usb: dwc2_restore_host_registers: no host
registers to restore
[
On 05/18/2018 11:06 AM, Shuah Khan wrote:
On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote:
On Thu, May 17, 2018 at 03:16:28PM -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
Zitat von Andy Shevchenko :
On Thu, May 17, 2018 at 8:03 PM, Guido Kiener
wrote:
Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to
get/set I/O timeout for specific file handle.
+static int usbtmc_ioctl_get_timeout(struct usbtmc_file_data *file_data,
+
On Thu, May 10, 2018 at 02:10:28PM +0800, Chunfeng Yun wrote:
> Add a DT binding documentation of XS-PHY for MediaTek SoCs
> with USB3.1 GEN2 controller
>
> Signed-off-by: Chunfeng Yun
> ---
> .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 110
>
> 1 file changed, 11
On Fri, May 18, 2018 at 10:04:02PM +0200, Rafael J. Wysocki wrote:
> On Fri, May 18, 2018 at 5:15 PM, Greg Kroah-Hartman
> > Given that Windows works with this same set of ACPI tables, perhaps the
> > requirement isn't that this memory location be uncached?
> >
> > We shouldn't have to fix up ACPI
On Fri, 18 May 2018, Alexander Kappner wrote:
> Further debugging shows that the code that causes the device to hang is in
> drivers/scsi/sd.c:2698. So the reason why usb-storage works and UAS does
> not is because the device setting both skip_ms_page_3f=1 and
> skip_ms_page_8=1 is required. Th
On Fri, May 18, 2018 at 5:15 PM, Greg Kroah-Hartman
wrote:
> On Fri, May 18, 2018 at 06:08:24PM +0300, Heikki Krogerus wrote:
>>
>> Rafael, the problem here with these Dell laptops is that a memory page
>> that is used as a mailbox for special communication between EC FW and
>> OS (called UCSI mai
On Thu, May 17, 2018 at 8:03 PM, Guido Kiener wrote:
> Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to
> get/set I/O timeout for specific file handle.
> +static int usbtmc_ioctl_get_timeout(struct usbtmc_file_data *file_data,
> + void __user *arg
> Was this tested with uas or usb-storage?
On both. dd works either way.
> Are you certain Oliver's new code was executed? If you put
> US_FL_NO_WP_DETECT only in unusual_devs.h and not in ususual_uas.h then
> it would not affect the uas driver.
Yes, the code ran.
Further debugging shows tha
On Fri, May 18, 2018 at 01:57:20PM +0200, Greg KH wrote:
> ant wrote:
...
> > i didn't think you'd care too much about a report
> > from Debian stable, but i finally got that installed
> > and booting. i can leave that running today while
> > i'm working on other things and see what the logs
>
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,
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
drivers/usb/host/pci-quirks.h | 1
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.
We take this opportunity to change the quirks from using (1 << x)
to BIT_ULL(x)
Back around the 4.13 timeframe, we tried to address a rather bad issue
with the Renesas uPD72020x USB3 controller family. They have trouble
with the programming of the base addresses which tend to stick on XHCI
reset. This makes transitionning from 64bit to 32bit addresses
completely unsafe. This w
On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote:
> On Thu, May 17, 2018 at 03:16:28PM -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
On 17/05/18 14:29, Greg KH wrote:
> 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-b
On 17/05/18 14:28, Greg KH wrote:
> 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 64
On Fri, May 18, 2018 at 12:38:11PM +0200, Greg Kroah-Hartman wrote:
> It's amazing that this driver ever worked, but now that x86 doesn't
> allow USB data to be sent off of the stack, it really does not work at
> all. Fix this up by properly allocating the data for the small
> "commands" that get
Zitat von Greg KH :
On Fri, May 18, 2018 at 03:02:10PM +, gu...@kiener-muenchen.de wrote:
Zitat von Greg KH :
> On Thu, May 17, 2018 at 07:03:31PM +0200, Guido Kiener wrote:
> > @@ -2420,8 +2476,8 @@ static int usbtmc_probe(struct
usb_interface *intf,
> >
> > retcode = usb_regis
On Fri, May 18, 2018 at 06:08:24PM +0300, Heikki Krogerus wrote:
>
> Rafael, the problem here with these Dell laptops is that a memory page
> that is used as a mailbox for special communication between EC FW and
> OS (called UCSI mailbox) should be in uncached memory, but the memory
> is marked as
Zitat von Greg KH :
On Fri, May 18, 2018 at 02:48:11PM +, gu...@kiener-muenchen.de wrote:
Zitat von Greg KH :
> On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
> > +/*
> > + * usbtmc_message->flags:
> > + */
> > +#define USBTMC_FLAG_ASYNC0x0001
> > +#define USBT
On Fri, May 18, 2018 at 03:02:10PM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > On Thu, May 17, 2018 at 07:03:31PM +0200, Guido Kiener wrote:
> > > @@ -2420,8 +2476,8 @@ static int usbtmc_probe(struct usb_interface *intf,
> > >
> > > retcode = usb_register_dev(intf, &us
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-4.17-rc6
for you to fetch changes up to c171654caa875919be3
Zitat von Greg KH :
On Thu, May 17, 2018 at 07:03:31PM +0200, Guido Kiener wrote:
@@ -2420,8 +2476,8 @@ static int usbtmc_probe(struct usb_interface *intf,
retcode = usb_register_dev(intf, &usbtmc_class);
if (retcode) {
- dev_err(&intf->dev, "Not able to get a mi
Zitat von Greg KH :
On Thu, May 17, 2018 at 07:03:27PM +0200, Guido Kiener wrote:
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
On Fri, May 18, 2018 at 02:48:11PM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
> > > +/*
> > > + * usbtmc_message->flags:
> > > + */
> > > +#define USBTMC_FLAG_ASYNC0x0001
> > > +#define USBTMC_
On Fri, May 18, 2018 at 04:33:50PM +0200, Johan Hovold wrote:
> On Fri, May 18, 2018 at 03:53:54PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, May 18, 2018 at 03:25:47PM +0200, Johan Hovold wrote:
> > > Since forever this driver has had IXON and IXOFF mixed up, and has used
> > > the latter rather
Zitat von Greg KH :
On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
+/*
+ * usbtmc_message->flags:
+ */
+#define USBTMC_FLAG_ASYNC 0x0001
+#define USBTMC_FLAG_APPEND 0x0002
+#define USBTMC_FLAG_IGNORE_TRAILER 0x0004
+
+struct usbtmc_message {
+
As the amount of available ports varies by the kernels build
configuration. To remove the limitation of the fixed 128 ports
we allocate the amount of idevs by using the number we get
from the kernel.
Signed-off-by: Michael Grzeschik
---
tools/usb/usbip/libsrc/vhci_driver.c | 11 ---
tool
On Fri, May 18, 2018 at 03:53:54PM +0200, Greg Kroah-Hartman wrote:
> On Fri, May 18, 2018 at 03:25:47PM +0200, Johan Hovold wrote:
> > Since forever this driver has had IXON and IXOFF mixed up, and has used
> > the latter rather than the former to enable hardware-assisted software
> > flow control
Zitat von Greg KH :
On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
- 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
On Fri, May 18, 2018 at 03:25:50PM +0200, Johan Hovold wrote:
> Clean up the somewhat convoluted hardware-assisted flow control
> handling.
>
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/serial/ftdi_sio.c | 81 ++-
> 1 file changed, 23 insertions(+), 58 delet
On Fri, May 18, 2018 at 03:25:49PM +0200, Johan Hovold wrote:
> Drop urb_ prefixes from value and index variables used in control
> requests.
>
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/serial/ftdi_sio.c | 83 +--
> 1 file changed, 41 insertions(+), 42 del
On Fri, May 18, 2018 at 03:25:47PM +0200, Johan Hovold wrote:
> Since forever this driver has had IXON and IXOFF mixed up, and has used
> the latter rather than the former to enable hardware-assisted software
> flow control on output.
>
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/serial/ft
On Fri, May 18, 2018 at 03:25:48PM +0200, Johan Hovold wrote:
> Replace all __u types with their u counterparts throughout the driver
> (whose structures are not exported to user space).
>
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/serial/ftdi_sio.c | 50 +-
On Fri, May 18, 2018 at 01:32:51PM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > On Thu, May 17, 2018 at 07:03:29PM +0200, Guido Kiener wrote:
> > > Add USBTMC_IOCTL_CTRL_REQUEST to send arbitrary requests on the
> > > control pipe. Used by specific applications of IVI Fou
On Thu, May 17, 2018 at 03:16:28PM -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 d
On Thu, May 17, 2018 at 07:03:25PM +0200, Guido Kiener wrote:
> All T&M 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: Guid
On Thu, May 17, 2018 at 07:03:36PM +0200, Guido Kiener wrote:
> - 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 superf
On Thu, May 17, 2018 at 07:03:35PM +0200, Guido Kiener wrote:
> - fix ioctls USBTMC_IOCTL_ABORT_BULK_OUT/IN
"fix" how? be specific :)
>
> - add ioctls USBTMC_IOCTL_ABORT_BULK_OUT_TAG and
> USBTMC_IOCTL_ABORT_BULK_IN_TAG for test purpose.
Again, why test stuff in a generic driver?
And again
On Thu, May 17, 2018 at 07:03:34PM +0200, Guido Kiener wrote:
> 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
On Thu, May 17, 2018 at 07:03:32PM +0200, Guido Kiener wrote:
> - 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
On Thu, May 17, 2018 at 07:03:31PM +0200, Guido Kiener wrote:
> @@ -2420,8 +2476,8 @@ static int usbtmc_probe(struct usb_interface *intf,
>
> retcode = usb_register_dev(intf, &usbtmc_class);
> if (retcode) {
> - dev_err(&intf->dev, "Not able to get a minor"
> -
Zitat von Greg KH :
On Thu, May 17, 2018 at 07:03:29PM +0200, Guido Kiener wrote:
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 Kien
On Fri, May 18, 2018 at 01:57:20PM +0200, Greg KH wrote:
> On Fri, May 18, 2018 at 07:17:42AM -0400, ant wrote:
> > On Fri, May 18, 2018 at 08:41:28AM +0200, Greg KH wrote:
> > > On Thu, May 17, 2018 at 01:43:35PM -0400, ant wrote:
> > > >
> > > > Did I not say it right?
> > > >
> > > > Or perhap
Drop urb_ prefixes from value and index variables used in control
requests.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 83 +--
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/f
Clean up the somewhat convoluted hardware-assisted flow control
handling.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 81 ++-
1 file changed, 23 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftd
Since forever this driver has had IXON and IXOFF mixed up, and has used
the latter rather than the former to enable hardware-assisted software
flow control on output.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff
Replace all __u types with their u counterparts throughout the driver
(whose structures are not exported to user space).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers
Turns out the ftdi driver has had IXON and IXOFF, which are used to
enable outgoing and incoming software flow control, mixed up since
before git. The first patch addresses this while the following three
clean up the flow control handling code.
Johan
Johan Hovold (4):
USB: serial: ftdi_sio: fi
On Thu, May 17, 2018 at 07:03:27PM +0200, Guido Kiener wrote:
> 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 th
On Fri, May 18, 2018 at 06:06:53AM +0200, Florian Zumbiehl wrote:
> 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 ga
On 18.05.2018 16:04, Sudip Mukherjee wrote:
Hi Mathias,
On Fri, May 18, 2018 at 03:55:04PM +0300, Mathias Nyman wrote:
Hi,
Looks like event for Transfer block (TRB) at 0x32a21060 was never completed,
or at least not handled by xhci driver.
(either the event was never issued by hw, or something
On Fri, May 18, 2018 at 12:36:56PM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > On Fri, May 18, 2018 at 11:52:36AM +, gu...@kiener-muenchen.de wrote:
> > >
> > > Zitat von Greg KH :
> > >
> > > > On Thu, May 17, 2018 at 07:03:26PM +0200, Guido Kiener wrote:
> > > > >
On Fri, May 18, 2018 at 06:06:09AM +0200, Florian Zumbiehl wrote:
> 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?
Then it's an HX (even
Hi Mathias,
On Fri, May 18, 2018 at 03:55:04PM +0300, Mathias Nyman wrote:
> Hi,
>
> Looks like event for Transfer block (TRB) at 0x32a21060 was never completed,
> or at least not handled by xhci driver.
> (either the event was never issued by hw, or something got messed up in the
> driver along
Hi,
Looks like event for Transfer block (TRB) at 0x32a21060 was never completed,
or at least not handled by xhci driver.
(either the event was never issued by hw, or something got messed up in the
driver along the way)
HC doesn't look busted, it continues sending transfer completions events.
it
On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
> +/*
> + * usbtmc_message->flags:
> + */
> +#define USBTMC_FLAG_ASYNC0x0001
> +#define USBTMC_FLAG_APPEND 0x0002
> +#define USBTMC_FLAG_IGNORE_TRAILER 0x0004
> +
> +struct usbtmc_message {
> + void __user *me
On Thu, May 17, 2018 at 07:03:30PM +0200, Guido Kiener wrote:
> - 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 n
On Thu, May 17, 2018 at 07:03:29PM +0200, Guido Kiener wrote:
> 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-
Zitat von Greg KH :
On Fri, May 18, 2018 at 11:52:36AM +, gu...@kiener-muenchen.de wrote:
Zitat von Greg KH :
> 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) rece
On Fri, May 18, 2018 at 11:57:01AM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > 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
On Fri, May 18, 2018 at 12:08:16PM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > 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
> > >
> > >
Zitat von Greg KH :
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 t
On Fri, May 18, 2018 at 11:52:36AM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > 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 usbtm
On Fri, May 18, 2018 at 07:17:42AM -0400, ant wrote:
> On Fri, May 18, 2018 at 08:41:28AM +0200, Greg KH wrote:
> > On Thu, May 17, 2018 at 01:43:35PM -0400, ant wrote:
> > >
> > > Did I not say it right?
> > >
> > > Or perhaps a kernel or some other issue?
> > >
> > >
> > > =
> > >
> > >
Zitat von Greg KH :
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 com
Zitat von Greg KH :
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
On Fri, May 18, 2018 at 08:41:28AM +0200, Greg KH wrote:
> On Thu, May 17, 2018 at 01:43:35PM -0400, ant wrote:
> >
> > Did I not say it right?
> >
> > Or perhaps a kernel or some other issue?
> >
> >
> > =
> >
> >
> > (no need to CC I'm subscribed to list),
hi, thank you for replying,
Manu,
On 2018-05-18 16:10, Manu Gautam wrote:
Hi,
On 4/16/2018 3:47 PM, Tushar Nimkar wrote:
On 2018-04-05 12:39, Felipe Balbi wrote:
Hi,
tnim...@codeaurora.org writes:
On 2018-04-05 11:24, Felipe Balbi wrote:
Hi,
Greg KH writes:
On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaur
Hi Paul,
On Thu, May 17, 2018 at 03:34:49PM +0200, Paul Menzel wrote:
> Dear Heikki,
>
> Note, this problem also exists on the Dell XPS 13 9360 (Kaby Lake) device.
OK. Good to know. Though, we don't have one of those either.
> On 05/17/18 10:59, Heikki Krogerus wrote:
> > On Wed, May 16, 2018 a
Hi,
On 4/16/2018 3:47 PM, Tushar Nimkar wrote:
> On 2018-04-05 12:39, Felipe Balbi wrote:
>> Hi,
>>
>> tnim...@codeaurora.org writes:
>>> On 2018-04-05 11:24, Felipe Balbi wrote:
Hi,
Greg KH writes:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org
> wrote
It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all. Fix this up by properly allocating the data for the small
"commands" that get sent to the device.
The USB stack will free the buffer when the data has be
Hi Mathias,
We are using an Intel Atom based board and the usb controller is:
00:14.0 USB Controller: Intel Corporation Device 0f35 (rev 11) (prog-if 30)
Flags: bus master, medium devsel, latency 0, IRQ 130
Memory at df7e (64-bit, non-prefetchable) [size=64K]
Capabilit
On Fri, May 18, 2018 at 10:56:25AM +0200, Arend van Spriel wrote:
> On 5/17/2018 6:46 PM, Greg KH wrote:
> > 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, Ma
On Fri, 2018-05-18 at 10:56 +0200, Arend van Spriel wrote:
>
> > + buffer = kmalloc(sizeof(cmd), GFP_KERNEL);
> > + if (!buffer)
> > + return -ENOMEM;
> > + memcpy(buffer, cmd, sizeof(cmd));
It should also use kmemdup() ;-)
johannes
--
To unsubscribe from this list: send the line
On 5/17/2018 6:46 PM, Greg KH wrote:
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, Car
The usb_ep_queue() in printer_write() is possible to call req->complete().
In that case, since tx_complete() calls list_add(&req->list, &dev->tx_reqs),
printer_write() should not call list_add(&req->list, &dev->tx_reqs_active)
because the transfer has already finished. So, this patch checks
the con
On 18/05/18 10:47, Andrzej Hajda wrote:
> On 18.05.2018 09:38, Roger Quadros wrote:
>> On 18/05/18 08:39, Andrzej Hajda wrote:
>>> 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
>>>
Hi Bin,
On Wednesday, 16 May 2018 18:45:40 EEST Bin Liu wrote:
> On Tue, May 15, 2018 at 10:58:16PM +0100, Kieran Bingham wrote:
> > Hi Bin, Felipe,
> >
> > We have been trying to get a UVC gadget operational on the Pandaboard ES
> > platform, and we believe we've hit an issue with short packets
On 18.05.2018 09:38, Roger Quadros wrote:
> On 18/05/18 08:39, Andrzej Hajda wrote:
>> 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.
>>
>> Re
On 18/05/18 08:39, Andrzej Hajda wrote:
> 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
I don't think we ac
86 matches
Mail list logo
