From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: drivers/accessibility/speakup/serialio.c:48:19: warning: variable 'quot' set but not used
Date: Mon, 16 Nov 2020 21:33:55 +0100 [thread overview]
Message-ID: <20201116203355.t7dboh6vlj57dsau@function> (raw)
In-Reply-To: <ef625c1e21c492be8c423730e45e90d92b1ae899.camel@decadent.org.uk>
Ben Hutchings, le lun. 16 nov. 2020 19:51:23 +0000, a ecrit:
> On Mon, 2020-11-16 at 20:01 +0100, Samuel Thibault wrote:
> > Perhaps we should rather use
> >
> > depends on ISA || (X86 && COMPILE_TEST)
> >
> > ?
> > so that we have compile testing on x86 only (where the inb/outb macros
> > always behave fine) to avoid such issues on other archs?
>
> That seems reasonable though unusual.
>
> > Or we tell the architecture maintainers to fix their out macros into
> > consuming their parameters?
> [...]
>
> It does seem odd for parisc to define the I/O functions this way. I
> don't know if it's really a bug.
Sorry I wasn't clear: the problem here is when CONFIG_EISA is disabled,
the eisa_in/out calls are replaced by BUG() stubs, and the stubs do not
consume their input:
arch/parisc/include/asm/io.h
#if defined(CONFIG_PCI)
extern void outb(unsigned char b, int addr);
#elif defined(CONFIG_EISA)
#define outb eisa_out8
#else
#define outb(x, y) BUG()
#endif
Samuel
next prev parent reply other threads:[~2020-11-16 20:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 1:54 drivers/accessibility/speakup/serialio.c:48:19: warning: variable 'quot' set but not used kernel test robot
2020-11-16 19:01 ` Samuel Thibault
2020-11-16 19:51 ` Ben Hutchings
2020-11-16 20:33 ` Samuel Thibault [this message]
2020-11-16 20:39 ` Ben Hutchings
-- strict thread matches above, loose matches on Subject: below --
2020-11-23 4:27 kernel test robot
2021-02-12 20:29 kernel test robot
2021-04-03 13:38 kernel test robot
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=20201116203355.t7dboh6vlj57dsau@function \
--to=samuel.thibault@ens-lyon.org \
--cc=ben@decadent.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.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