The following changes since commit aa05cfa95f686be5d1485094402ebc7b03729e0e:
Merge tag 'fixes-for-v4.4-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
(2015-11-17 14:48:24 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kern
On 18 November 2015 at 12:54, Peter Chen wrote:
> I am clear now, I will queue it.
Thank you
--
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
Support hisilicon,hi6220-usb for HiKey board
Signed-off-by: Zhangfei Gao
---
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/platform.c| 32 ++
2 files changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/us
Support hisilicon,hi6220-usb for HiKey board
Signed-off-by: Zhangfei Gao
---
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/platform.c| 32 ++
2 files changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/us
Support hi6220 use phy for HiKey board
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/phy/phy-hi6220-usb.txt | 16 ++
drivers/phy/Kconfig| 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-hi6220-usb.c
On Wed, Nov 18, 2015 at 11:48:36AM +0530, Saurabh Sengar wrote:
> On 18 November 2015 at 11:35, Peter Chen wrote:
> > On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
> >> call to of_find_property() before of_property_read_u32() is unnecessary.
> >> of_property_read_u32() anyway cal
On Tue, 2015-11-17 at 14:13 -0500, Alan Stern wrote:
> On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
>
> > Alan, could we perhaps let the zerocopy flag make the request fail (instead
> > of going through a bounce buffer) if direct DMA is not possible? That way,
> > it would be quite obvious th
On 18 November 2015 at 11:35, Peter Chen wrote:
> On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
>> call to of_find_property() before of_property_read_u32() is unnecessary.
>> of_property_read_u32() anyway calls to of_find_property() only.
>>
>> Signed-off-by: Saurabh Sengar
>> -
On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar
> ---
> v4 : removed return type check for optional proper
This patch modifies the ep.caps.type_{iso,bulk,int} setting and
the second argument of usb_ep_maxpacket_limit() using
the dparam.pipe_configs.
In the previous code, all the type_{iso,bulk,int} were set to true.
However, to avoid waste time for finding suitable pipe in usb_ep_enable(),
this driver
The current code has info->bufnmb_last to calculate the BUFNMB bits of
PIPEBUF register. However, since the bufnmb_last is initialized in
the usbhs_pipe_init() only, this driver is possible to set unexpected
value to the register if usb_ep_{enable,disable}() are called many times.
So, this patch m
This patch is based on the latest Felipe's usb.git / testing/next branch.
(The commit id = 81e9d14a53eb1abfbe6ac828a87a2deb4702b5f1)
Changes from v1:
- Rebase the latest usb.git testing/next branch.
- Separate other one patch. (In other words, that patch is for bugfix.)
Yoshihiro Shimoda (2):
This patch fixes an issue that NULL pointer dereference happens when
a gadget driver calls usb_ep_dequeue() for ep0 after disconnected
a usb cable. This is because that usbhsg_try_stop() will call
usbhsg_ep_disable(&dcp->ep) when a usb cable is disconnected and
the pipe of dcp (ep0) is set to NULL.
On Wed, Nov 18, 2015 at 09:30:39AM +0530, Saurabh Sengar wrote:
> Hi Peter,
>
> Yes itc_setting is still optional, in case dts does not pass this
> property, return type will be -EINVAL and there would be no problem.
> The function will break only if there is 'No data'(-ENODATA) or
> 'overflow'(-E
call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.
Signed-off-by: Saurabh Sengar
---
v4 : removed return type check for optional property 'itc-setting'
drivers/usb/chipidea/core.c | 57 +---
Hi Peter,
Yes itc_setting is still optional, in case dts does not pass this
property, return type will be -EINVAL and there would be no problem.
The function will break only if there is 'No data'(-ENODATA) or
'overflow'(-ENODATA) error for this property.
In case this is not OK, I will send a anoth
On Tue, Nov 17, 2015 at 05:22:26PM +0530, Saurabh Sengar wrote:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar
> ---
> v2 : removed pval variable
> v3 : removed unnecess
On Tue, Nov 17, 2015 at 11:00:18PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
> >
> > Arnd Bergmann writes:
> > > USB_OTG initially depended on USB_SUSPEND, which was later turned into
> > > PM_RUNTIME and finally into PM. I don't know at what point the
Alan Stern wrote:
> if we can directly map the user-provided buffer for DMA.
Given a memory buffer either kernel or userspace has to apply the
hardware constraints to find out what part if any is usable for DMA.
I think it's fine to push this task to userspace - as long as
userspace has a way to
Hi,
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, November 18, 2015 12:32 AM
>
> Hi,
>
> Yoshihiro Shimoda writes:
> > This patch fixes an issue that NULL pointer dereference happens when
> > a gadget driver calls usb_ep_dequeue() after usb_ep_disable().
> >
> > Signed-off-by: Y
On 17 November 2015 at 21:34, Andy Shevchenko wrote:
> On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang wrote:
>> It dose not work when we want to use the usb-to-serial port based
>> on one usb gadget as a console. Thus this patch adds the console
>> initialization to support this request.
>
>
>> @@
usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.
Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings
---
drivers/usb/core/c
On Tue, Nov 17, 2015 at 11:41:03AM -0600, Felipe Balbi wrote:
> Hi Greg,
>
> Here's the first round of fixes for this first
> rc. Only 11 commits this time.
>
> Let me know if you want anything to be changed.
>
> thanks
>
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d713
Hi,
Arnd Bergmann writes:
> On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
>>
>> Arnd Bergmann writes:
>> > USB_OTG initially depended on USB_SUSPEND, which was later turned into
>> > PM_RUNTIME and finally into PM. I don't know at what point the dependency
>> > became unnecessary bu
On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
>
> Arnd Bergmann writes:
> > USB_OTG initially depended on USB_SUSPEND, which was later turned into
> > PM_RUNTIME and finally into PM. I don't know at what point the dependency
> > became unnecessary but it appears to work fine without CO
Hi,
Arnd Bergmann writes:
> USB_OTG initially depended on USB_SUSPEND, which was later turned into
> PM_RUNTIME and finally into PM. I don't know at what point the dependency
> became unnecessary but it appears to work fine without CONFIG_PM now.
>
> However, we get lots of warnings in randconfi
Hi,
On Mon, Nov 16, 2015 at 4:51 PM, Douglas Anderson wrote:
> Until we have logic to determine which devices share the same TT let's
> add logic to assume that all devices on a given dwc2 controller are on
> one single_tt hub. This is better than the previous code that assumed
> that all device
Stefan Wahren writes:
> This patch series fixes multiple issues on Raspberry Pi which
> were reproducable since commit 09a75e857790
> ("usb: dwc2: refactor common low-level hw code to platform.c")
>
> Changes in V2:
> - add fix for kernel oops
> - extend "usb: dwc2: Return errors from PHY" to ha
USB_OTG initially depended on USB_SUSPEND, which was later turned into
PM_RUNTIME and finally into PM. I don't know at what point the dependency
became unnecessary but it appears to work fine without CONFIG_PM now.
However, we get lots of warnings in randconfig kernels like:
warning: (USB_OTG_FSM
My recent Intel box is spewing these messages:
xhci_hcd :00:14.0: xHCI Host Controller
xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2:
On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
> > xHCI always uses 64-bit addresses. But many EHCI controllers don't,
> > and only a few of the EHCI platform drivers support 64-bit DMA.
>
> OK, sure. But are systems with USB2 only and more than 4GB of RAM common?
> (And will they not increas
On Tue, Nov 17, 2015 at 03:16:55PM -0500, Alan Stern wrote:
>>> But what other way of allocating memory is there?
>> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
>> map up a chunk of GPU memory for you into userspace, but you have no
>> guarantees as of if it's DMA-ab
On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
> On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote:
> > But what other way of allocating memory is there?
>
> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
> map up a chunk of GPU memory for you into userspac
On Tue, Nov 17, 2015 at 03:01:39PM -0500, Alan Stern wrote:
>> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
>>> Is there an API for allocating user memory below 4 GB? Would a new
>>> MMAP flag be acceptable?
>> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it so
On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> > Is there an API for allocating user memory below 4 GB? Would a new
> > MMAP flag be acceptable?
>
> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
> mo
On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> Is there an API for allocating user memory below 4 GB? Would a new
> MMAP flag be acceptable?
MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
more like a kludge than anything else.
/* Steinar */
--
Homepa
Hi,
Markus Rechberger writes:
> Such kind of security is a little bit odd for a stack that doesn't
> work nearly as well as Mac or Windows.
And you say this based on what, exactly ?
Linux supports many more devices, it's usually faster with most devices
(actually Mac's is on par with Linux, Wi
By the way on MacOSX we also pre-allocate some buffer in userspace
first for everything.
Well it's up to you anyway I haven't seen a move into a good direction
in that area for years anyway on Linux so I'm used to deal with what
is currently available.
On Tue, Nov 17, 2015 at 8:13 PM, Alan Stern
On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote:
> But what other way of allocating memory is there?
For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
map up a chunk of GPU memory for you into userspace, but you have no
guarantees as of if it's DMA-able. But ty
On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
> On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
> > 1. the memset on isochronous transfers to empty the buffers in order
> > to avoid leaking raw memory to userspace (this costs a lot on intel
> > Atoms and is also noticeable on
On Mon, 16 Nov 2015, Christoph Hellwig wrote:
> On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote:
> > The original use case: DVB capture on embedded devices.
> >
> > My use case: USB3 uncompressed HD video capture (from multiple cards).
> >
> > Both of these hit (beyond the s
Just a side note, for older videodevices it was also common to
allocate the DMA memory during bootup because it might have failed
during runtime because of memory fragmentation.
The reason for the memset on the isochronous transfer is that USB
might not fill up the entire buffer leaving half of th
On Tue, 17 Nov 2015, Markus Rechberger wrote:
> There are 2 problems with the current implementation:
>
> 1. the memset on isochronous transfers to empty the buffers in order
> to avoid leaking raw memory to userspace (this costs a lot on intel
> Atoms and is also noticeable on other systems).
I
On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
> 1. the memset on isochronous transfers to empty the buffers in order
> to avoid leaking raw memory to userspace (this costs a lot on intel
> Atoms and is also noticeable on other systems).
>
> 2. the memory fragmentation. Seems l
There are 2 problems with the current implementation:
1. the memset on isochronous transfers to empty the buffers in order
to avoid leaking raw memory to userspace (this costs a lot on intel
Atoms and is also noticeable on other systems).
2. the memory fragmentation. Seems like recent systems hav
On Tue, 17 Nov 2015, Michael Reutman wrote:
> > Apologies for the delay, been working on another project recently that
> > has taken up most of my time.
> >
> > I applied the patch and have ran our application for 20 to 30 minutes
> > thus far without issue. Later on tonight I'll set it up for an
On Tue, 17 Nov 2015, Dmitry Katsubo wrote:
> Alan, I have difficulties with making it working. The patch that was
> supposed to be trivial, does not work. The problem is that given USB
> adapter is detected as "uas" device (so, driven by uas.ko module). It
> took me few days to understand that, be
Hi Greg,
Here's the first round of fixes for this first
rc. Only 11 commits this time.
Let me know if you want anything to be changed.
thanks
The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
are available in the git repos
On Tue, 17 Nov 2015, Christoph Hellwig wrote:
> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> > In other words, you're suggesting we do this:
> >
> > Check that userspace requested zerocopy (otherwise the user
> > program might try to access other data stored in the same
On 2015-11-12 13:09, Dmitry Katsubo wrote:
> On 2015-11-11 16:16, Alan Stern wrote:
>>> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA
>>> Technology Corp.
>>> Device Descriptor:
>>>bLength18
>>>bDescriptorType 1
>>>bcdUSB
This fixes all errors from checkpatch.pl about that
"foo * bar" should be "foo *bar"
Signed-off-by: Bogicevic Sasa
---
drivers/hid/usbhid/hiddev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 2f1ddca..c7
Alan,
On Tue, Nov 17, 2015 at 7:40 AM, Alan Stern wrote:
> On Mon, 16 Nov 2015, Doug Anderson wrote:
>
>> > Fundamentally there's no difference between a "connect" interrupt and a
>> > "disconnect" interrupt. They should both do exactly the same things:
>> > clear the interrupt source, post a "c
Enable the 2 USB host controllers used on the Orange Pi Plus
and add the necessary regulators.
Signed-off-by: Reinder de Haan
Signed-off-by: Hans de Goede
Signed-off-by: Jens Kuske
---
Hi Hans,
with these regulators USB works on the Orange Pi Plus too.
I don't know if adding the regulators in
On Mon, 16 Nov 2015, Doug Anderson wrote:
> > Fundamentally there's no difference between a "connect" interrupt and a
> > "disconnect" interrupt. They should both do exactly the same things:
> > clear the interrupt source, post a "connection change" event, and set
> > the driver's connect status
Hi,
Yoshihiro Shimoda writes:
> This patch fixes an issue that NULL pointer dereference happens when
> a gadget driver calls usb_ep_dequeue() after usb_ep_disable().
>
> Signed-off-by: Yoshihiro Shimoda
and which gadget driver is that ? Let's fix it. We should _not_ call
usb_ep_dequeue() after
On Thu, Nov 12, 2015 at 10:46 AM, Michael Reutman
wrote:
> On Mon, Nov 9, 2015 at 9:21 AM, Alan Stern wrote:
>> Here's a revised quick-and-dirty workaround. It replaces the earlier
>> one. (And like the earlier one, it is meant to apply on top of
>> the usbfs-snoop patch, but I don't think that
From: Ben McCauley
In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.
Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and w
On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang wrote:
> It dose not work when we want to use the usb-to-serial port based
> on one usb gadget as a console. Thus this patch adds the console
> initialization to support this request.
> @@ -79,6 +80,16 @@
> */
> #define QUEUE_SIZE 16
>
C: m...@mansr.com, peter.c...@freescale.com, gre...@linuxfoundation.org,
>> linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org, Saurabh Sengar
>>
>> CC: Saurabh Sengar
>>
>> Hi Saurabh,
>>
>> [auto build test WARNING on peter.chen-usb/ci-for-usb-next]
>> [also
On Tue, 2015-11-17 at 13:07 +0100, Steinar H. Gunderson wrote:
> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> > Check that userspace requested zerocopy (otherwise the user
> > program might try to access other data stored in the same cache
> > lines as the buffer whil
c...@freescale.com, gre...@linuxfoundation.org,
> linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org, Saurabh Sengar
>
> CC: Saurabh Sengar
>
> Hi Saurabh,
>
> [auto build test WARNING on peter.chen-usb/ci-for-usb-next]
> [also build test WARNING on v4.4-rc1 next-201511
On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> Check that userspace requested zerocopy (otherwise the user
> program might try to access other data stored in the same cache
> lines as the buffer while the I/O is in progres);
Needed for send only, right? For recei
call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.
Signed-off-by: Saurabh Sengar
---
v2 : removed pval variable
v3 : removed unnecessary if condition
drivers/usb/chipidea/core.c | 59 +++
Saurabh Sengar writes:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar
> ---
> v2: removed pval variable
> drivers/usb/chipidea/core.c | 61
> +++--
call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.
Signed-off-by: Saurabh Sengar
---
v2: removed pval variable
drivers/usb/chipidea/core.c | 61 +++--
1 file changed, 26
Saurabh Sengar writes:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar
> ---
> drivers/usb/chipidea/core.c | 67
> ++---
> 1 fi
call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.
Signed-off-by: Saurabh Sengar
---
drivers/usb/chipidea/core.c | 67 ++---
1 file changed, 32 insertions(+), 35 deletion
On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> In other words, you're suggesting we do this:
>
> Check that userspace requested zerocopy (otherwise the user
> program might try to access other data stored in the same cache
> lines as the buffer while the I/O is i
Hello.
On 11/17/2015 12:18 PM, Chunfeng Yun wrote:
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++
1 file changed, 51 insertions(+)
cre
On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote:
> This quirk works as well if debug host doesn't have DBC. I didn't try a
> DBC-capable debug host yet.
Hi,
I went through it again, with your v3 patch series on top of vanilla v4.3.0.
Two targets, one host, all with Intel chipset (XHCI device
On Mon, 2015-11-16 at 12:30 -0500, Ilia Mirkin wrote:
> Task dump for CPU 2:
> kworker/2:2 R running task13152 23226 2 0x
> Workqueue: usb_hub_wq hub_event
> 88017fd3ba08 88017fd3b9c8 8111dfc8 0002
> 88017fd3ba08 88017fd3b9e0 8111f
add xHCI and phy drivers for MT8173-EVB
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 42 +
2 files changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt817
There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
to minimize the scheduling effort for synchronous and
interrupt endpoints. The parameters are put into reseved
DWs of slot context and endpoint context.
2. Its IMODI unit for Interr
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt81
>From 577f68d9c0ca1531d5f9cae0dcbea2ba116c8551 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun
Date: Tue, 17 Nov 2015 17:09:05 +0800
Subject: [PATCH v12 0/3] Mediatek xHCI support
The patch supports MediaTek's xHCI controller.
There are some differences from xHCI spec:
1. The interval is specified i
On 16.11.2015 17:25, Alan Stern wrote:
On Sun, 15 Nov 2015, Stéphane Lavergne wrote:
On Sat, Sep 12, 2015 at 4:08 AM, Hans-Peter Jansen wrote:
With some changes in the 4.0 time frame, AND an update of the epson iscan
stuff, I'm happily scanning with my Epson 4490 Photo scanner plugged to a US
76 matches
Mail list logo
