On Sat, Jul 14, 2012 at 16:20:12 -0400, Alan Stern wrote:
...
> The usbmon trace doesn't show any reason for the write failures; the
> second bug interferes before the device can report a reason. Working
> around that other bug isn't quite so easy as the first -- it requires a
> kernel patch (bel
Bjørn Mork writes:
> Anyone? Should I just submit this set as-is?
>
> New "Gobi 4000" device IDs are popping up as laptop vendors start
> selling these things pre-installed. Just noticed Lenovo adding MC7700
> and MC7750 modules using different vendor IDs from the MC77xx we've got
> covered.
On Sun, Jul 15, 2012 at 13:24:04 +0300, Sami Farin wrote:
> On Sat, Jul 14, 2012 at 16:20:12 -0400, Alan Stern wrote:
> ...
> > The usbmon trace doesn't show any reason for the write failures; the
> > second bug interferes before the device can report a reason. Working
> > around that other bug i
Hi Oleksij,
On Monday 09 July 2012 07:35:54 Oleksij Rempel wrote:
> Am 08.07.2012 23:35, schrieb Laurent Pinchart:
> > On Sunday 08 July 2012 10:45:45 Oleksij Rempel wrote:
> >> On 08.07.2012 09:22, Eric Ding wrote:
> >>> On 07/08/2012 02:52 PM, Oleksij Rempel (fishor) wrote:
> Hi, can you pl
Hi Eric,
On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
> On 07/09/2012 10:17 PM, Alan Stern wrote:
> > On Sun, 8 Jul 2012, Jonathan Nieder wrote:
> >> Eric Ding wrote:
> >>> So it looks like you'd have to both look for USB_CLASS_VIDEO and check
> >>> uvc_ids[] too... which becomes somewhat ha
On 07/15/2012 08:21 PM, Laurent Pinchart wrote:
> On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
>> So... now what, then? Who decides which is the better of two evils:
>> obvious code duplication vs. layering violation? FWIW, it does seem
>> like the number of Logitech webcams which aren't US
Hi Eric,
On Sunday 15 July 2012 20:24:26 Eric Ding wrote:
> On 07/15/2012 08:21 PM, Laurent Pinchart wrote:
> > On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
> >> So... now what, then? Who decides which is the better of two evils:
> >> obvious code duplication vs. layering violation? FWIW,
On Sun, 15 Jul 2012, Laurent Pinchart wrote:
> Hi Eric,
>
> On Sunday 15 July 2012 20:24:26 Eric Ding wrote:
> > On 07/15/2012 08:21 PM, Laurent Pinchart wrote:
> > > On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
> > >> So... now what, then? Who decides which is the better of two evils:
> >
On 2012-07-12 16:54, Alan Stern wrote:
> On Thu, 12 Jul 2012, Udo van den Heuvel wrote:
>
>> # cat /proc/interrupts
(...)
>> 18: 25190 18052161 21311 IO-APIC-fasteoi
>> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
(...)
>> So what can we conclude?
> The conclusion is that
On 2012-07-15 16:28, Udo van den Heuvel wrote:
> After disabling:
And somewhat later:
bus pci, device :00:12.0
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x083 HCFS=operational CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0024 FNO SF
intr
Patches 1-3 are the exact same as previously posted as RFC, except
for updated commit messages and descriptions, incorporating one
spelling fix from Sergei Shtylyov
Patch 4 has been reduced to code changes only, moving all device
ID updates to patch 5.
Patch 5 has been updated with the MC7710 ID
No need to replicate the same code all over the place.
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/qcserial.c | 49 ++---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index
Creating a common exit path from qcprobe to make it
easier to extend it.
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/qcserial.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 74e0b13
Preparing qcprobe support for more than just strict
Gobi 1k or 2k+ devices. Many newer Qualcomm based
devices provide the same serial ports, but using
varying USB interface layouts.
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/qcserial.c | 44 -
1 f
No need to verify the interface layout when doing
interface number based matching. We can safely trust
the device ID table in this case.
This allows the driver to support any USB interface
layout for non-Gobi 1k/2k+ devices.
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/qcserial.c |7 ++
The QMI mode of the Sierra Wireless MC7710 is close to
a Gobi device, and also identified as one by the
Windows drivers provided by Sony. The serial interfaces
are the same as for any other Gobi module, but the USB
interface layout is different:
0: DM/DIAG (also present in bootloader mode)
2: N
The MC7710 in QMI mode does not support the vendor
specific USB requests used by this driver. The most
noticable effect of this is a 5 second delay as each
serial port is probed, caused by the set_power_state
command timing out:
[ 17.434291] usbcore: registered new interface driver sierra
[
On Sun, 15 Jul 2012, Sami Farin wrote:
> On Sun, Jul 15, 2012 at 13:24:04 +0300, Sami Farin wrote:
> > On Sat, Jul 14, 2012 at 16:20:12 -0400, Alan Stern wrote:
> > ...
> > > The usbmon trace doesn't show any reason for the write failures; the
> > > second bug interferes before the device can rep
On Sun, 15 Jul 2012, Udo van den Heuvel wrote:
> > The conclusion is that ohci-hcd is the only driver using IRQ 18. If
> > you build a kernel with CONFIG_USB_DEBUG enabled, it will be possible
> > to see if the OHCI hardware is responsible for the IRQ problem.
> >
> > When the IRQ line gets di
On 2012-07-15 17:35, Alan Stern wrote:
> echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/unbind
Afterwards I did:
> echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/bind
And I saw:
Jul 15 17:50:30 surfplank2 kernel: ohci_hcd :00:13.1: remove, state 1
Jul 15 17:50:30 surfplank2 kernel: usb
On 2012-07-15 17:55, Udo van den Heuvel wrote:
> After doing this I could modprobe pwc and start mrtg without problem.
Euh: s/mrtg/motion/
Udo
--
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 htt
On Sun, 15 Jul 2012, Udo van den Heuvel wrote:
> On 2012-07-15 17:35, Alan Stern wrote:
> > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/unbind
>
> Afterwards I did:
>
> > echo :00:13.1 >/sys/bus/pci/drivers/ohci_hcd/bind
Um, I think you missed the point. The whole idea of the test is
Sascha & Shawn, Felipe & Alex,
What's your opinion where I put this driver? The usbmisc drivers is
SoC specific and provide callbacks to ci13xxx_imx driver at runtime.
- How to organize the driver
This patch is designed to put all per-soc driver in one file. But
I plan to put it in discrete files
On 07/13/2012 10:41 PM, Matt Causey wrote:
On Fri, Jul 13, 2012 at 7:13 AM, Andiry Xu wrote:
On 07/13/2012 09:56 AM, Matt Causey wrote:
On Thu, Jul 12, 2012 at 12:54 PM, Matt Causey
wrote:
On Thu, Jul 12, 2012 at 2:04 AM, Andiry Xu wrote:
On 07/12/2012 10:53 AM, Matt Causey wrote:
On
This patch adds support to parse probe data for
ehci driver for exynos using device tree
Signed-off-by: Thomas Abraham
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 13c179f..37d84cf 100644
--- a/drivers/
This patch adds support to parse probe data for
ohci driver for exynos using device tree.
Signed-off-by: Thomas Abraham
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 8bcbdb5..fc3091b 100644
--- a/d
Changes from v1:
1) Moved "struct of_device_id exynos_ehci_match[]"
to the next of "struct dev_pm_ops s5p_ehci_pm_ops" in ehci-s5p.c.
2) Rebased on 'usb-next' branch.
Vivek Gautam (3):
USB: ohci-exynos: Add support for device tree
USB: ehci-s5p: Add support for device tree
USB: ehci-s5p: Add
This patch retrieves and configures the vbus control gpio via
the device tree. The suspend/resume callbacks will be later
modified for vbus control.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 37d84cf..
Changes from v1:
1) Rebased on 'usb-next' branch.
Vivek Gautam (2):
USB: dwc3-exynos: Add support for device tree
USB: dwc3-exynos: Add vbus setup function to the exynos dwc3 glue
layer
drivers/usb/dwc3/dwc3-exynos.c | 47
1 files changed, 47 in
This patch adds support to parse probe data for
dwc3 driver for exynos using device tree
Signed-off-by: Praveen Paneri
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/d
This patch retrieves and configures the vbus control gpio via
the device tree. The suspend/resume callbacks will be later
modified for vbus control.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 25 +
1 files changed,
On Monday, July 16, 2012 2:56 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ohci driver for exynos using device tree.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
>
> diff --git a/driv
On Monday, July 16, 2012 2:56 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ehci driver for exynos using device tree
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
>
> diff --git a/drive
On Monday, July 16, 2012 2:56 PM, Vivek Gautam wrote:
>
> This patch retrieves and configures the vbus control gpio via
> the device tree. The suspend/resume callbacks will be later
> modified for vbus control.
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
Acked-by: Jingoo
34 matches
Mail list logo
