> On 5 Dec 2018, at 10:42, Greg Kroah-Hartman
> wrote:
>> On Tue, Dec 04, 2018 at 11:43:34PM +0100, alex.theis...@me.com wrote:
>> With the exception of the first patch I am not entirely sure if my changes
>> are
>> correct and justified. This is my first contribution and I am equally
>> satisf
Refactoring, no functional changes.
But worth mentioning that checking for port link resume state is now behind
a additional port power check.
This is fine as ports can't be in resume state if port power bit is not
set.
xhci spec section 4.19.1.1.6 figure 34 shows that port power bit must be
set
Hi Greg
This series for usb-next mostly about refactoring the xhci roothub
side of the get_port_status request
-Mathias
Mathias Nyman (7):
xhci: move bus_state structure under the xhci_hub structure.
xhci: remove unused hcd_index()
xhci: move usb3 speficic bits to own function in get_port_
Move the bus_state structure under struct usb_hub.
We need a bus_state strucure for each roothub to keep track of suspend
related info for each port.
Instead of keeping an array of two bus_state structures right under
struct xhci, it makes more sense move them to the xhci_hub structure.
No functi
Now that each root hub has their own bus_state strucure the
hcd_undex() used to get the correct bus_state strucure is
no longer needed.
No functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/host/xhci.
refactoring, no functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 68 ++---
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 5dba0a4..60aeff3 100
Group the code where the wPortstatus and wPortChange bits
are set into one place.
No functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/dri
Mostly refactoring, with the exception that USB_PORT_STAT_L1 link state
is reported if xhci port link is in U2 AND port is powered.
Previously we did not check if the port was powered, but according to
xhci spec 4.19.1.1.6 All the 'Enabled' states, including
USB_PORT_STAT_L1 (U2), U1, U0 and U3 mu
Move U0 link state handing to USB3 and USB2 specific functions
Note that
bus_state->resuming_ports:
bus_state->resume_done[]:
are only used for USB2, and don't need to cleared for USB3 ports
No functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 32 +++
From: Zeng Tao
It is introduced for the pre-0.96 xHC controllers, and the driver only
support HW LPM for 1.0 and later controllers.It's not actually used now
and is thought not to be used in the future any more, so just remove it.
Signed-off-by: Zeng Tao
Signed-off-by: Mathias Nyman
---
drive
Urgently need money? We can help you!
Are you by the current situation in trouble or threatens you in trouble?
In this way, we give you the ability to take a new development.
As a rich person I feel obliged to assist people who are struggling to give
them a chance. Everyone deserved a second chanc
On Wed, Dec 05, 2018 at 07:57:37AM +, PETER CHEN wrote:
>
> > On 04.12.18 21:01, Fabio Estevam wrote:
> > > Hi Frieder,
> > >
> > > On Tue, Dec 4, 2018 at 12:31 PM Schrempf Frieder
> > > wrote:
> > >
> > >> There are many other optional properties for this driver and a lot of
> > >> them are
Hi Felipe,
On 12/6/2018 10:01 PM, Felipe Balbi wrote:
> Hi,
>
> Thinh Nguyen writes:
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 679c12e14522..2de563124fc1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2254,6 +2254
Hi Felipe,
On 11/9/2018 12:54 AM, Felipe Balbi wrote:
> Hi,
>
> Thinh Nguyen writes:
>>> Thinh Nguyen writes:
> Thinh Nguyen writes:
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>> index 636630fb9
This patch series introduce a new feature in DWC_usb31 with more
aggressive low power management using reference clock.
Changes in v2:
- Revise commit messages to correctly describe the feature
- Split previous patch "usb: dwc3: Add reference clock properties" to 2
separate patches
- Remove refe
This patch introduces property "snps,refclk-period-ns" to inform the
controller of the reference clock period. If the reference clock period
is different from the default Core Consultant setting, then this
property can be set to the reference clock period.
This property does not control the refere
This patch writes the reference clock period provided from the device
property to GUCTL.REFCLKPER. This value informs the controller of the
reference clock period if the default Core Consultant setting
GUCTL.REFCLKPER is different.
Typical reference clock periods are 25, 41, 50, 52, 58, and 62ns.
This patch adds a property to enable the controller to track the
frame number based on the reference clock.
When operating in USB 2.0 mode, the peripheral controller uses the USB2
PHY clocks to track the frame number. This prevents the controller from
suspending the USB2 PHY when the device goes i
Version 1.80a of the DWC_usb31 peripheral controller introduced a
feature to track the frame number based the reference clock. This patch
checks and enables this feature.
When operating in USB 2.0 mode, the peripheral controller uses the USB2
PHY clocks to track the frame number. This prevents the
Hi Bjorn,
On 11/6/2018 12:44 AM, Felipe Balbi wrote:
> Thinh Nguyen writes:
>
>> ++ linux-usb
>> ++ Greg
>>
>> On 11/2/2018 6:47 PM, Thinh Nguyen wrote:
>>> Synopsys USB 3.x host HAPS platform has a class code of
>>> PCI_CLASS_SERIAL_USB_XHCI, and xhci driver can claim it. However, these
>>> devi
Hi Maynard,
On 12/7/2018 3:09 AM, Maynard CABIENTE wrote:
> Hi Minas,
>
> I tried your new patch on top of the other 2 patches for a couple of days now
> and I do not see the issue that Marek encountered. Of course, I did not see
> it also on the original two patches you created. I also do not
Hi Marek,
On 12/6/2018 7:04 PM, Marek Szyprowski wrote:
> Dear Minas,
>
> On 2018-12-04 13:34, Minas Harutyunyan wrote:
>> On 11/23/2018 6:43 PM, Dan Carpenter wrote:
>>> Ugh... We also had a long thread about the v2 patch but it turns out
>>> the list was not CC'd. I should have checked for th
Hi,
Minas Harutyunyan writes:
> Hi Marek,
>
> On 12/6/2018 7:04 PM, Marek Szyprowski wrote:
>> Dear Minas,
>>
>> On 2018-12-04 13:34, Minas Harutyunyan wrote:
>>> On 11/23/2018 6:43 PM, Dan Carpenter wrote:
Ugh... We also had a long thread about the v2 patch but it turns out
the l
This set adds USB SS PHY support to Qualcomm's QCS404 SoC
The PHY is implemented using Synopsys SS PHY 1.0.0 IP
The code is based on Sriharsha Allenki's
original implementation.
Jorge Ramirez-Ortiz (1):
dt-bindings: Add Qualcomm USB Super-Speed PHY bindings
Shawn Guo (1):
phy: qualcomm: usb
From: Shawn Guo
Driver to control the Synopsys SS PHY 1.0.0 implemeneted in QCS404
Based on Sriharsha Allenki's original code.
Signed-off-by: Jorge Ramirez-Ortiz
Signed-off-by: Shawn Guo
Reviewed-by: Vinod Koul
---
drivers/phy/qualcomm/Kconfig | 11 ++
drivers/phy/qualcomm/Makef
Binding description for Qualcomm's Synopsys 1.0.0 super-speed PHY
controller embedded in QCS404.
Based on Sriharsha Allenki's original
definitions.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Vinod Koul
---
.../devicetree/bindings/usb/qcom,usb-ssphy.txt | 78 ++
1
Hi Filipe,
My patch dccf1bad4be7eaa096c1f3697bd37883f9a08ecb "usb: dwc2: Disable
all EP's on disconnect" applied to 4.20-rc1.
I need to update this patch. What I should do. There are 2 options:
1. Ack Marek Szyprowski [PATCH] usb: dwc2:
Revert "usb: dwc2: Disable all EP's on disconnect" then
Hi,
Minas Harutyunyan writes:
> Hi Filipe,
>
> My patch dccf1bad4be7eaa096c1f3697bd37883f9a08ecb "usb: dwc2: Disable
> all EP's on disconnect" applied to 4.20-rc1.
>
> I need to update this patch. What I should do. There are 2 options:
>
> 1. Ack Marek Szyprowski [PATCH] usb: dwc2:
> Revert
On Wed, Dec 05, 2018 at 12:52:22PM +, Minas Harutyunyan wrote:
> Hi,
>
> On 12/4/2018 5:29 PM, Dan Carpenter wrote:
> > On Tue, Dec 04, 2018 at 12:34:08PM +, Minas Harutyunyan wrote:
> >> @@ -3185,12 +3183,13 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg
> >> *hsotg)
> >> hsot
Hi Dan,
On 12/7/2018 2:16 PM, Dan Carpenter wrote:
> On Wed, Dec 05, 2018 at 12:52:22PM +, Minas Harutyunyan wrote:
>> Hi,
>>
>> On 12/4/2018 5:29 PM, Dan Carpenter wrote:
>>> On Tue, Dec 04, 2018 at 12:34:08PM +, Minas Harutyunyan wrote:
@@ -3185,12 +3183,13 @@ void dwc2_hsotg_discon
Hi Dan,
On 12/7/2018 3:20 PM, Minas Harutyunyan wrote:
> Hi Dan,
>
> On 12/7/2018 2:16 PM, Dan Carpenter wrote:
>> On Wed, Dec 05, 2018 at 12:52:22PM +, Minas Harutyunyan wrote:
>>> Hi,
>>>
>>> On 12/4/2018 5:29 PM, Dan Carpenter wrote:
On Tue, Dec 04, 2018 at 12:34:08PM +, Minas Har
On Fri, Dec 07, 2018 at 02:13:18PM +, Minas Harutyunyan wrote:
>
> My patch doesn't pass sparse checking: "warning: context imbalance in
> 'dwc2_hsotg_core_init_disconnected' - unexpected unlock". Sparse persist!
> So, I need to re-work patch. Can I use your idea with
> dwc2_hsotg_ep_disable
On Thu, Dec 06, 2018 at 11:02:27AM +0800, Kyle Tso wrote:
> Current matching rules ensure that the voltage range of selected Source
> Capability is entirely within the range defined in one of the Sink
> Capabilities. This is reasonable but not practical because Sink may not
> support wide range of
On Fri, 7 Dec 2018, Felipe Balbi wrote:
>
> hi,
>
> Anurag Kumar Vulisha writes:
> >>Does the data book suggest a value for the timeout?
> >>
> >
> > No, the databook doesn't mention about the timeout value
> >
> >>> >At this point, it seems that the generic approach will be messier than
> >>>
On Tue, Dec 04, 2018 at 04:36:18PM -0500, Alan Stern wrote:
> On Tue, 4 Dec 2018, Kyle Williams wrote:
>
> > Description: Some USB device / host controller combinations seem to have
> > problems with Link Power management. In particular it is described that
> > the combination of certain Logitech
On Wed, Dec 05, 2018 at 10:39:02AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 04, 2018 at 03:38:25PM -0500, Kyle Williams wrote:
> > Description: Some USB device / host controller combinations seem to have
> > problems with Link Power management. In particular it is described that
> > the combi
From: Kyle Williams
Description: Some USB device / host controller combinations seem to have
problems with Link Power management. In particular it is described that
the combination of certain Logitech uvc devices and other powered media
devices such causes 'not enough bandwidth for new device sta
Changes in v3:
- seperated work to allow matched interfaces to use the
USB_QUIRK_NO_LPM quirk to affect a broader range of devices instead of
setting each device individually
Kyle Williams (2):
USB: quirks: Check device interface LPM capability
USB: quirks: Disable LPM for Logitech UVC devices
From: Kyle Williams
Description: enable the ability to disable LPM for all devices matched
by interface information
Signed-off-by: Kyle Williams
---
drivers/usb/core/hub.c | 87 +++---
1 file changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/u
From: Kyle Williams
Description: Some USB device / host controller combinations seem to have
problems with Link Power management. In particular it is described that
the combination of certain Logitech uvc devices and other powered media
devices such causes 'not enough bandwidth for new device sta
40 matches
Mail list logo
