mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Vinod Koul <vkoul@kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] phy: marvell: phy-mvebu-a3700-comphy: Reset COMPHY registers before USB 3.0 power on
Date: Wed, 21 Sep 2022 14:57:22 +0200	[thread overview]
Message-ID: <20220921125722.enp2tffhuz55enwv@pali> (raw)
In-Reply-To: <20220921124457.26hjljy7fcv45zfk@shindev>

On Wednesday 21 September 2022 12:44:58 Shinichiro Kawasaki wrote:
> On Sep 21, 2022 / 08:05, Pali Rohár wrote:
> > On Wednesday 21 September 2022 05:03:01 Shinichiro Kawasaki wrote:
> > > On Sep 20, 2022 / 14:11, Pali Rohár wrote:
> > > > Turris MOX board with older ARM Trusted Firmware version v1.5 is not able
> > > > to detect any USB 3.0 device connected to USB-A port on Mox-A module after
> > > > commit 0a6fc70d76bd ("phy: marvell: phy-mvebu-a3700-comphy: Remove broken
> > > > reset support"). On the other hand USB 2.0 devices connected to the same
> > > > USB-A port are working fine.
> > > > 
> > > > It looks as if the older firmware configures COMPHY registers for USB 3.0
> > > > somehow incompatibly for kernel driver. Experiments show that resetting
> > > > COMPHY registers via setting SFT_RST auto-clearing bit in COMPHY_SFT_RESET
> > > > register fixes this issue.
> > > > 
> > > > Reset the COMPHY in mvebu_a3700_comphy_usb3_power_on() function as a first
> > > > step after selecting COMPHY lane and USB 3.0 function. With this change
> > > > Turris MOX board can successfully detect USB 3.0 devices again.
> > > > 
> > > > Before the above mentioned commit this reset was implemented in PHY reset
> > > > method, so this is the reason why there was no issue with older firmware
> > > > version then.
> > > > 
> > > > Fixes: 0a6fc70d76bd ("phy: marvell: phy-mvebu-a3700-comphy: Remove broken reset support")
> > > > Reported-by: Marek Behún <kabel@kernel.org>
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > ---
> > > > Shinichiro, could you please check that all USB functionality still
> > > > works correctly on your board?
> > > > ---
> > > 
> > > Sure. TL;DR, this patch works ok for my espressobin v7 board.
> > > 
> > > Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> > > 
> > > I prepared base kernel v5.19.10 applying the commit 0a6fc70d76bd. Regardless
> > > whether this fix patch for Turrix MOX board is applied or not, two USB ports on
> > > my esprssobin v7 board worked as expected. I confirmed it by using USB thumb
> > > drive. The drive was detected and its partition was mounted successfully using
> > > either of the two USB ports.
> > 
> > Thank you for testing! Anyway, please check that USB 3.0 device is
> > working fine. Because as I wrote in commit message, on Turris Mox was
> > USB 2.0 device working fine, but USB 3.0 not. And maybe check in system
> > (lsusb) that USB 3.0 device was really detected as USB 3.0 because USB
> > 3.0 devices have supported also fallback USB 2.0/1.x legacy mode.
> 
> Ah, I see. For that check, I connected my USB 3.1 drive to the USB 3.0 port of
> my espressobin, then checked 'lsusb -vt' and sysfs:
> 
> $ lsusb -vt
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>     ID 1d6b:0003 Linux Foundation 3.0 root hub
>     |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>         ID 0781:5583 SanDisk Corp. Ultra Fit
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
>     ID 1d6b:0002 Linux Foundation 2.0 root hub
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
>     ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> $ cat /sys/bus/usb/devices/3-1/version 
>  3.00
> 
> USB3 port is listed under the Bus 03, "3.0" root hub. According to sysfs, its
> USB version is 3.00. I observed same outputs with and without the patch for
> Turris MOX board.
> 
> Are these good enough? If other check is needed, please let me know.

Perfect, that is enough! If USB 3.1 drive is detected and working then
everything is OK.

  reply	other threads:[~2022-09-21 12:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 12:11 Pali Rohár
2022-09-21  5:03 ` Shinichiro Kawasaki
2022-09-21  8:05   ` Pali Rohár
2022-09-21 12:44     ` Shinichiro Kawasaki
2022-09-21 12:57       ` Pali Rohár [this message]
2022-09-24  7:14     ` Vinod Koul
2022-09-24  8:31       ` Pali Rohár
2022-09-30 23:45         ` Pali Rohár
2022-10-09 12:07           ` Pali Rohár
2022-10-10  5:19           ` Vinod Koul
2022-10-17  5:39             ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220921125722.enp2tffhuz55enwv@pali \
    --to=pali@kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®