> 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@xxxxxxxxxxxxxxx> > > > > Tested-by: Ioana Ciornei <ioana.ciornei@xxxxxxx> > > 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. The firmware is just doing the reverse translation. > > 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? I agree. It's unnecessary and confusing. I'll add this on the list of fixups to be made by the firmware team. Ioana > > --
