Re: driver migration

Greg KH writes: > > On Mon, Feb 15, 2016 at 11:30:43PM +, tilman wrote: > > Dear all > > > > a couple of years ago I wrote a driver for a serial dongle. > > I did not add it to the linux source because the dongle requires a firmware > > to be downloaded to the device (ezusb). >

[PATCH] usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys

On xHCI controllers of R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set to 1. However, these SoCs don't support 64-bit address memory pointers. So, this driver should call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup(). Otherwise, the xHCI controller will be died

[PATCH] usb: check for signals in chaoskey read function

Call signal_pending before reading a chunk of data from the device so that long read operations can be interrupted with a signal. Signed-off-by: Keith Packard --- drivers/usb/misc/chaoskey.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [PATCH] usb: dwc2: host: fix the data toggle error in full speed descriptor dma

On 1/25/2016 10:20 PM, Jianqiang Tang wrote: > From: "Tang, Jianqiang" > > There will be data toggle error happen for full speed buld-out transfer. > The data toggle bit is saved in qh for non-control transfers, it is wrong > to check the qtd for that case. > > Also

Re: [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port

On 02/15/2016 07:16 PM, Mathias Nyman wrote: > On 04.02.2016 01:56, Lu Baolu wrote: >> Hi Mathias, >> >> Greg is asking for your ack for these patches. Can you please >> help to take a look? >> > > I'll take look now that I finally got the USB 3.1 code done, > Sorry about the delay It doesn't

Re: [PATCH v3 0/2] usbip: vhci number of ports extension

On Tue, Feb 16, 2016 at 12:37:57AM +, fx IWATA NOBUO wrote: > > > > What limitation? Why change it? What's the problem here... > > > > > > In original code, number of devices to be able to attach is 8. > > > It's came from VHCI_NPORTS, the default is 8. > > > It can be changed with compile

RE: [PATCH v3 0/2] usbip: vhci number of ports extension

> > > What limitation? Why change it? What's the problem here... > > > > In original code, number of devices to be able to attach is 8. > > It's came from VHCI_NPORTS, the default is 8. > > It can be changed with compile option -DVHCI_NPORTS The maximum number > > is limited to USB_MAXCHILDREN

[PATCH v2] usb: dwc3: Fix assignment of EP transfer resources

The assignement of EP transfer resources was not handled properly in the dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE") previously fixed one aspect of this where resources may be exhausted with multiple calls to SET_INTERFACE. However, it

Re: [PATCH] usb: dwc3: Fix assignment of EP transfer resources

On 2/12/2016 2:05 AM, Felipe Balbi wrote: > > Hi, > > John Youn writes: >> On 2/10/2016 1:07 PM, Felipe Balbi wrote: >>> John Youn writes: >> Basically assign all the resources in advance. > > I thought about that, but wouldn't this,

RE: [PATCH v7 1/3] usbip: exporting devices

> Why isn't this in the changelog itself? But more importantly, I don't see > how this patch makes your "goal" implemented... Sorry. I think almost same thing is in cover letter but version info is getting long. Anyway I will improve the log. > Anyway, please break this all up into smaller,

Re: driver migration

On Mon, Feb 15, 2016 at 11:30:43PM +, tilman wrote: > Dear all > > a couple of years ago I wrote a driver for a serial dongle. > I did not add it to the linux source because the dongle requires a firmware > to be downloaded to the device (ezusb). > The manufacturer, IO-DATA, did not want me

driver migration

Dear all a couple of years ago I wrote a driver for a serial dongle. I did not add it to the linux source because the dongle requires a firmware to be downloaded to the device (ezusb). The manufacturer, IO-DATA, did not want me to use their firmware. I am now in the process to move the driver

[PATCH v2] usb: dwc2: Add extra delay when forcing dr_mode

Fixes an issue found on rockchip rk3036 and rk3188 SOC platforms. For some reason, the existing msleep(25) is not enough after the force mode. The following patch was reported to fix the issue. This does increase the probe delay again slightly, but not up to the level it was before the original

Re: [PATCH 3/3] usb: dwc2: USB_DWC2 should depend on HAS_DMA

On 2/15/2016 3:21 AM, Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "usb_gadget_map_request" [drivers/usb/dwc2/dwc2.ko] undefined! > ERROR: "usb_gadget_unmap_request" [drivers/usb/dwc2/dwc2.ko] undefined! > ERROR: "bad_dma_ops" [drivers/usb/dwc2/dwc2.ko] undefined! > > Add a

Re: [PATCH] usb: dwc2: Add extra delay when forcing dr_mode

On 2/13/2016 1:41 PM, Michael Niewoehner wrote: > Hi John, > Hi Heiko, > > on rk3188 25 ms don’t seem to be enough also. > Increasing the sleep time to 50 ms solve the problem for me while 32 ms seem > to be the absolute minimum. > > Best regards > Michael > > > > Am 13.02.2016 um 22:13

Re: [PATCH 1/3] usb: core: Allow compilation on platforms where NO_DMA=y

On 02/15/2016 01:28 PM, Geert Uytterhoeven wrote: On Mon, Feb 15, 2016 at 12:49 PM, Vegard Nossum wrote: On 02/15/2016 12:21 PM, Geert Uytterhoeven wrote: If NO_DMA=y: ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined! ERROR:

Re: [PATCH v7 1/3] usbip: exporting devices

On Mon, Feb 15, 2016 at 04:21:59AM +, fx IWATA NOBUO wrote: > > I don't see any benifit here at all, please explain it better. > > You are saying what your patch does, but not why we would want it. > > It may not be better than cover letter but I try. > > My use case is > a) a service in

Re: [PATCH v3 0/2] usbip: vhci number of ports extension

On Mon, Feb 15, 2016 at 05:40:42AM +, fx IWATA NOBUO wrote: > > What limitation? Why change it? What's the problem here... > > In original code, number of devices to be able to attach is 8. > It's came from VHCI_NPORTS, the default is 8. > It can be changed with compile option -DVHCI_NPORTS

Re: [PATCH 1/3] usb: USB Type-C Connector Class

On Wed, 2016-02-10 at 13:23 +0200, Heikki Krogerus wrote: > That is tricky, as we would need to keep a list of the preselected > modes and for all SVIDs the connector supports. I don't think it would > be practical to do from this file as we would then use it differently > when connected and not

[PATCH 7/7] usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage

IS_ERR_VALUE macro should be used only with unsigned long type. Otherwise it can work incorrectly. The patch follows conclusion from discussion on LKML [1][2]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2120927 [2]: http://permalink.gmane.org/gmane.linux.kernel/2150581 Signed-off-by:

[PATCH 0/7] fix IS_ERR_VALUE usage

Hi, This small set of independent patches tries to fix incorrect IS_ERR_VALUE macro usage. It fixes most usages leading to errors as described in [1]. It also follows conclusion from the discussion [1][2] - IS_ERR_VALUE should be used only with unsigned long type, signed types should use

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > I consider the use of __raw_* accessors a bug, I don't think we should > ever do that because it hides how the hardware actually works, it doesn't > work with spinlocks, and it can lead to the compiler splitting up accesses > into byte sized ones (not on

Re: [PATCH 1/3] usb: core: Allow compilation on platforms where NO_DMA=y

Hi Vegard, On Mon, Feb 15, 2016 at 12:49 PM, Vegard Nossum wrote: > On 02/15/2016 12:21 PM, Geert Uytterhoeven wrote: >> If NO_DMA=y: >> >> ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined! >> ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko]

Re: [PATCH 1/3] usb: core: Allow compilation on platforms where NO_DMA=y

On 02/15/2016 12:21 PM, Geert Uytterhoeven wrote: If NO_DMA=y: ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined! ERROR:

[PATCH 1/3] usb: core: Allow compilation on platforms where NO_DMA=y

If NO_DMA=y: ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/core/usbcore.ko] undefined! ERROR:

