[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201231135243.tvzkre2sddhdxfbq@pali>
Date: Thu, 31 Dec 2020 14:52:43 +0100
From: Pali Rohár <pali@...nel.org>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Marek Behún <kabel@...nel.org>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] net: sfp: allow to use also SFP modules which are
detected as SFF
On Wednesday 30 December 2020 19:12:40 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 06:27:07PM +0100, Marek Behún wrote:
> > On Wed, 30 Dec 2020 18:06:52 +0100
> > Pali Rohár <pali@...nel.org> wrote:
> >
> > > if (!sfp->type->module_supported(&id) &&
> > > (memcmp(id.base.vendor_name, "UBNT ", 16) ||
> > > memcmp(id.base.vendor_pn, "UF-INSTANT ", 16)))
> >
> > I would rather add a quirk member (bitfield) to the sfp structure and do
> > something like this
> >
> > if (!sfp->type->module_supported(&id) &&
> > !(sfp->quirks & SFP_QUIRK_BAD_PHYS_ID))
> >
> > or maybe put this check into the module_supported method.
>
> Sorry, definitely not. If you've ever looked at the SDHCI driver with
> its multiple "quirks" bitfields, doing this is a recipe for creating
> a very horrid hard to understand mess.
>
> What you suggest just results in yet more complexity.
Should I rather put this vendor name/pn check into the
sfp_module_supported() function?
static bool sfp_module_supported(const struct sfp_eeprom_id *id)
{
if (id->base.phys_id == SFF8024_ID_SFP &&
id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP)
return true;
if (id->base.phys_id == SFF8024_ID_SFF_8472 &&
id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP &&
!memcmp(id->base.vendor_name, "UBNT ", 16) &&
!memcmp(id->base.vendor_pn, "UF-INSTANT ", 16))
return true;
return false;
}
Powered by blists - more mailing lists