On 10/03/2021 16:47, Krzysztof Kozlowski wrote: > 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... Oh, it's not that horrible as it sounds. They actually have different compatibles for edac driver with these differences (e.g. in interrupts). They just do not use them and instead check for the basic (common?) compatible and architecture... Anyway without testing I am not the person to fix the edac driver. Best regards, Krzysztof
