From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.bootlin.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fdDMh-00056X-Er for linux-mtd@lists.infradead.org; Wed, 11 Jul 2018 11:33:02 +0000 Date: Wed, 11 Jul 2018 13:32:36 +0200 From: Boris Brezillon To: Arnd Bergmann Cc: Ralf Baechle , "open list:RALINK MIPS ARCHITECTURE" , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Richard Weinberger , Miquel Raynal , linux-mtd , linux-wireless , Marek Vasut , Brian Norris , David Woodhouse Subject: Re: [PATCH v2 04/24] mtd: rawnand: s3c2410: Allow selection of this driver when COMPILE_TEST=y Message-ID: <20180711133236.67726256@bbrezillon> In-Reply-To: References: <20180709200945.30116-1-boris.brezillon@bootlin.com> <20180709200945.30116-5-boris.brezillon@bootlin.com> <20180711131626.732967be@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 11 Jul 2018 13:27:53 +0200 Arnd Bergmann wrote: > On Wed, Jul 11, 2018 at 1:16 PM, Boris Brezillon > wrote: > > On Mon, 9 Jul 2018 22:09:25 +0200 > > Boris Brezillon 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.