Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 20 Sep 2022 14:50:11 +0200
From:   Marco Felsch <m.felsch@pengutronix.de>
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Juergen Borleis <jbe@pengutronix.de>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH] net: fec: limit register access on i.MX6UL
Message-ID: <20220920125011.em66q7t7buywvr4m@pengutronix.de>
References: <20220920095106.66924-1-jbe@pengutronix.de>
 <Yym2I8SYMW7HRWLD@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yym2I8SYMW7HRWLD@lunn.ch>
User-Agent: NeoMutt/20180716
Precedence: bulk

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.

Regards,
  Marco