mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juergen Borleis <jbe@pengutronix.de>
To: Marco Felsch <m.felsch@pengutronix.de>, Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel@pengutronix.de
Subject: Re: [PATCH] net: fec: limit register access on i.MX6UL
Date: Mon, 24 Oct 2022 09:42:44 +0200	[thread overview]
Message-ID: <caaf147aeb71d69d767cc8509809a2770d297cb9.camel@pengutronix.de> (raw)
In-Reply-To: <20220920125011.em66q7t7buywvr4m@pengutronix.de>

Am Dienstag, dem 20.09.2022 um 14:50 +0200 schrieb Marco Felsch:
> On 22-09-20, Andrew Lunn wrote:
> > > +/* for i.MX6ul */
> > > +static u32 fec_enet_register_offset_6ul[] = {
> > > +       FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
> > > +       FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT,
> > > FEC_R_CNTRL,
> > > +       FEC_X_CNTRL, FEC_ADDR_LOW, FEC_ADDR_HIGH, FEC_OPD, FEC_TXIC0,
> > > FEC_RXIC0,
> > > +       FEC_HASH_TABLE_HIGH, FEC_HASH_TABLE_LOW, FEC_GRP_HASH_TABLE_HIGH,
> > > +       FEC_GRP_HASH_TABLE_LOW, FEC_X_WMRK, FEC_R_DES_START_0,
> > > +       FEC_X_DES_START_0, FEC_R_BUFF_SIZE_0, FEC_R_FIFO_RSFL,
> > > FEC_R_FIFO_RSEM,
> > > +       FEC_R_FIFO_RAEM, FEC_R_FIFO_RAFL, FEC_RACC,
> > > +       RMON_T_DROP, RMON_T_PACKETS, RMON_T_BC_PKT, RMON_T_MC_PKT,
> > > +       RMON_T_CRC_ALIGN, RMON_T_UNDERSIZE, RMON_T_OVERSIZE, RMON_T_FRAG,
> > > +       RMON_T_JAB, RMON_T_COL, RMON_T_P64, RMON_T_P65TO127,
> > > RMON_T_P128TO255,
> > > +       RMON_T_P256TO511, RMON_T_P512TO1023, RMON_T_P1024TO2047,
> > > +       RMON_T_P_GTE2048, RMON_T_OCTETS,
> > > +       IEEE_T_DROP, IEEE_T_FRAME_OK, IEEE_T_1COL, IEEE_T_MCOL,
> > > IEEE_T_DEF,
> > > +       IEEE_T_LCOL, IEEE_T_EXCOL, IEEE_T_MACERR, IEEE_T_CSERR,
> > > IEEE_T_SQE,
> > > +       IEEE_T_FDXFC, IEEE_T_OCTETS_OK,
> > > +       RMON_R_PACKETS, RMON_R_BC_PKT, RMON_R_MC_PKT, RMON_R_CRC_ALIGN,
> > > +       RMON_R_UNDERSIZE, RMON_R_OVERSIZE, RMON_R_FRAG, RMON_R_JAB,
> > > +       RMON_R_RESVD_O, RMON_R_P64, RMON_R_P65TO127, RMON_R_P128TO255,
> > > +       RMON_R_P256TO511, RMON_R_P512TO1023, RMON_R_P1024TO2047,
> > > +       RMON_R_P_GTE2048, RMON_R_OCTETS,
> > > +       IEEE_R_DROP, IEEE_R_FRAME_OK, IEEE_R_CRC, IEEE_R_ALIGN,
> > > IEEE_R_MACERR,
> > > +       IEEE_R_FDXFC, IEEE_R_OCTETS_OK
> > > +};
> > >  #else
> > >  static __u32 fec_enet_register_version = 1;
> > 
> > Seeing this, i wonder if the i.MX6ul needs its own register version,
> > so that ethtool(1) knows what registers are valid?
> 
> Regarding the uAPI (uapi/linux/ethtool.h):
> 8<-------------------------------------------------
>  * @version: Dump format version.  This is driver-specific and may
>  *      distinguish different chips/revisions.  Drivers must use new
>  *      version numbers whenever the dump format changes in an
>  *      incompatible way.
> 8<-------------------------------------------------
> I would say yes.

But there is no format change. Only a value change. Where the i.MX6 may report a
value, the i.MX6UL just reports a zero.

jb

-- 
Pengutronix e.K.                       | Juergen Borleis             |
Steuerwalder Str. 21                   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany              | Phone: +49-5121-206917-128  |
Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-9    |



  reply	other threads:[~2022-10-24  7:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20  9:51 Juergen Borleis
2022-09-20 11:56 ` Marc Kleine-Budde
2022-10-24  7:35   ` Juergen Borleis
2022-09-20 12:46 ` Andrew Lunn
2022-09-20 12:50   ` Marco Felsch
2022-10-24  7:42     ` Juergen Borleis [this message]
2022-10-24  7:40   ` Juergen Borleis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caaf147aeb71d69d767cc8509809a2770d297cb9.camel@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®