[PATCH -next] USB: serial: quatech2: remove set but not used variable 'port_priv'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/serial/quatech2.c: In function 'qt2_process_read_urb':
drivers/usb/serial/quatech2.c:503:27: warning:
variable 'port_priv' set but not used [-Wunused-but-set-variable]
It not used any more after
commit 2be818a116b2 ("Revert "USB: quatech2: only write to the tty if the port
is open."")
Signed-off-by: YueHaibing
---
drivers/usb/serial/quatech2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index f2fbe1e..a62981c 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -500,7 +500,6 @@ static void qt2_process_read_urb(struct urb *urb)
struct usb_serial *serial;
struct qt2_serial_private *serial_priv;
struct usb_serial_port *port;
- struct qt2_port_private *port_priv;
bool escapeflag;
unsigned char *ch;
int i;
@@ -514,7 +513,6 @@ static void qt2_process_read_urb(struct urb *urb)
serial = urb->context;
serial_priv = usb_get_serial_data(serial);
port = serial->port[serial_priv->current_port];
- port_priv = usb_get_serial_port_data(port);
for (i = 0; i < urb->actual_length; i++) {
ch = (unsigned char *)urb->transfer_buffer + i;
@@ -566,7 +564,6 @@ static void qt2_process_read_urb(struct urb *urb)
serial_priv->current_port = newport;
port = serial->port[serial_priv->current_port];
- port_priv = usb_get_serial_port_data(port);
i += 3;
escapeflag = true;
break;
Re: KASAN: slab-out-of-bounds Read in vhci_hub_control
On Wed, Oct 10, 2018 at 10:26 PM, Shuah Khan wrote: > On 10/10/2018 01:42 PM, Dmitry Vyukov wrote: >> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan wrote: >>> On 09/04/2018 12:52 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e40 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=121caa4640 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab640 >>> >>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer >>> depend on state of the machine? i.e what is the status of vhci_hcd - are >>> there any devices attached? >>> >>> I can see the problem looking at the code and fix is easy. However, I would >>> like be able to reproduce it and verify the fix works. Also this would be a >>> good regression for the driver I could consider adding to selftests. >> >> >> >> Are you sure you used the provided config/commit? >> I've followed these instructions: >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce >> and the C repro gave me this in a second: > > I managed to reproduce and fix it. I did add reported by tag as well. > > Here is fix: > https://patchwork.kernel.org/patch/10628833/ > > Sudip verified the patch. Great. Thanks!
P/Contact
Dear Sir Please contact for detailed information of funds transfer based on your surname, Your prompt response will be highly appreciated. Kind Regards, Allen Yun B.Group manager contact id..
[PATCH] net: cdc_ncm: use tasklet_init() for tasklet_struct init
The tasklet initialisation would be better done by tasklet_init() instead of assuming all the fields are in an ok state by default. This does not fix any actual know bug. Signed-off-by: Ben Dooks --- drivers/net/usb/cdc_ncm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 0d722b326e1b..863f3548a439 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -784,8 +784,7 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_ hrtimer_init(&ctx->tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); ctx->tx_timer.function = &cdc_ncm_tx_timer_cb; - ctx->bh.data = (unsigned long)dev; - ctx->bh.func = cdc_ncm_txpath_bh; + tasklet_init(&ctx->bh, cdc_ncm_txpath_bh, (unsigned long)dev); atomic_set(&ctx->stop, 0); spin_lock_init(&ctx->mtx); -- 2.19.1
Re: [PATCH] usbip: vhci_hcd: Check rhport everywhere in vhci_hub_control()
Hi Ben, Thanks for the patch. On 10/10/2018 11:30 PM, Ben Hutchings wrote: > Commit 5b22f676118f "usbip: vhci_hcd: check rhport before using in > vhci_hub_control()" added some validation of rhport, but left > several problems: > > - If VHCI_HC_PORTS < 256, we can get rhport >= VHCI_HC_PORTS which > is also out of range. To keep things simple, set rhport to -1 if > this would happen. > - For GetPortStatus, we range-check wIndex (and by implication > rhport) and report an error, but *don't* skip the following code. > Add a goto to the error path. > - At the end of the function, there's one last port_status lookup > that's not protected by any range check. I have patch out for this to fix a syzbot reported problem. console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e40 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=121caa4640 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab640 I was able to reproduce the problem with the C reproducer and fixed it. Here is fix: https://patchwork.kernel.org/patch/10628833/ Sudip verified the patch. thanks, -- Shuah
Re: Query on usb/core/devio.c
On Tue, 9 Oct 2018 13:27:02 +0200 Greg KH wrote: > 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? > (As you probably might have guessed), we have a composite USB device with USB audio and USB HID. However, to support our specific features (USP) that does not fit into either USB-audio or USB-HID spec, we have another interface. Some of the controls exposed by it indirectly affect the audio pipeline. It is this part of system which is in user-space and uses USB-FS driver to talk to interface. We are looking into closing the device instance during normal operation i.e.: only open/close device when needed. However, we still have one particular use-case where our USB device sends async notification to USB-host via the above interface. For that, as of now, we queue a URB from user-space. But because, the link never enters suspend (L2), we receive this async notification. I am not sure, how this use-case will work, if we open-close device only when needed. Assuming we have PM calls moved from open/close to ioctl or some other appropriate method, is the following sequence possible - * Queue an URB -> suspend (L2) * Device does remote wake & sends async notification * URB above returns with that notification > thanks, > > greg k-h P.S.: Oliver N - I hope above comment also acts as a response to your comment in previous part of mail thread. Thanks,
Re: Query on usb/core/devio.c
On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: > On Tue, 9 Oct 2018 13:27:02 +0200 > Greg KH wrote: > > > 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? > > > > (As you probably might have guessed), we have a composite USB device with USB > audio and USB HID. However, to support our specific features (USP) that does > not fit into either USB-audio or USB-HID spec, we have another interface. > Some of the controls exposed by it indirectly affect the audio pipeline. > It is this part of system which is in user-space and uses USB-FS driver to > talk to interface. > > We are looking into closing the device instance during normal operation i.e.: > only open/close device when needed. > > However, we still have one particular use-case where our USB device sends > async notification to USB-host via the above interface. For that, as of now, > we queue a URB from user-space. But because, the link never enters suspend > (L2), we receive this async notification. > > I am not sure, how this use-case will work, if we open-close device only when > needed. > > Assuming we have PM calls moved from open/close to ioctl or some other > appropriate method, is the following sequence possible - > * Queue an URB -> suspend (L2) > * Device does remote wake & sends async notification > * URB above returns with that notification It won't work like that. When a device goes into suspend there can't be any outstanding URBs. How about instead having a mechanism whereby your usrspace driver can tell when the device does a remote wakeup? At that point it could submit an URB via usbfs and receive the async notification. Alan Stern
Re: usbfs zerocopy broken on ARM/ARM64
On Sun, 7 Oct 2018, Steve Markgraf wrote:
> Hi,
>
> I'm the author of a userspace library that makes use of the usbfs
> zerocopy-feature via libusb-1.0, and recently received a bug report that
> garbage data is received with bulk transfers on ARM-based systems.
>
> When I debugged the issue, I found out that the Kernel maps seemingly
> random memory to my transfer buffers, containing memory of other
> processes or even the Kernel itself.
>
> The code that does the mapping in drivers/usb/core/devio.c:
> (line 243 in v4.19-rc7)
>
> > if (remap_pfn_range(vma, vma->vm_start,
> > virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> > size, vma->vm_page_prot) < 0) {
>
> With the following change the issue is fixed for ARM systems, but it
> breaks x86 systems:
>
> - virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> + page_to_pfn(virt_to_page(dma_addr)),
>
> Both usbm->mem and dma_addr are returned by the previous call to
> usb_alloc_coherent().
> Here's an example of the pointers generated by the two macros on an
> ARM64 system for the same buffer:
>
> virt_to_phys(usbm->mem) >> PAGE_SHIFT: 808693ce
> page_to_pfn(virt_to_page(dma_addr)): 9775a856
>
> From what I read so far I got the impression that the 'proper' way would
> be to use dma_mmap_coherent() with dma_addr instead of
> remap_pfn_range(), however, I did not get it to work. Can anyone help
> out?
This is question is more about the kernel's architecture-specific
design than about USB. You should ask on the
linux-a...@vger.kernel.org, linux-arm-ker...@lists.infradead.org, and
linux-ker...@vger.kernel.org mailing lists.
Alan Stern
[PATCH v2] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll
This adds device tree bindings for the Faraday FOTG2
dual-mode host controller.
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans Ulli Kroll
Acked-by: Rob Herring
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Changed "OTH" to "OTG"
- Collected Rob's ACK.
- I don't see any problem with these bindings, but IIRC Hans
had some reservations for the OTG mode, maybe we can strip
some properties like the mini-usb thing and use as a starter
so we can add host mode at least?
---
.../bindings/usb/faraday,fotg210.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/faraday,fotg210.txt
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
new file mode 100644
index ..06a2286e2054
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
@@ -0,0 +1,35 @@
+Faraday FOTG Host controller
+
+This OTG-capable USB host controller is found in Cortina Systems
+Gemini and other SoC products.
+
+Required properties:
+- compatible: should be one of:
+ "faraday,fotg210"
+ "cortina,gemini-usb", "faraday,fotg210"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Optional properties:
+- clocks: should contain the IP block clock
+- clock-names: should be "PCLK" for the IP block clock
+
+Required properties for "cortina,gemini-usb" compatible:
+- syscon: a phandle to the system controller to access PHY registers
+
+Optional properties for "cortina,gemini-usb" compatible:
+- cortina,gemini-mini-b: boolean property that indicates that a Mini-B
+ OTG connector is in use
+- wakeup-source: see power/wakeup-source.txt
+
+Example for Gemini:
+
+usb@6800 {
+ compatible = "cortina,gemini-usb", "faraday,fotg210";
+ reg = <0x6800 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cc 12>;
+ clock-names = "PCLK";
+ syscon = <&syscon>;
+ wakeup-source;
+};
--
2.17.1
Re: [PATCH 5/6] usb: musb: gadget: implement send_response
Hi, On Tue, Oct 09, 2018 at 10:49:02PM -0400, Paul Elder wrote: > This patch implements a mechanism to signal the MUSB driver to reply to > a control OUT request with STALL or ACK. > > Signed-off-by: Paul Elder > Reviewed-by: Laurent Pinchart The patch looks good to me, here is my Acked-by: Acked-by: Bin Liu but I am unable to test this patch set - the current Greg's usb-next tree gives deadlock error between composite_disconnect() and usb_function_deactivate() when loading g_webcam.ko on BeagleboneBlack. The error happens before applying this patch set. Regards, -Bin.
Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage
Hi,
On Tue, Oct 09, 2018 at 10:49:01PM -0400, Paul Elder wrote:
> A usb gadget function driver may or may not want to delay the status
> stage of a control OUT request. An instance it might want to is to
> asynchronously validate the data of a class-specific request.
>
> Add a function usb_ep_delay_status to allow function drivers to choose
> to delay the status stage in the request completion handler. The UDC
> should then check the usb_ep->delayed_status flag and act accordingly to
> delay the status stage.
>
> Also add a function usb_ep_send_response as a wrapper for
> usb_ep->ops->send_response, whose prototype is added as well. This
> function should be called by function drivers to tell the UDC what to
> reply in the status stage that it has requested to be delayed.
>
> Signed-off-by: Paul Elder
> Reviewed-by: Laurent Pinchart
> ---
> drivers/usb/gadget/udc/core.c | 35 +++
> include/linux/usb/gadget.h| 11 +++
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index af88b48c1cea..1ec5ce6b43cd 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -443,6 +443,41 @@ void usb_ep_fifo_flush(struct usb_ep *ep)
> }
> EXPORT_SYMBOL_GPL(usb_ep_fifo_flush);
>
> +/**
> + * usb_ep_ep_delay_status - set delay_status flag
> + * @ep: the endpoint whose delay_status flag is being set
> + *
> + * This function instructs the UDC to delay the status stage of a control
> + * request. It can only be called from the request completion handler of a
> + * control request.
> + */
> +void usb_ep_delay_status(struct usb_ep *ep)
> +{
> + ep->delayed_status = true;
> +}
> +EXPORT_SYMBOL_GPL(usb_ep_delay_status);
Is usb_ep_set_delay_status() better? I thought it implies get/return
action if a verb is missing in the function name.
Regards,
-Bin.
Re: [PATCH] net: cdc_ncm: use tasklet_init() for tasklet_struct init
From: Ben Dooks Date: Thu, 11 Oct 2018 14:03:32 +0100 > The tasklet initialisation would be better done by tasklet_init() > instead of assuming all the fields are in an ok state by default. > > This does not fix any actual know bug. > > Signed-off-by: Ben Dooks Applied to net-next.
Re: [PATCH 0/6] usb: gadget: add mechanism to asynchronously validate data stage of ctrl out request
Hi, On Tue, Oct 09, 2018 at 10:48:57PM -0400, Paul Elder wrote: > This patch series adds a mechanism to allow asynchronously validating > the data stage of a control out request, and for stalling or suceeding > the request accordingly. This mechanism is implemented for MUSB, and is > used by UVC. At the same time, UVC packages the setup stage and data Why is this for MUSB only? Other UDC such as DWC3 doesn't need this? Regards, -Bin.
RE: [RFC] usb: chipidea: Add minimal support for HSIC interface on i.MX6QDL
> > Thanks, I should do it earlier, I could not find a suitable board with HSIC > > support > at mainline kernel. > > It is very kind that you could help on it and test function at real > > board. My suggestion is follow all flows in Link [2] since we need to cover > suspend/resume and remote wakeup. > > It seems like power management and other things in the linux-imx kernel are > not > fully implemented in mainline so there are quite a few differences. > > My knowledge of USB, etc. is very limited, so I guess this is currently > beyond my > skills. Can you or someone else provide a patch to get started? I could help > with > testing, reviewing, etc. > Ok, I will supply the patch, and you could add your dts changes as well as testing. Thanks. Peter
[PATCH net-next] net: cdc_ncm: remove set but not used variable 'ctx'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/usb/cdc_ncm.c: In function 'cdc_ncm_status':
drivers/net/usb/cdc_ncm.c:1603:22: warning:
variable 'ctx' set but not used [-Wunused-but-set-variable]
struct cdc_ncm_ctx *ctx;
It not used any more after
commit fa83dbeee558 ("net: cdc_ncm: remove redundant "disconnected" flag")
Signed-off-by: YueHaibing
---
drivers/net/usb/cdc_ncm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 35a7d61..50c05d0f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1600,11 +1600,8 @@ int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff
*skb_in)
static void cdc_ncm_status(struct usbnet *dev, struct urb *urb)
{
- struct cdc_ncm_ctx *ctx;
struct usb_cdc_notification *event;
- ctx = (struct cdc_ncm_ctx *)dev->data[0];
-
if (urb->actual_length < sizeof(*event))
return;
