On 9/27/2017 11:29 PM, Jack Pham wrote:
> On Wed, Sep 27, 2017 at 02:29:09PM +0530, Manu Gautam wrote:
>> QMP V3 USB3 PHY is a DP USB combo PHY with
>> dual RX/TX lanes to support type-c. There is a
>> separate block DP_COM for configuration related
>> to type-c or DP. Add support for dp_com regi
Shrirang Bagul writes:
> On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
>
>> Don't you want to add these to qmi_wwan as well?
>
> I haven't tested these devices with qmi_wwan. Perhaps a separate patch once
> it's
> verified.
Please do, if you can. I realize that QMI isn't a default conf
On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
> On Fri, Sep 29, 2017 at 12:39:51PM +0800, Shrirang Bagul wrote:
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series which will by default boot with vid 0x413c and pid's 0x81cf,
> > 0x81d0, 0x81d1,0x81d2.
> >
>
Hi Mathias,
On Mon, Sep 25, 2017 at 4:16 PM, Mathias Nyman
wrote:
> On 25.09.2017 10:08, Joe Lee wrote:
>>
>> From: Joe Lee
>>
>> For AMD Promontory xHCI host,
>> although you can disable USB 2.0 ports in BIOSsettings,
>> those ports will be enabled anyway after you remove a device on
>> that po
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly. Since the callback is called from
both a timer and a tasklet, adjust the tasklet to pass the timer address
to
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly. Adds pointer back to hid_device for
multitouch.
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: linux-in...@vge
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Mathias Nyman
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: Thomas Gleixner
Signed-off-by:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: T
I've been trying to figure out how to configure UVC resolution and
format. My understanding is that I need to use descriptors for this,
but don't know which ones. I've been reading through the UVC
(http://www.usb.org/developers/docs/devclass_docs/USB_Video_Class_1_5.zip)
spec for several days now b
Use put_unaligned_le32 rather than using byte ordering function and
memcpy which makes code clear.
Also, add the header file where it is declared.
Done using Coccinelle and semantic patch used is :
@ rule1 @
identifier tmp; expression ptr,x; type T;
@@
- tmp = cpu_to_le32(x);
<+... when != tm
On 9/26/2017 2:44 AM, Mathias Nyman wrote:
> On 25.09.2017 19:09, David Laight wrote:
>> From: Adam Wallis
>>> Sent: 25 September 2017 13:26
>>> inc_deq() currently bails earlier for EVENT rings than the common return
>>> point of the function, due to the fact that EVENT rings do not have
>>> link
On Tue, Oct 03, 2017 at 11:29:40AM +0200, Johan Hovold wrote:
> On Fri, Sep 29, 2017 at 10:37:55AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote:
> > > Hi!
> > >
> > > I've got the following report while fuzzing the kernel with syzkaller.
> >
On Wed, Oct 04, 2017 at 11:01:13AM +0200, Johan Hovold wrote:
> Make sure to reset the USB-console port pointer when console setup fails
> in order to avoid having the struct usb_serial be prematurely freed by
> the console code when the device is later disconnected.
>
> Fixes: 73e487fdb75f ("[PAT
On Wed, Oct 04, 2017 at 11:01:12AM +0200, Johan Hovold wrote:
> A clean-up patch removing removing two redundant NULL-checks from the
> console disconnect handler inadvertently also removed a third check.
> This could lead to the struct usb_serial being prematurely freed by the
> console code when
On Wed, Oct 4, 2017 at 3:12 AM, Richard Leitner
wrote:
>
> On 09/21/2017 07:10 PM, Serge Semin wrote:
>> On Thu, Sep 21, 2017 at 11:26:04AM -0500, Rob Herring
>> wrote:
>>> On Wed, Sep 20, 2017 at 4:27 PM, Serge Semin
>>> wrote:
>
> ...
>
These are different parameters of the device. They
Am Montag, den 02.10.2017, 10:23 +0800 schrieb Daniel Drake:
> On Wed, Sep 27, 2017 at 3:12 PM, Oliver Neukum wrote:
> >
> > 1) kernel version?
>
> Currently testing 4.14.0-rc2 but reproduced on multiple older versions
> too going back to 4.8. (Have not found a working kernel version)
>
> >
>
On Wed, 04 Oct 2017 14:03:25 +0200,
Johan Hovold wrote:
>
> On Wed, Oct 04, 2017 at 12:41:55PM +0200, Takashi Iwai wrote:
> > On Wed, 04 Oct 2017 12:23:11 +0200,
> > Johan Hovold wrote:
> > >
> > > On Wed, Oct 04, 2017 at 12:04:06PM +0200, Takashi Iwai wrote:
> > > > On Wed, 04 Oct 2017 11:24:42
On 04.09.2017 00:38, Martin Blumenstingl wrote:
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Curren
Use the of_device_get_match_data() helper instead of open coding.
Signed-off-by: Geert Uytterhoeven
---
drivers/usb/renesas_usbhs/common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index f0ce304c
Use the of_device_get_match_data() helper instead of open coding.
Signed-off-by: Geert Uytterhoeven
---
drivers/usb/host/xhci-plat.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 163bafde709f79bf..a1b
Use the of_device_get_match_data() helper instead of open coding,
postponing the matching until when it's really needed.
Note that the renesas_usb3 driver is used with DT only, so there's
always a valid match.
Signed-off-by: Geert Uytterhoeven
---
drivers/usb/gadget/udc/renesas_usb3.c | 7 +-
On Wed, Oct 04, 2017 at 12:41:55PM +0200, Takashi Iwai wrote:
> On Wed, 04 Oct 2017 12:23:11 +0200,
> Johan Hovold wrote:
> >
> > On Wed, Oct 04, 2017 at 12:04:06PM +0200, Takashi Iwai wrote:
> > > On Wed, 04 Oct 2017 11:24:42 +0200, Johan Hovold wrote:
> > > > On Wed, Oct 04, 2017 at 08:10:59AM +
On Fri, 29 Sep 2017, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon
Am Dienstag, den 03.10.2017, 16:01 +0200 schrieb Bjørn Mork:
> Adding anything else, e.g. based on the table at
> http://www.usb.org/developers/defined_class/#BaseClassEFh , is a bit
> more risky. We don't know if a driver will work with *any* such device
> until we've actually seen one.
>
> This
On Wed, 04 Oct 2017 12:23:11 +0200,
Johan Hovold wrote:
>
> On Wed, Oct 04, 2017 at 12:04:06PM +0200, Takashi Iwai wrote:
> > On Wed, 04 Oct 2017 11:24:42 +0200, Johan Hovold wrote:
> > > On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
>
> > > > Well, what I had in my mind is just a
On Wed, Oct 04, 2017 at 12:04:06PM +0200, Takashi Iwai wrote:
> On Wed, 04 Oct 2017 11:24:42 +0200, Johan Hovold wrote:
> > On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> > > Well, what I had in my mind is just a snippet from usb_submit_urb(),
> > > something like:
> > >
> > > bo
On 03.10.2017 18:27, Kristian Evensen wrote:
On Tue, Oct 3, 2017 at 4:51 PM, Kristian Evensen
wrote:
Disabling the timer caused a different error to be triggered. Instead
of "HC died...", I now get the following message looping over and
over:
[16870.871935] qmi_wwan 4-1:1.4: Tx URB error: -19
On Wed, 04 Oct 2017 11:24:42 +0200,
Johan Hovold wrote:
>
> On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> > On Tue, 03 Oct 2017 19:42:21 +0200,
> > Greg Kroah-Hartman wrote:
> > >
> > > On Tue, Oct 03, 2017 at 12:50:08PM -0400, Alan Stern wrote:
> > > > On Tue, 3 Oct 2017, Takas
On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> On Tue, 03 Oct 2017 19:42:21 +0200,
> Greg Kroah-Hartman wrote:
> >
> > On Tue, Oct 03, 2017 at 12:50:08PM -0400, Alan Stern wrote:
> > > On Tue, 3 Oct 2017, Takashi Iwai wrote:
> > >
> > > > > It's a dev_WARN because it indicates a
On Wed, Sep 27, 2017 at 04:36:11PM +0200, Andrey Konovalov wrote:
> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.
>
> On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).
>
> gadgetfs: bound to dummy_udc driver
> usb 1-1: new full-speed USB device numbe
A clean-up patch removing removing two redundant NULL-checks from the
console disconnect handler inadvertently also removed a third check.
This could lead to the struct usb_serial being prematurely freed by the
console code when a driver accepts but does not register any ports for
an interface whic
Make sure to reset the USB-console port pointer when console setup fails
in order to avoid having the struct usb_serial be prematurely freed by
the console code when the device is later disconnected.
Fixes: 73e487fdb75f ("[PATCH] USB console: fix disconnection issues")
Cc: stable # 2.6.18
Sig
A recent clean-up patch of mine did more than intended and introduced
the potential for a use-after-free on disconnect under some very
specific circumstances. Fortunately those circumstances were not obscure
enough to prevent Andrey's fuzzing from triggering the bug.
While fixing this one I found
On Wed, Oct 04, 2017 at 10:08:24AM +0200, Takashi Iwai wrote:
> On Wed, 04 Oct 2017 09:52:36 +0200,
> Greg Kroah-Hartman wrote:
> >
> > On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> > > On Tue, 03 Oct 2017 19:42:21 +0200,
> > > Greg Kroah-Hartman wrote:
> > > >
> > > > On Tue, O
On 09/21/2017 07:10 PM, Serge Semin wrote:
> On Thu, Sep 21, 2017 at 11:26:04AM -0500, Rob Herring wrote:
>> On Wed, Sep 20, 2017 at 4:27 PM, Serge Semin wrote:
...
>>> These are different parameters of the device. They got different
>>> configuration
>>> registers and descriptions:
>>> max_p
On Wed, 04 Oct 2017 09:52:36 +0200,
Greg Kroah-Hartman wrote:
>
> On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> > On Tue, 03 Oct 2017 19:42:21 +0200,
> > Greg Kroah-Hartman wrote:
> > >
> > > On Tue, Oct 03, 2017 at 12:50:08PM -0400, Alan Stern wrote:
> > > > On Tue, 3 Oct 2017,
On 09/16/2017 12:42 PM, Serge Semin wrote:
> USB electrical signaling drive strength boost bit is also supported
> by USB2517 hub. Since it got three addition ports, the designers
> needed to add one more register for initialization. It turned out
> to be formerly reserved 0xF7. As before we just
On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> On Tue, 03 Oct 2017 19:42:21 +0200,
> Greg Kroah-Hartman wrote:
> >
> > On Tue, Oct 03, 2017 at 12:50:08PM -0400, Alan Stern wrote:
> > > On Tue, 3 Oct 2017, Takashi Iwai wrote:
> > >
> > > > > It's a dev_WARN because it indicates a
On 09/16/2017 12:42 PM, Serge Semin wrote:
> USB2517 got three additionl downstream ports, which can
> as well be mapped to another logical ports. USB2551xb driver
typo in "USB251xb"
> currently doesn't fully support such setting configuration
> from dts file. This patch doesn't change this, but
Hi Serge,
On 09/16/2017 12:42 PM, Serge Semin wrote:
> There are USB2517 and USB2517i hubs, which have almost the same
> registers space as already supported USB251xbi series. The difference
> it in DIDs and in few functions. This patch adds the USB2517/i data
> structures to the driver, so it wou
On 09/16/2017 12:42 PM, Serge Semin wrote:
> USB251xb as well as USB2517 datasheet states, that all these
> hubs differ by number of ports declared as the last digit in the
> model name. So USB2512 got two ports, USB2513 - three, and so on.
> Such setting must be reflected in the device specific d
Hi,
W dniu 04.10.2017 o 06:22, Kishon Vijay Abraham I pisze:
Hi,
@Kishon:
As far as I understand what you suggest is to move phy_init() and
phy_power_on() invocations from dwc3/core.c to xhci-plat, but,
to the best of my knowledge, they are needed in device mode, too.
What I meant is p
42 matches
Mail list logo
