Hi Peter, Felipe,
> > new drivers only on drivers/phy/, sorry.
>
> This driver has many USB dependencies, like otg, gadget. I don't know it
> can use generic phy currently.
I would like to remind you the thread at
http://thread.gmane.org/gmane.linux.kernel/1858137. I have a USB PHY driver
here
It seems the problem is also triggerable without rtorrent, but other tools like
git when checking out lots of files (in the kernel git repository for example).
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majord
From: Mark Glover
Signed-off-by: Mark Glover
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb3
Hi John Youn:
Could you please give some suggestions from your point of view,
about this probe time issue ?
Thanks a lot.
at 2015/2/11 2:23, Julius Werner wrote:
@@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
gusbcfg = readl(hsotg->regs + GUSBCFG);
On 10.02.2015 17:43, Sneeker Yeh wrote:
> Hi
>
> 2015-01-31 0:38 GMT+08:00 Felipe Balbi :
>> Hi,
>>
>> On Thu, Jan 29, 2015 at 10:23:12AM -0600, Felipe Balbi wrote:
>>> On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote:
Hi,
On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeke
On Tue, Feb 10, 2015 at 08:52:02AM -0600, Felipe Balbi wrote:
> On Tue, Feb 10, 2015 at 09:58:23PM +0800, Huang Rui wrote:
> > On Mon, Feb 09, 2015 at 08:59:06PM -0500, Alan Stern wrote:
> > > On Tue, 10 Feb 2015, Huang Rui wrote:
> > >
> > > > On Mon, Feb 09, 2015 at 10:59:42AM -0500, Alan Stern
On Tue, Feb 10, 2015 at 09:55:14AM -0500, Alan Stern wrote:
> On Tue, 10 Feb 2015, Huang Rui wrote:
>
> > On Mon, Feb 09, 2015 at 08:59:06PM -0500, Alan Stern wrote:
> > > On Tue, 10 Feb 2015, Huang Rui wrote:
> > >
> > > > On Mon, Feb 09, 2015 at 10:59:42AM -0500, Alan Stern wrote:
> > > > > On
Hi David,
> > > > In order for phy to be functional, it does not depend only on toggling
> > > > GPIOs. It depends on DWC3 going to reset state, then phy executes power
> > > > on sequence, then DWC3 going out of reset state to sync clocks with phy.
> > > > You're saying we should tell BIOS is con
Hello.
My 3.16.7 panicked yesterday when I was working with a Thorlabs DCC1545M camera
(inside it's actually an IDS UI-154x/UI-554x sensor, if that matters).
>From USB point of view, it's a simple USB 2.0 device with 1 config, 1 IF and 2
>bulk EPs.
As long as I was working with it using my USB 2
Hello.
On 2/11/2015 9:46 AM, Hayes Wang wrote:
Separate USB_RX_EARLY_AGG into USB_RX_EARLY_TIMEOUT and USB_RX_EARLY_SIZE.
Replace r8153_set_rx_agg() with r8153_set_rx_early_timeout() and
r8153_set_rx_early_size().
Set the default timeout value according to the USB speed.
Signed-off-by:
Hello.
My 3.16.7 panicked yesterday when I was working with a Thorlabs DCC1545M camera
(inside it's actually an IDS UI-154x/UI-554x sensor, if that matters).
>From USB point of view, it's a simple USB 2.0 device with 1 config, 1 IF and 2
>bulk EPs.
As long as I was working with it using my USB 2
On Wed, Feb 11, 2015 at 08:28:09PM +0800, Huang Rui wrote:
> On Tue, Feb 10, 2015 at 08:52:02AM -0600, Felipe Balbi wrote:
> > On Tue, Feb 10, 2015 at 09:58:23PM +0800, Huang Rui wrote:
> > > On Mon, Feb 09, 2015 at 08:59:06PM -0500, Alan Stern wrote:
> > > > On Tue, 10 Feb 2015, Huang Rui wrote:
>
I'd appreciate some advice from anyone here who's familiar with using
signal-based notification (setting urb->signr) when using usbfs. It's working
correctly when this particular device is on, as well as when it's disconnected,
but I'm seeing what seems to be odd behaviour when the device is con
Dave Mielke wrote:
> Under what circumstances should usbfs code, after having received a signal,
> expect to not be able to reap a URB, and how should it interpret this
> situation?
I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
return -1 with errno = ENODEV, or to return 0
On Wed, 11 Feb 2015, Dave Mielke wrote:
> I'd appreciate some advice from anyone here who's familiar with using
> signal-based notification (setting urb->signr) when using usbfs. It's working
> correctly when this particular device is on, as well as when it's
> disconnected,
> but I'm seeing w
On 02/10/2015 10:48 PM, Felipe Balbi wrote:
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c6d0c8e..405a3d0 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -173,6 +173,15 @@ config USB_MXS_PHY
MXS Phy is used by some of the i.MX SoCs, for
On Tue, 10 Feb 2015, Enrico Mioso wrote:
> Hello guys.
> the problem is still reproducible with final 3.19 kernel - I can confirm it.
> Re-sending the last trace here - don't know if it's available in cxg.de.
Please stop posting these process traces. They don't help.
Instead, post a usbmon trac
[quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
>return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
I just reverified. It's definitely returning -1 with EAGAIN.
>What happens if you ioctl(fd,
Dave Mielke wrote:
> [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>
> >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
>
> I just reverified. It's definitely returning -1 with EAGAIN.
[quoted lines by Alan Stern on 2015/02/11 at 10:13 -0500]
>What do you mean by "turned off"? When the device is turned off, does
>it appear to the host controller that the device has disconnected from
>the USB bus?
No. This also occurs after connecting the device while it's turned off. In this
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>
> >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
>
> I just reverified. It's definitely retu
On Wed, 11 Feb 2015, Peter Stuge wrote:
> Dave Mielke wrote:
> > [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
> >
> > >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> > >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
> >
> > I just
[quoted lines by Alan Stern on 2015/02/11 at 10:54 -0500]
>> I just reverified. It's definitely returning -1 with EAGAIN.
>
>That indicates the device is connected and the URB is still in
>progress. You can't reap it because it hasn't completed. The signal
>you received must have referred to a
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 10:13 -0500]
>
> >What do you mean by "turned off"? When the device is turned off, does
> >it appear to the host controller that the device has disconnected from
> >the USB bus?
>
> No. This also occurs after
Hi All,
I am trying to enable hotplugging for usb on my h/w based on 2.6.16 kernel.
The hotplug kernel module is enabled and I have registered a user
script "test.sh"
with the proc file system.
/root # echo "/bin/test.sh" > /proc/sys/kernel/hotplug
---
/root # cat /proc/sys/k
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 10:54 -0500]
>
> >> I just reverified. It's definitely returning -1 with EAGAIN.
> >
> >That indicates the device is connected and the URB is still in
> >progress. You can't reap it because it hasn't complete
[quoted lines by Peter Stuge on 2015/02/11 at 16:40 +0100]
>But I don't believe you should have to discard the URB when the
>device disappears.
I can see, from Alan's questions, that I wasn't clear enough. By "was turned
off", I meant that the device's power switch was in its off position. It wa
Hi,
On Wed, Feb 11, 2015 at 10:07 AM, temp sha wrote:
> Hi All,
>
> I am trying to enable hotplugging for usb on my h/w based on 2.6.16 kernel.
I am not sure if you still can get support for such old version.
> The hotplug kernel module is enabled and I have registered a user
> script "test.sh"
Thank you. If I'll be able I'll try.
Thank you again guys.
Enrico
On Wed, 11 Feb 2015, Alan Stern wrote:
Date: Wed, 11 Feb 2015 16:21:50
From: Alan Stern
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org
Subject: Re: intensive IO on usb-storage device causing syst
[quoted lines by Alan Stern on 2015/02/11 at 11:13 -0500]
>Hmmm. In addition to usbmon, you can try writing 1 to
>/sys/module/usbcore/parameters/usbfs_snoop and then seeing what shows
>up in the dmesg log.
Looking at the snoop logs is hinting that I may need to add another piece to
this puzzl
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 11:13 -0500]
>
> >Hmmm. In addition to usbmon, you can try writing 1 to
> >/sys/module/usbcore/parameters/usbfs_snoop and then seeing what shows
> >up in the dmesg log.
>
> Looking at the snoop logs is hint
[quoted lines by Alan Stern on 2015/02/11 at 12:11 -0500]
>That probably is the explanation. I don't know anything about
>signalfd; you should ask somebody who does.
Okay, I shall. Perhaps you could answer another question that I've been
wondering about. Does usbfs send the completion signal t
On 06.02.2015 17:20, Gregory CLEMENT wrote:
> From: Shimmer Huang
>
> Linux xHCI driver does not check the CEC bit in register PORTSC when
> handling port status events. If Port Configure Error for root hub port
> occurs, CEC bit in PORTSC would be set by xHC and remains 1. This
> happends when t
i was sure that script did not run because I verified the same with
touch command.
#!/bin/sh
echo "my hotplug script"
touch test
file test did not get created.
Thanks.
On Wed, Feb 11, 2015 at 9:59 PM, Bin Liu wrote:
> Hi,
>
> On Wed, Feb 11, 2015 at 10:07 AM, temp sha wrote:
>> Hi All,
>>
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 12:11 -0500]
>
> >That probably is the explanation. I don't know anything about
> >signalfd; you should ask somebody who does.
>
> Okay, I shall. Perhaps you could answer another question that I've been
> w
Thanks. We do take care to block the signal for all other threads just in case.
Regarding the possibility of signalfd delivering the signal too early: Wouldn't
it still be true that something within the usbfs code would still need to be
doing something to trigger that behaviour? If usbfs really
Peter,
On Tue, Feb 10, 2015 at 10:08 PM, Peter Stuge wrote:
> Bin Liu wrote:
>> I have a ARM SoC which has a dwc3 drd controller, to validate if there
>> is a limit of max device connections, I connected multiple hubs, then
>> keyboards and mice.
>>
>> When plugged in the 32th device, xHCI shows
Some information that may be helpful:
There's a significant difference in the way a signal handler is used versus the
way signalfd notifications are used. That difference is that the signal is
unblocked when a signal handler is used (so that the handler can catch it) but
is blocked when signalf
Hi Heikki,
On Fri, Jan 23, 2015 at 05:12:56PM +0200, Heikki Krogerus wrote:
> Registers DWC3's ULPI interface with the ULPI bus when it's
> available.
>
> Signed-off-by: Heikki Krogerus
> ---
> drivers/usb/dwc3/Kconfig | 7 +++
> drivers/usb/dwc3/Makefile | 4 ++
> drivers/usb/dwc3/core.c
On Wed, Feb 11, 2015 at 03:12:55PM +0200, Heikki Krogerus wrote:
> Hi David,
Hi Heikki,
>
> > > > > In order for phy to be functional, it does not depend only on toggling
> > > > > GPIOs. It depends on DWC3 going to reset state, then phy executes
> > > > > power
> > > > > on sequence, then DWC3
Hey,
I'm trying to understand why this Option Globetrotter modem
(net/usb/hso driver, 0af0:6971) ends up returning NUL bytes read
continuously in the TTY when plugged in a USB3 port but not in a USB2
one.
I'm testing this with a 3.18.6 kernel plus a self-compiled hso driver
from net-next; but I h
On Wed, 11 Feb 2015, Dave Mielke wrote:
> Thanks. We do take care to block the signal for all other threads just in
> case.
>
> Regarding the possibility of signalfd delivering the signal too early:
> Wouldn't
> it still be true that something within the usbfs code would still need to be
> do
On Wed, Feb 11, 2015 at 12:54:52PM -0600, Bin Liu wrote:
> Peter,
>
> On Tue, Feb 10, 2015 at 10:08 PM, Peter Stuge wrote:
> > Bin Liu wrote:
> >> I have a ARM SoC which has a dwc3 drd controller, to validate if there
> >> is a limit of max device connections, I connected multiple hubs, then
> >>
[quoted lines by Alan Stern on 2015/02/11 at 14:45 -0500]
>Does the poll return immediately after the URB is submitted, or is
>there a delay? What if you try calling poll _before_ the URB is
>submitted?
poll() is used for the underlying event mechanism, so it's always being caled.
The entire ap
Felipe,
On Wed, Feb 11, 2015 at 2:03 PM, Felipe Balbi wrote:
> On Wed, Feb 11, 2015 at 12:54:52PM -0600, Bin Liu wrote:
>> Peter,
>>
>> On Tue, Feb 10, 2015 at 10:08 PM, Peter Stuge wrote:
>> > Bin Liu wrote:
>> >> I have a ARM SoC which has a dwc3 drd controller, to validate if there
>> >> is a
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 14:45 -0500]
>
> >Does the poll return immediately after the URB is submitted, or is
> >there a delay? What if you try calling poll _before_ the URB is
> >submitted?
>
> poll() is used for the underlying even
On Wed, 11 Feb 2015, Bin Liu wrote:
> Felipe,
>
> On Wed, Feb 11, 2015 at 2:03 PM, Felipe Balbi wrote:
> > On Wed, Feb 11, 2015 at 12:54:52PM -0600, Bin Liu wrote:
> >> Peter,
> >>
> >> On Tue, Feb 10, 2015 at 10:08 PM, Peter Stuge wrote:
> >> > Bin Liu wrote:
> >> >> I have a ARM SoC which has
[quoted lines by Alan Stern on 2015/02/11 at 15:22 -0500]
>Well, it's a mystery. There are exactly two places in the usbfs code
>where a signal is sent: async_completed() and usbdev_remove(). As you
>can tell from the usbfs_snoop output, async_completed() doesn't get
>called until the URB com
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 15:22 -0500]
>
> >Well, it's a mystery. There are exactly two places in the usbfs code
> >where a signal is sent: async_completed() and usbdev_remove(). As you
> >can tell from the usbfs_snoop output, async
What might it mean that ssi_addr is NULL? Is a non-user urb ever submitted
underneath that might be causing the notification?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: d...@mielke.c
Just like the siginfo data has fields that must be left over from somewhere
else, might it be that the user urb is copied, without clearing the signr
field, to initialize an underlying system-provided urb?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone:
On Wed, 11 Feb 2015, Dave Mielke wrote:
> What might it mean that ssi_addr is NULL? Is a non-user urb ever submitted
> underneath that might be causing the notification?
usbfs has only user-generated URBs. It doesn't submit any URBs on its
own.
Of course, other parts of the kernel can submit
Hi,
Since 3.19-rcX kernel crashes when I disconnect an external
HDD drive (not sure since which kernel revision tough early
3.19-rcs possibly are not affected).
To reproduce I do:
- connect my disk
- use disk with LUKS (luksOpen)
- stop using disk (luksClose)
- sdparm -C stop /dev/sgX(sg devi
[quoted lines by Alan Stern on 2015/02/11 at 16:22 -0500]
>usbfs has only user-generated URBs. It doesn't submit any URBs on its
>own.
I see in tghe code:
devio.c:507: sinfo.si_addr = as->userurb;
So, if ssi_addr is NULL wouldn't that mean that as->userurb is NULL? What
could cause that?
On Wed, 11 Feb 2015, Dave Mielke wrote:
> Just like the siginfo data has fields that must be left over from somewhere
> else, might it be that the user urb is copied, without clearing the signr
> field, to initialize an underlying system-provided urb?
No, the signr field is always copied from t
Hi,
On Wed, Feb 11, 2015 at 2:25 PM, Alan Stern wrote:
> On Wed, 11 Feb 2015, Bin Liu wrote:
>
>> Felipe,
>>
>> On Wed, Feb 11, 2015 at 2:03 PM, Felipe Balbi wrote:
>> > On Wed, Feb 11, 2015 at 12:54:52PM -0600, Bin Liu wrote:
>> >> Peter,
>> >>
>> >> On Tue, Feb 10, 2015 at 10:08 PM, Peter Stug
On Wed, 11 Feb 2015, Bin Liu wrote:
> > The problem probably isn't the number of endpoints, but rather the
> > scheduling entries for interrupt and isochronous endpoints.
>
> -12 return code in the log is due to COMP_ENOMEM (7, in Table 135 in
> xHCI Specs) returned by the completion of configure
On 2/6/2015 2:23 PM, John Youn wrote:
> On 2/6/2015 6:02 AM, Zhangfei Gao wrote:
>> On 6 February 2015 at 16:07, Kaukab, Yousaf wrote:
>> GAHBCFG_HBSTLEN_INCR4 << diff --git a/drivers/usb/dwc2/gadget.c
>> b/drivers/usb/dwc2/gadget.c index 15aa578..20085de 100644
>> --- a/drivers/usb/dw
Alan,
On Wed, Feb 11, 2015 at 3:56 PM, Alan Stern wrote:
> On Wed, 11 Feb 2015, Bin Liu wrote:
>
>> > The problem probably isn't the number of endpoints, but rather the
>> > scheduling entries for interrupt and isochronous endpoints.
>>
>> -12 return code in the log is due to COMP_ENOMEM (7, in T
From: Joe Perches
Date: Tue, 10 Feb 2015 12:55:03 -0800
> Use the normal {} instead of a macro to terminate an array.
>
> Remove the macro too.
>
> Signed-off-by: Joe Perches
I've applied both of your FOO_END removal patches, thanks Joe.
--
To unsubscribe from this list: send the line "unsubs
Okay. Found it. Yes, I was indeed making an assumption. When a signalfd file
descriptor is closed, it doesn't remove any of the signals that were in its
queue. The next time a signalfd file descriptor is opened for the same signal,
therefore, the signal from the closing of the urb on the previou
Hi Geert-san,
Thank you for the reply!
> Hi Shimoda-san,
>
> On Mon, Feb 9, 2015 at 9:16 AM, Yoshihiro Shimoda
> wrote:
> > The usbhsf_pkt_handler(pipe, USBHSF_PKT_DMA_DONE) in usbhsf_dma_complete()
> > will call the complete function of a usb gadget driver finally.
> > According to the gadget.
On Wed, Feb 11, 2015 at 10:49:47AM +, Mark Glover wrote:
> From: Mark Glover
>
> Signed-off-by: Mark Glover
What is different from your previous version? Please address my comments
to that one before resending.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linu
Hi Geert-san,
> Hi Shimoda-san,
>
> On Mon, Feb 9, 2015 at 9:16 AM, Yoshihiro Shimoda
> wrote:
> > Some Renesas SoCs have the USB-DMAC. It is able to terminate transfers
> > when a short packet is received, even if less bytes than the transfer
> > counter size have been received. Also, it is abl
Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
[...]
> > + ocp_data = tp->coalesce / 8;
>
> Why not do it in the initializer?
This is for patch #3. The patch #3 would use this function.
The unit of the relative setting from the ethtool is 1 us.
However, the unit for the hw is
On 2/11/2015 3:42 AM, Roy wrote:
> Hi John Youn:
>
> Could you please give some suggestions from your point of view,
> about this probe time issue ?
>
> Thanks a lot.
>
> at 2015/2/11 2:23, Julius Werner wrote:
>>> @@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
The function regulator_set_optimum_mode() is changing name to
regulator_set_load(), so update the code accordingly.
Signed-off-by: Bjorn Andersson
---
drivers/usb/phy/phy-msm-usb.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c
The function regulator_set_optimum_mode() is changing name to
regulator_set_load(), so update the code accordingly.
Signed-off-by: Bjorn Andersson
---
drivers/usb/phy/phy-ab8500-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drive
Changing the name of the regulator_set_optimum_mode() to
regulator_set_load() better reflects that the API is doing.
This series does the name change and move the current consumers
over.
Bjorn Andersson (5):
regulator: s/regulator_set_optimum_mode/regulator_set_load/
ufs: Rename of regulator_
In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.
Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.
Signed-off-by: G
Sergei Shtylyov; net...@vger.kernel.org
[...]
> > > + ocp_data = tp->coalesce / 8;
> >
> > Why not do it in the initializer?
>
> This is for patch #3. The patch #3 would use this function.
> The unit of the relative setting from the ethtool is 1 us.
> However, the unit for the hw is 8 us. Ther
Hi Geert-san,
> > Still, that would need some better protection, as local_irq_save() disables
> > interrupts only on the CPU it's running on, not on other CPUs in a
> > multiprocessor system.
>
> I see. I will investigate this issue more.
I tried this issue on v3.19 with dmac enabled, it also ca
v2:
For patch #1, replace
u32 ocp_data;
ocp_data = tp->coalesce / 8;
with
u32 ocp_data = tp->coalesce / 8;
And replace
struct net_device *dev = tp->netdev;
u32 ocp_data;
ocp_data = (agg_buf_sz - dev->mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
with
Support setting the rx coalesce. Then someone could change the rx
agg timeout value through ethtool.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/
The rx early size is calculated with the mtu, so it has to be
re-calculated when the mtu is changed.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index
Separate USB_RX_EARLY_AGG into USB_RX_EARLY_TIMEOUT and USB_RX_EARLY_SIZE.
Replace r8153_set_rx_agg() with r8153_set_rx_early_timeout() and
r8153_set_rx_early_size().
Set the default timeout value according to the USB speed.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 58 ++
On 02/11/15 22:25, Bruno Prémont wrote:
> Since 3.19-rcX kernel crashes when I disconnect an external
> HDD drive (not sure since which kernel revision tough early
> 3.19-rcs possibly are not affected).
>
> It looks like this crash is related to the fact that I enable
> multiqueue (CONFIG_SCSI_MQ_
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/usb/hi6220-usb.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/hi6220-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/hi6220-usb.txt
b/Documenta
Add usb phy controller for hi6220 platform
Signed-off-by: Zhangfei Gao
---
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-hi6220-usb.c | 306 +++
3 files changed, 316 insertions(+)
create mode 100644 drivers/p
v4:
Move drivers/usb/phy/phy-hi6220-usb.c to drivers/phy/phy-hi6220-usb.c, required
by Balbi.
Modify dt bindings per comments from Mark and Sergei
v3:
fix typo and add -EPROBE_DEFER of regulator, pointed by Peter
v2:
address comments from Sergei and Peter
add hi6220_phy_setup(false) code
v1:
hi
Signed-off-by: Zhangfei Gao
---
drivers/usb/dwc2/platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index ae095f0..f7c67db 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform
Add necessary dwc2 binding documentation for Hisilicon soc: hi6220
Signed-off-by: Zhangfei Gao
---
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
b/Documentation/devicetree/bindings/usb/dwc2.txt
i
82 matches
Mail list logo