[PATCH 2/3] usb: host: Some host drivers should depend on HAS_DMA

If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined!

[PATCH 0/3] usb: Allow compilation on platforms where NO_DMA=y

This patch series allows to compile USB on platforms where NO_DMA=y. I've been using it for quite a while to make allmodconfig/allyesconfig build for m68k/sun3. Thanks for your comments! Geert Uytterhoeven (3): usb: core: Allow compilation on platforms where NO_DMA=y usb: host: Some host

[PATCH 3/3] usb: dwc2: USB_DWC2 should depend on HAS_DMA

If NO_DMA=y: ERROR: "usb_gadget_map_request" [drivers/usb/dwc2/dwc2.ko] undefined! ERROR: "usb_gadget_unmap_request" [drivers/usb/dwc2/dwc2.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/dwc2/dwc2.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert

Re: [uml-devel] [PATCH 1/2] usb: support building without CONFIG_HAS_DMA

Hi Vegard, On Mon, Feb 15, 2016 at 11:41 AM, Vegard Nossum wrote: > Some platforms don't have DMA, but we should still be able to build > USB drivers for these platforms. They could still be used through > vhci_hcd, usbip_host, or maybe something like USB passthrough in

Re: [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port

On 04.02.2016 01:56, Lu Baolu wrote: Hi Mathias, Greg is asking for your ack for these patches. Can you please help to take a look? I'll take look now that I finally got the USB 3.1 code done, Sorry about the delay -Mathias -- To unsubscribe from this list: send the line "unsubscribe

[PATCH 2/2] usb: remove HAS_IOMEM dependency from USB_SUPPORT

USB has not been usable on UML since this commit: commit e25df1205f37c7bff3ab14fdfc8a5249f3c69c82 Author: Martin Schwidefsky Date: Thu May 10 15:45:57 2007 +0200 [S390] Kconfig: menus with depends on HAS_IOMEM. Add "depends on HAS_IOMEM" to a number of menus

[PATCH 1/2] usb: support building without CONFIG_HAS_DMA

Some platforms don't have DMA, but we should still be able to build USB drivers for these platforms. They could still be used through vhci_hcd, usbip_host, or maybe something like USB passthrough in UML from a capable host. This is admittedly ugly with the #ifdefs, but those are necessary to get

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

On Monday 15 February 2016 08:33:37 Krzysztof Hałasa wrote: > Arnd Bergmann writes: > > >> Anyway, I think readl()/writel() do the right thing: in BE mode they > >> swap PCI accesses and don't swap normal registers, in LE mode nothing is > >> swapped. > > > > This seems to be true

Re: [PATCH 2/5] usb: musb: core: added helper functions for parsing DT

Hello Sergei On 12.02.2016 18:50, Sergei Shtylyov wrote: +/* gets the "dr_mode" property from DT and converts it into musb_mode + * if the property is not found returns MUSB_UNDEFINED + */ +extern enum musb_mode musb_get_mode(struct device *dev); + +#if IS_ENABLED(CONFIG_OF) +/* gets the