Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2384698pxy; Tue, 3 Aug 2021 05:19:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPUpWQmRMCN/+IZW0IDkpyDpoZoRXJY61ddDpec1MTAwRS1aa+qLdjZisxQgjJbZvWD9NS X-Received: by 2002:aa7:d30e:: with SMTP id p14mr24877731edq.204.1627993191023; Tue, 03 Aug 2021 05:19:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627993191; cv=none; d=google.com; s=arc-20160816; b=UNhhaj3nAe6tkAGzADQ53Vgam05bST5H0xI/EcmX09H06nKlmUNCOaZgFKHwhBD1wE vEGuheoClXtIg7p7+gjJrCRYrksM0fasm5o/OIUST2JsRub2lGXPypn6cHq6whqJA9BM 2pB8sm2OsJ3Ilw0wz0kKmjTHuSuO7mhvhEnTF9e3vBHXKA9E+9hUI1aHRtM+u7PrES59 7w58kd+JEzSKDMzI6+NqgSYZtQcY5KAzgbv0daem3IawkLaVF1060sUAU0ETEDR5f9R4 NoODthRbiWXi00xHk3NPj9RAt1c9ORsGx54dfm3WKN6I5W/NLywlzVmzEQP8HlWOYqUe kFmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=a2fLQLa9T1WgoJyo3Ce3ILO7NJdmHVc8r8Z3tdezB/8=; b=Nw6uyH5AzbDUOEsJ91eSwA7tQziVA3EvlhdJQt+07wNhJr1KWh/gjVvvOKr/ypEdeo 6Y1v7N8w8OSGjViG9RnAGpX8V4PkAFuBTI35t32ssdLIb/ErKh0Ob9t33/Og6GguLkwV dkbbjEk72sl88CWHxdCUybNsYm1TZro8xE/8Y+o1TRabagANRk1cGBWLSlCZy4z3N3cd ThS77KZRls1lQkmDZs/HLVgR7iS6tjypi3kuHHJHzeaksNJ4pcMzX/EqMzv/wZ0/5cmk VN96IW8665ugIx1auNIpKhX65VG5tcTysyJ2qhFlflIIjFkxjtEVX5sAZ5SNocvnhyW8 Bj4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J4vot0vA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l24si13453117ejz.543.2021.08.03.05.19.26; Tue, 03 Aug 2021 05:19:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J4vot0vA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235826AbhHCMPx (ORCPT + 99 others); Tue, 3 Aug 2021 08:15:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:44374 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235847AbhHCMPt (ORCPT ); Tue, 3 Aug 2021 08:15:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B875160F56; Tue, 3 Aug 2021 12:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627992938; bh=YFyNorBzvHKd2LCdkw4zsM+gAMFMoZIoTqWAAptOfkg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=J4vot0vAmpIzv0uaEowWDkSGSknUbFG2w0ls6kn5sjZyCbGTHTXgcxzCDuA+/DRfn s3YvkZ+d4b/xyx3I4Ky5pOJC8c4gon3eKy84lrQJRTRwwWV3/LGIwU+m5yumygPvjm X6wlzVEY2QguuhaJCRmb/ATxyutApfmj+fMkdBs2ANSw9IzKEnn0tpS8QC09+kQj91 4WO/E05vUbAdhpe5vJ1IHu7wSEs7tAhspeZz2RZqzTBACbgqbOGiRio8lb1y2yV2Cc NrGYvszcFaG4Wvpe0qhVYxOQB/gdnc78HprwXKly/XXbanIBswJBWR711f0SQ/R0Mi q3X4QTrD5sYgQ== Received: by mail-wr1-f52.google.com with SMTP id p5so25102293wro.7; Tue, 03 Aug 2021 05:15:38 -0700 (PDT) X-Gm-Message-State: AOAM5301wUk4NkN88MBRUUwQhUyH3WXltxrl95d8JVTsNKqwVwSq35CM 1GaC1eZpnL+KKyXnEnPcltJj3tUM34o03hnRNkg= X-Received: by 2002:adf:e107:: with SMTP id t7mr22741611wrz.165.1627992937364; Tue, 03 Aug 2021 05:15:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Tue, 3 Aug 2021 14:15:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access To: John Garry Cc: Linus Torvalds , linux-arch , linux-pci , Linux Kernel Mailing List , Niklas Schnelle Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 3, 2021 at 1:23 PM John Garry wrote: > > so I'm just not building those drivers any more, and not > > defining the inb()/outb() helpers either, causing a build failure when I'm > > missing an option. > > > > However it sounds like you are interested in a third option here, which > > brings us to: > > > > LEGACY_PCI: any PCI driver that uses inb()/outb() or is only available > > on old-style PCI but not PCIe hardware without a bridge. > > To be disabled for most architectures and possibly distros but can > > be enabled for kernels that want to use those devices, as long as > > CONFIG_HAS_IOPORT is set by the architecture. > > > > HAS_IOPORT: not a legacy PCI device, but can only be built on > > architectures that define inb()/outb(). To be disabled for s390 > > and any other machine that has no useful definition of those > > functions. > > That seems reasonable. And asm-generic io.h should be ifdef'ed by > HAS_IOPORT. In your patch you had it under CONFIG_IOPORT - was that > intentional? No, that was a typo. Thanks for pointing this out. > On another point, I noticed SCSI driver AHA152x depends on ISA, but is > not an isa driver - however it does use port IO. Would such dependencies > need to be changed to depend on HAS_IOPORT? I'm not sure what you mean here. As far as I can tell, AHA152x is an ISA driver in the sense that it is a driver for ISA add-on cards. However, it is not a 'struct isa_driver' in the sense that AHA1542 is, AHA152x is even older and uses the linux-2.4 style initialization using a module_init() function that does the probing. > I did notice that arm32 support CONFIG_ISA - not sure why. This is for some of the earlier machines we support: mach-footbridge has some on-board ISA components, while SA1100, PXA25x and S3C2410 each have at least one machine with a PC/104 connector using ISA signaling for add-on cards. There are also a couple of platforms with PCMCIA or CF slots using the same ISA style I/O signals, but those have separate drivers. > > HARDCODED_IOPORT: (or another name you might think of,) Used by > > drivers that unconditionally do inb()/outb() without checking the > > validity of the address using firmware or other methods first. > > depends on HAS_IOPORT and possibly architecture specific > > settings. > > Yeah, that sounds the same as what I was thinking. Maybe IOPORT_NATIVE > could work as a name. I would think that only x86/ia64 would define it. > A concern though is that someone could argue that is a functional > dependency, rather than just a build dependency. You can have those on a number of platforms, such as early PowerPC CHRP or pSeries systems, a number of MIPS workstations including recent Loongson machines, and many Alpha platforms. Maybe the name should reflect that these all use PC-style ISA/LPC port numbers without the ISA connectors. Arnd