| Message ID | 20210907102722.47543-1-bert@biot.com |
|---|---|
| Headers | show |
| Series | Add support for Airoha EN7523 SoC | expand |
On 07/09/2021 12:27, Bert Vermeulen wrote: > From: John Crispin <john@phrozen.org> > > Add vendor prefix "airoha" for Airoha. > > Signed-off-by: John Crispin <john@phrozen.org> > Signed-off-by: Bert Vermeulen <bert@biot.com> > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 07fb0d25fc15..e9c956535f97 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -333,6 +333,8 @@ patternProperties: > description: EBV Elektronik > "^eckelmann,.*": > description: Eckelmann AG > + "^airoha,.*": > + description: Airoha Wrong ordering. Best regards, Krzysztof
On Tue, Sep 7, 2021 at 2:27 PM Daniel Palmer <daniel@0x0f.com> wrote: > On Tue, 7 Sept 2021 at 20:52, Arnd Bergmann <arnd@arndb.de> wrote: > > > Off-topic but related: Another MediaTek spin off, SigmaStar, seems to > > > have done exactly the same thing. Cortex A53 chip running as a 32bit > > > system to avoid having to fix their software. I'm interested to see if > > > this makes it into arm or arm64. :) > > > > Maybe it's best to just add them to both at the same time? The boot > > loader situation might take a bit to work out, but in theory this should > > be fixable. > > I wonder how fixable it would be.. > > I haven't gotten a board with the chip in question (SSD268G) yet but > from looking at some firmware binaries I can see that even u-boot is a > 6 year old 32bit version. > As far as I can tell there's no PSCI, ATF etc that I think would be > expected for an arm64 machine. If the source code is available, creating a minimal PSCI implementation in u-boot should be possible, and it would make it work well for both 32-bit and 64-bit kernels. There is no need for ATF here. > I think the broken memory controller is still there so somehow I'd > need to get the heavy barrier to work in arm64. I haven't yet worked > out if that's even possible. I think I missed that part of the discussion, or I forgot about it already. What is the issue you are referring to here? Arnd
Hi Arnd, On Tue, 7 Sept 2021 at 23:12, Arnd Bergmann <arnd@arndb.de> wrote: > > I think the broken memory controller is still there so somehow I'd > > need to get the heavy barrier to work in arm64. I haven't yet worked > > out if that's even possible. >I think I missed that part of the discussion, or I forgot about it already. >What is the issue you are referring to here? Sorry. I should have put a bit more context. This is for the SSD268G not the original target of this series. But a similar situation. The SSD268G (according to the decompiled device tree) is the same hardware as the MSTAR_V7 chips but with a Cortex A53 instead of the Cortex A7. So it probably has the same memory controller as the MSTAR_V7 stuff and that memory controller is not coherent so it needs the kernel to make sure memory requests are flushed out to memory before DMA happens[0]. For arm I fixed that with the heavy mb callback. With arm64 I have no idea how to fix that. I'm interested to see how this Airoha EN7523 series goes as if/when I push anything for the SSD268G it'll probably only be for a 32bit kernel. 0 - https://elixir.bootlin.com/linux/latest/source/arch/arm/mach-mstar/mstarv7.c#L61