mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org
Cc: "Carlo Caione" <carlo@caione.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Giuseppe Cavallaro" <peppe.cavallaro@st.com>,
	"Alexandre TORGUE" <alexandre.torgue@st.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Andre Roth" <neolynx@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"Yegor Yefremov" <yegorslists@googlemail.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
Date: Mon, 28 Nov 2016 09:54:28 -0800	[thread overview]
Message-ID: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> (raw)
In-Reply-To: <1480348229-25672-1-git-send-email-jbrunet@baylibre.com>

On 11/28/2016 07:50 AM, Jerome Brunet wrote:
> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
> The platform seems to enter LPI on the Rx path too often while performing
> relatively high TX transfer. This eventually break the link (both Tx and
> Rx), and require to bring the interface down and up again to get the Rx
> path working again.
> 
> The root cause of this issue is not fully understood yet but disabling EEE
> advertisement on the PHY prevent this feature to be negotiated.
> With this change, the link is stable and reliable, with the expected
> throughput performance.
> 
> The patchset adds options in the generic phy driver to disable EEE
> advertisement, through device tree. The way it is done is very similar
> to the handling of the max-speed property.
> 
> Patch 4 is provided here for testing purpose only. Please don't merge
> patch 4, this change will go through the amlogic's tree.

Sorry, but I really don't like the route this is going, and I should
have made myself clearer before on that, I really think utilizing a PHY
fixup is more appropriate here than an extremely generic DT property.
The fixup code can be in the affected PHY driver, or it can be somewhere
else, your call. There is no shortage of option on how to implement it,
and this would be something easy to enable/disable for known good
configurations (ala PCI/USB fixups).

If we start supporting generic "enable", "disable" type of properties
with values that map directly to register definitions of the HW, we
leave too much room for these properties to be utilized to implement a
specific policy, and this is not acceptable.
-- 
Florian

  parent reply	other threads:[~2016-11-28 17:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 15:50 Jerome Brunet
2016-11-28 15:50 ` [PATCH net-next v4 1/4] net: phy: add an option to disable EEE advertisement Jerome Brunet
2016-11-28 15:50 ` [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants Jerome Brunet
2016-12-05 14:39   ` Rob Herring
2016-12-19 15:16     ` Jerome Brunet
2016-11-28 15:50 ` [PATCH net-next v4 3/4] dt: bindings: add ethernet phy eee-broken-modes option documentation Jerome Brunet
2016-11-28 15:50 ` [PATCH net-next v4 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE Jerome Brunet
2016-11-28 17:54 ` Florian Fainelli [this message]
2016-11-30  9:47   ` [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue Jerome Brunet
2016-11-30 18:28     ` Florian Fainelli
2017-01-05 23:25   ` Russell King - ARM Linux
2017-01-06  5:42     ` Yegor Yefremov
2017-01-06 11:58       ` Russell King - ARM Linux
2017-01-06 10:11     ` Jerome Brunet
2017-01-06 11:42       ` Russell King - ARM Linux
2017-01-06 13:50         ` Jerome Brunet
2017-01-06 15:05           ` Russell King - ARM Linux

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=049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=afaerber@suse.de \
    --cc=alexandre.torgue@st.com \
    --cc=andrew@lunn.ch \
    --cc=carlo@caione.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=julia.lawall@lip6.fr \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=narmstrong@baylibre.com \
    --cc=neolynx@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=yegorslists@googlemail.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

Powered by JetHome