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<---
next prev parent 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