04.05.2013 00:34, Greg KH пишет:
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the se
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
> 03.05.2013 21:16, Greg KH пишет:
>
> >Sounds like an application is doing a foolish thing and should stop it.
> Its not.
> The app is quering only for _input_ (specifying only read fds
> to select). But the select() in linux is implem
From: Dan Carpenter
Date: Fri, 3 May 2013 09:44:20 +0300
> We're only passing the two high bits of an integer. It works for little
> endian but not for big endian.
>
> Signed-off-by: Dan Carpenter
s/bits/bytes/, applied, and queued up for stable, thanks
--
To unsubscribe from this list: send
* Tony Lindgren [130503 10:55]:
> Looks like we can get VBUS interrupt before the ID interrupt
> at least with a Motorola LapDock if the USB mini-A cable is
> inserted slowly at the omap end. This issue also prevents
> enumerating the LapDock during the boot.
>
> It seems that the issue is caused
Looks like we can get VBUS interrupt before the ID interrupt
at least with a Motorola LapDock if the USB mini-A cable is
inserted slowly at the omap end. This issue also prevents
enumerating the LapDock during the boot.
It seems that the issue is caused by musb getting confused and
trying to do th
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the select() in linux is implemented the way that
even when it polls for input, it will still call tty_
03.05.2013 20:52, Greg KH пишет:
What exactly is the "problem" being seen?
OK, the problem is that while select() "stalls", the entire
output queue is transmitted, and when the app writes
more, there is already a big pause.
In fact, the app calls select() before writing every char,
so then the d
On Fri, May 03, 2013 at 10:05:55PM +0400, Stas Sergeev wrote:
> 03.05.2013 20:52, Greg KH пишет:
> >On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
> >>03.05.2013 20:30, Greg KH пишет:
> >>>We need some way to check the chars in the buffer, is the device you are
> >>>using just very s
03.05.2013 20:52, Greg KH пишет:
On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we c
On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
> 03.05.2013 20:30, Greg KH пишет:
> >We need some way to check the chars in the buffer, is the device you are
> >using just very slow to respond to this request? How slow? Do you have
> >a test case that we can see how it is affected?
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we can see how it is affected?
Greg, unfortunately, I do have nothing.
The customer is in CC list, s
On Fri, May 03, 2013 at 07:02:46PM +0400, Stas Sergeev wrote:
> Hi.
>
> We have a regression because of this patch:
> http://lkml.indiana.edu/hypermail/linux/kernel/1210.1/01456.html
> While it is arguably reasonable to have this for tcdrain or close,
> it also slows down poll/select a lot because
On Fri, 2013-05-03 at 09:39 +0200, Schemmel Hans-Christoph wrote:
> /drivers/net/usb/qmi_wwan.c: Added support for Cinterion's PLxx WWAN
> Interface by adding Cinterion's Vendor ID as well as Product ID and
> QMI_FIXED_INTF.
>
> /drivers/usb/serial/option.c: Added support for Cinterion's PLxx WW
On Tue, 19 Mar 2013, Waskiewicz Jr, Peter P wrote:
> On 3/18/2013 1:35 PM, Greg KH wrote:
> > On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote:
> >> I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS
> >> 12.04.2. This has the latest updates installed, kerne
For all ux500 based platforms the maximum number of end-points are used.
Move this knowledge into the driver so we can relinquish the burden from
platform data. This also removes quite a bit of complexity from the driver
and will aid us when we come to enable the driver for Device Tree.
Cc: Felipe
The dma_mask will always be the same as the coherent_dma_mask, so let's
cut down on the platform_data burden and set it as such in the driver.
This also saves us from supporting it separately when we come to enable
this driver for Device Tree.
Cc: Felipe Balbi
Cc: linux-usb@vger.kernel.org
Acked-
The MUSB HDRC configuration never changes between each of the ux500
supported platforms, so there's little point passing it though platform
data. If we set it in the driver instead, we can make good use of it
when booting with either ATAGs or Device Tree.
Cc: Felipe Balbi
Cc: linux-usb@vger.kerne
If we can ever get to a state where we can solely search for DMA channels
by name, this will almost completely alleviate the requirement to pass
copious amounts of information though platform data. Here we take the
first step towards this. The next step will be to enable Device Tree
complete with n
This patch will allow ux500-musb to be probed and configured solely from
configuration found in Device Tree.
Cc: Felipe Balbi
Cc: Rob Herring
Cc: linux-usb@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Acked-by: Linus Walleij
Acked-by: Fabio Baltieri
Signed-off-by: Lee Jones
---
..
In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.
Cc: Felipe Balbi
Cc: linux-usb@vger.kernel
On Thu, 2 May 2013, Sarah Sharp wrote:
> On Thu, May 02, 2013 at 04:01:32PM -0400, Alan Stern wrote:
> > Sarah:
> >
> > xhci_queue_isoc_tx_prepare() has a comment saying "Always assume
> > URB_ISO_ASAP set". I'd like to see about fixing this, but I don't know
> > where to look. It doesn't see
Hi Laurent,
thank you for the comment.
On 05/03/13 02:05, Laurent Pinchart wrote:
Hi Vladimir,
On Friday 03 May 2013 02:00:29 Vladimir Zapolskiy wrote:
On 05/03/13 01:18, Laurent Pinchart wrote:
On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
This change removes redundant calls to
/drivers/net/usb/qmi_wwan.c: Added support for Cinterion's PLxx WWAN Interface
by adding Cinterion's Vendor ID as well as Product ID and QMI_FIXED_INTF.
/drivers/usb/serial/option.c: Added support for Cinterion's PLxx WWAN Interface
by blacklisting USB Interface 4 (WWAN Port). Renamed Product ID
On Fri, May 03, 2013 at 11:39:00AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 09:32:06AM +0100, Russell King - ARM Linux wrote:
> > On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> > > How about we pass yours for not reading the patch before flaming ?
> >
> > And
Hi,
On Fri, May 03, 2013 at 09:32:06AM +0100, Russell King - ARM Linux wrote:
> On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> > How about we pass yours for not reading the patch before flaming ?
>
> And another thing. If you want to be flamed, continue with that tone.
> The pro
Hi Laurent,
On Fri, May 03, 2013 at 01:20:15AM +0200, Laurent Pinchart wrote:
[snip]
> I'm open to suggestions :-) What features of the userspace application do you
> think could (and should) be moved to kernelspace ? Many of them are highly
> application-specific.
All UVC_EVENTS beneath STREAM
On Fri, May 03, 2013 at 11:30:09AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 09:15:10AM +0100, Russell King - ARM Linux wrote:
> > > > This is exactly why we have platform_device_alloc(),
> > > > platform_device_register_full() and friends - so that people don't have
> > > > to
On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> How about we pass yours for not reading the patch before flaming ?
And another thing. If you want to be flamed, continue with that tone.
The problem here is that *you* have not been flamed in the previous
message. The previous messa
Hi,
On Fri, May 03, 2013 at 09:15:10AM +0100, Russell King - ARM Linux wrote:
> > > This is exactly why we have platform_device_alloc(),
> > > platform_device_register_full() and friends - so that people don't have to
> > > fsck around with kzalloc themselves and get it wrong like the above does.
> We're only passing the two high bits of an integer. It works for little
bytes
> endian but not for big endian.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> index 0969905..03e8a15 100644
> --- a
On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 12:13:53AM +0100, Russell King - ARM Linux wrote:
> > > > > > Signed-off-by: Alexander Shiyan
> > > > > > ---
> > > > > > arch/arm/mach-omap2/usb-host.c | 21 +
> > > > > > 1 file
Teppo Kotilainen writes:
> Information from driver description files:
>
> diag: VID_19D2&PID_0412&MI_00
> nmea: VID_19D2&PID_0412&MI_01
> at:VID_19D2&PID_0412&MI_02
> modem: VID_19D2&PID_0412&MI_03
> net: VID_19D2&PID_0412&MI_04
>
> Signed-off-by: Teppo Kotilainen
> ---
> driv
Information from driver description files:
diag: VID_19D2&PID_0412&MI_00
nmea: VID_19D2&PID_0412&MI_01
at:VID_19D2&PID_0412&MI_02
modem: VID_19D2&PID_0412&MI_03
net: VID_19D2&PID_0412&MI_04
Signed-off-by: Teppo Kotilainen
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed,
Information from driver description files:
diag: VID_19D2&PID_0412&MI_00
nmea: VID_19D2&PID_0412&MI_01
at:VID_19D2&PID_0412&MI_02
modem: VID_19D2&PID_0412&MI_03
net: VID_19D2&PID_0412&MI_04
Signed-off-by: Teppo Kotilainen
---
drivers/usb/serial/option.c | 2 ++
1 file changed
Hi,
Thank you for your support. I had overlooked qmi_wwan. I did some digging and
it seems the modem indeed has a QMI interface (i/f number 4).
I added the interface to blacklist in option, and added it to qmi_wwan. Now I
get /dev/cdc-wdm0 and wwan0 devices. Querying various device information
35 matches
Mail list logo
