linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: John Garry <john.garry@huawei.com>, Arnd Bergmann <arnd@kernel.org>
Cc: 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: Mon, 20 Dec 2021 10:27:39 +0100	[thread overview]
Message-ID: <11e180449d82e5276586cdaab5e70a1c1b3adb42.camel@linux.ibm.com> (raw)
In-Reply-To: <d45ee18a-1faa-9c56-071d-18f5737d225c@huawei.com>

On Fri, 2021-12-17 at 16:30 +0000, John Garry wrote:
> On 17/12/2021 15:55, Arnd Bergmann wrote:
> > > > 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.
> > Agreed, I missed these when I looked through the HAS_IOPORT users,
> > that's why I suggested to split up that part of the patch per subsystem
> > so they can be inspected more carefully.
> 
> ok
> 
>  >
>  > My feeling is that in this case we want some other dependency, e.g. a
>  > new CONFIG_LPC. It should actually be possible to use this driver on
>  > any machine with an LPC bus, which would by definition be the primary
>  > I/O space, so it should be possible to load it on Arm64.
> 
> You did suggest HARDCODED_IOPORT earlier in this thread, and the 
> definition/premise there seemed sensible to me.
> 
> Anyway it seems practical to make all these changes in a single series, 
> so need a way forward as Niklas has no such changes for this additional 
> kconfig option.
> 
> As a start, may I suggest we at least have Niklas' patch committed to a 
> dev branch based on -next or latest mainline release for further analysis?
> 
> Thanks,
> John
> 
> 

My plan would be to split the patch up into more manageable pieces as
suggested by Arnd plus of course fixes like the missing ARM select. As
Arnd suggested I'll split the HAS_IOPORT additions into the initial
introduction plus arch selects and then the HAS_IOPORT dependencies per
subsytem. I think these per subsystem dependency patches then would be
a great place to find drivers which should have a different dependency
be it on LPC or a newly introduced HARDCODED_IOPORT. The thing is we
can find and check HAS_IOPORT dependencies easily but it's hard to find
HARDCODED_IOPORT so I think the lattter should be a refinement of the
former. It can of course still go in as a single series. I'll
definitely make the next iteration available as a git branch.

Thanks,
Niklas


  reply	other threads:[~2021-12-20  9: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
2021-12-17 15:55                                   ` Arnd Bergmann
2021-12-17 16:30                                     ` John Garry
2021-12-20  9:27                                       ` Niklas Schnelle [this message]
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=11e180449d82e5276586cdaab5e70a1c1b3adb42.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=arnd@kernel.org \
    --cc=john.garry@huawei.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).