Re: [PATCH net-next] tg3: normalize inherited M3000 register byte order

[Magnus Lindholm]

Hi Andrew,

On Sun, Oct 11, 2026 at 3:33 PM Andrew Lunn <andrew@xxxxxxx> wrote:
>
> On Fri, Oct 09, 2026 at 02:52:57PM +0200, Magnus Lindholm wrote:
> > Hi Andrew,
> >
> > On Fri, Oct 9, 2026 at 2:09 PM Andrew Lunn <andrew@xxxxxxx> wrote:
> > >
> > > > > Is there a legitimate reason you would want the bytes are swapped?
> > >
> > > You missed answering this. I'm guessing, but does the hardware offer
> > > this to make big endian machines more efficient?
> > >
> > > Please could you look at the driver and think about what would happen
> > > on a big endian machine. Is the change still correct?
> > >
> > >         Andrew
> >
> > You're right, my earlier reply missed the underlying question.
> >
> > That is a plausible reason for providing the hardware swap mode:
> > it can accommodate big-endian accesses without software byte
> > swapping. I haven't verified Broadcom's design rationale.
> >
> > However, Linux tg3 alreadThanks, I'll expand the commit message with this explanation in v3.y initializes misc_host_ctrl with WORD_SWAP set
> > and BYTE_SWAP clear on both little- and big-endian builds, before
> > this helper runs.
> >
> > The helper restores that existing setting. Its swab32() compensates
> > for the device's inherited register state, not CPU endianness.
> > Subsequent accesses use the normal driver path, and the separate
> > __BIG_ENDIAN handling for DMA remains unchanged.
> >
> > That is why I believe the correction is appropriate on either
> > endianness. The runtime tests were on the M3000 running big-endian
> > SPARC64.
>
> Please expand the commit message to show you have thought about this.
>


Thanks, I'll expand the commit message with this explanation in v3.

Magnus