Zitat von Greg Kroah-Hartman :
On Mon, Sep 24, 2018 at 12:20:42PM +, gu...@kiener-muenchen.de wrote:
Zitat von Oliver Neukum :
> On Mo, 2018-09-24 at 10:56 +, gu...@kiener-muenchen.de wrote:
> > Zitat von Greg Kroah-Hartman :
> >
> > > On Mon, Sep 24, 2018 at 11:24:10AM +0200, Olive
The platform firmware "location" data is used to find port peer
relationships. But firmware is an unreliable source. Errors in ACPI
tables can lead to missing or wrong peer relationships. Debugging
this is currently hard.
Exporting the location attribute makes it easier to spot mismatches
between
The platform firmware "location" data is used to find port peer
relationships. But firmware is an unreliable source, and there are
real world examples of errors leading to missing or wrong peer
relationships. Debugging this is currently hard.
Exporting the location attribute makes it easier to sp
Hi Bjørn,
I love your patch! Perhaps something to improve:
[auto build test WARNING on peter.chen-usb/ci-for-usb-next]
[also build test WARNING on v4.19-rc5 next-20180928]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
The platform firmware "location" data is used to find port peer
relationships. But firmware is an unreliable source, and there are
real world examples of errors leading to missing or wrong peer
relationships. Debugging this is currently hard.
Exporting the location attribute makes it easier to sp
On Fri, 28 Sep 2018, Bjørn Mork wrote:
> The platform firmware "location" data is used to find port peer
> relationships. But firmware is an unreliable source, and there are
> real world examples of errors leading to missing or wrong peer
> relationships. Debugging this is currently hard.
>
> Ex
Alan Stern writes:
>> diff --git a/Documentation/ABI/testing/sysfs-bus-usb
>> b/Documentation/ABI/testing/sysfs-bus-usb
>> index 08d456e07b53..8f394c976fee 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-usb
>> +++ b/Documentation/ABI/testing/sysfs-bus-usb
>> @@ -173,14 +173,14 @@ Descriptio
The platform firmware "location" data is used to find port peer
relationships. But firmware is an unreliable source, and there are
real world examples of errors leading to missing or wrong peer
relationships. Debugging this is currently hard.
Exporting the location attribute makes it easier to sp
On 9/28/2018 7:05 AM, Hal Emmerich wrote:
> From 04fbf78e4e569bf872f1ffcb0a6f9b89569dc913 Mon Sep 17 00:00:00 2001
> From: Hal Emmerich
> Date: Thu, 19 Jul 2018 21:48:08 -0500
> Subject: [PATCH] usb: dwc2: disable power_down on rockchip devices
>
> The bug would let the usb controller enter pa
On Thu, Sep 20, 2018 at 06:43:19PM +0300, Mathias Nyman wrote:
> Hi Greg
>
> Second try, shuffling patches between for-usb-linus and for-usb-next
>
> A few patches that makes sure USB3 devices enumerate to correct speed
> after resume on Mediatek hosts, enables role mux on Apollo lake platforms,
On Sat, Sep 22, 2018 at 06:31:26AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/usb/core/driver.c: In function 'usb_driver_claim_interface':
> drivers/usb/core/driver.c:513:21: warning:
> variable 'udev' set but not used [-Wunused-but-set-variable]
>
> Si
On Fri, Sep 28, 2018 at 08:30:41AM +, gu...@kiener-muenchen.de wrote:
>
> Zitat von Greg Kroah-Hartman :
>
> > On Mon, Sep 24, 2018 at 12:20:42PM +, gu...@kiener-muenchen.de wrote:
> > >
> > > Zitat von Oliver Neukum :
> > >
> > > > On Mo, 2018-09-24 at 10:56 +, gu...@kiener-muenche
Hi Mathias,
On Fri, Sep 28, 2018 at 03:35:10AM +, Peter Chen wrote:
>
> > > Cc:
> > > Reported-by: Peter Chen
> > > Signed-off-by: Mathias Nyman
> > > ---
> > > drivers/usb/host/xhci-ring.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/xhc
On Thu, Sep 27, 2018 at 07:26:26PM +0300, Mathias Nyman wrote:
> Ensure that the shared_hcd pointer is valid when calling usb_put_hcd()
>
> The shared_hcd is removed and freed in xhci by first calling
> usb_remove_hcd(xhci->shared_hcd), and later
> usb_put_hcd(xhci->shared_hcd)
>
> Afer commit fe
On Fri, 28 Sep 2018, Greg Kroah-Hartman wrote:
> On Sat, Sep 22, 2018 at 06:31:26AM +, YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/usb/core/driver.c: In function 'usb_driver_claim_interface':
> > drivers/usb/core/driver.c:513:21: warning:
> > variable
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_pd_select_pps_apdo':
drivers/usb/typec/tcpm/tcpm.c:2212:39: warning:
variable 'snk_ma' set but not used [-Wunused-but-set-variable]
drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_pd_build_pps_reques
Sorry, Pls ignore this err patch.
On 2018/9/29 13:10, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_pd_select_pps_apdo':
> drivers/usb/typec/tcpm/tcpm.c:2212:39: warning:
> variable 'snk_ma' set but not used [-Wunused-but-
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_pd_select_pps_apdo':
drivers/usb/typec/tcpm/tcpm.c:2212:39: warning:
variable 'snk_ma' set but not used [-Wunused-but-set-variable]
drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_pd_build_pps_reques
Hi,
I recently got new Lenovo Thinkpad T480s with the ThinkPad Thunderbolt
3 Dock. The USB ports (but probably also audio and ethernet) on the
dock always don't work after resume from suspend on up-to-date Fedora
29 with kernel-4.18.9-300.fc29.x86_64. HDMI port in the dock seems
works (but with so
Zitat von Colin King :
From: Colin Ian King
Currently the allocation of a buffer is performed before a sanity check on
the required buffer size and if the buffer size is too large the error exit
return leaks the allocated buffer. Fix this by checking the size before
allocating.
Also, the s
Currently when requesting a specific voltage or current through
the psy interface, for PPS, when reading back from that interface
the values will always be the same as previously given, if the
request was successful. However PPS only allows for 20mV voltage
steps and 50mA current steps, and the psy
On Fri, Sep 28, 2018 at 04:33:49PM +0100, Adam Thomson wrote:
> Currently when requesting a specific voltage or current through
> the psy interface, for PPS, when reading back from that interface
> the values will always be the same as previously given, if the
> request was successful. However PPS
On 28 September 2018 17:04, Guenter Roeck wrote:
> On Fri, Sep 28, 2018 at 04:33:49PM +0100, Adam Thomson wrote:
> > Currently when requesting a specific voltage or current through
> > the psy interface, for PPS, when reading back from that interface
> > the values will always be the same as previ
On Thu, Sep 27, 2018 at 5:33 AM, Artur Petrosyan
wrote:
> We would like to buy the HiKey board to perform testes.
> We found this HiKey LeMaker to have USB 2.0 ports
> https://www.ebay.com/itm/HiKey-LeMaker-version-2GB-Kirin-620-SoC-8-core-ARM-Cortex-A53-CPU-ARM-Mali-450/263958047308?hash=item3d75
On Fri, Sep 14, 2018 at 11:42 AM Jack Pham wrote:
>
> Hi Badhri,
>
> On Thu, Sep 13, 2018 at 04:38:10PM -0700, Badhri Jagan Sridharan wrote:
> > On Thu, Sep 13, 2018 at 10:07 AM Jack Pham wrote:
> > > On Thu, Sep 13, 2018 at 6:43 AM Badhri Jagan Sridharan
> > > > Yeah thats for the source. But fo
Cancel pending work before freeing smsc75xx private data structure
during binding. This fixes the following crash in the driver:
BUG: unable to handle kernel NULL pointer dereference at 0050
IP: mutex_lock+0x2b/0x3f
Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
task:
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit
ethernet adapter driver")
Signed-off-by: Florian Fainelli
-
The driver supports a fair amount of Wake-on-LAN modes, but is not
checking that the user specified one that is supported.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000
Ethernet device driver")
Signed-off-by: Florian Fainelli
---
drivers/net/usb/lan78xx.c | 17
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: e0e474a83c18 ("smsc95xx: add wol magic packet support")
Signed-off-by: Florian Fainelli
---
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device
Driver Support")
Signed-off-by: Florian Fainelli
---
dri
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: 6c636503260d ("smsc75xx: add wol magic packet support")
Signed-off-by: Florian Fainelli
---
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: 21ff2e8976b1 ("r8152: support WOL")
Signed-off-by: Florian Fainelli
---
drivers/net/usb/r81
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet
adapters")
Signed-off-by: Florian Fainelli
---
drivers/net/usb
Hi all,
Most of our USB Ethernet drivers don't seem to be checking properly
whether the user is supplying a correct Wake-on-LAN mode to enter, so
the experience as an user could be confusing, since it would generally
lead to either no wake-up, or the device not being marked for wake-up.
Please re
> The driver supports a fair amount of Wake-on-LAN modes, but is not
> checking that the user specified one that is supported.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000
> Ethernet device driver")
> Signed-off-by: Florian Fainelli
Reviewed-by: Woojung Huh
Than
During the initial connect to a non-pd port, sink would hard reset
twice before deeming that the port partner is non-pd. TCPM sets the
the charge path to false during the hard reset. This causes unnecessary
connects/disconnects of charge path and makes port take longer to
charge from the non-pd por
>From USB_PD_R3_0
7.1.5 Response to Hard Resets
Device operation during and after a Hard Reset is defined as follows:
Self-powered devices Should Not disconnect from USB during a Hard Reset
(see Section 9.1.2).
Bus powered devices will disconnect from USB during a Hard Reset due to the
loss of thei
During HARD_RESET the data link is disconnected.
For self powered device, the spec is advising against doing that.
>From USB_PD_R3_0
7.1.5 Response to Hard Resets
Device operation during and after a Hard Reset is defined as follows:
Self-powered devices Should Not disconnect from USB during a Hard
+ ja...@codeaurora.org
On Fri, Sep 28, 2018 at 4:47 PM Badhri Jagan Sridharan
wrote:
>
> During the initial connect to a non-pd port, sink would hard reset
> twice before deeming that the port partner is non-pd. TCPM sets the
> the charge path to false during the hard reset. This causes unnecessar
39 matches
Mail list logo
