Issue title: SoC Controller: Be sure scratch register init value is checked in both little/big endian cases
 Issue body: In the current SoC Controller driver, the scratch value is only checked against little endian value:
````
+	if (reg == SCRATCH_REG_VALUE) {
+		pr_info("Detected endianness: Little Endian");
+		litex_read_reg = ioread32;
+		litex_write_reg = iowrite32;
+	} else {
+		pr_info("Detected endianness: Big Endian");
+		litex_read_reg = ioread32be;
+		litex_write_reg = iowrite32be;
+	}
````
It would be good to also check it for the big Endian case and report a failure if not matching any of the cases.

Also once https://github.com/litex-hub/linux-on-litex-vexriscv/issues/72 will be added, we should be sure to reset the scratch register before doing this test. It will be possible to do so with https://github.com/enjoy-digital/litex/issues/347.
 Comments: 
 Comment 0: Any chance that using the new LiteX CSR accessors in the SoC controller driver https://github.com/enjoy-digital/litex/pull/339 might preempt the need to even worry about endianness in the first place? That, and enabling things to work beyond just the 32-bit cpu, 8-bit csr_data_width use case?

(I get that this is Linux on *vexriscv*, and I'm interested in 64-bit Rocket, but it'd be nice to have something generic that works in all cases for upstream Linux :)
 Comment 1: @gsomlo: indeed that would be even better! cc @mateusz-holenko 
 Comment 2: I totally agree that using versatile CSR accessors - like the one currenty in LiteX - is a very good idea. In fact this is why we introduced `litex.h` header to this repo in the first place (https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/patches/linux/0006-drivers-gpio-add-LiteX-GPIO-driver.patch#L290). 
Our implementation might require some tweaking to support CPUs beyond 32-bits but it won't be problematic --- the general idea behind both approaches is exactly the same.

Now to the idea of using the code from LiteX directly - it won't be possible to use external headers in mainline kernel anyway, so we need to provide some fixed version with the driver. In this context I don't see a big difference between using `litex.h` (from this repo) or `common.h` (from LiteX).

As for the endianness detection - we do it in order to use `read32/be`/`write32/be` functions. This is the preferred way of accessing IO in kernel as it automatically handles memory barriers.
There is also a matter of locking - we must make sure that accesses to CSRs in multi-CPU systems are atomic. It's not currently implemented in `litex.h`, but it's planned in the future.

All in all, I'm not sure if sharing the same header between LiteX (intended for small, "bare-metal" solutions) and linux-on-litex-vexriscv (intended specifically for the Linux kernel) makes sense.
The general idea and shape - sure, but the implementation details?

We prepared a fix for the current version of SoC Controller driver verifying the endianness in both directions: https://github.com/antmicro/linux-on-litex-vexriscv/commit/2b4edf8f4f2cd327b1abe5a70cf72a7823ac9ccc

@enjoy-digital, @gsomlo - what do you think?
 Comment 3: Thanks @mateusz-holenko, you will probably found this discussion interesting: https://github.com/enjoy-digital/litex/issues/365#issuecomment-579755860.

>All in all, I'm not sure if sharing the same header between LiteX (intended for small, "bare-metal" solutions) and linux-on-litex-vexriscv (intended specifically for the Linux kernel) makes sense.
The general idea and shape - sure, but the implementation details?

It seems there will always be specific needs/constraints that will justify the need for specific accessors, so i'm fine with your solution. Having generic accessors in `common.h` will still useful for initial port on a new architectures or bare metal tests when there are no constraints. If @gsomlo is also fine with your fix, we could integrate it.
 Comment 4: I was really confused about `ioread32()` vs. `ioread32be()`, until I realized that the thing they're both relying upon (`readl()`) actually does its _own_ byteswap on BE architectures. There's `__raw_readl()` which just reads a value from a `uint32 *`, but then `readl` wraps a `__le32_to_cpu` around the raw read, so `ioread32be()` is used to _undo_ that :)

Might be worth bypassing all of this `ioread32[be]` stuff with simply:
```
static inline unsigned long ioread_litex_simple(const volatile void __iomem *addr)
{
    unsigned long val;
    __io_br();
    val = *(const volatile unsigned long __force *)addr;
    __io_ar(val);
    return val;
}
```
which then would:
1. work on both 32 and 64 bit alignment (otherwise we'd have to `#ifdef` based on cpu width and use `ioread64[be]()` on 64-bit CPUs)
2. move us back to where we don't have to think or care about endianness, since the way LiteX wires up CSR subregisters (a.k.a. "simple CSRs") always matches the CPU endianness (while _across_ subregisters, the more significant subregisters are stored at lower addresses, Big Endian style, on both Big and Little endian architectures)

At this point I'm ok with whatever you guys decide, since I'm not really a vexriscv user. At some point in the near future I'm hoping to get some spare cycles and contribute to making Linux drivers work seamlessly for both 32 and 64bit (e.g., Rocket) and both endianness options, but I don't want to hold back progress on vexriscv by picking nits from the sidelines :)
 Comment 5: Thanks for the idea, @gsomlo - it looks interesting! Using the `ioread_litex_simple` approach would definiately simplify the code. 

For now, however, I suggest we review and merge the fix we have (https://github.com/litex-hub/linux-on-litex-vexriscv/pull/95). It will solve this issue and give us time to plan further improvements in SoC Controller's driver (including dropping the endianness detection).
 Comment 6: Thanks @mateusz-holenko for #95, i'm fine with it. @gsomlo would you mind also reviewing it?
 Comment 7: I don't want to hold you all back, so I'm ok merging whatever works on vexriscv for now. I'm stuck in a place with poor Internet access for the next two weeks, and I'm not set up to test things on 32bit linux in the first place, so it'd be a while before I can actually provide any useful feedback on this specific patch.

I'd like to ensure we handle 64-bit vs. 32-bit and 8-vs-32 bit csr_data_width as seamlessly as possible before we try to push anything like this into upstream/mainline linux though.

The `ioread_litex_simple()` idea to work around dealing with alignment and endianness _at all_ was mostly motivated by folks on lkml pointing out `*be()` as a "reason for concern" :) 
(https://lore.kernel.org/patchwork/patch/1143354/)

In my (limited) experience, getting anything into upstream linux is a protracted, labor intensive affair, so getting it right for all relevant use cases first would definitely be valuable, IMHO.

 Comment 8: Thanks for the feedback @gsomlo, i agree with you for upstreaming to Linux: if some efforts on our side could reduce future headaches while trying to upstream/maintaining the driver or just adapting it to a new architecture, we should do it. i keep thing issue open to continue discussing on this and will rename it.
 Comment 9: @gsomlo: you suggestion has been implemented by @mateusz-holenko in https://github.com/litex-hub/linux-on-litex-vexriscv/pull/106.
 Comment 10: @gsomlo: Once again, thanks for the idea. I changed the implementaion a little as in kernel 5.0.13 `__io_ar` does not accept any arguments + I made it work on `u32`, but nevertheless it helped to eliminate the need of detecting endianness after all!
 Comment 11: Happy to be of help, and thanks for doing this -- should make it that much
easier to support 64bit kernels in the future :)

{'source': 'GithubIssues', 'repo_name_with_owner': 'litex-hub/linux-on-litex-vexriscv', 'issue_id': 551293085, 'repo_stars': 358.0}