[PATCH 2/7] ARM: shmobile: r8a7779: Use ioremap() to map INTC2 registers

[Arnd Bergmann]

On Tue, Nov 17, 2020 at 4:52 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Tue, Nov 17, 2020 at 4:06 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > On Tue, Nov 17, 2020 at 3:47 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > On Tue, Nov 17, 2020 at 3:39 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > > > On Tue, Nov 17, 2020 at 3:19 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > > On Tue, Nov 17, 2020 at 1:25 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > > > > > On Tue, Nov 17, 2020 at 11:30 AM Geert Uytterhoeven
> > > > > > <geert+renesas at glider.be> wrote:
> > > > > > > Replace using the legacy IOMEM() macro to map various registers related
> > > > > > > to INTC2 configuration by ioremap().
> > > > > > >
> > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> > > > > >
> > > > > > The patch looks good, but since you are already touching these __raw_writel(),
> > > > > > could you turn them into normal writel() to have a chance that this works
> > > > > > on big-endian? It could be either a follow-up or merged into the same patch.
> > > > >
> > > > > (Do you want us to support big-endian on these old platforms? ;-)
> > > > >
> > > > > At your service. Seems to work well.
> > > >
> > > > In general, my preference is that code is written in a portable way, to make
> > > > it at least plausible that it works. I don't expect anyone to actually run
> > > > big-endian code on it, but if you can confirm that it boots all the way
> > > > to not finding a compatible /sbin/init, that would be awesome.
> > >
> > > With "work well", I meant no regressions after converting from _raw_*()
> > > to normal accessors.  No idea how to boot big-endian kernels on this
> > > hardware ;-)
> >
> > There is no change when booting them, you just enable
> > CONFIG_CPU_BIG_ENDIAN and recompile the kernel.
>
> And have to select ARCH_SUPPORTS_BIG_ENDIAN first...
>
> > The bootloader remains little-endian and the first instruction in
> > the image then changes into big-endian mode. The expected
> > behavior is that it crashes as soon as it tries to get into user
>
> Cool!
>
> SH-Mobile AG5 boots until trying to power off the A3R power domain.
> After converting the __raw_*() accessors in
> drivers/soc/renesas/rmobile-sysc.c and drivers/clk/renesas/clk-sh73a0.c
> it continues until /sbin/init fails, as expected.

Ok, great!

> R-Car M2-W boots until DHCP timeout.  Could be due to either sh_eth or
> the micrel PHY driver, or MDIO (replacing io{read,write}32() by
> {read,write}l() in sh_eth.c doesn't help).

My guess would be that the sh_eth_soft_swap() logic is wrong
there, it seems to have been written in the SuperH days.

> Note that drivers/tty/serial/8250/8250_dw.c, which is used on RZ/N1,
> uses __raw_{write,read}q(), too.

This one is only used for octeon, which like superh has different
rules for endianness compared to everything else.

> So I guess it's a bit too early to enable ARCH_SUPPORTS_BIG_ENDIAN
> unconditionally.

The ARCH_SUPPORTS_BIG_ENDIAN logic is rather broken, as
it lets you build a big-endian kernel if any enabled platform sets it.
What we should probably have instead is 'depends on !CPU_BIG_ENDIAN'
in the platforms that do not support it.

> > space. Recompiling that is significantly more work.
>
> Doh, and even Debian ports doesn't support armeb anymore, else it
> would just be a debootstrap away...

Debian actually dropped all big-endian platforms other than s390
now, the last other one was mips32 (mips32el is still there for the
moment).

      Arnd