On Wed, Jul 11, 2018 at 1:32 PM, Boris Brezillon
<boris.brezillon@xxxxxxxxxxx> wrote:
> On Wed, 11 Jul 2018 13:27:53 +0200
> Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
>> On Wed, Jul 11, 2018 at 1:16 PM, Boris Brezillon
>> <boris.brezillon@xxxxxxxxxxx> wrote:
>> > On Mon, 9 Jul 2018 22:09:25 +0200
>> > Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote:
>> >
>> >> It just makes NAND maintainers' life easier by allowing them to
>> >> compile-test this driver without having ARCH_S3C24XX or ARCH_S3C64XX
>> >> enabled.
>> >>
>> >> We add a dependency on HAS_IOMEM to make sure the driver compiles
>> >> correctly, and a dependency on !IA64 because the {read,write}s{bwl}()
>> >> accessors are not defined for this architecture.
>> >
>> > I see that SPARC does not define those accessors either. So I guess we
>> > should add depends on !SPARC.
>> >
>> > Arnd, any other way to know when the platform implements
>> > {read,write}s{bwl}() accessors?
>>
>> I'd just consider that a bug, and send a patch to fix sparc64 if it's broken.
>> sparc32 appears to have these, and when Thierry sent the patch
>> to implement them everywhere[1], he said that he tested sparc64 as
>> well, so either something regressed since then, or his testing
>> was incomplete. Either way, the correct answer IMHO would be to
>> make it work rather than to add infrastructure around the broken
>> configurations.
>
> I guess the same goes for IA64 then.
Right. FWIW, I just tried it out and sent the respective arch patches.
Arnd
