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).
> > The manufa
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 aft
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 a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc
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 fix one static analysis tool
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 ma
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 op
> > > 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 (3
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 introduc
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, essentially, enable all
> endpoints unconditi
> 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, logi
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 to
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 fro
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 se
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 dep
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 schri
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: "bad_dma_ops" [drivers/usb/core/usbcore
The write value is 8bit, but currently writing a larger number (eg a doubled
digit) is not errored but instead gets cast and sets off an action probably
undesired.
Signed-off-by: Alan Cox
---
drivers/usb/chipidea/debug.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/chipi
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 int
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
On Monday 15 February 2016 14:51:13 Krzysztof Hałasa wrote:
> 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 s
On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> Because USB Type-C ports (DRP ones) will select the data role randomly
> when you connect (to an other DRP port). USB Type-C spec defines that
> you can "prefer" host mode, but when both ends prefer host mode, it's
> +-0.
That question ha
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 c
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: And
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 compariso
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 ARM with the curre
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] undefined!
>> ERROR:
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: "dma_pool_all
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:
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!
ERR
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 driv
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 Uytterho
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 UML
> from a capable host.
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 linu
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 to make them
disappear
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 a
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 when CONFIG_IXP
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 "ment
37 matches
Mail list logo
