Re: [PATCH drivers\usb\serial\pl2303.c & pl2303.h] Prolific's PL2303G: new USB to UART chip
On Thu, Dec 06, 2018 at 03:47:46PM +0800, Charles Yeh wrote: > Hi Greg, > The patch file: diffpl2303.patch is attached.. > Please you kindly check... Please fix up the patch to look like all other patches on this mailing list. You do not need the huge comment in the file, that should be in the body of the email for the changelog, you do not have a signed-off-by line, the patch was not at the right "depth" of the kernel source tree, and you sent this as an attachment. Any one of these would prevent the patch from being accepted... Please fix this up and resend it properly. thanks, greg k-h
Re: [PATCH] USB: quirks: add NO_LPM quirk for Logitech Flare
On Wed, Nov 28, 2018 at 06:19:31PM -0500, Kyle Williams wrote:
> Description: Some USB device / host controller combinations seem to have
> problems with Link Power management. In particular it is described that
> the combination of a Logitech Flare and other powered devices such as
> the Atrus device causes 'not enough bandwidth for new device state'error
>
> This patch creates a quirk entry for the Logitech Flare device
> indicating LPM should remain disabled for the device.
>
> Signed-off-by: Kyle Williams
> Cc: stable
> ---
> drivers/usb/core/quirks.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 49c44d89a394..e43c72cc98ee 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -224,6 +224,9 @@ static const struct usb_device_id usb_quirk_list[] = {
> /* Logitech Logitech Screen Share */
> { USB_DEVICE(0x046d, 0x086c), .driver_info = USB_QUIRK_NO_LPM },
>
> + /* Logitech Flare */
> + { USB_DEVICE(0x046d, 0x0876), .driver_info = USB_QUIRK_NO_LPM },
> +
> /* Logitech Rally Camera */
> { USB_DEVICE(0x046d, 0x0881), .driver_info = USB_QUIRK_NO_LPM },
> { USB_DEVICE(0x046d, 0x0888), .driver_info = USB_QUIRK_NO_LPM },
> --
> 2.18.1
Tabs are all converted to spaces, making this patch impossible to apply
:(
Re: Support Mac address pass through on Dell DS1000 dock
On Tue, Nov 20, 2018 at 09:10:22PM +0100, Bjørn Mork wrote: > Greg KH writes: > > > I do not see any USB networking device here at all. > > No, It wasn't easy to see. But it's there both with and without the > feature enabled: > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M > | Port 4: Dev 10, If 0, Class=Hub, Driver=hub/7p, 5000M > |__ Port 2: Dev 11, If 0, Class=Vendor Specific Class, Driver=r8152, > 5000M Ah, sorry, I missed that. > This feature is only for convenience and should never prevent the > network from working. Unless the other end is confused by seeing the > same mac address on two ports... Better take down or disconnect the > undocked interface after docking. Ok, so it seems that this driver does not support the pass-through option for some reason. Mario, any ideas what Frédéric can do here to help debug the issue? He has some Dell hardware that does not seem to be working properly with the pass-through option. I place odds that the driver needs some kind of update for newer device signatures, which is what some of us worried about a long time ago when this patch first went in... thanks, greg k-h
Re: Support Mac address pass through on Dell DS1000 dock
On Tue, Nov 20, 2018 at 06:04:58PM +0100, FRÉDÉRIC PARRENIN wrote: > > - Mail original - > > De: "Greg KH" > > À: "FRÉDÉRIC PARRENIN" > > Cc: "linux-usb" > > Envoyé: Mardi 20 Novembre 2018 17:54:06 > > Objet: Re: Support Mac address pass through on Dell DS1000 dock > > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > A: Top-posting. > > Q: What is the most annoying thing in e-mail? > > > http://daringfireball.net/2007/07/on_top > > > On Tue, Nov 20, 2018 at 05:46:21PM +0100, Frédéric Parrenin wrote: > > > I am runing 4.18 from debian stretch-backports. > > > > This is the output of lsusb -t: > > > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M > > > |__ Port 4: Dev 10, If 0, Class=Hub, Driver=hub/7p, 5000M > > > |__ Port 2: Dev 11, If 0, Class=Vendor Specific Class, Driver=r8152, > > > 5000M > > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M > > > |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, > > > 12M > > > |__ Port 3: Dev 47, If 0, Class=Hub, Driver=hub/7p, 480M > > > |__ Port 4: Dev 48, If 0, Class=Hub, Driver=hub/4p, 480M > > > |__ Port 1: Dev 50, If 3, Class=Human Interface Device, > > > Driver=usbhid, 12M > > > |__ Port 1: Dev 50, If 1, Class=Audio, Driver=snd-usb-audio, 12M > > > |__ Port 1: Dev 50, If 2, Class=Audio, Driver=snd-usb-audio, 12M > > > |__ Port 1: Dev 50, If 0, Class=Audio, Driver=snd-usb-audio, 12M > > > |__ Port 4: Dev 52, If 0, Class=Hub, Driver=hub/3p, 480M > > > |__ Port 2: Dev 53, If 0, Class=Human Interface Device, > > > Driver=usbhid, 12M > > > |__ Port 2: Dev 53, If 1, Class=Human Interface Device, > > > Driver=usbhid, 12M > > > |__ Port 3: Dev 54, If 0, Class=Vendor Specific Class, > > > Driver=, 12M > > > |__ Port 7: Dev 51, If 0, Class=Mass Storage, Driver=usb-storage, > > > 480M > > > |__ Port 5: Dev 49, If 0, Class=Audio, Driver=snd-usb-audio, 480M > > > |__ Port 5: Dev 49, If 3, Class=Audio, Driver=snd-usb-audio, 480M > > > |__ Port 5: Dev 49, If 1, Class=Audio, Driver=snd-usb-audio, 480M > > > |__ Port 5: Dev 49, If 2, Class=Audio, Driver=snd-usb-audio, 480M > > > |__ Port 7: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M > > > |__ Port 7: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M > > > I do not see any USB networking device here at all. Perhaps it is > > showing up as a PCI device? > > > What is the output of: > > lspci -tv > > > That might show the network device, and if so, you will have to mess > > with the PCI driver, not the USB driver for this type of feature. > > # lspci -tv > -[:00]-+-00.0 Intel Corporation Device 5904 >+-02.0 Intel Corporation Device 5916 >+-04.0 Intel Corporation Skylake Processor Thermal Subsystem >+-05.0 Intel Corporation Skylake Imaging Unit >+-13.0 Intel Corporation Device 9d35 >+-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller >+-14.2 Intel Corporation Sunrise Point-LP Thermal subsystem >+-14.3 Intel Corporation Device 9d32 >+-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C > Controller #0 >+-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C > Controller #1 >+-15.2 Intel Corporation Sunrise Point-LP Serial IO I2C > Controller #2 >+-16.0 Intel Corporation Sunrise Point-LP CSME HECI #1 >+-16.3 Intel Corporation Device 9d3d >+-1c.0-[01]00.0 Toshiba America Info Systems Device 0116 >+-1c.7-[02]00.0 Intel Corporation Device 24fd >+-1d.0-[03]00.0 Realtek Semiconductor Co., Ltd. RTS525A PCI > Express Card Reader >+-1f.0 Intel Corporation Device 9d4e >+-1f.2 Intel Corporation Sunrise Point-LP PMC >+-1f.3 Intel Corporation Device 9d71 >\-1f.4 Intel Corporation Sunrise Point-LP SMBus > > I should add that when running the above commands, I had passthrough mac > address enabled in the Bios. Odd, I don't see a network device anywhere here. Can you compare the "before and after" results for both of these options to see if you see any network device? I don't see it here, sorry. greg k-h
Re: Support Mac address pass through on Dell DS1000 dock
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://daringfireball.net/2007/07/on_top On Tue, Nov 20, 2018 at 05:46:21PM +0100, Frédéric Parrenin wrote: > I am runing 4.18 from debian stretch-backports. > > This is the output of lsusb -t: > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M > |__ Port 4: Dev 10, If 0, Class=Hub, Driver=hub/7p, 5000M > |__ Port 2: Dev 11, If 0, Class=Vendor Specific Class, Driver=r8152, > 5000M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M > |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, > 12M > |__ Port 3: Dev 47, If 0, Class=Hub, Driver=hub/7p, 480M > |__ Port 4: Dev 48, If 0, Class=Hub, Driver=hub/4p, 480M > |__ Port 1: Dev 50, If 3, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 1: Dev 50, If 1, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 1: Dev 50, If 2, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 1: Dev 50, If 0, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 4: Dev 52, If 0, Class=Hub, Driver=hub/3p, 480M > |__ Port 2: Dev 53, If 0, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 2: Dev 53, If 1, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 3: Dev 54, If 0, Class=Vendor Specific Class, > Driver=, 12M > |__ Port 7: Dev 51, If 0, Class=Mass Storage, Driver=usb-storage, > 480M > |__ Port 5: Dev 49, If 0, Class=Audio, Driver=snd-usb-audio, 480M > |__ Port 5: Dev 49, If 3, Class=Audio, Driver=snd-usb-audio, 480M > |__ Port 5: Dev 49, If 1, Class=Audio, Driver=snd-usb-audio, 480M > |__ Port 5: Dev 49, If 2, Class=Audio, Driver=snd-usb-audio, 480M > |__ Port 7: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 7: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M I do not see any USB networking device here at all. Perhaps it is showing up as a PCI device? What is the output of: lspci -tv That might show the network device, and if so, you will have to mess with the PCI driver, not the USB driver for this type of feature. thanks, greg k-h
Re: Support Mac address pass through on Dell DS1000 dock
On Tue, Nov 20, 2018 at 05:33:54PM +0100, Frédéric Parrenin wrote: > I have a Dell latitude 5285 laptop connected to a Dell DS1000 docking station > through an usb-c cable. > Both devices are supposed to support Mac Address "pass through", that is, the > internal laptop mac address is used instead of the mac address of the docking > station. > Unfortunately, this does not seem to work under linux. > When I type "ip a", I get the mac adress of the docking station. > And the network does not work. > Is this supposed to work under linux? > I saw a commit related to this issue here: > https://github.com/torvalds/linux/commit/34ee32c9a5696247be405bb0c21f3d1fc6cb5729 > but it does not specifically mention the Dell DS1000. What type of USB driver is binding to this device? If you run: lsusb -t from a command line, what is the output? And what kernel version are you using? thanks, greg k-h
Re: [PATCH drivers\usb\serial\pl2303.c & pl2303.h] Prolific's PL2303G: new USB to UART chip
On Tue, Nov 20, 2018 at 05:21:04PM +0800, Charles Yeh wrote: > Hi Johan, > After read Documentation\process\submitting-patches.rst, > I have write some describe in attach file : "diffpl2303c.patch" > "diffpl2303h.patch" > > If this file does not meet the file requirements, please let me > know how to do it. This is close, but not quite there yet. You need to make one patch for all of the files modified, look at all of the patches on the mailing list for examples of this. Also, you need a proper changelog text and a signed-off-by line, the file Documentation/SubmittingPatches in the kernel source tree will describe all of this and how to do it. And finally, your patch needs to properly use tabs, not spaces, look at the diff you generated for examples of how the lines do not align properly now. Can you try again please? thanks, greg k-h
Re: Prolific: PL2303G Linux driver ( new USB to UART chip)
On Wed, Nov 07, 2018 at 06:18:07PM +0800, Charles Yeh wrote: > Hi Greg, > > The " Documentation/SubmittingPatches is write : This file has moved > to process/submitting-patches.rst > > The document is "Documentation\process\submitting-patches.rst" ? > please confirm Yes, that is what the file says, please follow it and read that.
Re: Prolific: PL2303G Linux driver ( new USB to UART chip)
On Wed, Nov 07, 2018 at 05:17:02PM +0800, Charles Yeh wrote: > Hi Greg, > Can you give me a link URL about " Documentation/SubmittingPatches "? > I am not very familiar with Linux kernel OS... It is in the main kernel source tree that you had to patch in order to create the diff you did, you already have this all on your system already :) greg k-h
Re: Prolific: PL2303G Linux driver ( new USB to UART chip)
On Wed, Nov 07, 2018 at 04:07:03PM +0800, Charles Yeh wrote: > Hi Johan, > I use latest mainline releas: 4.19 to make patch file.. > please refer to attach file: "diff419pl2303c.patch" & " > diff419pl2303h.patch " Please read the file, Documentation/SubmittingPatches in the kernel source tree for how to properly create and submit a patch. We can not do much with these two attached files :( thanks, greg k-h
Re: [PATCH 1/2] pci: pci_ids: Move Synopsys HAPS platform device IDs
On Mon, Nov 05, 2018 at 06:46:26PM +, Thinh Nguyen wrote: > Hi Greg, > > On 11/2/2018 11:26 PM, Greg KH wrote: > > On Fri, Nov 02, 2018 at 06:47:38PM -0700, Thinh Nguyen wrote: > >> Move Synopsys HAPS platform device IDs to pci_ids.h. > > Why? pci_ids.h, at the top of the file, says to not add new entries to > > the file. > > Yes, I notice. However, I want to reference these IDs in > /drivers/pci/quirks.c. It's related to this patch subject "[PATCH 2/2] > pci: quirks: Override Synopsys USB 3.x HAPS device driver". > I will CC that patch to linux-usb mailing list also. Please let me know > if this is ok. Otherwise, any suggestion? Ah, ok, that is fine, as I never saw patch 2/2, I didn't know that :)
Re: [PATCH 1/2] pci: pci_ids: Move Synopsys HAPS platform device IDs
On Fri, Nov 02, 2018 at 06:47:38PM -0700, Thinh Nguyen wrote: > Move Synopsys HAPS platform device IDs to pci_ids.h. Why? pci_ids.h, at the top of the file, says to not add new entries to the file. thanks, greg k-h
Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU
On Wed, Oct 24, 2018 at 05:46:22PM +, Ajay Gupta wrote: > Hi Wolfram, > > > I don't think SMBus is an option in this case since the intended > > > client (Cypress something in patch 2/2) does xfers that would need > > > 16-bit commands and I think they are always 8-bit in SMBus, no? > > > > Yes. Command is 8 bit, data can be 16. Thanks for the heads up! > Please help review v13 of this patch set at > https://marc.info/?l=linux-i2c=153859126630601=2 > https://marc.info/?l=linux-i2c=153859127330604=2 > https://marc.info/?l=linux-i2c=153859127830605=2 It is the middle of the merge window, maintainers are a "bit" busy at the moment :)
Re: [PATCH] HID: hiddev: fix potential Spectre v1
On Thu, Oct 18, 2018 at 01:50:26PM -0300, Breno Leitao wrote:
> Hi Gustavo,
>
> On 10/17/2018 05:30 PM, Gustavo A. R. Silva wrote:
> >
> > Hi Breno,
> >
> > On 10/17/18 9:47 PM, Breno Leitao wrote:
> >> uref->usage_index can be indirectly controlled by userspace, hence leading
> >> to a potential exploitation of the Spectre variant 1 vulnerability.
> >>
> >> This problem might show up in the cmd = HIDIOCGCOLLECTIONINDEX flow at
> >> function
> >> hiddev_ioctl_usage(), where uref->usage_index is compared to
> >> field->maxusage
> >> and then used as an index to dereference field->usage array.
> >>
> >> This is a summary of the current flow, which matches the traditional
> >> Spectre V1 issue:
> >>
> >>copy_from_user(uref, user_arg, sizeof(*uref))
> >>if (uref->usage_index >= field->maxusage)
> >>goto inval;
> >>i = field->usage[uref->usage_index].collection_index;
> >>return i;
> >>
> >> This patch fixes this by sanitizing field uref->usage_index before using
> >> it to
> >> index field->usage, thus, avoiding speculation in the first load.
> >>
> >> Signed-off-by: Breno Leitao
> >> ---
> >> drivers/hid/usbhid/hiddev.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> >> index 23872d08308c..8829cbc1f6b1 100644
> >> --- a/drivers/hid/usbhid/hiddev.c
> >> +++ b/drivers/hid/usbhid/hiddev.c
> >> @@ -512,6 +512,9 @@ static noinline int hiddev_ioctl_usage(struct hiddev
> >> *hiddev, unsigned int cmd,
> >>if (cmd == HIDIOCGCOLLECTIONINDEX) {
> >>if (uref->usage_index >= field->maxusage)
> >>goto inval;
> >> + uref->usage_index =
> >> + array_index_nospec(uref->usage_index,
> >> + field->maxusage);
> >
> > Good catch.
> >
> >>} else if (uref->usage_index >= field->report_count)
> >>goto inval;
> >
> > Although, notice that this is the same index, and it can be used to index
> > field->value[]
> > at lines 526 and 532.
>
> Right, this seems to be a possible problem also, when 'cmd' =
> HIDIOC{G,S}USAGES.
>
> I am reworking the patch to cover both issues. What do you think of the draft
> below?
>
> Thank you for reviewing it!
>
> ---
>
> Subject: [PATCH] HID: hiddev: fix potential Spectre v1
>
> uref->usage_index can be indirectly controlled by userspace, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
>
> This field is used as an array index by the hiddev_ioctl_usage() function,
> when 'cmd' is HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or HIDIOCSUSAGES.
>
> For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to
> field->maxusage and then used as an index to dereference field->usage
> array. The very same thing happens to the cmd == HIDIOC{G,S}USAGES cases,
> where uref->usage_index is checked against an array maximum value and then
> it is used as an index in this array.
>
> This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the
> traditional Spectre V1 first load:
>
> copy_from_user(uref, user_arg, sizeof(*uref))
> if (uref->usage_index >= field->maxusage)
> goto inval;
> i = field->usage[uref->usage_index].collection_index;
> return i;
>
> This patch fixes this by sanitizing field uref->usage_index before using it
> to index field->usage, thus, avoiding speculation in the first load.
>
> Signed-off-by: Breno Leitao
> ---
> drivers/hid/usbhid/hiddev.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
Care to cc: stable as well?
thanks,
greg k-h
Re: Logitech G27 leds no more supported
On Wed, Oct 17, 2018 at 02:44:51PM +, elrond...@protonmail.com wrote: > > > Hi, > > No more leds subdirectory for this wheel, someone reports me G29 leds stays > supported correctly. > > No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds are > detected. Force feedback are correctly supported. > > Please fix this > > Cheer > > Elrondo > > INFO: Kernel 4.18 and older affected What kernel version did this work properly on? And I think the linux-input mailing list would want to know about this, this isn't a usb-core specific issue. I've added them to the cc: here. thanks, greg k-h
Re: “Mouse battery low” notification appears even when all notifications disabled
On Tue, Oct 16, 2018 at 04:15:34PM -0300, Cristian wrote: > Hello, > > Open bug in launchpad.net > https://bugs.launchpad.net/bugs/1798166 > > "I have a wireless mouse powered by non-rechargeable battery. The > mouse works absolutely fine even with low battery level. Problem is, > Ubuntu gives notifications about the battery level all the time. > > I have had this issue for almost two months now, and mouse is working > perfectly. I had to click away the notification almost every time I > moved the mouse. I was then able to make the notifications appear less > frequently, but the notification still always appear after some > interval, and always after I log in. > > Here are some specific things I have tried, they have not helped. > > https://askubuntu.com/questions/1071406/how-to-disable-mouse-battery-low-notification-in-ubuntu-18-04; This is not a kernel issue, please work with your distro to resolve this. Best of luck! greg k-h
Re: It can not be formatted with 'gnome-disk-utility' the pendrive
On Wed, Oct 10, 2018 at 03:39:01PM -0300, Cristian wrote: > Hello, > > Open bug in launchpad.net > https://bugs.launchpad.net/bugs/1797190 > > "I am trying to format a pendrive of 2TB(Purchased in China for ebay). > What I do is the following: > > 1) I start the notebook with Linux 4.18.0-9 > 2) I start with my GNOME session > 3) I connect the pendrive > 4) I open Nautilus > 5) The pendrive in nautilus appears as mounted > 6) In nautilus I hit a right click with the mouse to my pedrive > 7) I choose 'Format' > 8) A window opens where I can only choose between: ext4, NTFS or FAT > 9) I leave the default -> 'NTFS' > 10) Next press > 11) I change to the next window where the information of what is going > to happen appears and I confirm the format > 12) Then I return to nautilius > 13) The pendrive appears in nautilus > 14) It can not be accessed, even though the pendrive is mounted" This looks like a userspace bug. Please work with your distro first to determine if this really is a kernel issue or not. Good luck! greg k-h
Re: Query on usb/core/devio.c
On Tue, Oct 09, 2018 at 10:51:53AM +0100, Mayuresh Kulkarni wrote: > With all due respect, one of the possible reason for this could be, > power saving on mobile/tablet platforms (running Android). These > platforms usually have a single USB port. Specifically from our point > of view, these platforms are removing 3.5 mm jack and hence the only > interface available for headsets is USB. But the USB audio interface uses the in-kernel driver, which should handle the power management issues automatically. There is no need to use usbfs for hardware like this. So what real-world example are you having that requires this that does not use a kernel driver? And why can you not just close the device? thanks, greg k-h
Re: UVC gadget changes for v4.20
On Tue, Oct 02, 2018 at 01:03:34PM +0300, Felipe Balbi wrote: > > Hi, > > Laurent Pinchart writes: > > On Tuesday, 2 October 2018 10:26:25 EEST Felipe Balbi wrote: > >> Laurent Pinchart writes: > >> > Hi Felipe, > >> > > >> > (CC'ing Greg, in case you're on vacation) > >> > > >> > Ping ? I'd really like to get this merged in v4.20. Do you think that > >> > would be possible ? > >> > >> applying patches today. Are you merging this elsewhere or can I take it > >> as patches? > > > > Thank you ! You can take them as patches if needed, I sent a pull request > > for > > your convenience as I assumed a git merge would be easier, but that's up to > > you. > > I've already applied by merging the tag. It's all in > testing/next. Unless Greg asks me to rebase so that there's no merge, > I'll send a pull request this Thursday. No rebasing please. thanks, greg k-h
Re: ioctl for HID Power devices (UPS) always returning 0
On Sun, Sep 30, 2018 at 08:15:16PM +0200, Laurent Bigonville wrote: > Le 30/09/18 à 13:59, Laurent Bigonville a écrit : > > Hello, > > > > For quite some time, upower is not properly displaying the information > > from my Eaton UPS, looking at this it seems that the kernel is not > > returning the correct information. > > OK, the issue comes from 67ddbb3e6568fb1820b2cc45b00c50702b114801 (adding > HID_QUIRK_NOGET for these devices, which I'm partially responsible of as I > was seeing a 10s delay back then) > > If I revert the commit, I can see the values as expected, but I still see a > delay of 3 sec between the moment the USB device is seen by the kernel and > the HID driver is initialized: You should cc: the authors of that patch, and the linux-input mailing list. The developers there can help you out more than we can as this is a HID issue, not a generic USB issue. thanks, greg k-h
Re: [PATCH v2 0/3] xhci fixes for usb-linus
On Thu, Sep 20, 2018 at 06:43:19PM +0300, Mathias Nyman wrote: > Hi Greg > > Second try, shuffling patches between for-usb-linus and for-usb-next > > A few patches that makes sure USB3 devices enumerate to correct speed > after resume on Mediatek hosts, enables role mux on Apollo lake platforms, > and adds the missing cold attach status (CAS) bit quirk to Intel Sunrise > Point xhci controllers. > > Changes since v1 > > - Moved following patches from this series to for-usb-next (4.20) > xhci: Avoid USB autosuspend when resuming USB2 ports. > usb: xhci: tegra: Firmware header is little endian > > - Added patches to this series from for-usb-next queue: > usb: xhci-mtk: resume USB3 roothub first > usb: typec: pci: Enable Intel USB role mux on Apollo Lake platforms > > - Added stable tags > > Chunfeng Yun (1): > usb: xhci-mtk: resume USB3 roothub first > > Heikki Krogerus (1): > usb: typec: pci: Enable Intel USB role mux on Apollo Lake platforms > > Mathias Nyman (1): > xhci: Add missing CAS workaround for Intel Sunrise Point xHCI > > drivers/usb/host/xhci-mtk.c | 4 ++-- > drivers/usb/host/xhci-pci.c | 8 ++-- > 2 files changed, 8 insertions(+), 4 deletions(-) I only received 2 patches here, not 3, am I missing something on my end? Can you resend all of these again? sorry, greg k-h
Re: Fwd: Lenovo wireless keyboard - kernel/driver problem
On Tue, Sep 25, 2018 at 07:29:43PM +0200, Peter Hostačný wrote: > Hello there, > > there is quite a big trouble around few specific keyboards that are > not working in Linux. > I personally have "Lenovo Professional Wireless Keyboard and Mouse > Combo 4X30H56803" > The keyboard is not working, mouse is. There is a lot of information > spread across multiple threads of many sites. Issue is described quite > well in many of them. > > - > https://askubuntu.com/questions/897729/lenovo-professional-wireless-keyboard-and-mouse-combo-not-working-in-ubuntu?noredirect=1=1 > - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1771431 > - https://bugzilla.kernel.org/show_bug.cgi?id=197787 > - > https://unix.stackexchange.com/questions/377830/linux-hid-driver-for-primax-wireless-keyboards/377873#377873 > - > https://forums.lenovo.com/t5/Linux-Discussion/Professional-Wireless-Keyboard-not-working-on-Linux/td-p/3726486 > > Could you please have a look at it? I will be glad to provide any > information if needed. You might want to post this to the linux-in...@vger.kernel.org list. If one portion of the device is working, odds are it's not a USB problem, but rather a HID issue. thanks, greg k-h
Re: [PATCH v3] usb: core: added uevent for over-current
On Thu, Sep 20, 2018 at 10:17:54AM -0700, Jon Flatley wrote:
> After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
> counters") usb ports expose a sysfs value 'over_current_count'
> to user space. This value on its own is not very useful as it requires
> manual polling.
>
> As a solution, fire a udev event from the usb hub device that specifies
> the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate
> the path of the usb port where the over-current event occurred and the
> value of 'over_current_count' in sysfs. Additionally, call
> sysfs_notify() so the sysfs value supports poll().
>
> Signed-off-by: Jon Flatley
> ---
> Documentation/ABI/testing/sysfs-bus-usb | 9 ++-
> drivers/usb/core/hub.c | 36 +
> 2 files changed, 44 insertions(+), 1 deletion(-)
You should always put the "what changed in this version" below the ---
line so that people know what happened.
I am guess you just rebased this? Any other change?
thanks,
greg k-h
Re: [PATCH 1/2] usb: typec: mux: Take care of driver module reference counting
On Thu, Sep 20, 2018 at 02:26:28PM +0300, Heikki Krogerus wrote:
> On Thu, Sep 20, 2018 at 01:20:03PM +0200, Greg KH wrote:
> > On Wed, Sep 19, 2018 at 10:58:04AM +0300, Heikki Krogerus wrote:
> > > Functions typec_mux_get() and typec_switch_get() already
> > > make sure that the mux device reference count is
> > > incremented, but the same must be done to the driver module
> > > as well to prevent the drivers from being unloaded in the
> > > middle of operation.
> > >
> > > This fixes a potential "BUG: unable to handle kernel paging
> > > request at ..." from happening.
> > >
> > > Fixes: 93dd2112c7b2 ("usb: typec: mux: Get the mux identifier from
> > > function parameter")
> > > Cc:
> >
> > Why is this flagged for stable? 93dd2112c7b2 went into 4.19-rc1 and has
> > not been backported anywhere else.
> >
> > confused,
>
> Sorry, it should not have the stable tag. Shall I resend these?
No need, I'll handle it, thanks.
greg k-h
Re: [PATCH 1/2] usb: typec: mux: Take care of driver module reference counting
On Wed, Sep 19, 2018 at 10:58:04AM +0300, Heikki Krogerus wrote:
> Functions typec_mux_get() and typec_switch_get() already
> make sure that the mux device reference count is
> incremented, but the same must be done to the driver module
> as well to prevent the drivers from being unloaded in the
> middle of operation.
>
> This fixes a potential "BUG: unable to handle kernel paging
> request at ..." from happening.
>
> Fixes: 93dd2112c7b2 ("usb: typec: mux: Get the mux identifier from function
> parameter")
> Cc:
Why is this flagged for stable? 93dd2112c7b2 went into 4.19-rc1 and has
not been backported anywhere else.
confused,
greg k-h
Re: [PATCH v2] usb: core: added uevent for over-current
On Tue, Sep 11, 2018 at 10:43:10AM -0700, Jon Flatley wrote:
> After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
> counters") usb ports expose a sysfs value 'over_current_count'
> to user space. This value on its own is not very useful as it requires
> manual polling.
>
> As a solution, fire a udev event from the usb hub device that specifies
> the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate
> the path of the usb port where the over-current event occurred and the
> value of 'over_current_count' in sysfs. Additionally, call
> sysfs_notify() so the sysfs value supports poll().
>
> Signed-off-by: Jon Flatley
> ---
> Documentation/ABI/testing/sysfs-bus-usb | 9 ++-
> drivers/usb/core/hub.c | 36 +
> 2 files changed, 44 insertions(+), 1 deletion(-)
This patch doesn't apply against my usb-next branch at the moment.
Can you rebase it and resend?
thanks,
greg k-h
Re: [PATCH v6 01/22] usb: usbtmc: Add ioctl for generic requests on control
On Thu, Sep 20, 2018 at 01:00:35PM +0200, Greg KH wrote:
> On Wed, Sep 12, 2018 at 10:50:51AM +0200, Guido Kiener wrote:
> > --- a/include/uapi/linux/usb/tmc.h
> > +++ b/include/uapi/linux/usb/tmc.h
> > @@ -4,6 +4,7 @@
> > * Copyright (C) 2008 Novell, Inc.
> > * Copyright (C) 2008 Greg Kroah-Hartman
> > * Copyright (C) 2015 Dave Penkler
> > + * Copyright (C) 2018 IVI Foundation, Inc.
> > *
> > * This file holds USB constants defined by the USB Device Class
> > * and USB488 Subclass Definitions for Test and Measurement devices
> > @@ -40,6 +41,19 @@
> > #define USBTMC488_REQUEST_GOTO_LOCAL 161
> > #define USBTMC488_REQUEST_LOCAL_LOCKOUT162
> >
> > +struct usbtmc_request {
> > + __u8 bRequestType;
> > + __u8 bRequest;
> > + __u16 wValue;
> > + __u16 wIndex;
> > + __u16 wLength;
> > +} __attribute__ ((packed));
>
> This really is just 'struct usb_ctrlrequest', right? That's already
> defined in our uapi files. Why not use that?
>
> Bonus is, if you use that, you get the proper endian notation, which you
> don't have here, which means this is broken on big endian machines :(
>
> Try doing that, and fix up the endian issue.
Ah, nevermind, you are passing this to the hardware properly. This
should be just fine, I'll take it as-is, sorry for the noise.
greg k-h
Re: [PATCH v6 02/22] usb: usbtmc: Add ioctl for vendor specific write
On Wed, Sep 12, 2018 at 10:50:52AM +0200, Guido Kiener wrote:
> +/*
> + * usbtmc_message->flags:
> + */
> +#define USBTMC_FLAG_ASYNC0x0001
> +#define USBTMC_FLAG_APPEND 0x0002
> +
> +struct usbtmc_message {
> + __u32 transfer_size; /* size of bytes to transfer */
> + __u32 transferred; /* size of received/written bytes */
> + __u32 flags; /* bit 0: 0 = synchronous; 1 = asynchronous */
endian? Native or are these properly transferred to the hardware in the
correct way?
thanks,
greg k-h
Re: [PATCH v6 01/22] usb: usbtmc: Add ioctl for generic requests on control
On Wed, Sep 12, 2018 at 10:50:51AM +0200, Guido Kiener wrote:
> --- a/include/uapi/linux/usb/tmc.h
> +++ b/include/uapi/linux/usb/tmc.h
> @@ -4,6 +4,7 @@
> * Copyright (C) 2008 Novell, Inc.
> * Copyright (C) 2008 Greg Kroah-Hartman
> * Copyright (C) 2015 Dave Penkler
> + * Copyright (C) 2018 IVI Foundation, Inc.
> *
> * This file holds USB constants defined by the USB Device Class
> * and USB488 Subclass Definitions for Test and Measurement devices
> @@ -40,6 +41,19 @@
> #define USBTMC488_REQUEST_GOTO_LOCAL 161
> #define USBTMC488_REQUEST_LOCAL_LOCKOUT 162
>
> +struct usbtmc_request {
> + __u8 bRequestType;
> + __u8 bRequest;
> + __u16 wValue;
> + __u16 wIndex;
> + __u16 wLength;
> +} __attribute__ ((packed));
This really is just 'struct usb_ctrlrequest', right? That's already
defined in our uapi files. Why not use that?
Bonus is, if you use that, you get the proper endian notation, which you
don't have here, which means this is broken on big endian machines :(
Try doing that, and fix up the endian issue.
thanks,
greg k-h
Re: [PATCH 2/2] USB: usbdevfs: restore warning for nonsensical flags
On Thu, Sep 06, 2018 at 11:34:04AM -0400, Alan Stern wrote: > On Thu, 6 Sep 2018, Oliver Neukum wrote: > > > On Mi, 2018-09-05 at 15:07 +0200, Greg KH wrote: > > > On Wed, Sep 05, 2018 at 03:02:48PM +0200, Oliver Neukum wrote: > > > > On Mi, 2018-09-05 at 14:19 +0200, Greg KH wrote: > > > > > On Wed, Sep 05, 2018 at 12:07:03PM +0200, Oliver Neukum wrote: > > > > > > > > + if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK) > > > > > > + dev_warn(>dev->dev, "Requested nonsensical > > > > > > USBDEVFS_URB_SHORT_NOT_OK.\n"); > > > > > > + if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET) > > > > > > + dev_warn(>dev->dev, "Requested nonsensical > > > > > > USBDEVFS_URB_ZERO_PACKET.\n"); > > > > > > > > > > We should not make it trivial for userspace to spam the kernel log if > > > > > at > > > > > all possible. Returning an error is probably the better thing to do > > > > > here, not just silently fix it up or ignore it. > > > > > > > > That means a change in the API in a way that makes orking systems fail. > > > > > > Ah, good point. > > > > Well, but do we want to do this in the next major release even if we > > cannot do it in a stable release? > > > > > I guess they were hitting the same dev_WARN() messages > > > today anyway, right? > > > > Yes. And for a kernel problem you really want the stack traces. > > Still, that does not tell us that we want to print a message if > > user space messes up. So dev_warn() or nothing? > > An alternative is for usbfs to silently fix the flags when they are > wrong. Would that be any better? Probably not. I'll take the original patches now and see if there is any complaints by users. thanks, greg k-h
Re: [PATCH 01/10] usb: xhci-mtk: resume USB3 roothub first
On Mon, Sep 17, 2018 at 10:35:46AM +0300, Mathias Nyman wrote: > On 14.09.2018 16:27, Greg KH wrote: > > On Thu, Sep 13, 2018 at 03:23:54PM +0300, Mathias Nyman wrote: > > > From: Chunfeng Yun > > > > > > Give USB3 devices a better chance to enumerate at USB3 speeds if > > > they are connected to a suspended host. > > > Porting from "671ffdff5b13 xhci: resume USB 3 roothub first" > > > > > > Signed-off-by: Chunfeng Yun > > > Signed-off-by: Mathias Nyman > > > --- > > > drivers/usb/host/xhci-mtk.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Isn't this a bugfix for 4.19-final? And maybe for stable? > > > > This was part of a 6 patch series that mostly contained mediatek > bandwidth scheduling improvements. > > But I agree, this first one could go to 4.19 with stable flag. Ok, can you redo this whole series, and the 4.19-final series, so we get these all straightened out as to which patch goes where, and resend? I've dropped all of your pending patches from my queue now. thanks, greg k-h
Re: [PATCH 1/3] usb: xhci: tegra: Firmware header is little endian
On Mon, Sep 17, 2018 at 08:40:44AM +0200, Thierry Reding wrote: > On Fri, Sep 14, 2018 at 03:01:22PM +0200, Greg KH wrote: > > On Fri, Sep 14, 2018 at 03:33:29PM +0300, Mathias Nyman wrote: > > > From: Thierry Reding > > > > > > The XUSB firmware header is in little endian byte order, so make the > > > fields __le32 and __le16 instead of u32 and u16 to avoid warnings from > > > sparse when the fields are used with the endian-aware __le32_to_cpu() > > > and __le16_to_cpu() accessors, respectively. > > > > This isn't a "bug" in that no code is changed, so why is it needed for > > 4.19-final? > > > > Shouldn't this be fine to merge in 4.20-rc1? > > Yeah, I don't think there's a need to rush this. It's only to fix a > warning from sparse, but it shouldn't impact any code since the code > itself already properly parses the firmware in little endian byte > order. Thanks for confirming. Mathias, I'll wait for you to resend this as part of a 4.20-rc1 submission. thanks, greg k-h
Re: [PATCH 2/3] xhci: Avoid USB autosuspend when resuming USB2 ports.
On Wed, Sep 19, 2018 at 10:54:45AM +0530, Anshuman Gupta wrote: > On Mon, Sep 17, 2018 at 11:24:20AM +0300, Mathias Nyman wrote: > > On 14.09.2018 16:00, Greg KH wrote: > > > On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: > > > > From: Anshuman Gupta > > > > > > > > When USB bus host controller root hub resumes from autosuspend, > > > > it immediately tries to enter auto-suspend, but there can be a > > > > scenario when root hub is resuming its usb2 ports, in that particular > > > > case USB host controller auto suspend fails since it is busy > > > > to resuming its usb2 ports. > > > > > > > > This makes multiple failed cycles of auto-suspend until all usb2 > > > > ports of host controller root hub do not resume. > > > > > > > > This patch uses USB core framework usb_hcd_start_port_resume, > > > > usb_hcd_end_port_resume API's in order to autoresume/autosuspend > > > > root hub properly. > > > > > > > > Signed-off-by: Anshuman Gupta > > > > Signed-off-by: Mathias Nyman > > > > > > Not needed in stable? Does this fix a specific commit? > > > > > > thanks, > > > > > > greg k-h > > > > > > > This improves a bad initial design that prevented autosuspend by > > returning -EBUSY in xhci_bus_suspend() if a usb2 port was resuming. > > > > Instead increment usage count on the roothub to prevent pm from polling > > xhci_bus_suspend(). This is also what EHCI does. > > > > I'm not sure If this fixes a actual bug for Anshuman Gupta caused by > > the -EBUSY polling,(4.19 +stable), or if this is just a improvement in > > suspend/resume code for xhci (4.20). > > > > Anshuman Gupta, any comments? > This patch is not fixing any bug. > This patch provide improvement in runtime suspend/resume path of xhci. Great, then it shouldn't go into 4.19-final :) Mathias, can you redo this patch series and resend? thanks, greg k-h
Re: Kernel memory leak on CDC-ACM device plug/unplug
On Wed, Sep 19, 2018 at 04:11:55PM +0200, Romain Izard wrote: > While trying to debug a memory leak problem, I encountered the following > problem: > > After plugging/unplugging an USB CDC-ACM device, kmemleak reports multiple > copies of the following leak. It is not necessary to open the port for the > leak to happen. > > unreferenced object 0xddbfd500 (size 128): > comm "kworker/0:3", pid 675, jiffies 69734 (age 916.580s) > hex dump (first 32 bytes): > 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 1c d5 bf dd > backtrace: > [] acm_probe+0x868/0xc3c > [] usb_probe_interface+0x11c/0x274 > [] driver_probe_device+0x22c/0x320 > [<544a5b43>] bus_for_each_drv+0x58/0xb8 > [] __device_attach+0xd0/0x138 > [] bus_probe_device+0x84/0x8c > [<16645f2c>] device_add+0x3cc/0x5c0 > [<80c11c88>] usb_set_configuration+0x448/0x7b0 > [<76bdbcdf>] generic_probe+0x2c/0x78 > [] driver_probe_device+0x22c/0x320 > [<544a5b43>] bus_for_each_drv+0x58/0xb8 > [] __device_attach+0xd0/0x138 > [] bus_probe_device+0x84/0x8c > [<16645f2c>] device_add+0x3cc/0x5c0 > [<02a49898>] usb_new_device+0x264/0x424 > [<865a481b>] hub_event+0xa20/0x1154 > > For each additional plug/unplug cycle, around 30 such new leaks are created. > > Tested on a SAMA5D2 Xplained demo board, with a v4.18.8 kernel. > The CDC-ACM device was another SAMA5D2 device, with a composite profile > including a CDC-ACM port implemented with configfs. Have you come up with any patches that might resolve this? It's hard to see what exactly is "leaking" here. thanks, greg k-h
Re: Stylus reports 1% battery
On Sat, Sep 15, 2018 at 01:59:14AM -0600, Trent Gamblin wrote: > With an ELAN touchscreen and active stylus, the stylus reports 1% battery at > all times. I've used several batteries including 2 brand new ones, and tried > 2 new styluses. I noticed in the USB HID driver the possibility of ignoring > the battery on devices by adding IDs to the code, perhaps it's a good idea > with this device. > > When I use the stylus it pops up a notification saying the battery is low. > On Windows, I don't get any notification nor does there seem to be any way > to check the battery level, so I think it might not be a valid value at all. > The troubleshooting manual from Dell for the stylus simply says if the > stylus isn't working anymore, replace the battery. I'm using a Dell Inspiron > 5379 laptop. > > lsusb -vd output is attached. I've added the linux-input mailing list as the developers there should be able to help you out with this better than just the USB developers can. lsusb output preserved below... thanks, greg k-h > > Bus 001 Device 007: ID 04f3:2361 Elan Microelectronics Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x04f3 Elan Microelectronics Corp. > idProduct 0x2361 > bcdDevice 57.13 > iManufacturer 4 ELAN > iProduct 14 Touchscreen > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 41 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType33 > bcdHID 1.10 > bCountryCode0 Not supported > bNumDescriptors 1 > bDescriptorType34 Report > wDescriptorLength1043 > Report Descriptor: (length is 1043) > Item(Global): Usage Page, data= [ 0x0d ] 13 > Digitizer > Item(Local ): Usage, data= [ 0x02 ] 2 > Pen > Item(Main ): Collection, data= [ 0x01 ] 1 > Application > Item(Global): Report ID, data= [ 0x07 ] 7 > Item(Global): Physical Minimum, data= [ 0x00 ] 0 > Item(Local ): Usage, data= [ 0x20 ] 32 > Stylus > Item(Main ): Collection, data= [ 0x00 ] 0 > Physical > Item(Local ): Usage, data= [ 0x32 ] 50 > In Range > Item(Local ): Usage, data= [ 0x42 ] 66 > Tip Switch > Item(Local ): Usage, data= [ 0x44 ] 68 > Barrel Switch > Item(Local ): Usage, data= [ 0x3c ] 60 > Invert > Item(Local ): Usage, data= [ 0x45 ] 69 > Eraser > Item(Global): Logical Minimum, data= [ 0x00 ] 0 > Item(Global): Logical Maximum, data= [ 0x01 ] 1 > Item(Global): Report Size, data= [ 0x01 ] 1 > Item(Global): Report Count, data= [ 0x05 ] 5 > Item(Main ): Input, data= [ 0x02 ] 2 > Data Variable Absolute No_Wrap Linear > Preferred_State No_Null_Position Non_Volatile > Bitfield > Item(Global): Report Count, data= [ 0x03 ] 3 > Item(Main ): Input, data= [ 0x03 ] 3 > Constant Variable Absolute No_Wrap Linear > Preferred_State No_Null_Position Non_Volatile > Bitfield > Item(Global): Usage Page, data= [ 0x01 ] 1 > Generic Desktop Controls > Item(Local ): Usage, data= [ 0x30 ] 48 > Direction-X > Item(Global): Report Size, data= [ 0x10 ] 16 > Item(Global): Report Count, data= [ 0x01 ] 1 > Item(Global): Push, data=none > Item(Global): Unit Exponent, data= [ 0x0f ] 15 > Unit Exponent: 15 > Item(Global): Unit, data= [ 0x11 ] 17
Re: [PATCH 01/10] usb: xhci-mtk: resume USB3 roothub first
On Thu, Sep 13, 2018 at 03:23:54PM +0300, Mathias Nyman wrote: > From: Chunfeng Yun > > Give USB3 devices a better chance to enumerate at USB3 speeds if > they are connected to a suspended host. > Porting from "671ffdff5b13 xhci: resume USB 3 roothub first" > > Signed-off-by: Chunfeng Yun > Signed-off-by: Mathias Nyman > --- > drivers/usb/host/xhci-mtk.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Isn't this a bugfix for 4.19-final? And maybe for stable? thanks, greg k-h
Re: [PATCH 07/10] usb: typec: pci: Enable Intel USB role mux on Apollo Lake platforms
On Thu, Sep 13, 2018 at 03:24:00PM +0300, Mathias Nyman wrote: > From: Heikki Krogerus > > Intel Apollo Lake has the same internal USB role mux as > Intel Cherry Trail. > > Signed-off-by: Heikki Krogerus > Signed-off-by: Mathias Nyman > --- > drivers/usb/host/xhci-pci.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Why is this not a 4.19-final patch? Stable?
Re: [PATCH 1/3] usb: xhci: tegra: Firmware header is little endian
On Fri, Sep 14, 2018 at 03:33:29PM +0300, Mathias Nyman wrote: > From: Thierry Reding > > The XUSB firmware header is in little endian byte order, so make the > fields __le32 and __le16 instead of u32 and u16 to avoid warnings from > sparse when the fields are used with the endian-aware __le32_to_cpu() > and __le16_to_cpu() accessors, respectively. This isn't a "bug" in that no code is changed, so why is it needed for 4.19-final? Shouldn't this be fine to merge in 4.20-rc1? thanks, greg k-h
Re: [PATCH 3/3] xhci: Add missing CAS workaround for Intel Sunrise Point xHCI
On Fri, Sep 14, 2018 at 03:33:31PM +0300, Mathias Nyman wrote: > The workaround for missing CAS bit is also needed for xHC on Intel > sunrisepoint PCH. For more details see: > > Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 > > Signed-off-by: Mathias Nyman > --- > drivers/usb/host/xhci-pci.c | 2 ++ > 1 file changed, 2 insertions(+) No stable tree tagging?
Re: [PATCH 2/3] xhci: Avoid USB autosuspend when resuming USB2 ports.
On Fri, Sep 14, 2018 at 03:33:30PM +0300, Mathias Nyman wrote: > From: Anshuman Gupta > > When USB bus host controller root hub resumes from autosuspend, > it immediately tries to enter auto-suspend, but there can be a > scenario when root hub is resuming its usb2 ports, in that particular > case USB host controller auto suspend fails since it is busy > to resuming its usb2 ports. > > This makes multiple failed cycles of auto-suspend until all usb2 > ports of host controller root hub do not resume. > > This patch uses USB core framework usb_hcd_start_port_resume, > usb_hcd_end_port_resume API's in order to autoresume/autosuspend > root hub properly. > > Signed-off-by: Anshuman Gupta > Signed-off-by: Mathias Nyman Not needed in stable? Does this fix a specific commit? thanks, greg k-h
Re: Inaccessible dual-role port on CherryTrail
On Thu, Sep 13, 2018 at 03:40:12PM -0700, Rob Weber wrote: > Hi linux-usb, > > I'm currently bringing up a custom board that uses a CherryTrail > processor and I'm having quite a bit of trouble accessing the dual-role > port from Linux. > > Our system includes two USB 3.0-capable ports with Type-C connectors. > One port is designed to be a host-only port (downstream-facing), > while the other port is designed to be a dual-role port. The USB 2.0 > data lines and the SuperSpeed lines are connected to the SoC. Our > system uses two USB Power Delivery controllers to help with PD > negotiations. We have an OTG_ID signal connected to the SoC. > Depending on the data role negotiation (which we detect from the PD > controller), we either tie that signal to GND or let it float. > I'm running a 4.9.115 kernel built using Yocto with a few patches applied > to enable HDMI audio. 4.9 is really old by now, and lots and lots of USB-C and dwc3 and xhci changes have happened in the almost 2 years since that kernel was released. You might want to try 4.18 to see if your issues are already solved, have you tried that? thanks, greg k-h
Re: [PATCH V2] usbcore: Select UAC3 configuration for audio if present
On Wed, Sep 12, 2018 at 01:03:57AM +0530, saranya.go...@intel.com wrote:
> From: Saranya Gopal
Any reason you forgot to cc: the usb maintainer? :)
>
> USB audio class 3.0 specification introduced many significant
> changes like
> - new power domains, support for LPM/L1
> - new cluster descriptor
> - new high capability and class-specific string descriptors
> - BADD profiles
> - ... and many other things (check spec from link below:
> http://www.usb.org/developers/docs/devclass_docs/USB_Audio_v3.0.zip)
>
> Now that UAC3 is supported in linux, choose UAC3
> configuration for audio if the device supports it.
> Selecting this configuration will enable the system to
> save power by leveraging the new power domains and LPM L1
> capability and also support new codec types and data formats
> for consumer audio applications.
>
> Signed-off-by: Saranya Gopal
> Reviewed-by: Felipe Balbi
> ---
> Changes from V1: Deleted nested if check for is_uac3_config
>
> drivers/usb/core/generic.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
> index bc8242b..df38d5a 100644
> --- a/drivers/usb/core/generic.c
> +++ b/drivers/usb/core/generic.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include "usb.h"
>
> static inline const char *plural(int n)
> @@ -42,6 +43,16 @@ static int is_activesync(struct usb_interface_descriptor
> *desc)
> && desc->bInterfaceProtocol == 1;
> }
>
> +static int is_audio(struct usb_interface_descriptor *desc)
bool?
> +{
> + return desc->bInterfaceClass == USB_CLASS_AUDIO;
> +}
> +
> +static int is_uac3_config(struct usb_interface_descriptor *desc)
bool?
thanks,
greg k-h
Re: [PATCH] usb: core: added uevent for over-current
On Mon, Sep 10, 2018 at 03:12:22PM -0700, Jon Flatley wrote:
> On Mon, Sep 10, 2018 at 11:14 AM Greg KH wrote:
> >
> > On Fri, Aug 31, 2018 at 10:14:19AM -0700, Jon Flatley wrote:
> > > After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
> > > counters") usb ports expose a sysfs value 'over_current_count'
> > > to user space. This value on its own is not very useful as it requires
> > > manual polling.
> > >
> > > As a solution, fire a udev event from the usb hub device that specifies
> > > the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate
> > > the path of the usb port where the over-current event occurred and the
> > > value of 'over_current_count' in sysfs. Additionally, call
> > > sysfs_notify() so the sysfs value supports poll().
> > >
> > > Signed-off-by: Jon Flatley
> > > ---
> > > drivers/usb/core/hub.c | 36
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > index 65feedd69323..c986b0fc2daa 100644
> > > --- a/drivers/usb/core/hub.c
> > > +++ b/drivers/usb/core/hub.c
> > > @@ -27,6 +27,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -5096,6 +5097,40 @@ static void hub_port_connect_change(struct usb_hub
> > > *hub, int port1,
> > > usb_lock_port(port_dev);
> > > }
> > >
> > > +/* Handle notifying userspace about hub over-current events */
> > > +static void port_over_current_notify(struct usb_port *port_dev)
> > > +{
> > > + static char *envp[] = { NULL, NULL, NULL };
> > > + struct device *hub_dev;
> > > + char *port_dev_path;
> > > +
> > > + sysfs_notify(_dev->dev.kobj, NULL, "over_current_count");
> > > +
> > > + hub_dev = port_dev->dev.parent;
> > > +
> > > + if (!hub_dev)
> > > + return;
> > > +
> > > + port_dev_path = kobject_get_path(_dev->dev.kobj, GFP_KERNEL);
> > > + if (!port_dev_path)
> > > + return;
> > > +
> > > + envp[0] = kasprintf(GFP_KERNEL, "OVER_CURRENT_PORT=%s",
> > > port_dev_path);
> > > + if (!envp[0])
> > > + return;
> > > +
> > > + envp[1] = kasprintf(GFP_KERNEL, "OVER_CURRENT_COUNT=%u",
> > > + port_dev->over_current_count);
> > > + if (!envp[1])
> > > + goto exit;
> > > +
> > > + kobject_uevent_env(_dev->kobj, KOBJ_CHANGE, envp);
> > > +
> > > + kfree(envp[1]);
> > > +exit:
> > > + kfree(envp[0]);
> > > +}
> > > +
> > > static void port_event(struct usb_hub *hub, int port1)
> > > __must_hold(_dev->status_lock)
> > > {
> > > @@ -5138,6 +5173,7 @@ static void port_event(struct usb_hub *hub, int
> > > port1)
> > > if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
> > > u16 status = 0, unused;
> > > port_dev->over_current_count++;
> > > + port_over_current_notify(port_dev);
> >
> > When an overcurrent "event" happens, does it just stay overloaded for
> > long periods of time? Would this flood the system with lots of kobject
> > messages, or is this rate-limited somehow?
> >
> > Also, as this is a new user/kernel abi you are creating, it needs to be
> > documented somewhere. Perhaps in the sysfs file information for this
> > attribute?
> >
> > thanks,
> >
> > greg k-h
>
> The kobject message is only sent when the USB_PORT_STAT_C_OVERCURRENT bit
> is set. This happens when the port enters or leaves in over-current
> condition or when the port is powered off due to an over-current condition
> on another port. This bit is cleared after being processed so typically
> only two messages per over-current event should be expected.
So these do not "flap" really quickly? Just want to make sure we aren't
creating a way for the system to DoS itself :)
> Are you referring to documenting this udev event alongside the sysfs
> documentation for this attribute? Is this typically where this type of
> documentation goes?
Yes, there are other sysfs attributes documented this way, so that is
the best place that I can think of at the time.
Can you respin this patch with that change added?
thanks,
greg k-h
Re: [PATCH V4] roles: Fix USB 3.0 OTG issue on Intel platform
On Fri, Sep 07, 2018 at 09:59:40AM +0530, saranya.go...@intel.com wrote: > From: Saranya Gopal > > This patch adds static DRD mode for host/device > mode switch. This fixes the issue where device > mode was not working after DUT switches to host > mode with 3.0 OTG connector. > > Change-Id: Ib6d04b90d277d965ef10026751a7f4832cad5d2a Why is this line here? What commit does this "fix"? Or has this always been a problem? > Signed-off-by: Saranya Gopal > Signed-off-by: M Balaji > Reviewed-by: Heikki Krogerus > Revieved-by: Kuppuswamy Sathyanarayanan > > --- > drivers/usb/roles/intel-xhci-usb-role-switch.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) Does this need to go to any older stable kernels or is 4.20 ok? 4.19? something else? thanks, greg k-h
Re: [PATCH] usb: core: added uevent for over-current
On Fri, Aug 31, 2018 at 10:14:19AM -0700, Jon Flatley wrote:
> After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current
> counters") usb ports expose a sysfs value 'over_current_count'
> to user space. This value on its own is not very useful as it requires
> manual polling.
>
> As a solution, fire a udev event from the usb hub device that specifies
> the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate
> the path of the usb port where the over-current event occurred and the
> value of 'over_current_count' in sysfs. Additionally, call
> sysfs_notify() so the sysfs value supports poll().
>
> Signed-off-by: Jon Flatley
> ---
> drivers/usb/core/hub.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 65feedd69323..c986b0fc2daa 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -5096,6 +5097,40 @@ static void hub_port_connect_change(struct usb_hub
> *hub, int port1,
> usb_lock_port(port_dev);
> }
>
> +/* Handle notifying userspace about hub over-current events */
> +static void port_over_current_notify(struct usb_port *port_dev)
> +{
> + static char *envp[] = { NULL, NULL, NULL };
> + struct device *hub_dev;
> + char *port_dev_path;
> +
> + sysfs_notify(_dev->dev.kobj, NULL, "over_current_count");
> +
> + hub_dev = port_dev->dev.parent;
> +
> + if (!hub_dev)
> + return;
> +
> + port_dev_path = kobject_get_path(_dev->dev.kobj, GFP_KERNEL);
> + if (!port_dev_path)
> + return;
> +
> + envp[0] = kasprintf(GFP_KERNEL, "OVER_CURRENT_PORT=%s", port_dev_path);
> + if (!envp[0])
> + return;
> +
> + envp[1] = kasprintf(GFP_KERNEL, "OVER_CURRENT_COUNT=%u",
> + port_dev->over_current_count);
> + if (!envp[1])
> + goto exit;
> +
> + kobject_uevent_env(_dev->kobj, KOBJ_CHANGE, envp);
> +
> + kfree(envp[1]);
> +exit:
> + kfree(envp[0]);
> +}
> +
> static void port_event(struct usb_hub *hub, int port1)
> __must_hold(_dev->status_lock)
> {
> @@ -5138,6 +5173,7 @@ static void port_event(struct usb_hub *hub, int port1)
> if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
> u16 status = 0, unused;
> port_dev->over_current_count++;
> + port_over_current_notify(port_dev);
When an overcurrent "event" happens, does it just stay overloaded for
long periods of time? Would this flood the system with lots of kobject
messages, or is this rate-limited somehow?
Also, as this is a new user/kernel abi you are creating, it needs to be
documented somewhere. Perhaps in the sysfs file information for this
attribute?
thanks,
greg k-h
Re: [PATCH V6] roles: Fix USB 3.0 OTG issue on Intel platform
On Fri, Sep 07, 2018 at 11:33:23AM +0300, Felipe Balbi wrote: > > Hi Greg, > > "Gopal, Saranya" writes: > >> > diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c > >> b/drivers/usb/roles/intel-xhci-usb-role-switch.c > >> > index dad2d19..0d1ea82 100644 > >> > --- a/drivers/usb/roles/intel-xhci-usb-role-switch.c > >> > +++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c > >> > @@ -25,6 +25,9 @@ > >> > #define SW_VBUS_VALID BIT(24) > >> > #define SW_IDPIN_EN BIT(21) > >> > #define SW_IDPINBIT(20) > >> > +#define SW_SWITCH_EN_CFG0 BIT(16) > >> > >> Why is this not in the correct sorted order with the items above it? > > they are sorted in descending order. > > /* register definition */ > #define DUAL_ROLE_CFG00x68 > #define SW_VBUS_VALID BIT(24) > #define SW_IDPIN_EN BIT(21) > #define SW_IDPIN BIT(20) Ugh, you are right, that's what I get for trying to review code before my coffee has kicked in... Sorry about that. greg k-h
Re: [PATCH V6] roles: Fix USB 3.0 OTG issue on Intel platform
On Fri, Sep 07, 2018 at 12:32:01PM +0530, saranya.go...@intel.com wrote: > From: Saranya Gopal > > This patch adds static DRD mode for host/device > mode switch. This fixes the issue where device > mode was not working after DUT switches to host > mode with 3.0 OTG connector. > > Signed-off-by: Saranya Gopal > Signed-off-by: M Balaji > Reviewed-by: Heikki Krogerus > Reviewed-by: Kuppuswamy Sathyanarayanan > > --- > changes since V5: Corrected the name format in From and Signed-off-by > changes since V4: Removed change-Id > changes since V3: Added Reviewed-by Sathyanarayanan tag > changes since V2: Incorporated Heikki's review comments and added > Reviewed-by Heikki tag > changes since V1: none > > drivers/usb/roles/intel-xhci-usb-role-switch.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c > b/drivers/usb/roles/intel-xhci-usb-role-switch.c > index dad2d19..0d1ea82 100644 > --- a/drivers/usb/roles/intel-xhci-usb-role-switch.c > +++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c > @@ -25,6 +25,9 @@ > #define SW_VBUS_VALIDBIT(24) > #define SW_IDPIN_EN BIT(21) > #define SW_IDPIN BIT(20) > +#define SW_SWITCH_EN_CFG0BIT(16) Why is this not in the correct sorted order with the items above it? Is this a patch that should go to the stable trees? If so, which ones? thanks, greg k-h
Re: [PATCH V5] roles: Fix USB 3.0 OTG issue on Intel platform
On Fri, Sep 07, 2018 at 11:45:18AM +0530, saranya.go...@intel.com wrote: > From: saranya That's not right :( > > This patch adds static DRD mode for host/device > mode switch. This fixes the issue where device > mode was not working after DUT switches to host > mode with 3.0 OTG connector. > > Signed-off-by: saranya Neither is that :( Why change lines that were correct last time around? greg k-h
Re: [PATCH V4] roles: Fix USB 3.0 OTG issue on Intel platform
On Fri, Sep 07, 2018 at 09:59:40AM +0530, saranya.go...@intel.com wrote: > From: Saranya Gopal > > This patch adds static DRD mode for host/device > mode switch. This fixes the issue where device > mode was not working after DUT switches to host > mode with 3.0 OTG connector. > > Change-Id: Ib6d04b90d277d965ef10026751a7f4832cad5d2a This line is not needed, you didn't run checkpatch.pl :( > Signed-off-by: Saranya Gopal > Signed-off-by: M Balaji > Reviewed-by: Heikki Krogerus > Revieved-by: Kuppuswamy Sathyanarayanan > > --- > drivers/usb/roles/intel-xhci-usb-role-switch.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) What changed from previous versions? That always needs to be somewhere, usually below the --- line. v5?
Re: [PATCH 2/2] USB: usbdevfs: restore warning for nonsensical flags
On Wed, Sep 05, 2018 at 03:02:48PM +0200, Oliver Neukum wrote:
> On Mi, 2018-09-05 at 14:19 +0200, Greg KH wrote:
> > On Wed, Sep 05, 2018 at 12:07:03PM +0200, Oliver Neukum wrote:
> > > If we filter flags before they reach the core we need to generate our
> > > own warnings.
> > >
> > > Signed-off-by: Oliver Neukum
> > > Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
> > > ---
> > > drivers/usb/core/devio.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> > > index 263dd2f309fb..244417d0dfd1 100644
> > > --- a/drivers/usb/core/devio.c
> > > +++ b/drivers/usb/core/devio.c
> > > @@ -1697,6 +1697,11 @@ static int proc_do_submiturb(struct usb_dev_state
> > > *ps, struct usbdevfs_urb *uurb
> > > u |= URB_NO_INTERRUPT;
> > > as->urb->transfer_flags = u;
> > >
> > > + if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
> > > + dev_warn(>dev->dev, "Requested nonsensical
> > > USBDEVFS_URB_SHORT_NOT_OK.\n");
> > > + if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
> > > + dev_warn(>dev->dev, "Requested nonsensical
> > > USBDEVFS_URB_ZERO_PACKET.\n");
> >
> > We should not make it trivial for userspace to spam the kernel log if at
> > all possible. Returning an error is probably the better thing to do
> > here, not just silently fix it up or ignore it.
>
> That means a change in the API in a way that makes orking systems fail.
Ah, good point. I guess they were hitting the same dev_WARN() messages
today anyway, right?
> Do you want an extra version for stable?
No, but why was this patch not marked for stable?
thanks,
greg k-h
Re: [PATCH] Revert "cdc-acm: implement put_char() and flush_chars()"
On Thu, Aug 30, 2018 at 11:18:36AM +0200, Oliver Neukum wrote:
> This reverts commit a81cf9799ad7299b03a4dff020d9685f9ac5f3e0.
>
> The patch causes a regression, which I cannot find the reason for.
> So let's revert for now, as a revert hurts only performance.
>
> I was trying to resolve the problem with Oliver but we don't get any
> conclusion
> for 5 months, so I am now sending this to mail list and cdc_acm authors.
>
> I am using simple request-response protocol to obtain the boiller
> parameters
> in constant intervals.
>
> A simple one transaction is:
> 1. opening the /dev/ttyACM0
> 2. sending the following 10-bytes request to the device:
> unsigned char req[] = {0x02, 0xfe, 0x01, 0x05, 0x08, 0x02, 0x01,
> 0x69, 0xab, 0x03};
> 3. reading response (frame of 74 bytes length).
> 4. closing the descriptor
> I am doing this transaction with 5 seconds intervals.
>
> Before the bad commit everything was working correctly: I've got a
> requests and
> a responses in a timely manner.
>
> After the bad commit more time I am using the kernel module, more
> problems I have.
> The graph [2] is showing the problem.
>
> As you can see after module load all seems fine but after about 30
> minutes I've got
> a plenty of EAGAINs when doing read()'s and trying to read back the
> data.
>
> When I rmmod and insmod the cdc_acm module again, then the situation is
> starting
> over again: running ok shortly after load, and more time it is running,
> more EAGAINs
> I have when calling read().
>
> As a bonus I can see the problem on the device itself:
> The device is configured as you can see here on this screen [3].
> It has two transmision LEDs: TX and RX. Blink duration is set for 100ms.
> This is a recording before the bad commit when all is working fine: [4]
> And this is with the bad commit: [5]
> As you can see the TX led is blinking wrongly long (indicating
> transmission?)
> and I have problems doing read() calls (EAGAIN).
>
> Reported-by: manio
> Signed-off-by: Oliver Neukum
> Fixes: a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()")
> Cc: stable
> ---
> drivers/usb/class/cdc-acm.c | 92
> -
> drivers/usb/class/cdc-acm.h | 1 -
> 2 files changed, 93 deletions(-)
This does not apply to Linus's tree right now, can you refresh it and
resend?
thanks,
greg k-h
Re: [PATCH v5 2/2] usb: typec: ucsi: add support for Cypress CCGx
On Fri, Aug 31, 2018 at 01:22:21PM -0700, Ajay Gupta wrote:
> Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
> over I2C interface.
>
> This UCSI I2C driver uses I2C bus driver interface for communicating
> with Type-C controller.
>
> Signed-off-by: Ajay Gupta
> ---
> Changes from v1 -> v2
> Fixed identation in drivers/usb/typec/ucsi/Kconfig
> Changes from v2 -> v3
> Fixed most of comments from Heikki
> Rename ucsi_i2c_ccg.c -> ucsi_ccg.c
> Changes from v3 -> v4
> Fixed comments from Andy
> Changes from v4 -> v5
> Fixed comments from Andy
>
> drivers/usb/typec/ucsi/Kconfig| 10 +
> drivers/usb/typec/ucsi/Makefile | 2 +
> drivers/usb/typec/ucsi/ucsi_ccg.c | 390
> ++
> 3 files changed, 402 insertions(+)
> create mode 100644 drivers/usb/typec/ucsi/ucsi_ccg.c
>
> diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
> index e36d6c7..7811888 100644
> --- a/drivers/usb/typec/ucsi/Kconfig
> +++ b/drivers/usb/typec/ucsi/Kconfig
> @@ -23,6 +23,16 @@ config TYPEC_UCSI
>
> if TYPEC_UCSI
>
> +config UCSI_CCG
> + tristate "UCSI Interface Driver for Cypress CCGx"
> + depends on I2C
> + help
> + This driver enables UCSI support on platforms that expose a
> + Cypress CCGx Type-C controller over I2C interface.
> +
> + To compile the driver as a module, choose M here: the module will be
> + called ucsi_ccg.
> +
> config UCSI_ACPI
> tristate "UCSI ACPI Interface Driver"
> depends on ACPI
> diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
> index 7afbea5..2f4900b 100644
> --- a/drivers/usb/typec/ucsi/Makefile
> +++ b/drivers/usb/typec/ucsi/Makefile
> @@ -8,3 +8,5 @@ typec_ucsi-y := ucsi.o
> typec_ucsi-$(CONFIG_TRACING) += trace.o
>
> obj-$(CONFIG_UCSI_ACPI) += ucsi_acpi.o
> +
> +obj-$(CONFIG_UCSI_CCG) += ucsi_ccg.o
> diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> b/drivers/usb/typec/ucsi/ucsi_ccg.c
> new file mode 100644
> index 000..1e7c3b2
> --- /dev/null
> +++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
> @@ -0,0 +1,390 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * UCSI driver for Cypress CCGx Type-C controller
> + *
> + * Copyright (C) 2017-2018 NVIDIA Corporation. All rights reserved.
> + * Author: Ajay Gupta
> + *
> + * Some code borrowed from drivers/usb/typec/ucsi/ucsi_acpi.c
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include "ucsi.h"
> +
> +struct ucsi_ccg {
> + struct device *dev;
> + struct ucsi *ucsi;
> + struct ucsi_ppm ppm;
> + struct i2c_client *client;
> + int irq;
> +};
> +
> +#define CCGX_I2C_RAB_DEVICE_MODE 0x00
> +#define CCGX_I2C_RAB_READ_SILICON_ID 0x2
> +#define CCGX_I2C_RAB_INTR_REG0x06
> +#define CCGX_I2C_RAB_FW1_VERSION 0x28
> +#define CCGX_I2C_RAB_FW2_VERSION 0x20
> +#define CCGX_I2C_RAB_UCSI_CONTROL0x39
> +#define CCGX_I2C_RAB_UCSI_CONTROL_START BIT(0)
> +#define CCGX_I2C_RAB_UCSI_CONTROL_STOP BIT(1)
> +#define CCGX_I2C_RAB_RESPONSE_REG0x7E
> +#define CCGX_I2C_RAB_UCSI_DATA_BLOCK 0xf000
> +
> +static int ccg_read(struct ucsi_ccg *uc, u16 rab, u8 *data, u32 len)
> +{
> + struct device *dev = uc->dev;
> + struct i2c_client *client = uc->client;
> + unsigned char buf[2];
> + struct i2c_msg msgs[] = {
> + {
> + .addr = client->addr,
> + .flags = 0x0,
> + .len= 0x2,
> + .buf= buf,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .buf= data,
> + },
> + };
Are you sure you are allowed to do i2c messages off of the stack like
this? Will that work on all platforms?
> + u32 rlen, rem_len = len;
> + int err;
> +
> + while (rem_len > 0) {
> + msgs[1].buf = [len - rem_len];
> + rlen = min_t(u16, rem_len, 4);
> + msgs[1].len = rlen;
> + put_unaligned_le16(rab, buf);
> + err = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> + if (err < 0) {
> + dev_err(dev, "i2c_transfer failed, err %d\n", err);
You are printing out an error here, no need to print out another
error every time you call this function and it fails, right? Only do it
in one place, otherwise it is extra noisy when things fail.
> + return err;
> + }
> + rab += rlen;
> + rem_len -= rlen;
> + }
> +
> + return 0;
> +}
> +
> +static int ccg_write(struct ucsi_ccg *uc, u16 rab, u8 *data, u32 len)
Re: [PATCH v5 2/2] usb: typec: ucsi: add support for Cypress CCGx
On Fri, Aug 31, 2018 at 01:22:21PM -0700, Ajay Gupta wrote: > + dev_info(dev, "Silicon id %2ph", data + CCGX_I2C_RAB_READ_SILICON_ID); > + dev_info(dev, "FW1 version %8ph\n", data + CCGX_I2C_RAB_FW1_VERSION); > + dev_info(dev, "FW2 version %8ph\n", data + CCGX_I2C_RAB_FW2_VERSION); Drivers should be totally quiet when initialized, unless something goes wrong. Please don't spam the kernel log with this type of stuff. You can use dev_dbg() if it helps with debugging the code, that might be a better idea here. Also, a pointer? Are you sure about that? That looks really odd... thanks, greg k-h
Re: [PATCH 2/2] USB: usbdevfs: restore warning for nonsensical flags
On Wed, Sep 05, 2018 at 12:07:03PM +0200, Oliver Neukum wrote:
> If we filter flags before they reach the core we need to generate our
> own warnings.
>
> Signed-off-by: Oliver Neukum
> Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
> ---
> drivers/usb/core/devio.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 263dd2f309fb..244417d0dfd1 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -1697,6 +1697,11 @@ static int proc_do_submiturb(struct usb_dev_state *ps,
> struct usbdevfs_urb *uurb
> u |= URB_NO_INTERRUPT;
> as->urb->transfer_flags = u;
>
> + if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
> + dev_warn(>dev->dev, "Requested nonsensical
> USBDEVFS_URB_SHORT_NOT_OK.\n");
> + if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
> + dev_warn(>dev->dev, "Requested nonsensical
> USBDEVFS_URB_ZERO_PACKET.\n");
We should not make it trivial for userspace to spam the kernel log if at
all possible. Returning an error is probably the better thing to do
here, not just silently fix it up or ignore it.
thanks,
greg k-h
Re: Question about a patch for Worlde controller
On Wed, Sep 05, 2018 at 08:58:38AM +, Maxence Duprès wrote: > Sorry to ask you again but nothing appear in rc2 or in testing branch > for Worlde/Prodipe keyboard in drivers/usb/core/quirks.c > > USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB Sorry for the delay, it's been a rough merge window... It should be queued up later this week. greg k-h
Re: Fw: keyboard-problem on bpi-r2 since 4.17
On Tue, Sep 04, 2018 at 06:39:20AM +0200, Frank Wunderlich wrote: > > > > Hi, > > i have problems with usb-keyboard on bananapi-r2 since 4.17. same keyboard > works till 4.16. > In 4.19-rc1 same issue occours. Keyboard is recognized and on keypress it is > disconnected > and connected again without anything written to console. > > dmesg (printk-debuglevel=8) looks like this: > > [ 77.292068] usb 1-1: USB disconnect, device number 2 > [ 77.292068] usb 1-1: USB disconnect, device number 2 > [ 77.472554] evbug: Disconnected device: input0 > [ 77.472554] evbug: Disconnected device: input0 > [ 77.632390] evbug: Disconnected device: input1 > [ 77.632390] evbug: Disconnected device: input1 > [ 77.773255] evbug: Disconnected device: input2 > [ 77.773255] evbug: Disconnected device: input2 > [ 78.342590] usb 1-1: new low-speed USB device number 3 using xhci-mtk > [ 78.342590] usb 1-1: new low-speed USB device number 3 using xhci-mtk > [ 78.545576] input: USB USB Keykoard as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.0/0003:1C4F:0002.0003/input/input4 > [ 78.545576] input: USB USB Keykoard as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.0/0003:1C4F:0002.0003/input/input4 > [ 78.627589] evbug: Connected device: input4 (USB USB Keykoard at > usb-1a1c.usb-1/input0) > [ 78.636266] hid-generic 0003:1C4F:0002.0003: input,hidraw0: USB HID > v1.10 Keyboard [USB USB Keykoard] on usb-1a1c.usb-1/input0 > [ 78.627589] evbug: Connected device: input4 (USB USB Keykoard at > usb-1a1c.usb-1/input0) > [ 78.655044] input: USB USB Keykoard Consumer Control as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.1/0003:1C4F:0002.0004/input/input5 > [ 78.636266] hid-generic 0003:1C4F:0002.0003: input,hidraw0: USB HID > v1.10 Keyboard [USB USB Keykoard] on usb-1a1c.usb-1/input0 > [ 78.655044] input: USB USB Keykoard Consumer Control as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.1/0003:1C4F:0002.0004/input/input5 > [ 78.734340] evbug: Connected device: input5 (USB USB Keykoard > Consumer Control at usb-1a1c.usb-1/input1) > [ 78.746118] input: USB USB Keykoard System Control as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.1/0003:1C4F:0002.0004/input/input6 > [ 78.734340] e[ 78.760069] evbug: Connected device: input6 (USB USB > Keykoard System Control at usb-1a1c.usb-1/input1) > vbug: Connected [ 78.770893] hid-generic 0003:1C4F:0002.0004: > input,hidraw1: USB HID v1.10 Device [USB USB Keykoard] on > usb-1a1c.usb-1/inpu > t1 > device: input5 (USB USB Keykoard Consumer Control at > usb-1a1c.usb-1/input1) > [ 78.746118] input: USB USB Keykoard System Control as > /devices/platform/1a1c.usb/usb1/1-1/1-1:1.1/0003:1C4F:0002.0004/input/input6 > [ 78.760069] evbug: Connected device: input6 (USB USB Keykoard System > Control at usb-1a1c.usb-1/input1) > [ 78.770893] hid-generic 0003:1C4F:0002.0004: input,hidraw1: USB HID > v1.10 Device [USB USB Keykoard] on usb-1a1c.usb-1/input1 > > can i debug this further? > > i see that mtk_xhci-driver was rewritten to use new api > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/host/xhci-mtk.c?h=v4.17-rc1=6ae9f5062aa6f5a301c16715c601c05bc9aa450e > > maybe this is the reason, but i don't know how to debug it. i tried > disabling acpi and apic via cmdline to exclude anything acpi-related. > > maybe you have an idea... Can you use 'git bisect' to track down the offending commit? thanks, greg k-h
Re: Nothing in /sys/class/udc
On Mon, Sep 03, 2018 at 09:39:14AM +0300, Ranran wrote: > Hello, > > I try to add gadget configfs as described in: > https://www.kernel.org/doc/Documentation/usb/gadget_configfs.txt > Yet, I find nothing in /sys/class/udc: > > user@user-VirtualBox:~/tegra$ ls /sys/class/udc/ -al > total 0 > drwxr-xr-x 2 root root 0 Sep 3 00:30 . > drwxr-xr-x 58 root root 0 Sep 3 00:30 .. > > I also don't have dwc2, but dwc3: > user@user-VirtualBox:~/tegra$ lsmod | grep dw > dwc3 90112 0 > ulpi 16384 1 dwc3 > udc_core 24576 2 dwc3,libcomposite > user@user-VirtualBox:~/tegra$ > > Kernel is 4.4.50. Why do you think the dwc3 driver will work here? Do you really have this hardware being emulated? And 4.4.50 is very old, please use a modern kernel please. thanks, greg k-h
Re: A question about 'lsusb'
On Thu, Aug 30, 2018 at 05:10:53PM -0400, Alan Stern wrote: > On Thu, 30 Aug 2018, Faisal Mehmood wrote: > > > Based on my (limited) understanding if I were to disable udev, the > > userspace should not be able to enumerate/interact with any newly > > connected device since udev handles uevents generated by kernel. > > (right?) > > That's not quite right. Yes, udev does handle uevents. But a newly > connected device may be usable from userspace, to some extent, without > any handling of uevents. > > > So as a test, I disabled systemd-udevd and then plugged in a flash > > drive. I disabled support for usb mass storage in the kernel. So 'lsblk' > > didn't show the device, just as expected. However, 'lsusb' still > > dynamically updates the list as I repeatedly plugin and remove a flash > > drive. > > An example of what I described above. > > > Then I studied libusb/lsusb code for a bit. It seems that lsusb makes use > > of 'libusb_get_device_list()' to find the connected usb devices. But I > > couldn't find any detail regarding implementation of > > libusb_get_device_list. > > That's an internal aspect of libusb, so it might not be described in > the documentation. You can always check the source code if you really > want to know how it works. I think it may look at the files under > /sys/bus/usb/devices/ -- that's certainly one possibility which would > always work even without udev. > > > I am sure I'm missing something. Could someone please help me understand > > what is happening behind the scenes? > > udev does things like loading drivers into the kernel (modprobe'ing > them) and creating nodes under /dev. But a driver that is already > present in the kernel doesn't need to be modprobe'd, and the files > under /sys are created automatically by the kernel rather than by udev. Also, udev has not created /dev nodes for probably a decade now. That's what devtmpfs does. udev can create symlinks to existing dev nodes, and some "special-case" device nodes where the kernel name is not what userspace wants to use. But really, why would anyone _want_ to remove udev, it's such a nice program and solves so many problems :) thanks, greg k-h
Re: [PATCH v2 2/2] usb: typec: ucsi: add support for Cypress CCGx
On Sat, Aug 25, 2018 at 07:29:24PM +0300, Andy Shevchenko wrote: > > --- > > This email message is for the sole use of the intended recipient(s) and may > > contain > > confidential information. Any unauthorized review, use, disclosure or > > distribution > > is prohibited. If you are not the intended recipient, please contact the > > sender by > > reply email and destroy all copies of the original message. > > --- > > You have an issue here. Not an issue if you want your emails to just be deleted automatically, like I do :)
Re: Question about a patch for Worlde controller
On Mon, Aug 20, 2018 at 12:03:47PM +, Maxence Duprès wrote: > Hello, > > I found nothing about this patch on git: > > Something gone wrong with it ? No, it got caught in my system and didn't get pushed out fully, my fault. I have it in my queue again to apply once 4.19-rc1 is out and get it into 4.19-final, so all is good, no need to worry. thanks, greg k-h
Re: 4.18 regression: composite usb mouse/keyboard went mad
On Sun, Aug 19, 2018 at 01:32:47PM +0200, Harald Dunkel wrote: > Hi folks, > > since 4.18 my composite mouse/keyboard doesn't work correctly anymore. > Usually the device can switch between keyboard and (gyroscopic) mouse > mode, but with the new kernel the mouse movements seem to generate > cursor up/down events in parallel, regardless of the mode the mouse > is in. > > vendor/product id is 2389/00a8. > > > If I plugin the USB receiver, then 4.17.17 writes this into kern.log: > > Aug 19 13:12:24 porky kernel: [ 58.780112] usb 1-8: USB disconnect, device > number 5 > Aug 19 13:12:24 porky kernel: [ 59.051691] usb 1-8: new full-speed USB > device number 6 using xhci_hcd > Aug 19 13:12:24 porky kernel: [ 59.180180] usb 1-8: New USB device found, > idVendor=062a, idProduct=1a9e, bcdDevice= 1.00 > Aug 19 13:12:24 porky kernel: [ 59.180183] usb 1-8: New USB device strings: > Mfr=1, Product=2, SerialNumber=0 > Aug 19 13:12:24 porky kernel: [ 59.180184] usb 1-8: Product: RF USB > Controller > Aug 19 13:12:24 porky kernel: [ 59.180186] usb 1-8: Manufacturer: U-COMM > Aug 19 13:12:24 porky kernel: [ 59.182692] input: U-COMM RF USB Controller > as > /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/0003:062A:1A9E.0004/input/input16 > Aug 19 13:12:24 porky kernel: [ 59.234586] hid-generic 0003:062A:1A9E.0004: > input,hidraw0: USB HID v1.10 Mouse [U-COMM RF USB Controller] on > usb-:00:14.0-8/input0 > Aug 19 13:12:24 porky kernel: [ 59.236704] input: U-COMM RF USB Controller > as > /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.1/0003:062A:1A9E.0005/input/input17 > Aug 19 13:12:24 porky kernel: [ 59.288632] hid-generic 0003:062A:1A9E.0005: > input,hidraw1: USB HID v1.10 Keyboard [U-COMM RF USB Controller] on > usb-:00:14.0-8/input1 > Aug 19 13:12:24 porky kernel: [ 59.290936] input: U-COMM RF USB Controller > as > /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.2/0003:062A:1A9E.0006/input/input18 > Aug 19 13:12:24 porky kernel: [ 59.291081] hid-generic 0003:062A:1A9E.0006: > input,hidraw2: USB HID v1.10 Gamepad [U-COMM RF USB Controller] on > usb-:00:14.0-8/input2 > Aug 19 13:12:25 porky kernel: [ 59.512028] usb 1-7: new full-speed USB > device number 7 using xhci_hcd > Aug 19 13:12:25 porky kernel: [ 59.640429] usb 1-7: New USB device found, > idVendor=2389, idProduct=00a8, bcdDevice= 2.00 > Aug 19 13:12:25 porky kernel: [ 59.640432] usb 1-7: New USB device strings: > Mfr=1, Product=2, SerialNumber=0 > Aug 19 13:12:25 porky kernel: [ 59.640433] usb 1-7: Product: Usb Composite > Device > Aug 19 13:12:25 porky kernel: [ 59.640435] usb 1-7: Manufacturer: Usb > Composite Device > Aug 19 13:12:25 porky kernel: [ 59.643291] input: Usb Composite Device Usb > Composite Device as > /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:2389:00A8.0007/input/input19 > Aug 19 13:12:25 porky kernel: [ 59.694974] hid-generic 0003:2389:00A8.0007: > input,hidraw3: USB HID v2.00 Mouse [Usb Composite Device Usb Composite > Device] on usb-:00:14.0-7/input0 > Aug 19 13:12:25 porky kernel: [ 59.696099] input: Usb Composite Device Usb > Composite Device as > /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.1/0003:2389:00A8.0008/input/input20 > Aug 19 13:12:25 porky kernel: [ 59.747997] hid-generic 0003:2389:00A8.0008: > input,hidraw4: USB HID v2.00 Keyboard [Usb Composite Device Usb Composite > Device] on usb-:00:14.0-7/input1 > > > For 4.18.3 the logfile contains > > Aug 19 13:07:07 porky kernel: [ 7215.393644] usb 2-8: USB disconnect, device > number 6 > Aug 19 13:07:07 porky kernel: [ 7215.682577] usb 2-8: new full-speed USB > device number 8 using xhci_hcd > Aug 19 13:07:07 porky kernel: [ 7215.811318] usb 2-8: New USB device found, > idVendor=062a, idProduct=1a9e, bcdDevice= 1.00 > Aug 19 13:07:07 porky kernel: [ 7215.811322] usb 2-8: New USB device strings: > Mfr=1, Product=2, SerialNumber=0 > Aug 19 13:07:07 porky kernel: [ 7215.811324] usb 2-8: Product: RF USB > Controller > Aug 19 13:07:07 porky kernel: [ 7215.811326] usb 2-8: Manufacturer: U-COMM > Aug 19 13:07:07 porky kernel: [ 7215.814160] input: U-COMM RF USB Controller > as > /devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/0003:062A:1A9E.0009/input/input29 > Aug 19 13:07:07 porky kernel: [ 7215.865796] hid-generic 0003:062A:1A9E.0009: > input,hidraw0: USB HID v1.10 Mouse [U-COMM RF USB Controller] on > usb-:00:14.0-8/input0 > Aug 19 13:07:07 porky kernel: [ 7215.867996] input: U-COMM RF USB Controller > Keyboard as > /devices/pci:00/:00:14.0/usb2/2-8/2-8:1.1/0003:062A:1A9E.000A/input/input30 > Aug 19 13:07:07 porky kernel: [ 7215.919743] input: U-COMM RF USB Controller > System Control as > /devices/pci:00/:00:14.0/usb2/2-8/2-8:1.1/0003:062A:1A9E.000A/input/input31 > Aug 19 13:07:07 porky kernel: [ 7215.919861] input: U-COMM RF USB Controller > Consumer Control as >
Re: Xiaomi Mi mouse 2717:003b
On Fri, Aug 17, 2018 at 06:31:55PM +0200, Domenico Suppa wrote: > Regarding my wireless mouse > 2717:003b MI Dongle MI Wireless Mouse, > beginnig from the Kernel 4.18 the > file /dev/input/mouse* is not more > associated to the correct /dev/input/event* > file (even if it exists and works). So no > pointer's moviment is possibile, while all > three buttons work correctly. This mouse > is working perfectly (wifi and bluetooth) > with the kernel 4.16.18. I have tested it > on three machine. > Can you use 'git bisect' to try to find the offending commit? Also the linux-input mailing list might want to hear about this. thanks, greg k-h
Re: [PATCH] Driver for MaxLinear/Exar USB (UART) Serial Adapters
On Thu, Aug 16, 2018 at 01:28:54AM -0700, Patong Yang wrote: > On Thu, Aug 16, 2018 at 08:34:47AM +0200, Greg KH wrote: > > On Wed, Aug 15, 2018 at 10:56:47PM -0700, Patong Yang wrote: > > > Greg, > > > > > > Please see my response inline below. > > > > > > Patong > > > > > > > But there is a bigger problem here: > > > > > > > > > + xrusb_tty_driver = alloc_tty_driver(XRUSB_TTY_MINORS); > > > > > + if (!xrusb_tty_driver) > > > > > + return -ENOMEM; > > > > > > > > Why are you not using the usb serial core here? You need to do that, > > > > not try to provide your own custom tty driver. That way userspace > > > > programs will "just work" with your new device, no changes needed as > > > > your major/minor number and device name would be custom only for your > > > > device, which is not acceptable. > > > > > > The MaxLinear/USB serial devices support the CDC-ACM commands. > > > Therefore, we used the cdc-acm driver instead of the usb serial driver > > > as the starting point for developing the driver. We replaced "ACM" > > > with "XRUSB" throughout the driver. Would it be better if we just used > > > the same major/minor number as the CDC-ACM driver since it was based on > > > the cdc-acm driver? > > > > No, just use the cdc-acm driver itself and add your product/device id to > > it and it should work just fine. Why do you need to write a whole new > > driver at all? > > The basic TX/RX functionality works fine now with the cdc-acm driver. > That's the driver that is loaded because it's advertised as a cdc-acm > compatible device in the device descriptors. > > However, the cdc-acm driver (and spec) does not have support all of the > features in the MaxLinear/Exar USB UARTs. Hence the reason for a separate > and new driver. So your device should not be exposing itself as a cdc-acm driver if it is doing vendor-specific things, right? Ok, that's fine, but then you still need to tie into the usb-serial core, just use that and do not implement all of the duplicated tty handling logic that you have done here. You will end up with a ttyUSB* device node, which is what you, and your users want, not some custom-name that no program supports. thanks, greg k-h
Re: [PATCH] Driver for MaxLinear/Exar USB (UART) Serial Adapters
On Wed, Aug 15, 2018 at 10:56:47PM -0700, Patong Yang wrote: > Greg, > > Please see my response inline below. > > Patong > > > But there is a bigger problem here: > > > > > + xrusb_tty_driver = alloc_tty_driver(XRUSB_TTY_MINORS); > > > + if (!xrusb_tty_driver) > > > + return -ENOMEM; > > > > Why are you not using the usb serial core here? You need to do that, > > not try to provide your own custom tty driver. That way userspace > > programs will "just work" with your new device, no changes needed as > > your major/minor number and device name would be custom only for your > > device, which is not acceptable. > > The MaxLinear/USB serial devices support the CDC-ACM commands. > Therefore, we used the cdc-acm driver instead of the usb serial driver > as the starting point for developing the driver. We replaced "ACM" > with "XRUSB" throughout the driver. Would it be better if we just used > the same major/minor number as the CDC-ACM driver since it was based on > the cdc-acm driver? No, just use the cdc-acm driver itself and add your product/device id to it and it should work just fine. Why do you need to write a whole new driver at all? thanks, greg k-h
Re: Delayed "registered new interface driver snd-usb-audio"
On Tue, Aug 14, 2018 at 09:29:26AM +0300, Ran Shalit wrote:
> On Mon, Aug 13, 2018 at 9:57 PM, Greg KH wrote:
> > On Mon, Aug 13, 2018 at 09:34:37PM +0300, Ran Shalit wrote:
> >> Hello,
> >>
> >> I have a strange behabiour with sound card usb.
> >> I use kernel 3.18.11-rt7 (real-time kernel )
> >
> > Ugh, please go get support from whomever is forcing you to use such an
> > old and obsolete kernel version. You are paying them for support,
> > there's nothing that we can do about this :(
> >
> >> It takes 10 (!) seconds between detection of usb device till it is
> >> registered ("registered new interface driver snd-usb-audio") in
> >> kernel.
> >> We take the usb device out of reset using another HW.
> >>
> >> See below dmesg:
> >>
> >> [7.911220] ixgbe :01:00.1: registered PHC device on eth1
> >> [8.186213] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [8.218386] NET: Registered protocol family 10
> >> [8.691077] ixgbe :01:00.0 eth0: NIC Link is Down
> >> [9.090808] ixgbe :01:00.1 eth1: NIC Link is Down
> >> [9.893587] ixgbe :01:00.0 eth0: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [ 10.317939] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [ 38.171328] random: nonblocking pool is initialized
> >> [ 260.380461] usb 1-2: new full-speed USB device number 2 using xhci_hcd
> >> [ 260.545907] usb 1-2: config 1 has an invalid descriptor of length
> >> 0, skipping remainder of the config
> >> [ 260.546471] usb 1-2: New USB device found, idVendor=0451, idProduct=9010
> >> [ 260.546478] usb 1-2: New USB device strings: Mfr=1, Product=2,
> >> SerialNumber=3
> >> [ 260.546484] usb 1-2: Product: TI C55 Ver 6.00
> >> [ 260.546488] usb 1-2: Manufacturer: Texas Instruments
> >> [ 260.546491] usb 1-2: SerialNumber: 320001
> >> [ 260.594916] input: Texas Instruments TI C55 Ver 6.00 as
> >> /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.3/0003:0451:9010.0001/input/input3
> >> [ 260.595084] hid-generic 0003:0451:9010.0001: input,hidraw0: USB HID
> >> v1.11 Device [Texas Instruments TI C55 Ver 6.00] on
> >> usb-:00:14.0-2/input3
> >> [ 260.595153] usbcore: registered new interface driver usbhid
> >> [ 260.595157] usbhid: USB HID core driver
> >> [ 345.706843] usbcore: registered new interface driver snd-usb-audio
> >>
> >> Is there any idea what can cause this delay ?
> >
> > You are loading a new driver from somewhere, that takes time. Odds are
> > this is a userspace issue.
> >
> Thanks for the hint, which print did you refer to about the loading module ?
Your last one, that happens when the snd-usb-audio driver is loaded into
the kernel, it was not present before that. Go read up on how kernel
modules are automatically loaded when hardware is found, it's a long
kernel->userspace->kernel chain of events that happens.
> I will try to build the modules into kernel and see if it changes.
It will. But again, go bug the vendor that is forcing you to use such
an old ad obsolete kernel version for a new device please. That should
not be happening.
> We also noticed that in another kernel (and different ditribution too)
> the time is immediate, but it could be that the module was build
> inside kernel in that distribution. we also noticed that in the other
> distribution it is ehci_hcd, while in this (the slower) it is
> xhci_hcd. So that also might explain, right ?
No, the host controller driver should not matter at all.
good luck!
greg k-h
Re: patch ACS ACR122U
On Fri, Aug 10, 2018 at 07:42:07PM +, Julien F. wrote: > Hello, > > I'm running 4.15.0-30-generic (Ubuntu 18.04.1 LTS), so it shoud be ok, but i > still have the error :/ I would go file a bug with Ubuntu and tell them to upgrade their kernel :) The patch was never in any 4.15 kernel release, sorry, I recommend using a newer kernel, or a distro that uses newer kernels. good luck! greg k-h
Re: patch ACS ACR122U
On Fri, Aug 10, 2018 at 01:47:37PM +, Julien F. wrote: > Hello, > > I'm sending you this email because i found this topic > https://patchwork.kernel.org/patch/10407169/ on the error -11 when we > plug a NFC ACR122U reader, and ... that's exactly my problem ! and > nobodies on forums were able to help me ^^. So apparently you fixed > the issue ? do you now if this patch is currently embedded on the last > update of ubuntu 18 ? How can i know ? (of course i will test to plug > my device in it this evening, but what if i still have the issue ?). I have no idea what kernel version Ubuntu is using at all, sorry. The patch you are pointing at is in the following kernel versions: 4.14.50 4.16.16 4.17.2 so anything newer than those should be just fine for you to use. hope this helps greg k-h
Re: [PATCH] WORLDE Controller KS49 or Prodipe MIDI 49C USB controller
On Wed, Aug 08, 2018 at 11:56:33PM +, Maxence Duprès wrote: > WORLDE Controller KS49 or Prodipe MIDI 49C USB controller > cause a -EPROTO error, a communication restart and loop again. > > This issue has already been fixed for KS25. > https://lore.kernel.org/patchwork/patch/753077/ > > I just add device 201 for KS49 in quirks.c to get it works. > > This is the patch I propose. > > Signed-off-by: Laurent Roux > --- > drivers/usb/core/quirks.c | 1 -- > 1 file changed(-) THis was a bit corrupted, but I edited it by hand and applied it, 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
Re: Strange bug with Prodipe MIDI 49C USB
On Tue, Aug 07, 2018 at 09:05:03PM +, Maxence Duprès wrote:
> This is a proposed patch for KS49.
>
> The original patch for KS25: https://lore.kernel.org/patchwork/patch/753077/
>
> About the authorship, I don't know what it is. My real name is Roux
> Laurent.
>
>
> diff -Naur 1/drivers/usb/core/quirks.c 2/drivers/usb/core/quirks.c
> --- 1/drivers/usb/core/quirks.c 2018-08-06 16:18:22.0 +0200
> +++ 2/drivers/usb/core/quirks.c 2018-08-07 22:22:03.868499000 +0200
> @@ -182,6 +182,10 @@
> { USB_DEVICE(0x0218, 0x0401), .driver_info =
> USB_QUIRK_CONFIG_INTF_STRINGS },
>
> + /* WORLDE Controller KS49 or Prodipe MIDI 49C USB controller */
> + { USB_DEVICE(0x0218, 0x0201), .driver_info =
> + USB_QUIRK_CONFIG_INTF_STRINGS },
> +
> /* HP 5300/5370C scanner */
> { USB_DEVICE(0x03f0, 0x0701), .driver_info =
> USB_QUIRK_STRING_FETCH_255 },
>
That's a good start, but can you take a look at
Documentation/SubmittingPatches for how to do this in a way that I can
apply it? Also look at lots of other patches on the mailing lists to
get an idea of the needed format.
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
Re: Strange bug with Prodipe MIDI 49C USB
On Tue, Aug 07, 2018 at 05:50:21PM +, Maxence Duprès wrote:
>
>
> Hello,
>
> I just bought a midi keyboard Prodipe MIDI 49C USB for use within linux
> Rosegarden and LMMS.
> When I plug it in, nothing happen, no keyboard appears in software or in
> lsusb. Changing USB cable did nothing.
>
> The keyboard work fine with W7 32b and 64b and with W10 64b with
> Rosegarden and LMMS too. It is detected as "Worlde Controller KS49".
>
> In dmesg, I found that the keyboard is detected and disconnected again
> and again.
>
> I've done some tests with:
> Acer D150 Atom270 2Gb XUbuntu 32b 4.15.0-29-generic.
> Acer D150 Atom270 2Gb KXstudio 32b 3.13.0-19-lowlatency.
> Lenovo I5 3320 4Gb Xubuntu 64b 4.15.0-29-generic.
> AMD 5050e 8Gb Xubuntu 64b 4.15.0-29-generic.
>
> This is a part of dmesg:
> [ 805.156100] usb usb1-port8: Cannot enable. Maybe the USB cable is bad?
> [ 805.156122] usb usb1-port8: unable to enumerate USB device
> [ 805.468061] usb 5-2: new full-speed USB device number 72 using ohci-pci
> [ 805.669060] usb 5-2: New USB device found, idVendor=0218, idProduct=0201
> [ 805.669064] usb 5-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 805.669065] usb 5-2: Product: WORLDE Controller KS49
> [ 805.669067] usb 5-2: Manufacturer: WORLDE
> [ 805.684743] usb 5-2: USB disconnect, device number 72
> [ 806.248086] usb 5-2: new full-speed USB device number 73 using ohci-pci
> [ 806.444267] usb 5-2: New USB device found, idVendor=0218, idProduct=0201
> [ 806.444271] usb 5-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 806.444273] usb 5-2: Product: WORLDE Controller KS49
> [ 806.444274] usb 5-2: Manufacturer: WORLDE
> [ 806.459697] usb 5-2: USB disconnect, device number 73
> [ 807.080059] usb 5-2: new full-speed USB device number 74 using ohci-pci
> [ 807.279738] usb 5-2: New USB device found, idVendor=0218, idProduct=0201
> [ 807.279742] usb 5-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 807.279744] usb 5-2: Product: WORLDE Controller KS49
> [ 807.279746] usb 5-2: Manufacturer: WORLDE
> [ 807.297581] usb 5-2: USB disconnect, device number 74
> [ 807.560239] usb usb1-port8: attempt power cycle
>
> ...
>
> I just add some lines in quirks.c from Prodipe 25 but with the Prodipe
> 49 device ID.
>
> file: /drivers/usb/core/quirks.c line 185
>
> /* WORLDE easy key (easykey.49) MIDI controller */
> { USB_DEVICE(0x0218, 0x0201), .driver_info =
> USB_QUIRK_CONFIG_INTF_STRINGS },
>
> It work well now. Test with Kernel 4.17.13 and 4.15
>
> Possible to add this in kernel sources ?
Sure, care to make up a patch for this so that we can properly credit
you with the authorship of it?
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
Re: wrong device idProduct?
On Mon, Aug 06, 2018 at 11:31:11AM -0700, Nick Desaulniers wrote: > On Mon, Aug 6, 2018 at 11:27 AM Alan Stern wrote: > > > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern > > > wrote: > > > > > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > > > > > Hello, > > > > > Today my usb keyboard stopped working: > > > > > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > > > endpoint > > > > > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > > > Ultimate 4C), from the working one: > > > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > > > idProduct=0142 > > > > > and the broken one: > > > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > > > idProduct= > > > > > > > > > > This causes the product to be misidentified. Is something wrong with > > > > > the keyboard that's causing it to misreport the idProduct? > > > > > > > > Probably it lost some of its firmware. > > > > > > Is it possible to ask Linux to remount this device with a new idProduct? > > > > It's not possible to change the idProduct value. > > > > It is possible to try to use the keyboard in spite of the wrong > > idProduct. In fact, that's what your computer tried to do. But it > > didn't work, as you can see from the "couldn't find an input interrupt > > endpoint" error message in the log > > There's nothing for handling quirks? Surely not all devices are so > well behaved. Worst case I guess I could modify whatever maps > idProducts to drivers in *my* kernel and use that? No, your firmware is really broken and it is not responding with a full USB descriptor, it is messed up, there's nothing that any operating system can do about it, sorry. 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
Re: ] Sandisk Ultra Fit USB 3.0 thumb drive overheating way more than same USB does in Windows
On Fri, Aug 03, 2018 at 04:15:22PM +0100, Mustafa A wrote: > The drive (128GB USB 3.0) > https://www.sandisk.co.uk/home/usb-flash/ultra-fit-usb overheats to > the point where the metal part would burn someone if they held it for > more than a second. > > The overheating only happens on this brand of USB drives, other USB > 3.0 drives have been fine. > The overheating only happens with Linux 4.15.0-29 (the default Kubuntu > 18.04 kernel), it's fine when transferring files in Windows (tried > with 8.1). > The overheating happens even when files aren't transferring, even when > the drive is idle. > > The other hardware used is a HP g6-2205sa laptop (Intel i3-3110M CPU) I have seen this with some devices before, they just have bad thermal properties. Make sure the device is actually going to sleep when idle, use powertop to make it happen, that seems to work for me and is probably what Windows does. Otherwise, no, there's nothing that Linux can do here, as a test, try to plug the device into a system like a BIOS/UEFI that does not do any power management and watch it also heat up. I recommend getting a new device, that's what I did :) 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
Re: [PATCH v4 00/22] usb: usbtmc: Changes needed for compatible IVI/VISA library
On Mon, Jul 30, 2018 at 10:04:30AM +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 implementations on other operating systems. > > The USBTMC protocol is part of the "VISA Library" that is used by many > popular T applications. > > Initial implementations for Linux based on libusb has been created. > However using one common USBTMC driver results in more benefits: > > - Multiple applications can share access to the same instruments. > - The driver handles SRQ conflicts. > - Simplifies definition of udev rules for USBTMC devices. > - Simplifies development of applications using T instruments. > > The following collaborative patches meet the requirements of the IVI > Foundation to implement the library based on the usbtmc driver. > > Improvements in the data transfer rate of over 130 MByte/s for > usb 3.x connections have been measured. > > Guido Kiener, Dave Penkler, Steve Bayless (22): > usb: usbtmc: Add ioctl for generic requests on control > usb: usbtmc: Add ioctl for vendor specific write > usb: usbtmc: Add ioctl USBTMC_IOCTL_WRITE_RESULT > usb: usbtmc: Add ioctl for vendor specific read > usb: usbtmc: Add ioctl USBTMC_IOCTL_CANCEL_IO > usb: usbtmc: Add ioctl USBTMC_IOCTL_CLEANUP_IO > usb: usbtmc: Fix suspend/resume > usb: usbtmc: Add ioctl USBTMC488_IOCTL_WAIT_SRQ > usb: usbtmc: add ioctl USBTMC_IOCTL_MSG_IN_ATTR > usb: usbtmc: Add ioctl USBTMC_IOCTL_AUTO_ABORT > usb: usbtmc: Optimize usbtmc_write > usb: usbtmc: Optimize usbtmc_read > usb: usbtmc: Fix ioctl USBTMC_IOCTL_CLEAR > usb: usbtmc: Fix ioctl USBTMC_IOCTL_ABORT_BULK_IN > usb: usbtmc: Fix ioctl USBTMC_IOCTL_ABORT_BULK_OUT > usb: usbtmc: Replace USBTMC_TIMEOUT macros for control messages > usb: usbtmc: Add ioctl USBTMC_IOCTL_API_VERSION > usb: usbtmc: Update ioctl-number.txt > usb: usbtmc: Remove redundant code > usb: usbtmc: Remove redundant macro USBTMC_SIZE_IOBUFFER > usb: usbtmc: Fix split quoted string in debug message > usb: usbtmc: Remove sysfs group TermChar and auto_abort > > .../ABI/stable/sysfs-driver-usb-usbtmc| 35 - > Documentation/ioctl/ioctl-number.txt |2 +- > drivers/usb/class/usbtmc.c| 1652 + > include/uapi/linux/usb/tmc.h | 41 + > 4 files changed, 1291 insertions(+), 439 deletions(-) What changed from v3 of this patch set? That needs to be listed somewhere, right? 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
Re: [PATCH] Driver for MaxLinear/Exar USB (UART) Serial Adapters
On Tue, Jul 24, 2018 at 03:36:36PM -0700, Patong Yang wrote: > The original driver/patch was submitted on April 4, 2018. This is the > second version based on the feedback received on the original patch. > > v2: Removed custom IOCTLs, as suggested by Greg KH > Using standard Linux GPIO APIs, as suggested by Greg KH > Removed file reads/writes as suggested by Greg KH > > Signed-off-by: Patong Yang > --- > drivers/usb/serial/xrusb_serial.c | 2380 + > drivers/usb/serial/xrusb_serial.h | 234 +++ Why do you need a .h file for a single driver? Please just put it all into one file. But there is a bigger problem here: > + xrusb_tty_driver = alloc_tty_driver(XRUSB_TTY_MINORS); > + if (!xrusb_tty_driver) > + return -ENOMEM; Why are you not using the usb serial core here? You need to do that, not try to provide your own custom tty driver. That way userspace programs will "just work" with your new device, no changes needed as your major/minor number and device name would be custom only for your device, which is not acceptable. By doing that, your code will also be much smaller, always a good benefit as well. 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
Re: [PATCH v3 02/23] usb: usbtmc: Add ioctl for generic requests on control
On Tue, Jul 24, 2018 at 11:05:29AM +0200, Guido Kiener wrote:
> +struct usbtmc_ctrlrequest {
> + struct usbtmc_request req;
> + __u64 data; /* pointer to user space */
> +} __attribute__ ((packed));
Hint, this structure could just be:
struct usbtmc_ctrlreqest {
struct usbtmc_request req;
__u8 data[0];
} __attribute__((__aligned__(8)));
No more pointer mess anymore, right?
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
Re: [PATCH v3 02/23] usb: usbtmc: Add ioctl for generic requests on control
On Tue, Jul 24, 2018 at 11:05:29AM +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.
>
> The maximum length of control request is set to 4k.
>
> Signed-off-by: Guido Kiener
> Reviewed-by: Steve Bayless
> ---
> drivers/usb/class/usbtmc.c | 84
> include/uapi/linux/usb/tmc.h | 15 +++
> 2 files changed, 99 insertions(+)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 83ffa5a14c3d..3b3b4284d04e 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2007 Stefan Kopp, Gechingen, Germany
> * Copyright (C) 2008 Novell, Inc.
> * Copyright (C) 2008 Greg Kroah-Hartman
> + * Copyright (C) 2018 IVI Foundation, Inc.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -36,6 +37,9 @@
> /* Default USB timeout (in milliseconds) */
> #define USBTMC_TIMEOUT 5000
>
> +/* I/O buffer size used in generic read/write functions */
> +#define USBTMC_BUFSIZE (4096)
> +
> /*
> * Maximum number of read cycles to empty bulk in endpoint during CLEAR and
> * ABORT_BULK_IN requests. Ends the loop if (for whatever reason) a short
> @@ -129,6 +133,21 @@ struct usbtmc_file_data {
> /* Forward declarations */
> static struct usb_driver usbtmc_driver;
>
> +#ifdef CONFIG_COMPAT
> +static void __user *u64_to_uptr(u64 value)
> +{
> + if (in_compat_syscall())
> + return compat_ptr(value);
> + else
> + return (void __user *)(unsigned long)value;
> +}
> +#else
> +static inline void __user *u64_to_uptr(u64 value)
> +{
> + return (void __user *)(unsigned long)value;
> +}
> +#endif /* CONFIG_COMPAT */
For Linux, if there are functions/operations that are always needed by
all drivers (or even some), then those functions are provided in the
core kernel with header files or in the library. So if you are writing
a single driver, and find you need to create something that looks very
"generic", either you are doing something that no other driver has ever
needed before in the history of Linux, or you are doing something wrong.
Which do you think it is here? :)
Please fix this up and do it properly. Your driver should only have 1
#ifdef CONFIG_COMPAT line, and that was in patch 1 for this series.
Nothing else should be needed if you create your structures correctly.
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
Re: [PATCH v2 08/29] usb: usbtmc: Add ioctl for generic requests on control
On Sat, Jul 21, 2018 at 11:11:55AM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg KH :
>
> > On Wed, Jul 18, 2018 at 10:45:41AM +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.
> > >
> > > The maximum length of control request is set to 4k.
> > >
> > > Signed-off-by: Guido Kiener
> > > Reviewed-by: Steve Bayless
> > > ---
> > > drivers/usb/class/usbtmc.c | 151 +++
> > > include/uapi/linux/usb/tmc.h | 15
> > > 2 files changed, 166 insertions(+)
> > >
> > > diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> > > index d685db78b80b..846599dd0c84 100644
> > > --- a/drivers/usb/class/usbtmc.c
> > > +++ b/drivers/usb/class/usbtmc.c
> > > @@ -5,6 +5,7 @@
> > > * Copyright (C) 2007 Stefan Kopp, Gechingen, Germany
> > > * Copyright (C) 2008 Novell, Inc.
> > > * Copyright (C) 2008 Greg Kroah-Hartman
> > > + * Copyright (C) 2018 IVI Foundation, Inc.
> > > */
> > >
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > @@ -36,6 +37,9 @@
> > > /* Default USB timeout (in milliseconds) */
> > > #define USBTMC_TIMEOUT 5000
> > >
> > > +/* I/O buffer size used in generic read/write functions */
> > > +#define USBTMC_BUFSIZE (4096)
> > > +
> > > /*
> > > * Maximum number of read cycles to empty bulk in endpoint during CLEAR
> > > and
> > > * ABORT_BULK_IN requests. Ends the loop if (for whatever reason) a short
> > > @@ -126,6 +130,17 @@ struct usbtmc_file_data {
> > > bool term_char_enabled;
> > > };
> > >
> > > +#ifdef CONFIG_COMPAT
> > > +
> > > +struct compat_usbtmc_ctrlrequest {
> > > + struct usbtmc_request req;
> > > + compat_uptr_t data;
> > > +} __packed;
> >
> > Wait, why? You are creating a new api here, why do you need a 32bit
> > compat layer? Just create it in a way that works for both layouts.
> > Just make your pointer a 64bit value and cast it to the pointer when
> > using it. Other ioctls do this in lots of places, making things simpler
> > overall. That way you don't need an ioctl compat call at all.
> >
> > Please rework the code that way, don't create new apis that have to add
> > "old" 32bit compatibility support to them. That's just extra work you
> > don't need to do here.
> >
> > thanks,
> >
> > greg k-h
>
> Maybe I'm still missing something. You wanted us that the driver supports
> 32 bit applications on 64 bit systems. Therefore we added the patch
> [PATCH v2 07/29] usb: usbtmc: Add support for 32 bit compat applications
> I do not know any other way to make ioctl functions working for
> 32 bit application, except adding the line .compat_ioctl =
> usbtmc_compat_ioctl.
> Please note that all other ioctl calls like USBTMC_IOCTL_CLEAR etc. do not
> work for 32 applications as well when we omit patch 07.
>
> Please let us first agree on patch 07 and then we can continue to discuss
> patch 08.
"patch 07" was about 300 patches ago in the number of patches I have
reviewed today, sorry, I don't reallhy remember what it looked like but
I think it was something like adding a custom compat_ioctl handler,
right?
If so, no, that's not correct, your compat_ioctl function should be the
same as your "normal" ioctl function. You do not need a separate
function for 32 vs. 64 bits if you do everything correctly.
So yes, you are right, 32bit applications will not work until you set
compat_ioctl, but just be sure to set it to the correct thing.
So feel free to resend this type of change, but just do not make any
special ioctl handlers for 32bits. If you do that, you have not
designed your ioctls correctly.
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
Re: [PATCH v2 09/29] usb: usbtmc: Add ioctl for vendor specific write
On Wed, Jul 18, 2018 at 10:45:42AM +0200, Guido Kiener wrote:
> The new ioctl USBTMC_IOCTL_WRITE sends a generic message to bulk OUT.
> This ioctl is used for vendor specific or asynchronous I/O as well.
>
> 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 and
> out_status/out_transfer_size is not reset. EPOLLOUT | EPOLLWRNORM
> is signaled when all submitted urbs are completed.
>
> Flush flying urbs when file handle is closed or device is
> suspended or reset.
>
> Signed-off-by: Guido Kiener
> Reviewed-by: Steve Bayless
> ---
> drivers/usb/class/usbtmc.c | 416 ++-
> include/uapi/linux/usb/tmc.h | 14 ++
> 2 files changed, 428 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 846599dd0c84..c46280f53f39 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -37,6 +37,8 @@
> /* Default USB timeout (in milliseconds) */
> #define USBTMC_TIMEOUT 5000
>
> +/* Max number of urbs used in write transfers */
> +#define MAX_URBS_IN_FLIGHT 16
> /* I/O buffer size used in generic read/write functions */
> #define USBTMC_BUFSIZE (4096)
>
> @@ -125,9 +127,19 @@ struct usbtmc_file_data {
> u32timeout;
> u8 srq_byte;
> atomic_t srq_asserted;
> +
> u8 eom_val;
> u8 term_char;
> bool term_char_enabled;
> +
> + spinlock_t err_lock; /* lock for errors */
> +
> + struct usb_anchor submitted;
> +
> + /* data for generic_write */
> + struct semaphore limit_write_sem;
> + u32 out_transfer_size;
> + int out_status;
> };
>
> #ifdef CONFIG_COMPAT
> @@ -137,12 +149,21 @@ struct compat_usbtmc_ctrlrequest {
> compat_uptr_t data;
> } __packed;
>
> +struct compat_usbtmc_message {
> + __u32 transfer_size;
> + __u32 transferred;
> + __u32 flags;
> + compat_uptr_t message;
> +} __packed;
Same here, no need for this at all.
I've stopped reviewing in the series here. I've applied the first 6
patches in the series, please rework the remaining ones to not have any
compatibility ioctls needed and resend. Or you can restructure what you
already have and resend everything without the new ioctls so I can
review/take them if you need more time to redo the ioctls stuff.
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
Re: [PATCH v2 08/29] usb: usbtmc: Add ioctl for generic requests on control
On Wed, Jul 18, 2018 at 10:45:41AM +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.
>
> The maximum length of control request is set to 4k.
>
> Signed-off-by: Guido Kiener
> Reviewed-by: Steve Bayless
> ---
> drivers/usb/class/usbtmc.c | 151 +++
> include/uapi/linux/usb/tmc.h | 15
> 2 files changed, 166 insertions(+)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index d685db78b80b..846599dd0c84 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2007 Stefan Kopp, Gechingen, Germany
> * Copyright (C) 2008 Novell, Inc.
> * Copyright (C) 2008 Greg Kroah-Hartman
> + * Copyright (C) 2018 IVI Foundation, Inc.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -36,6 +37,9 @@
> /* Default USB timeout (in milliseconds) */
> #define USBTMC_TIMEOUT 5000
>
> +/* I/O buffer size used in generic read/write functions */
> +#define USBTMC_BUFSIZE (4096)
> +
> /*
> * Maximum number of read cycles to empty bulk in endpoint during CLEAR and
> * ABORT_BULK_IN requests. Ends the loop if (for whatever reason) a short
> @@ -126,6 +130,17 @@ struct usbtmc_file_data {
> bool term_char_enabled;
> };
>
> +#ifdef CONFIG_COMPAT
> +
> +struct compat_usbtmc_ctrlrequest {
> + struct usbtmc_request req;
> + compat_uptr_t data;
> +} __packed;
Wait, why? You are creating a new api here, why do you need a 32bit
compat layer? Just create it in a way that works for both layouts.
Just make your pointer a 64bit value and cast it to the pointer when
using it. Other ioctls do this in lots of places, making things simpler
overall. That way you don't need an ioctl compat call at all.
Please rework the code that way, don't create new apis that have to add
"old" 32bit compatibility support to them. That's just extra work you
don't need to do here.
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
Re: [PATCH v2 03/29] usb: usbtmc: Add ioctls to set/get usb timeout
On Wed, Jul 18, 2018 at 10:45:36AM +0200, Guido Kiener wrote:
> +/*
> + * Set the usb timeout value
> + */
> +static int usbtmc_ioctl_set_timeout(struct usbtmc_file_data *file_data,
> + void __user *arg)
> +{
> + u32 timeout;
> +
> + if (get_user(timeout, (__u32 __user *)arg))
> + return -EFAULT;
> +
> + /* Note that timeout = 0 means
> + * MAX_SCHEDULE_TIMEOUT in usb_control_msg
> + */
> + if (timeout < USBTMC_MIN_TIMEOUT)
> + return -EINVAL;
No max timeout limit? That feels odd, but ok, it's your api, you might
be waiting a long time :)
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
Re: [PATCH v2 01/29] usb: usbtmc: Support Read Status Byte with SRQ per file
On Wed, Jul 18, 2018 at 10:45:34AM +0200, Guido Kiener wrote: > } > - dev_warn(dev, "invalid notification: %x\n", > data->iin_buffer[0]); > + dev_warn(dev, "invalid notification: %x\n", > + data->iin_buffer[0]); > break; > case -EOVERFLOW: > dev_err(dev, "overflow with length %d, actual length is %d\n", > @@ -1295,6 +1369,7 @@ static void usbtmc_interrupt(struct urb *urb) > case -ESHUTDOWN: > case -EILSEQ: > case -ETIME: > + case -EPIPE: > /* urb terminated, clean up */ > dev_dbg(dev, "urb terminated, status: %d\n", status); > return; Minor nit, these two changes didn't have anything to do with the larger patch. I'll let them slide for now, but please be more careful in the future. 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
Re: [PATCH 2/2] USB: iuu_phoenix: drop redundant input-speed re-encoding
On Mon, Jul 16, 2018 at 01:51:56PM +0200, Johan Hovold wrote: > Drop redundant input-speed re-encoding at every open(). The output and > input speeds are initialised to the same value and are kept in sync on > termios updates. > > Signed-off-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman -- 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 1/2] USB: serial: iuu_phoenix: drop unused driver-data baud rate
On Mon, Jul 16, 2018 at 01:51:55PM +0200, Johan Hovold wrote: > Drop unused driver-data baud rate. > > Signed-off-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman -- 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: quirks: add delay quirks for Corsair Strafe
On Wed, Jul 04, 2018 at 03:14:17PM +0300, Nico Sneck wrote: > CC Greg in hopes of having someone take a look at this patch before > Monday (when my military service starts). It's in my queue, will probably get to it next week. At first glance looks fine. Good luck on your service! 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
Re: [PATCH 0/1] xhci fix for usb-linus
On Mon, Jul 02, 2018 at 04:14:10PM +0300, Mathias Nyman wrote: > Hi Greg > > A small fix for usb-linus making sure runtime PM get/put is balanced > > -Mathias > > Kai-Heng Feng (1): > usb: xhci: dbc: Don't decrement runtime PM counter if DBC is not > started > > drivers/usb/host/xhci-dbgcap.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > -- > 2.7.4 I seem to not have received the actual patch 1/1 here, did it get lost somewhere? confused, 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
Re: [PATCH 1/2 ] cdc_ncm: Handle multicast Ethernet traffic
On Fri, Jun 29, 2018 at 04:47:28PM +0200, Miguel Rodríguez Pérez wrote: > Some CDC_NCM devices are used as docks for laptops. In this case, it > makes sense to accept multicast Ethernet traffic, as these devices > can reside in a proper LAN. Without this, mDNS or IPv6 simply do not > work. > > Signed-off-by: Miguel Rodríguez Pérez > --- > drivers/net/usb/cdc_ncm.c | 28 > 1 file changed, 28 insertions(+) This had the same subject as the previous patch, which is not correct. Also, please use scripts/get_maintainer.pl to determine what lists to send this to, you need to add the netdev list for it to be picked up properly. 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
Re: [PATCH v8 00/14] staging: typec: tcpci: move out of staging
On Wed, Jun 27, 2018 at 07:45:18AM +0800, Li Jun wrote: > This patch set attempts to move the tcpci drivers out of staging by fix > some tcpci driver issues and define typec and power delivery device > properties, the changes are verified on NXP PTN5110, which is a standard > tcpci typec port controller device with power delivery support, tested > power source and sink with drp config. Nice work, thanks for sticking with this. All now merged. 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
Re: [PATCH 3/3] Fixed simple typo from ELCOM to ELECOM.
On Tue, Jun 26, 2018 at 07:07:59PM -0500, Guy Chronister wrote: > Signed-off-by: Guy Chronister I know I don't take patches with no change log at all, but other maintainers might be nicer :) 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
Re: usb/serial - pl2303 module - buffer overflow
On Sun, Jun 24, 2018 at 05:40:37PM +0200, Matthias Dieter Wallnöfer wrote: > Hi people, > > as I am working with a PL2303-based USB-to-serial converter I discovered > that the SW-based flow control was unsupported for all kernels till the > upcoming 4.18 release. Thanks to the patch by Florian Zumbiehl this > deficit was finally resolved and also my tests showed that now the flow > characters get finally sent as one would expect it. > > According to my tests the HW (RTS/CTD) and SW flow control is now > working correctly in the direction *inbound* to USB. Unfortunately I am > less convinced that it does so also the other way around. > > Let me explain why: as the datasheets available on the web state, the > chip is equipped with both internal receive and send buffers. Consider > enabling the HW or SW flow control and filling up both the PL2303's > internal and the device's target recv buffer, for example with a string > of 12'000 characters (in my case it was a PC connected with a nullmodem > link). > > First, the target device's buffer fills up which is fine. When the > buffer's high watermark is reached, the Prolific chip gets informed that > it should not send anymore. This means that now fresh chars arriving > from the USB host end up in the internal send buffer which grows and > grows. Filled up also this one I am not aware of any mechanism which > informs the host to stop doing so, that in the end data gets lost. I think that is because this device does not have any way to do so. When USB to serial devices first came out, a number of devices did have this type of capability, and it was complex. The devices that did this also were "rock solid" but unfortunatly did not sell all that well, and over the decades we ended up with the dirt-cheap devices we have today without the full capabilities of old-style UARTS because it was "good enough". If you really worry about this type of problem, I suggest you get one of those other types of devices (io-edgeport is one example, I think there are others). Last time I looked at the data sheet of the pl2303 device, I do not think it had this type of funcationality at all. Also note that there are different types of this device, as well as "cheap clones" which _almost_ work the same, but not always for some of the "odd" features, like flow control :) Sorry, and good luck! 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
Re: no exposure setting on webcams using uvcvideo
On Sun, Jun 24, 2018 at 05:23:26PM +0400, safocl wrote: > By the way, with the patch > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=0dc68cabdb626e33d02561529e6a4c681b72a784 > everything is fine with the allocated memory for data in 1 byte. > so I think the bug is resolved, it remains only to wait for inclusion in the > ready stable branch That patch just got queued up for the 4.17.y release, so all should be good now, right? 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
Re: [PATCH v3] storage: Widen bcdDevice range for SanDisk SDDR-31 quirk
On Sun, Jun 10, 2018 at 08:54:09PM +0200, Mark Knibbs wrote: > When I re-sent the patch with tabs I accidentally left the new maximum > bcdDevice at 0x00ff. Sorry! Hopefully this is finally OK. This should not be in the change log text, please remove it. > > > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that > was only applied for bcdDevice 0x0009, but later firmware which reports > bcdDevice 0x0022 needs it too. > > Signed-off-by: Mark Knibbs > --- > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index 747d3a9..dfcceaf 100644 Below the --- line you should put what changed for each version of the patch, so we have an idea of what to look for when reviewing it. > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -1044,7 +1044,7 @@ UNUSUAL_DEV( 0x0781, 0x0001, 0x0200, 0x0200, > USB_SC_SCSI, USB_PR_CB, NULL, > US_FL_SINGLE_LUN ), Tabs all worked fine here. 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
Re: [PATCH v2] storage: Widen bcdDevice range for SanDisk SDDR-31 quirk
On Thu, Jun 07, 2018 at 09:54:45PM +0200, Mark Knibbs wrote: > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that > was only applied for bcdDevice 0x0009, but later firmware which reports > bcdDevice 0x0022 needs it too. > > Signed-off-by: Mark Knibbs > --- > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index 747d3a9..dfcceaf 100644 > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -1044,7 +1044,7 @@ UNUSUAL_DEV( 0x0781, 0x0001, 0x0200, 0x0200, > USB_SC_SCSI, USB_PR_CB, NULL, > US_FL_SINGLE_LUN ), > > -UNUSUAL_DEV( 0x0781, 0x0002, 0x0009, 0x0009, > +UNUSUAL_DEV( 0x0781, 0x0002, 0x, 0x0022, > "SanDisk Corporation", > "ImageMate CompactFlash USB", > USB_SC_DEVICE, USB_PR_DEVICE, NULL, The tabs all got converted to spaces so this patch can not be applied :( Please fix up and resend. 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
Re: add toshiba dtb305 to unusual_devs.h
On Sun, Jun 03, 2018 at 01:31:38AM +0800, Druggo Yang wrote: > --- a/drivers/usb/storage/unusual_devs.h2018-04-02 05:20:27.0 > +0800 > +++ b/drivers/usb/storage/unusual_devs.h2018-06-02 19:08:38.002689059 > +0800 > @@ -319,6 +319,13 @@ > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_NO_WP_DETECT), > > +/* Add by Druggo Yang */ > +UNUSUAL_DEV( 0x0480, 0xa001, 0x0100, 0x, > +"Toshiba", > +"DTB305", > +USB_SC_DEVICE, USB_PR_DEVICE, NULL, > +US_FL_ALWAYS_SYNC), > + > /* Reported by Egbert Eich */ > UNUSUAL_DEV( 0x0480, 0xd010, 0x0100, 0x, > "Toshiba", > > > > T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=04 Dev#= 6 Spd=480 MxCh= 0 > D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=0480 ProdID=a001 Rev= 1.14 > S: Manufacturer=USB device > S: Product=USB device > S: SerialNumber=WQ6709252 > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 30mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch is malformed (tabs converted to spaces, linewrapped, etc.) and can not be applied. Please read the file, Documentation/email-clients.txt in order to fix this. - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot -- 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 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue
On Fri, Jun 01, 2018 at 01:14:22PM +0300, Mathias Nyman wrote: > On 01.06.2018 11:23, Greg KH wrote: > > On Wed, May 23, 2018 at 06:41:35PM +0100, Marc Zyngier wrote: > > > 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 was observed on a fairly popular arm64 > > > platform (AMD Opteron 1100, which has all of its memory above 4GB). > > > > > > The fix was to perform a PCI reset of the device, but we have had > > > multiple reports that this generated regressions (the controller not > > > being usable after the patch was applied). > > > > > > This series reverts the problematic patch, and tries to address it in > > > a more constrained way. If the controller is behind an IOMMU (and only > > > in that case), we zero its base addresses before reseting it. In the > > > affected configuration, this has the effect of putting the device in a > > > state where the XHCI reset will be effective. > > > > > > It must be noted that in the absence of an IOMMU (and maybe even in > > > its presence), this device is completely unsafe, and may silently > > > corrupt memory. > > > > Mathias, any objections for me queueing these up now for 4.18-rc1? > > > > Nope, 4.18-rc1 is fine for me. > Didn't want to bother you with anything this late in the cycle. > The following patch is also ready for 4.18-rc1: > "[PATCH v2] usb: xhci: force all memory allocations to node" > https://marc.info/?l=linux-usb=152701535103950=2 > > Feel free to pick it as well. If not then I'll re-send it after 4.18-rc1 > > For both the Renesas series, and memory allocation to node patch: > > Acked-by: Mathias Nyman Great, will go queue them up now, 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
Re: [PATCH v3 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue
On Wed, May 23, 2018 at 06:41:35PM +0100, Marc Zyngier wrote: > 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 was observed on a fairly popular arm64 > platform (AMD Opteron 1100, which has all of its memory above 4GB). > > The fix was to perform a PCI reset of the device, but we have had > multiple reports that this generated regressions (the controller not > being usable after the patch was applied). > > This series reverts the problematic patch, and tries to address it in > a more constrained way. If the controller is behind an IOMMU (and only > in that case), we zero its base addresses before reseting it. In the > affected configuration, this has the effect of putting the device in a > state where the XHCI reset will be effective. > > It must be noted that in the absence of an IOMMU (and maybe even in > its presence), this device is completely unsafe, and may silently > corrupt memory. Mathias, any objections for me queueing these up now for 4.18-rc1? 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
Re: [PATCH] ftdi_sio: add Id for Physik Instrumente E-870
On Thu, May 31, 2018 at 01:24:52PM +0200, Johan Hovold wrote:
> On Thu, May 31, 2018 at 12:39:41PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Mar 29, 2018 at 08:39:37AM +0200, Teichmann, Martin wrote:
> > > This adds support for the Physik Instrumente E-870 PIShift Drive
> > > Electronics, a Piezo motor driver.
> > >
> > > Signed-off-by: Martin Teichmann
> > > ---
> > > drivers/usb/serial/ftdi_sio.c | 1 +
> > > drivers/usb/serial/ftdi_sio_ids.h | 1 +
> > > 2 files changed, 2 insertions(+)
> >
> > Johan, want me to pick this one up? I think you missed it in your last
> > pull request.
>
> No, this one was actually already applied and later reverted when it
> turned out it was not really an ftdi device at all:
>
> 5267c5e09c25 ("Revert "USB: serial: ftdi_sio: add Id for Physik
> Instrumente E-870"")
Ah, oops, missed that. dropping this from my queue now, 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
Re: [PATCH] ftdi_sio: add Id for Physik Instrumente E-870
On Thu, Mar 29, 2018 at 08:39:37AM +0200, Teichmann, Martin wrote: > This adds support for the Physik Instrumente E-870 PIShift Drive > Electronics, a Piezo motor driver. > > Signed-off-by: Martin Teichmann > --- > drivers/usb/serial/ftdi_sio.c | 1 + > drivers/usb/serial/ftdi_sio_ids.h | 1 + > 2 files changed, 2 insertions(+) Johan, want me to pick this one up? I think you missed it in your last pull request. 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
Re: 4.16 issue with mbim modem and ping with size > 14552 bytes
On Mon, May 28, 2018 at 09:58:01AM +0200, Daniele Palmas wrote: > 2018-05-25 0:54 GMT+02:00 Daniele Palmas <dnl...@gmail.com>: > > Hi Greg, > > > > 2018-05-24 17:53 GMT+02:00 Greg KH <gre...@linuxfoundation.org>: > >> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote: > >>> Hello, > >>> > >>> I have an issue with an USB mbim modem when trying to send with ping > >>> more than 14552 bytes: it looks like to me a kernel issue, but not at > >>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the > >>> issue. > >>> > >>> My kernel is 4.16. The device is the following: > >> > >> Does older kernels work, or is this something that has always been > >> there? > >> > > > > Not tested yet, I'm going to do. > > > > So, ping with more than 14552 was working properly until v4.5-rc7: > starting from v4.5 I'm not even able to make a data connection with > mbim since things fail badly with the following: > > [ 259.551836] [ cut here ] > [ 259.551848] WARNING: CPU: 2 PID: 0 at > /home/kernel/COD/linux/net/sched/sch_generic.c:303 > dev_watchdog+0x237/0x240() > [ 259.551860] NETDEV WATCHDOG: wwp0s20u7i2 (cdc_mbim): transmit queue > 0 timed out > [ 259.551861] Modules linked in: cdc_mbim cdc_wdm cdc_ncm usbnet mii > intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm > snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic > irqbypass crct10dif_pclmul snd_hda_intel snd_hda_codec snd_hda_core > crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64 > snd_pcm snd_seq_midi lrw snd_seq_midi_event gf128mul input_leds > snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer > cryptd snd soundcore shpchp serio_raw mac_hid lpc_ich 8250_fintek > mei_me mei parport_pc ppdev lp parport autofs4 hid_generic usbhid hid > i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse > sysimgblt ahci fb_sys_fops e1000e libahci drm ptp pps_core wmi fjes > video > [ 259.551889] CPU: 2 PID: 0 Comm: swapper/2 Not tainted > 4.5.0-040500-generic #201603140130 > [ 259.551890] Hardware name: LENOVO 10A6A0J5IX/SHARKBAY, BIOS > FBKT79AUS 04/17/2014 > [ 259.551891] 0286 108c91d75cf5b65f 88021eb03d98 > 813e0233 > [ 259.551893] 88021eb03de0 81d816a0 88021eb03dd0 > 81080e72 > [ 259.551894] 8800cee81880 0002 > 8800a19f8000 > [ 259.551895] Call Trace: > [ 259.551896][] dump_stack+0x63/0x90 > [ 259.551903] [] warn_slowpath_common+0x82/0xc0 > [ 259.551904] [] warn_slowpath_fmt+0x5c/0x80 > [ 259.551907] [] dev_watchdog+0x237/0x240 > [ 259.551909] [] ? qdisc_rcu_free+0x40/0x40 > [ 259.551910] [] call_timer_fn+0x35/0x120 > [ 259.551911] [] ? qdisc_rcu_free+0x40/0x40 > [ 259.551912] [] run_timer_softirq+0x246/0x2f0 > [ 259.551914] [] __do_softirq+0xf6/0x280 > [ 259.551916] [] irq_exit+0xa3/0xb0 > [ 259.551919] [] smp_apic_timer_interrupt+0x42/0x50 > [ 259.551920] [] apic_timer_interrupt+0x82/0x90 > [ 259.551922][] ? cpuidle_enter_state+0x11d/0x2c0 > [ 259.551925] [] cpuidle_enter+0x17/0x20 > [ 259.551928] [] call_cpuidle+0x2a/0x40 > [ 259.551929] [] cpu_startup_entry+0x295/0x350 > [ 259.551931] [] start_secondary+0x15e/0x190 > [ 259.551933] ---[ end trace 6f8d3c1a1b02644d ]--- > > but this is probably something different, cause with v4.16 data > connection works fine. > > If this is not helpful I guess I need to bisect. Bisection would be best. It looks like you narrowed things down really well already, bisection should go very quickly. 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
Re: 4.16 issue with mbim modem and ping with size > 14552 bytes
On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote: > Hello, > > I have an issue with an USB mbim modem when trying to send with ping > more than 14552 bytes: it looks like to me a kernel issue, but not at > the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the > issue. > > My kernel is 4.16. The device is the following: Does older kernels work, or is this something that has always been there? I ask, as my mobile provider does horrible things to large packet sizes. So much so that I have to set the mtu to 1280 just to get things to work properly when tethering my phone through to my laptop. So this might be a network provider issue :) 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
Re: [PATCH 07/12] usb: usbtmc: Add ioctl USBTMC488_IOCTL_WAIT_SRQ
On Wed, May 23, 2018 at 02:08:27PM +0200, Oliver Neukum wrote:
> Am Donnerstag, den 17.05.2018, 19:03 +0200 schrieb Guido Kiener:
> > +static int usbtmc488_ioctl_wait_srq(struct usbtmc_file_data *file_data,
> > + unsigned int __user *arg)
> > +{
> > + struct usbtmc_device_data *data = file_data->data;
> > + struct device *dev = >intf->dev;
> > + int rv;
> > + unsigned int timeout;
> > + unsigned long expire;
> > +
> > + if (!data->iin_ep_present) {
> > + dev_dbg(dev, "no interrupt endpoint present\n");
> > + return -EFAULT;
> > + }
> > +
> > + if (get_user(timeout, arg))
> > + return -EFAULT;
> > +
> > + expire = msecs_to_jiffies(timeout);
> > +
> > + mutex_unlock(>io_mutex);
>
> There is such a thing as threads sharing file descriptors.
> That leads to the question what happens to the mutex if this
> ioctl() is called multiple times.
Processes can share file descriptors as well, no need to mess with a
thread :)
good catch.
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
