Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp106632imm; Thu, 16 Aug 2018 16:28:30 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzN3p85gNoOsHFzip8x1dORLLLKXcospfzMduIRwe/6nU4FMeD0mzZC7gYiuZ+RJCAcO4m2 X-Received: by 2002:a62:d113:: with SMTP id z19-v6mr33947285pfg.98.1534462110476; Thu, 16 Aug 2018 16:28:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534462110; cv=none; d=google.com; s=arc-20160816; b=X5g3nljGbo5aAvtrAgE9C79EYWWNMYWIB2shEWfekqLUcdCSD6Ix11TOYwk/MaGID2 brQrSx58CyK8oeKtkCMpFZ4M0Ia24YSRtqLuiS0tjYOoNQ3jYLDPcGOYxJS4uvW34IdH vu6mVj7JDC5eLV4cKIvQCnrgKJqbPco3Pi2qOY4Fu/MzssIY1pIMixANkYc+gy+FK/38 qoX+9EwttYMlOzrdFEfpaIqIqCd0+8/SOR2tXidrMLKEK/wtFwU0c10HzfSwNOU5BWTv MDWmavj2OAOcPiSv3gMk1lH0xRVIr8GmHpCYXv4LIQi06b79gXB3+c+FX2ENFkJ+sugR zL6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=q35a/uto94mAMrQgp3puKuo6JQc541ARllNkpqDGl6A=; b=rLssgde9M/Vtaq0rJeJE5mykt5J4t1rB875lJNxx2lBeyiCv2SXfGQHDpEnObadkcb tO8Ib2qZ7js50EMWCOxHLh5ypQpui2Zg/w9RMOapPvSJUs1Ukp8ahHrANW1n02UMzYNY zva7AdwEP8u4mD78+s8o+WjOxkbrzihp3dior8yjCWSbMGp3OdqauDBp7WdmmGS9jehI zUklEDe9botsVyy4u4+382B2cDqmUOIyPIdJxQxjuDESNfVvqZNFXo85RRWMeCOpUNnr pJ58FxWaekrAexRXVH1uPtB3jKV0ZabK+tOC2ItRNKGTGFH0L/Zbcd6bIP0jYdKDADLy f/wA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x6-v6si527758pgk.597.2018.08.16.16.28.15; Thu, 16 Aug 2018 16:28:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726066AbeHQC2M (ORCPT + 99 others); Thu, 16 Aug 2018 22:28:12 -0400 Received: from mga11.intel.com ([192.55.52.93]:14000 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725949AbeHQC2M (ORCPT ); Thu, 16 Aug 2018 22:28:12 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2018 16:27:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,249,1531810800"; d="scan'208";a="225288789" Received: from agluck-desk.sc.intel.com (HELO agluck-desk) ([10.3.52.160]) by orsmga004.jf.intel.com with ESMTP; 16 Aug 2018 16:26:44 -0700 Date: Thu, 16 Aug 2018 16:26:40 -0700 From: "Luck, Tony" To: Arnd Bergmann Cc: Bjorn Helgaas , Linux Kernel Mailing List , jchandra@broadcom.com, Sinan Kaya , Tomasz Nowicki , Lorenzo Pieralisi , Boris Brezillon , Miquel Raynal Subject: Re: how to fix acpi_pci_root_remap_iospace? Message-ID: <20180816232639.GA25889@agluck-desk> References: <20180816204506.GA21144@agluck-desk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote: > Another way would be to add > > #include > +#undef PCI_IOBASE > > in your asm/io.h. This is about as ugly as the your version, but > it would be local to ia64 ;-) Third way ... Is "0" actually the right value for PCI_IOBASE for some platform? #ifndef PCI_IOBASE #define PCI_IOBASE ((void __iomem *)0) #endif Or is this just here to make sure that: static inline u8 inb(unsigned long addr) { u8 val; __io_pbr(); val = __raw_readb(PCI_IOBASE + addr); __io_par(); return val; } etc. Do not throw errors? Should we really just enclose all of inb, inw, inl, ... inside of: #ifdef PCI_IOBASE ... all those static functions that use PCI_IOBASE ... #endif -Tony