From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DD2FC432BE for ; Tue, 3 Aug 2021 12:15:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5563660EE8 for ; Tue, 3 Aug 2021 12:15:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235867AbhHCMPx (ORCPT ); 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-Google-Smtp-Source: ABdhPJxAL8VftAhgCQ+bSLKaGZHOswlreW4hRX79bjyzo5amawkDoDYbsyb2ih3hosWG3M6soO1UgGXpHIPbXlBIBik= 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