[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200226101204.GW25745@shell.armlinux.org.uk>
Date: Wed, 26 Feb 2020 10:12:04 +0000
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Ioana Ciornei <ioana.ciornei@....com>
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Alexandre Torgue <alexandre.torgue@...com>,
"David S. Miller" <davem@...emloft.net>,
Felix Fietkau <nbd@....name>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Hauke Mehrtens <hauke@...ke-m.de>,
Jakub Kicinski <kuba@...nel.org>,
John Crispin <john@...ozen.org>,
Jonathan Corbet <corbet@....net>,
Jose Abreu <joabreu@...opsys.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Michal Simek <michal.simek@...inx.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>,
Sean Wang <sean.wang@...iatek.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next 5/8] net: dpaa2-mac: use resolved link config in
mac_link_up()
On Tue, Feb 25, 2020 at 04:36:32PM +0000, Ioana Ciornei wrote:
> > Subject: [PATCH net-next 5/8] net: dpaa2-mac: use resolved link config in
> > mac_link_up()
> >
> > Convert the DPAA2 ethernet driver to use the finalised link parameters in
> > mac_link_up() rather than the parameters in mac_config(), which are more
> > suited to the needs of the DPAA2 MC firmware than those available via
> > mac_config().
> >
> > Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>
>
> Tested-by: Ioana Ciornei <ioana.ciornei@....com>
Thanks.
> > +
> > + /* This is lossy; the firmware really should take the pause
> > + * enablement status rather than pause/asym pause status.
> > + */
>
> In what sense it's lossy? I cannot see how information can be lost by translating the rx/tx pause state to pause/asym.
> If it's just about the unnecessary double translation, then I agree.. this could have been done in an easier manner.
If you're just translating rx/tx to pause/asym and then doing the
reverse, then it isn't lossy, but if the firmware is resolving
pause/asym according to the table in IEEE 802.3, then it will be
lossy.
If the firmware doesn't interpret the bits, then why not do the
sensible thing and just pass the enablement status rather than
trying to confusingly encode it back to pause/asym?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Powered by blists - more mailing lists