netdev - Re: [PATCH v6 net-next 14/19] ionic: Add initial ethtool support

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] [day] [month] [year] [list]

Message-ID: <20190901195235.GG24673@lunn.ch>
Date:   Sun, 1 Sep 2019 21:52:35 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net
Subject: Re: [PATCH v6 net-next 14/19] ionic: Add initial ethtool support

On Fri, Aug 30, 2019 at 03:16:41PM -0700, Jakub Kicinski wrote:
> On Fri, 30 Aug 2019 14:25:12 -0700, Shannon Nelson wrote:
> > On 8/29/19 4:10 PM, Jakub Kicinski wrote:
> > > On Thu, 29 Aug 2019 11:27:15 -0700, Shannon Nelson wrote:  
> > >> +static int ionic_get_module_eeprom(struct net_device *netdev,
> > >> +				   struct ethtool_eeprom *ee,
> > >> +				   u8 *data)
> > >> +{
> > >> +	struct ionic_lif *lif = netdev_priv(netdev);
> > >> +	struct ionic_dev *idev = &lif->ionic->idev;
> > >> +	struct ionic_xcvr_status *xcvr;
> > >> +	char tbuf[sizeof(xcvr->sprom)];
> > >> +	int count = 10;
> > >> +	u32 len;
> > >> +
> > >> +	/* The NIC keeps the module prom up-to-date in the DMA space
> > >> +	 * so we can simply copy the module bytes into the data buffer.
> > >> +	 */
> > >> +	xcvr = &idev->port_info->status.xcvr;
> > >> +	len = min_t(u32, sizeof(xcvr->sprom), ee->len);
> > >> +
> > >> +	do {
> > >> +		memcpy(data, xcvr->sprom, len);
> > >> +		memcpy(tbuf, xcvr->sprom, len);
> > >> +
> > >> +		/* Let's make sure we got a consistent copy */
> > >> +		if (!memcmp(data, tbuf, len))
> > >> +			break;
> > >> +
> > >> +	} while (--count);  
> > > Should this return an error if the image was never consistent?  
> > 
> > Sure, how about -EBUSY?
> 
> Or EAGAIN ? Not sure

ETIMEOUT?

EAGAIN would suggest it is a temporary problem. But if this fails
after 10 attempts, i would guess it is not a temporary problem, the
firmware is in deep trouble, or the SFP is loose in its cage, about to
fall out.

	 Andrew