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, 24 May 2022 18:18:28 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Florian Fainelli <f.fainelli@gmail.com>
cc:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Paul Cercueil <paul@crapouillou.net>,
        Nathan Chancellor <nathan@kernel.org>,
        Tiezhu Yang <yangtiezhu@loongson.cn>,
        linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: Rewrite `csum_tcpudp_nofold' in plain C
In-Reply-To: <7682977b-5929-890a-3a18-662fbfcede5c@gmail.com>
Message-ID: <alpine.DEB.2.21.2205241811180.52080@angie.orcam.me.uk>
References: <alpine.DEB.2.21.2205222035380.52080@angie.orcam.me.uk> <7682977b-5929-890a-3a18-662fbfcede5c@gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Tue, 24 May 2022, Florian Fainelli wrote:

> >   I have visually inspected code produced and verified this change to boot
> > with TCP networking performing just fine, both with a 32-bit and a 64-bit
> > configuration.  Sadly with the little endianness only, because in the
> > course of this verification I have discovered the core card of my Malta
> > board bit the dust a few days ago, apparently in a permanent manner, and I
> > have no other big-endian MIPS system available here to try.
> 
> How about QEMU is not that a viable option for testing big/little endian
> configurations?

 Yeah, for this particular change, sure.  I don't have QEMU set up however 
at the moment and would have to take some time to sort it, and it won't do 
for peripherals it doesn't implement.  The failure is a fresh problem and 
I yet need to figure out what to do about it.  A bad coincidence I guess 
as I have MIPS hardware 10 years older that still goes strong.

  Maciej