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
