Hi George,
On 2014-05-02 07:54, George Cherian wrote:
Hi Leigh,
Can you please try out 3.15.0-rc3 with the attached config.
Thanks, that works (I can't believe it was that easy)! I'll use that as
a known-good config and then try to tweak the config to how I like it.
Regards,
Leigh.
--
T
Hi Tomasz,
On Thu, May 1, 2014 at 10:46 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Please see my comments inline.
Thanks for the review, please find my answers inline.
>
>
> On 30.04.2014 07:19, Vivek Gautam wrote:
>>
>> Add support to consume phy provided by Generic phy framework.
>> Keeping the
Bestätigen Sie Ihre 500,000,00 Euro
--
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
On Fri, May 2, 2014 at 2:55 PM, Vivek Gautam wrote:
> Hi Tomasz,
>
>
> On Thu, May 1, 2014 at 10:46 PM, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Please see my comments inline.
>
> Thanks for the review, please find my answers inline.
>
>>
>>
>> On 30.04.2014 07:19, Vivek Gautam wrote:
>>>
>>> Add su
01.05.2014 23:51, Felipe Balbi пишет:
I don't think you need that. Have tusb_get_revision() run only one
during tusb6010 probe/init function and cache the returned value inside
musb->revision or something like that, then remove all other calls to
tusb_get_revision() and have tusb6010_omap.c check
Hello
I have seen on the list that there was a previous interest on giving
support for this chipset. Is anyone currently working on it?
Apparently the chip can be configured in "legacy mode" being register
compatible with the net2280 chipset. Has this been tested?
The driver from the manufacture
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the s
From: Kamil Debski
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the d
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam
Acked-by: Alan Stern
Acked-by: Jingoo Han
---
Changes from v2:
- none
drivers/usb/host/ehci-exynos.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam
Acked-by: Alan Stern
Acked-by: Jingoo Han
---
Changes from v2:
- none
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 9 insertions(+), 11 deletion
Based and tested on 'usb-next' branch of Greg's usb tree, with relevant
device tree patches[1]
Hi Alan,
I have included your Acked-by in all the four patches, but there has been
some amount of restructuring as suggested by Tomasz Figa.
Please let me know if you have some comments on this patch-
On 05/02/14 21:47, Vivek Gautam wrote:
Based and tested on 'usb-next' branch of Greg's usb tree, with relevant
device tree patches[1]
Hi Alan,
I have included your Acked-by in all the four patches, but there has been
some amount of restructuring as suggested by Tomasz Figa.
Please let me k
Hi,
On Fri, May 02, 2014 at 02:11:30PM +0200, Ricardo Ribalda Delgado wrote:
> I have seen on the list that there was a previous interest on giving
> support for this chipset. Is anyone currently working on it?
no
> Apparently the chip can be configured in "legacy mode" being register
> compatib
On Fri, May 02, 2014 at 08:49:05AM +0300, Ivan T. Ivanov wrote:
> On Wed, 2014-04-30 at 11:27 -0500, Felipe Balbi wrote:
> > On Thu, Apr 24, 2014 at 06:48:11PM +0300, Ivan T. Ivanov wrote:
> > > From: Tim Bird
> > >
> > > Fix the value used for Parallel Transceiver Select (PTS) for the MSM USB
>
On Thu, 1 May 2014, Dan Williams wrote:
> On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
> > On Wed, 19 Mar 2014, Dan Williams wrote:
> [..]
> >> --- a/drivers/usb/core/port.c
> >> +++ b/drivers/usb/core/port.c
> >> @@ -104,6 +104,8 @@ static int usb_port_runtime_resume(struct device *dev)
>
On Mon, Apr 28, 2014 at 08:39:47AM +0800, Li Zhong wrote:
> Yes, maybe try to get the module reference is not bad before writing to
> driver attributes, as it doesn't make much sense to really call the
> callbacks for the driver attribute if the driver is being unload.
Please don't do that spuriou
On Wed, Apr 30, 2014 at 09:36:01PM -0400, Michal Nazarewicz wrote:
> On Thu, Apr 24 2014, Andrzej Pietrasiewicz wrote:
> > There is a custom (non-USB IF) extension to the USB standard:
> >
> > http://msdn.microsoft.com/library/windows/hardware/gg463182
> >
> > The said extension is maintained by Mi
Hi,
On Thu, May 01, 2014 at 10:15:00AM -0500, Felipe Balbi wrote:
> On Thu, May 01, 2014 at 09:45:17AM -0400, Alan Stern wrote:
> > On Thu, 1 May 2014, Zhuang Jin Can wrote:
> > > > again, you found a bug on the gadget driver. Fix that. composite.c
> > > > guarantees that for those functions which
Hi,
On Thu, May 01, 2014 at 10:13:28AM -0500, Felipe Balbi wrote:
> On Thu, May 01, 2014 at 04:44:52PM -0400, Zhuang Jin Can wrote:
> > On Wed, Apr 30, 2014 at 02:58:29PM -0500, Felipe Balbi wrote:
> > > On Thu, May 01, 2014 at 02:36:08AM -0400, Zhuang Jin Can wrote:
> > > > At least we should giv
Hi,
On Sat, May 03, 2014 at 12:05:41AM -0400, Zhuang Jin Can wrote:
> On Thu, May 01, 2014 at 10:13:28AM -0500, Felipe Balbi wrote:
> > On Thu, May 01, 2014 at 04:44:52PM -0400, Zhuang Jin Can wrote:
> > > On Wed, Apr 30, 2014 at 02:58:29PM -0500, Felipe Balbi wrote:
> > > > On Thu, May 01, 2014 a
Hi Vivek,
This looks much better, but there still are some issues. Please see my
comments inline.
On 02.05.2014 14:47, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionalit
On Thu, 1 May 2014, Dan Williams wrote:
> I've been testing this and the pm_request_resume() ends up leaving the
> usb device enabled indefinitely. It needs to be paired with a
> pm_runtime_autosuspend(), but at that point why not just add a
> usb_autoresume_device_async() helper.
Why didn't pm_
On Tue, 22 Apr 2014, Russel Hughes wrote:
> > More importantly, the routine sets urb->start_frame to the current
> > value of the frame counter. This is completely wrong; urb->start_frame
> > is supposed to be the (micro-)frame number for when the transfer
> > begins, not when the transfer was su
Lots of devices request much larger buffers than reasonable. This
cause real problems for users of hosts with limited resources.
Reducing the default buffer size to 16kB for such devices is
a reasonable trade-off between allowing them to aggregate traffic
and avoiding memory exhaustion on resource
Split out the part of setup dealing with updating the rx_max
and tx_max buffer sizes so that this code can be reused for
dynamically updating the limits.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 81 +--
1 file changed, 50 insertions(+)
Finish the rx_max/tx_max setup by flushing buffers and
informing usbnet about the changes. This way, the settings
can be modified while the netdev is up and running.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 31 +--
1 file changed, 25 insertions(+), 6
Datagram coalescing is an integral part of the NCM and MBIM
protocols, intended to reduce the interrupt load primarily
on the device end of the USB link. As with all coalescing
solutions, there is a trade-off between buffering and
interrupts.
The current defaults are based on the assumption that
To have an idea of the effects of the protocol coalescing
it's useful to have some counters showing the different
aspects.
Due to the assymetrical usbnet interface the netdev
rx_bytes counter has been counting real received payload,
while the tx_bytes counter has included the NCM/MBIM
framing over
We pad frames larger than X to maximum size for devices which
don't need a ZLP after maximum sized frames. This allows the
device to optimize its transfers for one fixed buffer size.
X was arbitrarily set at 512 bytes regardless of real buffer
maximum, causing extreme overheads due to excessive pa
Split the parts of setup dealing with device initialization from
parts just setting defaults for attributes which might be
changed after initialization.
Some commands of the device initialization are only allowed when
the data interface is in its disabled altsetting, so we must
separate them out o
Now that we have split out the part of the device setup
which MUST be done with the data interface in altsetting 0,
we can delay the rest of the initialization. This allows us
to move some of post-init buffer size config from bind to
the appropriate setup function.
The purpose of this refactoring
I have got quite a few reports from frustrated users of OpenWRT
hosts trying to use some powerful LTE modem, but not achieving
full speed. This is typically caused by a combination of
big buffers and little memory, giving in allocation errors and
bad performance as a result.
This series is an att
Many newer NCM and MBIM devices will request a maximum tx
datagram count which is much smaller than our hardcoded
absolute max. We can reduce the overhead without sacrificing
any of the simplicity for these devices, by simply using the
true negotiated count in when calculated the maximum NTH and
ND
Commit 4d619f625a60 ("net: cdc_ncm: no point in filling up the NTBs
if we send ZLPs") changed the padding logic for devices with the ZLP
flag set. This meant that frames of any size will be sent without
additional padding, except for the single byte added if the size is
a multiple of the USB packe
Fixes this warning introduced by commit 5b8f15f78e6f
("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):
===
[ INFO: suspicious RCU usage. ]
3.15.0-rc3 #213 Tainted: GW O
---
net/8021q/vlan_core.c:69 suspicious rcu_dereference_chec
On Fri, 2014-05-02 at 23:28 +0200, Bjørn Mork wrote:
> Fixes this warning introduced by commit 5b8f15f78e6f
> ("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):
>
> ===
> [ INFO: suspicious RCU usage. ]
> 3.15.0-rc3 #213 Tainted: GW O
> -
On Fri, May 02, 2014 at 02:11:30PM +0200, Ricardo Ribalda Delgado wrote:
> Hello
>
> I have seen on the list that there was a previous interest on giving
> support for this chipset. Is anyone currently working on it?
>
> Apparently the chip can be configured in "legacy mode" being register
> comp
Hi,
On Fri, May 02, 2014 at 03:22:07PM -0700, Amit Uttamchandani wrote:
> On Fri, May 02, 2014 at 02:11:30PM +0200, Ricardo Ribalda Delgado wrote:
> > Hello
> >
> > I have seen on the list that there was a previous interest on giving
> > support for this chipset. Is anyone currently working on it
We use usb ehci to connect with modem and run stress test on ehci
remote wake. Sometimes usb disconnect. We add more debug ftrace
(Kernel version: 3.10) and list the key log to show how problem
happened.
-0 [000] d.h2 26879.385095: ehci_irq: irq status 1008c PPCE FLR PCD
-0 [000] d.h2 2687
On Mon, 2014-04-28 at 16:34 +0300, Ivan T. Ivanov wrote:
> From: Tim Bird
>
> Select the secondary PHY using the TCSR register, if phy-num=1
> in the DTS (or phy_number is set in the platform data). The
> SOC has 2 PHYs which can be used with the OTG port, and this
> code allows configuring the
On Wed, 2014-04-30 at 11:38 -0500, Felipe Balbi wrote:
> this solves the following build warning found when
> running compile tests.
>
> drivers/usb/phy/phy-msm-usb.c: In function ‘msm_otg_read_dt’:
> drivers/usb/phy/phy-msm-usb.c:1459:20: warning: cast from pointer \
> to integer of differe
On Wed, 2014-04-30 at 11:38 -0500, Felipe Balbi wrote:
> Remove that single instance of writel_relaxed()
> call which is only available on ARM architecture.
>
> This will let us build test this driver on all
> different architectures.
>
> Signed-off-by: Felipe Balbi
Reviewed-by: Ivan T. Ivanov
42 matches
Mail list logo
