From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752153AbcGRTzT (ORCPT ); Mon, 18 Jul 2016 15:55:19 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36020 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530AbcGRTzP (ORCPT ); Mon, 18 Jul 2016 15:55:15 -0400 Date: Mon, 18 Jul 2016 12:55:11 -0700 From: Brian Norris To: Arnd Bergmann Cc: Cyrille Pitchen , linux-mtd@lists.infradead.org, nicolas.ferre@atmel.com, boris.brezillon@free-electrons.com, marex@denx.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mtd: atmel-quadspi: add driver for Atmel QSPI controller Message-ID: <20160718195511.GA137880@google.com> References: <20160714013242.GG54628@google.com> <20160716004507.GD76613@google.com> <3482823.TCe8doMvLu@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3482823.TCe8doMvLu@wuerfel> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 18, 2016 at 09:35:39PM +0200, Arnd Bergmann wrote: > On Friday, July 15, 2016 5:45:07 PM CEST Brian Norris wrote: > > Applied to l2-mtd.git with that fixup. > > I'm getting this build error now on a randconfig build: > > drivers/mtd/built-in.o: In function `atmel_qspi_run_command': > :(.text+0x1ee3c): undefined reference to `_memcpy_toio' > :(.text+0x1ee48): undefined reference to `_memcpy_fromio' Whoops, I noticed those during review, but I don't know why I forgot to mention them nor fix them up before applying. > On ARCH_EBSA, which doesn't build the file that contains the two > functions. I don't see any other driver on ARM using those two > functions directly. What is the specific reason for using them > here? Do you require byte-wise accesses, or could you use > the normal memcpy_toio/memcpy_fromio that turn into aligned > 32-bit word accesses instead? Good questions. I would suspect that aligned 32-bit accesses are what they're looking for, but I'm not absolutely sure. > If you have to use the non-portable > functions, maybe we can just make the driver depend on !ARCH_EBSA? I don't see an ARCH_EBSA. Did you mean ARCH_EBSA110? Or we could just drop the '|| (ARM && COMPILE_TEST)' clause for now: depends on ARCH_AT91 || (ARM && COMPILE_TEST) Brian