public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Arnd Bergmann <arnd@kernel.org>, "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	linux-serial@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] tty: serial: handle HAS_IOPORT dependencies
Date: Fri, 04 Oct 2024 18:03:45 +0200	[thread overview]
Message-ID: <d5c4e2aa1cc04bf1259fb6bd44f269621693b114.camel@linux.ibm.com> (raw)
In-Reply-To: <eedc037b-8790-4269-8ed6-d641b9cbc4ad@app.fastmail.com>

On Fri, 2024-10-04 at 12:48 +0000, Arnd Bergmann wrote:
> On Fri, Oct 4, 2024, at 10:09, Niklas Schnelle wrote:
> 
> > I'm working on a new proposal for 8250 now. Basically I think we can
> > put the warning/error in serial8250_pci_setup_port(). And then for
> > those 8250_pci.c "sub drivers" that require I/O ports instead of just
> > ifdeffing out their setup/init/exit we can define anything but setup to
> > NULL and setup to pci_default_setup() such that the latter will find
> > the I/O port BAR via FL_GET_BASE() and subsequently cause the error
> > print in serial8250_pci_setup_port(). It's admittedly a bit odd but it
> > also keeps the #ifdefs to just around the code that wouldn't compile.
> 
> Right, makes sense.
> 
> > One thing I'm not happy with yet is the handling around
> > is_upf_fourport(port) in 8250_pci.c. With !HAS_IOPORT this is defined
> > as false. With that it makes sure that inb_p()/outb_p() aren't called
> > but I think this only works because the compiler usually drops the dead
> > if clause. I think there were previous discussions around this but I
> > think just like IS_ENABLED() checks this isn't quite correct.
> 
> Not sure what you mean, we rely on dead code elimination in all
> kinds of places. The only bit to be aware of is that normal
> 'inline' functions may not get constant-folded all the time,
> but anything that is either a macro or __always_inline does
> work.

Ah ok, didn't know this was okay to rely on. Then I can roll the extra
#ifdefs back. Need to address the test bot's finding anyway. There we
can get #ifdef __i386__ but also !HAS_IOPORT on um.

> 
> I just verified that the version below does what Maciej
> suggested with IS_ENABLED() in 8250-pci, and this works fine.
> 
>        Arnd

Your version below is also pretty nice a bit more spread out but less
#ifdefs. That said at least in my NeoVim setup the #ifdefs are nicely
grayed out via clang-analyzer / lsp which to me actually makes #ifdefs
quite easy to see at a glance but that's probably a niche opinion.

> 
> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
> index 6709b6a5f301..784190824aad 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -928,6 +928,14 @@ static int pci_netmos_init(struct pci_dev *dev)
>  	return num_serial;
>  }
>  
> +static int serial_8250_need_ioport(struct pci_dev *dev)
> +{
> +	dev_warn(&dev->dev,
> +		 "Serial port not supported because of missing I/O resource\n");
> +
> +	return -ENXIO;
> +}
> +
---8<---


  reply	other threads:[~2024-10-04 16:03 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 15:29 [PATCH 0/1] tty: Handle HAS_IOPORT dependencies Niklas Schnelle
2024-04-05 15:29 ` [PATCH 1/1] tty: serial: handle " Niklas Schnelle
2024-04-08  9:54   ` Ilpo Järvinen
2024-04-08 10:17     ` Arnd Bergmann
2024-04-08 10:25       ` Ilpo Järvinen
2024-10-01  9:04       ` Niklas Schnelle
2024-04-08 15:35     ` Niklas Schnelle
2024-04-08 15:41       ` Ilpo Järvinen
2024-04-08 15:50         ` Arnd Bergmann
2024-05-23  2:11   ` Maciej W. Rozycki
2024-10-01 11:21     ` Niklas Schnelle
2024-10-01 15:31       ` Arnd Bergmann
2024-10-01 16:41       ` Maciej W. Rozycki
2024-10-02 12:44         ` Niklas Schnelle
2024-10-02 18:12           ` Maciej W. Rozycki
2024-10-02 22:00             ` Arnd Bergmann
2024-10-02 22:59               ` Maciej W. Rozycki
2024-10-04  6:53                 ` Arnd Bergmann
2024-10-04 16:24                   ` Maciej W. Rozycki
2024-10-04 16:57                     ` Arnd Bergmann
2024-10-04 10:09                 ` Niklas Schnelle
2024-10-04 12:48                   ` Arnd Bergmann
2024-10-04 16:03                     ` Niklas Schnelle [this message]
2024-10-04 14:44                   ` Niklas Schnelle
2024-10-04 16:34                   ` Maciej W. Rozycki
2024-11-22 15:18   ` Guenter Roeck
2024-11-22 15:35     ` Niklas Schnelle
2024-11-22 16:31       ` Arnd Bergmann
2024-11-22 17:22         ` Guenter Roeck
2024-11-22 19:24           ` Arnd Bergmann
2024-11-22 20:44             ` Guenter Roeck
2024-11-22 22:51               ` Arnd Bergmann
2024-11-23  2:14                 ` Guenter Roeck
2024-11-25  7:55             ` Andy Shevchenko
2024-11-25  9:53               ` Arnd Bergmann
2024-11-25 10:33                 ` Andy Shevchenko
2024-11-25 11:06                   ` Arnd Bergmann
2024-11-25 11:26                     ` Andy Shevchenko
2024-11-25 13:50                       ` Arnd Bergmann
2024-11-25 15:42                         ` Andy Shevchenko
2024-11-25 16:54                         ` Maciej W. Rozycki
2024-11-25 17:54                           ` Arnd Bergmann
2024-11-25 18:42                             ` Maciej W. Rozycki
2024-12-04 18:51                             ` Guenter Roeck
2024-11-25 15:59                     ` Arnd Bergmann
2024-12-04 21:09                       ` Guenter Roeck
2024-12-04 22:17                         ` Arnd Bergmann
2024-12-04 22:44                           ` Guenter Roeck
2024-12-05  7:08                             ` Arnd Bergmann
2024-12-05 14:31                               ` Guenter Roeck
2024-12-06 15:44                           ` Andy Shevchenko
2024-12-06 16:02                             ` Arnd Bergmann
2025-01-16 12:26                               ` Andy Shevchenko
2024-11-22 17:07       ` Guenter Roeck
2024-11-22 23:27         ` Niklas Schnelle
2024-11-22 23:34         ` Niklas Schnelle
2024-11-23  9:21           ` Arnd Bergmann
2024-04-05 22:33 ` [PATCH 0/1] tty: Handle " Andy Shevchenko
2024-04-06  8:06   ` Arnd Bergmann

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=d5c4e2aa1cc04bf1259fb6bd44f269621693b114.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=arnd@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    /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