[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bc77a68-ec04-863e-0c46-1ea442e392ee@schinagl.nl>
Date: Sun, 19 Feb 2023 17:07:34 +0100
From: Olliver Schinagl <oliver@...inagl.nl>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc: Sander Vanheule <sander@...nheule.net>, linux-mips@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mips: Realtek RTL: select NO_EXCEPT_FILL
Hey Thomas,
On 19-02-2023 11:31, Thomas Bogendoerfer wrote:
> On Sun, Feb 19, 2023 at 10:27:17AM +0100, Olliver Schinagl wrote:
>> It's still odd though; as we do not have _anything_ PCI, but it
>> SWAP_IO_SPACE causes the crash.
>
> but something uses readX/write() calls. If you aren't using any driver
> existing driver but only newly written dedicated for that SOC
> you could use raw_read/raw_writeX() instead. These type of functions
> are always using native endianess.
Ok that is valueable information. I think currently the only driver
(that I can think of right now) that we use 'off the shelf' is the uart
driver, so I hope that's written cleanly :)
As for readX/writeX, for sure that is being used, and I intended to
refactor that while going to proper and clean drivers (the realtek
support in openwrt is a big mess right now).
So you say raw_readX, but what about ioread32 which I thought was preferred?
I'll meanwhile read into what readX vs raw_readX to learn more with
regards to endianess.
Thank you so mcuh so far!
>
>> What makes SWAP_IO_SPACE generic then? :)
>
> als long as hardware presents memory used with readX/writeX is
> seen as little endian independant from CPU endianess it's generic.
'little endian independent'? What does that mean, that the register maps
follow the CPU endianess?
>
> Thomas.
>
Powered by blists - more mailing lists