From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Baruch Siach <baruch@tkos.co.il>,
Fabio Estevam <festevam@gmail.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
tinywrkb <tinywrkb@gmail.com>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
NXP Linux Team <linux-imx@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
Date: Tue, 17 Sep 2019 20:39:34 +0200 [thread overview]
Message-ID: <20190917183934.GJ20778@lunn.ch> (raw)
In-Reply-To: <20190917181905.GA25745@shell.armlinux.org.uk>
> > Well, the _correct_ driver needs to be used for the PHY specific
> > features to be properly controlled. Using the generic driver
> > in this situation will not be guaranteed to work.
I fully agree about the PHY driver. I'm expect this device is
violating c22 when it modifies the advertisement register itself. So
all bets are off for the genphy.
> Well, this hasn't worked, but not for the obvious reason. Register 0x14
> is documented as read/write. Bits 15:6 are reserved, bit 5 is the
> smart speed enable, 4:2 configures the attempts, bit 1 sets the link
> stable condition, bit 0 is reserved.
>
> Writing 0x80c results in the register reading back 0x82c. Writing
> 0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
> seems to prevent packets being passed - and at that point I lost
> control so I couldn't see what the result was.
>
> There is nothing in the data sheet which suggests that there is any
> gating of this register. So it looks like we're stuck with smartspeed
> enabled.
>
> So, I think there's only two remaining ways forward - to revert commit
> 5502b218e001 to restore the old behaviour, read back the advertisement
> from the PHY along with the rest of the status, as I've previously
> stated. It means that phylib will modify phydev->advertising at
> random points, just as it modifies phydev->lp_advertising, so locking
> may become an issue. The revert approach is probably best until we
> have something working along those lines.
We have a couple of other PHYs which support downshift. We should see
if we can follow what they do. What is i think important is that
read_status return the correct speed. So we probably cannot use
genphy_read_status() as is. Maybe we should split genphy_read_status()
into two, so the register reading bit can be done unconditionally by
phy drivers for hardware which don't report link down when they
should?
Andrew
next prev parent reply other threads:[~2019-09-17 18:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 15:55 [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed tinywrkb
2019-09-10 16:10 ` Fabio Estevam
2019-09-10 16:17 ` Baruch Siach
2019-09-10 16:46 ` Russell King - ARM Linux admin
2019-09-10 18:50 ` Andrew Lunn
2019-09-15 6:30 ` Baruch Siach
2019-09-15 12:29 ` Russell King - ARM Linux admin
2019-09-15 13:56 ` Andrew Lunn
2019-09-15 14:06 ` Russell King - ARM Linux admin
2019-09-15 14:15 ` Russell King - ARM Linux admin
2019-09-15 14:42 ` Andrew Lunn
2019-09-15 14:58 ` Russell King - ARM Linux admin
2019-09-17 12:41 ` tinywrkb
2019-09-17 12:54 ` Andrew Lunn
2019-09-17 13:32 ` tinywrkb
2019-09-17 13:39 ` Russell King - ARM Linux admin
2019-09-17 15:17 ` Russell King - ARM Linux admin
2019-09-17 15:30 ` Russell King - ARM Linux admin
2019-09-17 16:34 ` tinywrkb
2019-09-17 17:04 ` Russell King - ARM Linux admin
2019-09-17 17:19 ` Russell King - ARM Linux admin
2019-09-17 17:26 ` Andrew Lunn
2019-09-17 17:37 ` Russell King - ARM Linux admin
2019-09-17 18:19 ` Russell King - ARM Linux admin
2019-09-17 18:39 ` Andrew Lunn [this message]
2019-09-20 10:36 ` Russell King - ARM Linux admin
2019-09-17 21:42 ` Russell King - ARM Linux admin
2019-09-20 13:42 ` Russell King - ARM Linux admin
2019-09-17 22:30 ` Russell King - ARM Linux admin
2019-09-17 22:43 ` Russell King - ARM Linux admin
2019-09-18 14:45 ` tinywrkb
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=20190917183934.GJ20778@lunn.ch \
--to=andrew@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=tinywrkb@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).