Add the volume control quirk for avoiding the kernel warning for the Logitech HD
Webcam C525 as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2
(ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310) for
the Logitech HD Webcam C310.
Reported-by: Maksim Boyko
T
USB_CHIPIDEA_HOST does not need to depend on USB=y, USB_CHIPIDEA_HOST will work
just fine even if USB=m is used. The depends line can be safely removed since
USB_CHIPIDEA already depends on USB.
Tested on Gateworks imx6q Ventana board (gw-5400-a) and imx6dl Wandboard Dual
(imx6dl-wandboard).
Sign
From: Mark Brown
Since we only enable the PHY clock on init and the PHY init and shutdown
does not occur in atomitc context there is no need to prepare the clock
before it is enabled. Move the clk_prepare() operations to go along
with the enables, allowing the clock to be fully idle when not in
Fix probe of Rigol devices on big-endian machines. A quirk for these
devices was introduced by commit c2e314835 ("USB: usbtmc: Set
rigol_quirk if device is listed") but was only enabled on little-endian
machines.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold
---
drivers/usb/class/usbtmc
Make sure the reported device-type on big-endian machines is the same as
on little-endian ones.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold
---
drivers/usb/misc/adutux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/ad
Fix bug in device-type detection on big-endian machines originally
introduced by commit 0eafe4de ("USB: serial: mos7840: add support for
MCS7810 devices") which always matched on little-endian product ids.
Reported-by: kbuild test robot
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold
---
These fixes for v3.11 fix a few issues on big-endian machines due to
drivers matching directly on little-endian descriptor fields.
The mos7840 bug was discovered by the kbuild test robot
() after a recent change 40c24f28 ("USB:
mos7840: fix device-type detection") which fixed a different problem
w
Fix endianess bugs in firmware handling introduced by commits cb7a7c6a
("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905
("ti_usb_3410_5052: support alternate firmware") which made the driver
use the wrong firmware for certain devices on big-endian machines.
Cc: sta...@vger.kernel.or
Hello,
I got a USB modem from Smartfren Provider (Indonesia) which is not
identified by default by any driver. Manually loading driver via new_id
is so hard for some people. So that, I'd like to get this modem working
by default after successful mode switching.
Here is the detail of new modems
Am Sonntag, 11. August 2013, 15:08:26 schrieben Sie:
> Hello,
..
> 1. Smartfren xStream e781a with vid 0x1bbb and pid 0x0106
> 2. Smartfren AC682 with vid 0x19d2 and pid 0xffdd
> I have tested those modems. They run perfectly with option usb serial
> driver (/sys/bus/usb-serial/drivers/option1/new_
Hello.
On 08/11/2013 12:39 PM, Maksim A. Boyko wrote:
Add the volume control quirk for avoiding the kernel warning for the Logitech HD
Webcam C525 as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2
(ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310) for
t
Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice cover only non-enumerable buses. This generally
makes sense wher
Reorder the kernel doc comments for 'struct dwc2_core_params' to
match the ordering in the struct itself. Reorder the members of
'struct dwc2_qh' (and its kerneldoc comments) to minimize the
amount of structure padding.
Signed-off-by: Paul Zimmerman
---
drivers/staging/dwc2/core.h | 34 +
Here is the second version of the microframe scheduler patch, in
response to Matthijs' review. This one splits out the NAK holdoff
changes and some code rearrangement into separate patches. It also
removes some code and variables that were not used because the FIQ
code from the downstream Pi driver
From: Dom Cobley
Add the NAK holdoff patch from the downstream Raspberry Pi kernel.
This allows the transfer scheduler to better handle "cheeky devices
that just hold off using NAKs".
[original patch from Dom Cobley]
Signed-off-by: Dom Cobley
[adapted to dwc2 driver by Paul Zimmerman]
Signed-of
From: Dom Cobley
The transfer scheduler in the dwc2 driver is pretty basic, not to
mention buggy. It works fairly well with just a couple of devices
plugged in, but if you add, say, multiple devices with periodic
endpoints, the scheduler breaks down and can't enumerate all the
devices.
To improv
After commit 09fc7d22b024692b2fe8a943b246de1af307132b (usb: musb: fix incorrect
usage of resource pointer), CPPI DMA driver on DaVinci DM6467 can't detect its
dedicated IRQ and so the MUSB IRQ is erroneously used instead. This is because
only 2 resources are passed to the MUSB driver from the DaV
Hello.
On 08/11/2013 03:08 AM, Sergei Shtylyov wrote:
I have basically two questions on this change:
[...]
2) why you omitted am35x.c from this commit?
mistake
Are you going to fix it, or should I?
I'm just not sure how many resources there are with all these hwmod
compl
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown wrote:
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?
There is precedence for describing enumerated
On Sun, Aug 11, 2013 at 02:25:48PM -0700, Thomas D. Dean wrote:
> [1.] One line summary of the problem:
> [Bug 1151622] [ASUS P9X79 PRO] The usb driver appears to fail
>
> [2.] Full description of the problem/report:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1151622
> The console cont
On Wed, Aug 07, 2013 at 08:28:24PM +0100, Mark Brown wrote:
> From: Mark Brown
>
> The intn and connect GPIO properties are swapped in the code which will
> cause failures at runtime if these are connected, fix the code.
>
> There are currently no in-tree users of this device to check or update.
On 08/11/13 15:41, Greg KH wrote:
I tried linux 3.2.0-40, 3.2.0-5, 3.9.0-7, and, 3.10.5-031005.
The problem started back in 3.2.0-39. Here is a git bisect log
# bad: [ba89d2a7ca8233e29c9fdeabefb7fdbb6775626e] UBUNTU: Ubuntu-3.2.0-39.62
# good: [1420ada1a002d99e49d68d60a72f29ba58376b90] UBUNTU:
Greg:
Hello. We are sorry Thomas did not make it clear his testing was in
the latest upstream kernel (v3.11-rc4).
We have meticulously documented that anyone from the Ubuntu community
posting bugs upstream need to test the latest upstream kernel, and
make this distinctly clear, as I advised Thoma
On Sun, Aug 11, 2013 at 01:00:49PM +0200, Luka Perkov wrote:
> USB_CHIPIDEA_HOST does not need to depend on USB=y, USB_CHIPIDEA_HOST will
> work
> just fine even if USB=m is used. The depends line can be safely removed since
> USB_CHIPIDEA already depends on USB.
>
> Tested on Gateworks imx6q Ven
On 08/02/2013 03:31 PM, Felipe Balbi wrote:
Hi,
On Fri, Aug 02, 2013 at 01:15:33PM +0800, Qiao Zhou wrote:
On 08/01/2013 06:21 PM, Qiao Zhou wrote:
v2->v1:
stop pcm stream instead of wake up the sleep thread, which is more
reasonable.
Qiao Zhou (1):
usb: gadget: audio file: wake up sleep t
On Sun, 11 Aug 2013, Mark Brown wrote:
> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration. Similarly currently all the DT bindings in the kernel I've
> been able to notice cover only non-en
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration. Similarly currently all the DT bindings in the kernel I've
> been able to noti
For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role switches.
When the host roles begins, it opens v
The vbus regulator is a common element for USB vbus operation,
So, move it from glue layer to core.
Tested-by: Marek Vasut
Signed-off-by: Michael Grzeschik
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 26 ++
drivers/usb/chipidea/core.c|
This patchset adds tested otg id switch function and vbus connect
and disconnect detection for chipidea driver. And fix kinds of
bugs found at chipidea drivers after enabling id and vbus detection.
This patch are fully tested at imx6 sabresd and imx28evk platform by me.
Besides, marek tested it o
When the gadget role starts, we need to make sure the vbus is lower
than OTGSC_BSV, or there will be an vbus interrupt since we use
B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
When the host role starts, it may not be useful to wait vbus to lower
than OTGSC_BSV, but it can
CI_HDRC_REGS_SHARED stands for the controller registers is shared
with other USB drivers, if all USB drivers are at chipidea/, it doesn't
needed to set.
CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This
flag doesn't need to set if the vbus is always on for gadget
since dp has al
This file is mainly used to access otgsc currently, it may
add otg related things in the future.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/Makefile |2 +-
drivers/usb/chipidea/bits.h | 10 ++
drivers/usb/chipidea/core.c |3 ++-
drivers/usb/c
- The role's init will be called at probe procedure.
- The role's destroy will be called at fail patch
at probe and driver's removal.
- The role's start/stop will be called when specific
role has started.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 10 ++
Currently, the controller only runs when the ci->vbus_active is true.
So the flag CI_HDRC_PULLUP_ON_VBUS is useless no longer.
If the user doesn't have otgsc, he/she needs to change ci_handle_vbus_change
to update ci->vbus_active.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c
Since we need otgsc to know vbus's status at some chipidea
controllers even it is peripheral-only mode. Besides, some
SoCs (eg, AR9331 SoC) don't have otgsc register even
the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the
co
Move otg related things to otg file.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 63 +--
drivers/usb/chipidea/otg.c | 57 +-
drivers/usb/chipidea/otg.h |2 +
3 files chan
It is useless at below cases:
- If we implement both usb host and device at chipidea driver.
- If we don't need phy->otg.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/ch
We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc)
to know it is connect or disconnet event.
Meanwhile, we introduce two flags id_event and b_sess_valid_event to
indicate it is an id interrupt or a vbus interrupt.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drive
During the initialization, it needs to disable all interrupts
enable bit as well as clear all interrupts status bits to avoid
exceptional interrupt.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletion
For chipidea, the IP must know vbus before the controller
begins to run. So the .pullup should only be called when
the vbus is there.
Tested-by: Marek Vasut
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/driver
[1]
045e:0721 Microsoft LifeCam NX-3000 not detected
[2]
Since upgrate from quantal to raring I have the a problem with the webcam
"Microsoft LifeCam NX-3000". The webcam doesn't work.
The last good kernel is 3.8.0-15.25, while the bug first appears with kernel
3.8.0-16.26.
In /var/log/sysl
Separate the TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Acked-by:
Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Acked-
Separate the TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Acked-by: Al
On Thu, Aug 8, 2013 at 7:55 PM, Sarah Sharp
wrote:
> I've heard there's little to do at the software level, but I haven't
> been following the spec closely.
As I see it at least there has to be some framework that needs to
support USB PD specific class requests and also some framework to
manage U
Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Acked-by: Ala
Separate the Samsung OHCI S3C24xx/S3C64xx host controller driver
from ohci-hcd host code so that it can be built as a separate
driver module.This work is part of enabling multi-platform
kernels on ARM;it would be nice to have in 3.12.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.
Signed-off-by: Manjunath Goudar
Signed-off-by: Deepak Saxena
Acked-by: Al
On 12 August 2013 12:16, Manjunath Goudar wrote:
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
You really want it in 3.11, we are already at 3.11-rc5 :)
Whatever you write here gets in git history with your patch and I
am sure you never wanted
50 matches
Mail list logo
