All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access
Date: Fri, 17 Dec 2021 15:27:09 +0000	[thread overview]
Message-ID: <cd9310ab-6012-a410-2bfc-a2f8dd8d62f9@huawei.com> (raw)
In-Reply-To: <CAK8P3a0dnXX7Cx_kJ_yLAoQFCxoM488Ze-L+5v1m0YeyjF4zqw@mail.gmail.com>

On 17/12/2021 14:32, Arnd Bergmann wrote:
>> I was interesting in the IOPORT_NATIVE flag (or whatever we call it) as
>> it solves the problem of drivers which "unconditionally do inb()/outb()
>> without checking the validity of the address using firmware or other
>> methods first" being built for (and loaded on and crashing) unsuitable
>> systems. Such a problem is in [0]
>>
>> So if we want to support that later, then it seems that someone would
>> need to go back and re-edit many same driver Kconfigs – like hwmon, for
>> example. I think it's better to avoid that and do it now.
>>
>> Arnd, any opinion on that?
>>
>> I'm happy to help with that effort.
> I looked at the options the other day and couldn't really find any that
> fell into this category, so I suggested that Niklas would skip that for the
> moment. 

 From looking at the patch Niklas directed us at, as I understand, 
HAS_IOPORT is to decide whether the arch/platform may support PIO 
accessors - inb et al. And on that basis I am confused why it is not 
selected for arm64. And further compounded by:

  config INDIRECT_PIO
	 	bool "Access I/O in non-MMIO mode"
	 	depends on ARM64
	+	depends on HAS_IOPORT

If arm64 does not select, then why depend on it?

 > If you have a better way of finding the affected drivers,
 > that would be great.

Assuming arm64 should select HAS_IOPORT, I am talking about f71805f as 
an example. According to that patch, this driver additionally depends on 
HAS_IOPORT; however I would rather arm64, like powerpc, should not allow 
that driver to be built at all.

Thanks,
John

  reply	other threads:[~2021-12-17 15:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 13:47 [GIT PULL 1/2] asm-generic: rework PCI I/O space access Arnd Bergmann
2021-07-02 13:49 ` [GIT PULL 2/2] asm-generic: Unify asm/unaligned.h around struct helper Arnd Bergmann
2021-07-02 20:13   ` pr-tracker-bot
2021-07-02 19:42 ` [GIT PULL 1/2] asm-generic: rework PCI I/O space access Linus Torvalds
2021-07-03 12:12   ` Arnd Bergmann
2021-07-05 10:06     ` Arnd Bergmann
2021-08-03  9:46       ` John Garry
2021-08-03 10:06         ` Arnd Bergmann
2021-08-03 11:23           ` John Garry
2021-08-03 12:15             ` Arnd Bergmann
2021-08-04  7:55               ` John Garry
2021-08-04  8:52                 ` Arnd Bergmann
2021-08-10  9:19                   ` John Garry
2021-08-10 11:33                     ` Arnd Bergmann
2021-09-03  8:31                       ` Niklas Schnelle
2021-12-17 13:19                       ` Niklas Schnelle
2021-12-17 13:32                         ` Arnd Bergmann
2021-12-17 13:52                           ` Niklas Schnelle
2021-12-17 14:05                             ` Arnd Bergmann
2021-12-17 14:27                             ` John Garry
2021-12-17 14:32                               ` Arnd Bergmann
2021-12-17 15:27                                 ` John Garry [this message]
2021-12-17 15:55                                   ` Arnd Bergmann
2021-12-17 16:30                                     ` John Garry
2021-12-20  9:27                                       ` Niklas Schnelle
2021-12-21 16:48                                         ` John Garry
2021-12-21 16:57                                           ` Niklas Schnelle
2021-12-19 14:23                               ` David Laight
2021-12-21 16:21                                 ` John Garry
2021-07-05 12:40     ` Niklas Schnelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd9310ab-6012-a410-2bfc-a2f8dd8d62f9@huawei.com \
    --to=john.garry@huawei.com \
    --cc=arnd@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=schnelle@linux.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.