Am Donnerstag, den 03.05.2018, 08:24 +0800 schrieb Li Jun:
> +Optional properties for usb-c-connector:
> +- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
> + connector has power support.
> +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
> + or Tr
On 03/05/18 05:49, Faiz Abbas wrote:
> Hi Everyone,
>
> On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
>> On Wed, 11 Apr 2018 14:11:52 +0100,
>> Bockholdt Arne wrote:
>>>
>>> Hi all,
>>>
>>> is there anything new, I've just tried the new stable 4.16.1 kernel
>>> without any change. The R
Hello!
On 5/3/2018 3:24 AM, Li Jun wrote:
From: Peter Chen
With that we can clear any pending events and the port is registered
so driver can be ready to handle typec events once we request irq.
Signed-off-by: Peter Chen
Signed-off-by: Li Jun
---
drivers/staging/typec/tcpci.c | 15 ++
On 5/3/2018 11:29 AM, Sergei Shtylyov wrote:
From: Peter Chen
With that we can clear any pending events and the port is registered
so driver can be ready to handle typec events once we request irq.
Signed-off-by: Peter Chen
Signed-off-by: Li Jun
---
drivers/staging/typec/tcpci.c | 15
Hi
> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.com]
> Sent: 2018年5月3日 15:27
> To: Jun Li ; robh...@kernel.org;
> heikki.kroge...@linux.intel.com; gre...@linuxfoundation.org;
> li...@roeck-us.net
> Cc: gso...@gmail.com; dl-linux-imx ; Peter Chen
> ; shufan_...@richtek.com
Hi Marc,
On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote:
> On 03/05/18 05:49, Faiz Abbas wrote:
>> Hi Everyone,
>>
>> On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
>>> On Wed, 11 Apr 2018 14:11:52 +0100,
>>> Bockholdt Arne wrote:
Hi all,
is there anything new,
Am Donnerstag, den 03.05.2018, 08:35 + schrieb Jun Li:
> Hi
> > -Original Message-
> > From: Oliver Neukum [mailto:oneu...@suse.com]
> > Sent: 2018年5月3日 15:27
> > To: Jun Li ; robh...@kernel.org;
> > heikki.kroge...@linux.intel.com; gre...@linuxfoundation.org;
> > li...@roeck-us.net
> >
Hi,
Beginning with Linux 4.16 rc7 (4.16 rc6 was NOT affected), I do find the
following regularly in dmesg (often it does not happen during boot, but
after suspend to ram / resume):
[ 216.443309] pcieport :00:1c.0: AER: Corrected error received: id=00e0
[ 216.443951] pcieport :00:1c.
On 03/05/18 09:42, Faiz Abbas wrote:
> Hi Marc,
>
> On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote:
>> On 03/05/18 05:49, Faiz Abbas wrote:
>>> Hi Everyone,
>>>
>>> On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
On Wed, 11 Apr 2018 14:11:52 +0100,
Bockholdt Arne wrote:
>>
On 3 May 2018 at 11:41, Marc Zyngier wrote:
> On 03/05/18 09:42, Faiz Abbas wrote:
>> Hi Marc,
>>
>> On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote:
>>> On 03/05/18 05:49, Faiz Abbas wrote:
Hi Everyone,
On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
> On Wed, 11
Hi Manu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on phy/next]
[also build test ERROR on v4.17-rc3 next-20180503]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On 02.05.2018 20:52, Alan Stern wrote:
On Wed, 2 May 2018, Mathias Nyman wrote:
On 24.04.2018 16:50, Alan Stern wrote:
On Tue, 24 Apr 2018, Mathias Nyman wrote:
In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should prevent the controller from going
back int
On 03.05.2018 14:37, Mathias Nyman wrote:
On 02.05.2018 20:52, Alan Stern wrote:
On Wed, 2 May 2018, Mathias Nyman wrote:
On 24.04.2018 16:50, Alan Stern wrote:
On Tue, 24 Apr 2018, Mathias Nyman wrote:
In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should
Hi Amr,
On 5/2/2018 3:57 PM, Amr Bekhit wrote:
>> Could you please apply follow patches from linux-usb mailing list:
>> 1. usb: dwc2: hcd: Fix host channel halt flow
>> 2. usb: dwc2: host: Fix transaction errors in host mode
>> and test again.
>
> Thanks for your response. I've tried applying the
On 03/05/18 11:41, Ard Biesheuvel wrote:
> On 3 May 2018 at 11:41, Marc Zyngier wrote:
>> On 03/05/18 09:42, Faiz Abbas wrote:
>>> Hi Marc,
>>>
>>> On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote:
On 03/05/18 05:49, Faiz Abbas wrote:
> Hi Everyone,
>
> On Wednesday 11 April 2
On 30/04/2018 03:49 μμ, Kyprianos Papadimitriou wrote:
Dear Greg,
I am still monitoring the behavior. Please let me come back to you
when I am sure about that.
Where should I send the "patch"? As I told you it is not a 100% fix!
I will continue monitoring this week whether Trackman/Keyboard
On 03.05.2018 12:30, Esokrates wrote:
Hi,>
Beginning with Linux 4.16 rc7 (4.16 rc6 was NOT affected), I do find the following regularly in dmesg (often it does not happen during boot, but after suspend to ram / resume):
Hi
Can you try 'git bisect' to find the patch that causes the issues?
(A
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved b
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
-
Hi,
Am 05/02/18 um 14:40 schrieb Bin Liu:
> On Wed, May 02, 2018 at 03:12:16AM +0200, Daniel Glöckner wrote:
>> On Tue, May 01, 2018 at 08:48:11AM -0500, Bin Liu wrote:
>>> On Fri, Apr 27, 2018 at 03:00:05PM +0200, Daniel Glöckner wrote:
This commit returns -EBUSY when musb_bus_suspend is cal
It has been observed that writing 0xF2 to the power register while it
reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
RESUME and setting SUSPENDM in one go does not work. It might also violate
the USB spec to transition directly from resume to suspend, especially
when not
Some non-compliant high-speed USB devices have bulk endpoints with a
1024-byte maxpacket size. Although such endpoints don't work with
xHCI host controllers, they do work with EHCI controllers. We used to
accept these invalid sizes (with a warning), but we no longer do
because of an unintentional
On Thu, May 03, 2018 at 04:13:05PM +0300, Mathias Nyman wrote:
> On 03.05.2018 12:30, Esokrates wrote:
> > Hi,> Beginning with Linux 4.16 rc7 (4.16 rc6 was NOT affected), I do
> > find the following regularly in dmesg (often it does not happen during
> > boot, but after suspend to ram / resume):
>
From: Bjørn Mork
Date: Wed, 2 May 2018 22:22:54 +0200
> The USB_DEVICE_INTERFACE_NUMBER matching macro assumes that
> the { vendorid, productid, interfacenumber } set uniquely
> identifies one specific function. This has proven to fail
> for some configurable devices. One example is the Quectel
Hi,
Thanks very much for pointing out that commit!
Indeed, reverting makes the problem go away!
Also, interestingly it also makes the errors in
https://bugzilla.kernel.org/show_bug.cgi?id=199557
go away, tested using 4.16.7!
On 05/03/2018 05:18 PM, Mika Westerberg wrote:
Could you try to revert
On Thu, May 03, 2018 at 06:53:13PM +0200, Esokrates wrote:
> Hi,
>
> Thanks very much for pointing out that commit!
> Indeed, reverting makes the problem go away!
> Also, interestingly it also makes the errors in
> https://bugzilla.kernel.org/show_bug.cgi?id=199557
> go away, tested using 4.16.7!
Sure. Done.
On 05/03/2018 07:04 PM, Mika Westerberg wrote:
Could you then attach full dmesg of the failure without revert to the
bugzilla bug?
--
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 ht
On Thu, 3 May 2018, Mathias Nyman wrote:
> When everything is runtime suspended and start system suspend, we first
> suspend all
> the usb devices, including the roothubs calling choose_wakeup() for the
> roothubs.
> No flags are set yet. When pm continues suspending, and tries to suspend the
>
On Wed, 2 May 2018, Nazar Mokrynskyi wrote:
> Some more details from my system:
>
> [ 0.725657] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [ 0.725670] ehci-pci: EHCI PCI platform driver
> [ 0.726004] ehci-platform: EHCI generic platform driver
> [ 0.726340] ohci_hcd:
03.05.18 22:16, Alan Stern пише:
> On Wed, 2 May 2018, Nazar Mokrynskyi wrote:
>
> As far as I know, hubs attached at boot time get initialized and
> handled in exactly the same way as hubs attached afterward.
>
> When a device is connected to a high-speed hub, the hardware in the hub
> is what det
On Thu, 3 May 2018, Nazar Mokrynskyi wrote:
> 03.05.18 22:16, Alan Stern пише:
> > On Wed, 2 May 2018, Nazar Mokrynskyi wrote:
> >
> > As far as I know, hubs attached at boot time get initialized and
> > handled in exactly the same way as hubs attached afterward.
> >
> > When a device is connected
The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".
This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.
The
The table is never modified by the function. This allows us
to use it on a statically defined table that is marked const.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/usbstring.c | 2 +-
include/linux/usb/gadget.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
Starting from v4.17-rc1, I've been having problems with my laptop's
webcam. Immediately after attempting to open Guvcview(or any other camera
software), the system just stops working. No response from any input and
the Caps lock LED starts blinking.
I've been following the last three -rc and no cha
KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;
dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.
set dev->udev p
Hi Greg
One xhci regression fix for usb-linus.
The original patch went to stable so this needs to be applier there as well.
-Mathias
Mathias Nyman (1):
xhci: Fix use-after-free in xhci_free_virt_device
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
--
2.7.4
--
To unsubscrib
36 matches
Mail list logo
