According to the device tree bindings the vcc-supply is optional.
So far the driver did request the regulator using devm_regulator_get
which creates a dummy regulator for convenience. Since we can have
the supply unconnected, we should make use of the optional variant
of the regulator call which do
On 09/04/2016 12:55 AM, Randy Li wrote:
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).
We can get the PHY out of its bad state
On Sat, 3 Sep 2016, Jacek Anaszewski wrote:
> >> The remaining issue is the sysfs interface design for defining and
> >> presenting multiple USB ports. I'm still in favour of a single
> >> attribute with space separated list. This scheme is commonly used
> >> in existing interfaces.
> >
> > No suc
Hi all,
The external HDD enclosure I've bought recently stops responding after
it's been idle for ~5 minutes. Excerpt from typical dmesg output
attached (the "Valid eCryptfs headers" are irrelevant, and there for
completeness).
After searching the web, eventually I've come upon this Q&A, whi
The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup. We'll use the reset that's in the CRU to reset the
port when it's in a bad state.
Note that we add the reset to both dwc2 controllers ev
The only use for this is for solving a hardware design problem in
usb of Rockchip RK3288.
Signed-off-by: Randy Li
---
include/linux/phy/phy.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f08b672..4d34607 100644
--- a/include/linux/
It is a hardware bug in RK3288, the only way to solve it is to
reset the phy.
Signed-off-by: Randy Li
---
.../devicetree/bindings/phy/rockchip-usb-phy.txt | 3 +++
drivers/phy/phy-rockchip-usb.c | 20
2 files changed, 23 insertions(+)
diff --git a
changelog:
v7
Some minor fixup
v6
Send the last two patches
v5
A few modification at style, add the missing doc in the last
commit.
v4
1. Adding the reset callback in struct phy_ops.
2. Moving the reset into phy rockchip usb.
3. Trying to call a reset when dwc2 wakeup in rk3288.
v3
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).
We can get the PHY out of its bad state by asserting its "port reset",
but unfortun
Hi,
Thanks for your idea but unfortunately no... it did not change anything.
It seems to me that the problem is more "power related" (see my comment
on the laptop booting correctly on cold boot but ignoring the USB3 key
and going directly to Grub Menu when reboot)
Is there any parameter of the k
On 09/03/2016 05:17 PM, Alan Stern wrote:
On Sat, 3 Sep 2016, Jacek Anaszewski wrote:
Maybe it would make more sense, in this case, to allow only three
possibilities for a USB port activity trigger. Toggle the LED
whenever:
There is activity on the specified port, or
There is
On Sat, Sep 03, 2016 at 06:48:27PM +0200, kulamfm wrote:
> Hi,
>
> I can boot on Debian-Live installed on a USB2 key.
> I can't boot on Debian-Live installed on a USB3 key unless I wait a bit
> and with the good timing, deplug and replug the USB3 key.
> I have no idea if it is a BIOS problem, a U
On Sat, 3 Sep 2016, Jacek Anaszewski wrote:
> >>> Maybe it would make more sense, in this case, to allow only three
> >>> possibilities for a USB port activity trigger. Toggle the LED
> >>> whenever:
> >>>
> >>> There is activity on the specified port, or
> >>>
> >>> There is any activity on
On 09/02/2016 04:33 PM, Alan Stern wrote:
On Fri, 2 Sep 2016, Jacek Anaszewski wrote:
I'm pretty sure noone ever planned to have more than 1 trigger
assigned to a single LED. I just realized there will be a problem with
proposed solution: sysfs files conflict.
...
Currently we support only
On Sat, 3 Sep 2016, Alan Stern wrote:
> In other words, we have:
>
> CPU 0 CPU 1
> - -
> Start DMA Handle DMA-complete irq
> Sleep until bh->state Set bh->state
>
The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:
Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.8-rc5
for you to fetch changes up to 2c5575401e34de3d2fc90a
On Sat, 3 Sep 2016, Peter Zijlstra wrote:
> On Fri, Sep 02, 2016 at 04:29:19PM -0400, Alan Stern wrote:
> > I'm afraid so. The code doesn't use wait_event(), in part because
> > there's no wait_queue (since only one task is involved).
>
> You can use wait_queue fine with just one task, and it wo
On Sat, 3 Sep 2016, Peter Zijlstra wrote:
> On Sat, Sep 03, 2016 at 09:58:09AM +0300, Felipe Balbi wrote:
>
> > > What arch are you seeing this on?
> >
> > x86. Skylake to be exact.
>
> So it _cannot_ be the thing Alan mentioned. By the simple fact that
> spin_lock() is a full barrier on x86 (e
On Sat, 3 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Fri, 2 Sep 2016, Felipe Balbi wrote:
> >
> >>
> >> Hi,
> >>
> >> Alan Stern writes:
> >>
> >> [...]
> >>
> >> > No, that would be too late. The barrier needs to go between the write
> >> > to common->thead_wakeup_
Hi,
Peter Zijlstra writes:
> On Sat, Sep 03, 2016 at 09:58:09AM +0300, Felipe Balbi wrote:
>
>> > What arch are you seeing this on?
>>
>> x86. Skylake to be exact.
>
> So it _cannot_ be the thing Alan mentioned. By the simple fact that
> spin_lock() is a full barrier on x86 (every LOCK prefixed
On Sat, Sep 03, 2016 at 09:58:09AM +0300, Felipe Balbi wrote:
> > What arch are you seeing this on?
>
> x86. Skylake to be exact.
So it _cannot_ be the thing Alan mentioned. By the simple fact that
spin_lock() is a full barrier on x86 (every LOCK prefixed instruction
is).
> The following change
On Fri, Sep 02, 2016 at 04:29:19PM -0400, Alan Stern wrote:
> I'm afraid so. The code doesn't use wait_event(), in part because
> there's no wait_queue (since only one task is involved).
You can use wait_queue fine with just one task, and it would clean up
the code tremendously.
You can replace
On Fri, Sep 02, 2016 at 04:29:19PM -0400, Alan Stern wrote:
> On Fri, 2 Sep 2016, Paul E. McKenney wrote:
>
> > On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote:
> > > Paul, Peter, and Ingo:
> > >
> > > This must have come up before, but I don't know what was decided.
> > >
> > > Isn't
23 matches
Mail list logo
