netdev - Re: [PATCH] Add ethtool to mii advertisment conversion helpers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Nov 2011 01:29:42 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Matt Carlson <mcarlson@...adcom.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Michael Chan <mchan@...adcom.com>
Subject: Re: [PATCH] Add ethtool to mii advertisment conversion helpers

On Wed, 2011-11-16 at 17:16 -0800, Matt Carlson wrote:
> On Wed, Nov 16, 2011 at 04:34:37PM -0800, Ben Hutchings wrote:
[...]
> > > +#define mii_lpa_to_ethtool_100bt(lpa)	mii_adv_to_ethtool_100bt(lpa)
> > 
> > Shouldn't this additionally translate LPA_LPACK into ADVERTISED_Autoneg?
> 
> You mean, like this?
> 
> static inline u32 mii_lpa_to_ethtool_100bt(u32 lpa)
> {
> 	u32 result = 0;
> 
> 	if (lpa & LPA_LPACK)
> 		result |= ADVERTISED_Autoneg;
> 
> 	return result | mii_adv_to_ethtool_100bt(lpa);
> }
> 
> Yes, that looks like a better implementation.

Think so.

And I think the mii_adv_to_ethtool_* functions should add
ADVERTISED_Autoneg unconditionally.  But I'm not entirely sure that's
right.

> > [...]
> > > +static inline u32 mii_lpa_to_ethtool_1000T(u32 lpa)
> > [...]
> > > +static inline u32 ethtool_adv_to_mii_1000X(u32 ethadv)
> > [...]
> > > +static inline u32 mii_adv_to_ethtool_1000X(u32 adv)
> > [...]
> > 
> > I'm not convinced about the naming convention for these.  Would it not
> > make more sense to name them consistently by register name and signal
> > type:
> > 
> > ethtool_adv_to_mii_adv_t
> > mii_adv_to_ethtool_adv_t
> > ethtool_adv_to_mii_ctrl1000_t
> > mii_ctrl1000_to_ethtool_adv_t
> > mii_lpa_to_ethtool_lpa_t
> > mii_stat1000_to_ethtool_lpa_t
> > ethtool_adv_to_mii_adv_x
> > mii_adv_to_ethtool_adv_x
> 
> I don't have a strong preference either way.  I'll post the change along
> with the above modification.
> 
> > Shouldn't there be mii_lpa_to_ethtool_1000X (or
> > mii_lpa_to_ethtool_lpa_x)?
> 
> Yes.  You're right.  Should it just be a preprocessor definition that
> points to mii_adv_to_ethtool_1000X()?

I think that would need to handle LPA_LPACK as well.

> > Finally, do these need to be inline?
> 
> I don't have a strong preference here either.  Phy code tends to be
> slower, so there isn't really a strong performance argument.  The
> implementations don't seem to be so large to argue against it though.
> Would you prefer they not be inlined?

I suppose one of us should measure what difference it makes to code
size.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html