On 10/03/2021 16:39, Arnd Bergmann wrote: > On Wed, Mar 10, 2021 at 4:06 PM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: >> On 10/03/2021 15:45, Tom Rix wrote: >>> On 3/10/21 1:45 AM, Lee Jones wrote: >> >> Many other architectures do not have vendor prefix (TEGRA, EXYNOS, >> ZYNQMP etc). I would call it the same as in ARMv7 - ARCH_SOCFPGA - but >> the Altera EDAC driver depends on these symbols to be different. >> Anyway, I don't mind using something else for the name. > > I agree the name SOCFPGA is confusing, since it is really a class of > device that is made by multiple manufacturers rather than a brand name, > but renaming that now would be equally confusing. If the Intel folks > could suggest a better name that describes all products in the platform > and is less ambiguous, we could rename it to that. I think ARCH_ALTERA > would make sense, but I don't know if that is a name that is getting > phased out. (We once renamed the Marvell Orion platform to ARCH_MVEBU, > but shortly afterwards, Marvell renamed their embedded business unit (EBU) > and the name has no longer made sense since). I wait then for some ideas from Dinh (or anyone else). > > Regardless of what name we end up with, I do think we should have the > same name for 32-bit and 64-bit and instead fix the edac driver to do > runtime detection based on the compatible string. I can rename ARCH_SOCFPGA on 32-bit ARM as well, however converting edac driver from #ifdef ARCH_SOCFPGA64 to proper compatible string will be too much for me: I am not able to test it. This edac Altera driver is very weird... it uses the same compatible differently depending whether this is 32-bit or 64-bit (e.g. Stratix 10)! On ARMv7 the compatible means for example one IRQ... On ARMv8, we have two. It's quite a new code (2019 from Intel), not some ancient legacy, so it should never have been accepted... Best regards, Krzysztof