From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751538AbdFHSyH (ORCPT ); Thu, 8 Jun 2017 14:54:07 -0400 Received: from ale.deltatee.com ([207.54.116.67]:34610 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbdFHSyF (ORCPT ); Thu, 8 Jun 2017 14:54:05 -0400 To: Geert Uytterhoeven References: <1495726955-27497-1-git-send-email-logang@deltatee.com> <3c36765c-9e23-7947-b6d9-29ca892bd348@nod.at> <1bffdbbd-a317-d9a3-88d2-d02501d2fae1@deltatee.com> <8ad31524-dfc3-4fc4-f725-a8899aea9234@deltatee.com> Cc: Richard Weinberger , "linux-kernel@vger.kernel.org" , uml-devel , Stephen Bates , Jeff Dike , Al Viro , Arnd Bergmann From: Logan Gunthorpe Message-ID: <348baf8d-b42f-13a7-3398-cb0268d7c693@deltatee.com> Date: Thu, 8 Jun 2017 12:53:40 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8ad31524-dfc3-4fc4-f725-a8899aea9234@deltatee.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: arnd@arndb.de, viro@zeniv.linux.org.uk, jdike@addtoit.com, sbates@raithlin.com, user-mode-linux-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, richard@nod.at, geert@linux-m68k.org X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v2] um: add dummy ioremap and iounmap functions X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Any thoughts on this? My patches for the other architectures are already in linux-next. um is the only one that remains. Thanks, Logan On 27/05/17 12:15 PM, Logan Gunthorpe wrote: > Hi, > > On 27/05/17 12:08 PM, Geert Uytterhoeven wrote: >> Still, those code patch could be protected by #ifdef CONFIG_HAS_IOMEM, >> or better, if (IS_ENABLED(CONFIG_HAS_IOMEM)). > > Well I think it would have to be the former seeing the latter would > still end up trying to compile the missing function. But having ifdefs > inside code is not generally seen as good idea[1]. > > I'd really like to go forward with either this patch or something like > it. The other two arches that have this problem are fine with merging a > fix and adding ifdefs to work around a single arch doesn't feel right to me. > > Thanks, > > Logan > > [1] http://yarchive.net/comp/linux/ifdefs.html >