Hi All,
While testing usb-next on some Intle Bay and Cherry Trail
devices I noticed the following new error in my logs:
[ 26.187958] dwc3 dwc3.3.auto: Failed to get clk 'ref': -2
This is caused by the new clk_bulk_get() call in
drivers/usb/dwc3/core.c
If I understand the commit message
On Thu, Jun 07, 2018 at 09:54:45PM +0200, Mark Knibbs wrote:
> The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> was only applied for bcdDevice 0x0009, but later firmware which reports
> bcdDevice 0x0022 needs it too.
>
> Signed-off-by: Mark Knibbs
> ---
> diff --git
On Thu, 7 Jun 2018, Mark Knibbs wrote:
> The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> was only applied for bcdDevice 0x0009, but later firmware which reports
> bcdDevice 0x0022 needs it too.
>
> Signed-off-by: Mark Knibbs
> ---
> diff --git
On Thu, 2018-06-07 at 20:05 +, Corentin Labbe wrote:
> It's dangerous to use empty code define.
> Furthermore it lead to the following warning:
> "suggest braces around empty body in an « else » statement"
>
> So let's replace emptyness by "do {} while(0)"
I also suggest renaming COUNT to
The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
was only applied for bcdDevice 0x0009, but later firmware which reports
bcdDevice 0x0022 needs it too.
Signed-off-by: Mark Knibbs
---
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
On Thu, 7 Jun 2018, Alan Stern wrote:
> On Thu, 7 Jun 2018, Mark Knibbs wrote:
> > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> > was only applied for bcdDevice 0x0009 but later firmware needs it too.
> >
> > The later firmware has bcdDevice 0x0022. On the assumption
On Thu, 7 Jun 2018, Mark Knibbs wrote:
> The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> was only applied for bcdDevice 0x0009 but later firmware needs it too.
>
> The later firmware has bcdDevice 0x0022. On the assumption that any even
> later firmware (if it exists)
Some controllers take almost 55ms to complete controller
restore state (CRS).
There is no timeout limit mentioned in xhci specification so
fix the issue by increasing the timeout limit to 55ms
Signed-off-by: Ajay Gupta
Signed-off-by: Nagaraj Annaiah
---
drivers/usb/host/xhci.c | 2 +-
1 file
The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
was only applied for bcdDevice 0x0009 but later firmware needs it too.
The later firmware has bcdDevice 0x0022. On the assumption that any even
later firmware (if it exists) has the same problem I have widened the
bcdDevice
Hello
Sorry for the delay. I've briefly tested the changes and so far have
not encountered the issue anymore - due to the nature of it, it could
just coincidentally not be occurring anymore, though I suspect it would
have occurred some time by now.
Thanks!
Op maandag 4 juni 2018 om 14:07
On Thu, Jun 7, 2018 at 4:42 PM, Hans de Goede wrote:
>>> + msleep(100);
>>
>>
>> This has to be explained.
>
>
> Erm, this comes 1:1 from Intels Android X86 patches I've no
> idea why it is there, I believe it is better to leave this
> uncommented then making something up.
The above would
Hi,
On 07-06-18 18:43, Sergei Shtylyov wrote:
Hello!
On 06/07/2018 01:38 PM, Hans de Goede wrote:
On some Bay Trail (BYT) systems the firmware does not enable the
ULPI Refclk.
This commit adds a helper which checks and if necessary enabled the Refclk
and calls this helper for BYT machines.
Hello!
On 06/07/2018 01:38 PM, Hans de Goede wrote:
> On some Bay Trail (BYT) systems the firmware does not enable the
> ULPI Refclk.
>
> This commit adds a helper which checks and if necessary enabled the Refclk
> and calls this helper for BYT machines.
>
> Signed-off-by: Hans de Goede
> ---
Hi,
On 07-06-18 15:30, Andy Shevchenko wrote:
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede wrote:
On some Bay Trail (BYT) systems the firmware does not enable the
ULPI Refclk.
This commit adds a helper which checks and if necessary enabled the Refclk
and calls this helper for BYT machines.
Hi,
On 07-06-18 15:28, Andy Shevchenko wrote:
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede wrote:
Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.
Only some BYT devices have an external phy, but even on those devices
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede wrote:
> On some Bay Trail (BYT) systems the firmware does not enable the
> ULPI Refclk.
>
> This commit adds a helper which checks and if necessary enabled the Refclk
> and calls this helper for BYT machines.
> +static void
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede wrote:
> Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
> they require an external ULPI phy for device-mode.
>
> Only some BYT devices have an external phy, but even on those devices
> device-mode is not working because the dwc3
On Thu, Jun 07, 2018 at 04:17:14PM +0300, Dan Carpenter wrote:
> The tcpm_set_state() function take msecs not jiffies.
>
> Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
> Signed-off-by: Dan Carpenter
Acked-by: Heikki Krogerus
> diff --git a/drivers/usb/typec/tcpm.c
The tcpm_set_state() function take msecs not jiffies.
Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 8a201dd53d36..0dfd755020f4 100644
--- a/drivers/usb/typec/tcpm.c
+++
On Thu, Jun 07, 2018 at 09:22:56AM +0200, Hans de Goede wrote:
> Hi,
>
> On 06-06-18 23:36, Mats Karrman wrote:
> > Hello Gentlemen,
> >
> > I'm trying to get my head around USB role switches in connection with
> > Type-C ports
> > and device-trees. So far I have not found much documentation,
On 06.06.2018 23:36, Mats Karrman wrote:
> Hello Gentlemen,
>
> I'm trying to get my head around USB role switches in connection with Type-C
> ports
> and device-trees. So far I have not found much documentation, e.g. there are
> no
> device-tree bindings documented and really no good examples
Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.
Only some BYT devices have an external phy, but even on those devices
device-mode is not working because the dwc3 does not see the phy.
The problem is that the ACPI fwnode for
Even though we only use them once, it is better to not put/release
the GPIOs immediately after use, so that others cannot claim them.
Use devm functions to get the phy GPIOs, so that they will be
automatically released when were unbound from the device and
remove the gpio_put calls.
On some Bay Trail (BYT) systems the firmware does not enable the
ULPI Refclk.
This commit adds a helper which checks and if necessary enabled the Refclk
and calls this helper for BYT machines.
Signed-off-by: Hans de Goede
---
drivers/usb/dwc3/dwc3-pci.c | 34 ++
On 5/31/2018 4:17 PM, Manu Gautam wrote:
Move from dwc3-of-simple to dwc3-qcom glue driver to
support peripheral mode which requires qscratch wrapper
programming on VBUS event.
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Manu Gautam
---
Changes since v1:
Hi,
On 06-06-18 23:36, Mats Karrman wrote:
Hello Gentlemen,
I'm trying to get my head around USB role switches in connection with Type-C
ports
and device-trees. So far I have not found much documentation, e.g. there are no
device-tree bindings documented and really no good examples in
26 matches
Mail list logo
