From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial: 8250: 8250_core: Fix irq name for 8250 serial irq
Date: Mon, 20 Mar 2017 12:32:04 +0000 [thread overview]
Message-ID: <20170320123204.GI21222@n2100.armlinux.org.uk> (raw)
In-Reply-To: <CAHp75Vd7Q_0MZ69kojA_S_A4OOgdD5sR1MKW_NLXrZa6h+3GSA@mail.gmail.com>
On Thu, Mar 16, 2017 at 10:58:54PM +0200, Andy Shevchenko wrote:
> On Thu, Mar 16, 2017 at 4:55 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> > On 16/03/17 13:36, Russell King - ARM Linux wrote:
> >> On Thu, Mar 16, 2017 at 05:56:53PM +0530, Vignesh R wrote:
> >>> Using dev_name() as irq name during request_irq() might be misleading in
> >>> case of serial over PCI. Therefore use a better alternative name for
> >>> identifying serial port irqs as "serial" appended with serial_index of
> >>> the port. This ensures that "serial" string is always present in irq
> >>> name while port index will help in distinguishing b/w different ports.
> >>
> >> Wouldn't it be better to use the device name (iow, ttySx) rather than
> >> "serialx" ?
> >>
> >> Maybe a helper function in serial_core.c to format the device name into
> >> a supplied string, which can be re-used elsewhere, eg, uart_report_port()
> >> and uart_suspend_port(). IOW:
> >>
> >> const char *uart_port_name(char *buf, size_t n, struct uart_driver *drv,
> >> struct uart_port *port)
> >> {
> >> snprintf(buf, n, "%s%d", drv->dev_name,
> >> drv->tty_driver->name_base + port->line);
> >>
> >> return buf;
> >> }
> >>
> >> which means you can do this:
> >>
> >> char name[16];
> >>
> >> request_irq(..., uart_port_name(name, sizeof(name), driver, port), ...)
> >>
> >> which also avoids the allocation.
> >
> > ...and makes 'cat /proc/interrupts' particularly fun later:
> >
> > 8: 0 GICv2 72 Level ? ?h ????V!
> >
> > Unless a suitably long-lived string already exists somewhere else in the
> > serial core, the allocation is unavoidable, although kasprintf() (or its
> > devm_ variant) might make matters a little simpler.
>
> What prevents us to create a field in uart_port (uart8250_port?) where
> we put the uart_port_name() for future use as long as uart_port is
> alive?
Probably a good idea - I didn't check whether request_irq() just uses
the pointer to the string or takes a copy of the string (I should've
done before making the suggestion...)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2017-03-20 12:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 12:26 [PATCH] serial: 8250: 8250_core: Fix irq name for 8250 serial irq Vignesh R
2017-03-16 12:46 ` Jiri Slaby
2017-03-16 12:54 ` Jiri Slaby
2017-03-16 13:36 ` Russell King - ARM Linux
2017-03-16 14:55 ` Robin Murphy
2017-03-16 20:58 ` Andy Shevchenko
2017-03-20 12:24 ` Vignesh R
2017-03-20 12:32 ` Russell King - ARM Linux [this message]
2017-03-16 21:46 ` 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=20170320123204.GI21222@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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