From: Peter Hurley <peter@hurleysoftware.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: linux-serial@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] serial: don't announce CIR serial ports
Date: Tue, 04 Aug 2015 22:03:00 -0400 [thread overview]
Message-ID: <55C16ED4.7080604@hurleysoftware.com> (raw)
In-Reply-To: <55C149E6.7040407@maciej.szmigiero.name>
On 08/04/2015 07:25 PM, Maciej S. Szmigiero wrote:
> Hi Peter,
>
> Thanks for looking into it.
>
> On 04.08.2015 03:46, Peter Hurley wrote:
>> Hi Maciej,
>>
>> On 08/02/2015 05:09 PM, Maciej S. Szmigiero wrote:
>>> CIR type serial ports aren't real serial ports.
>>> This is just a way to prevent legacy serial driver
>>> from probing and eventually binding some resources
>>> so don't announce them like normal serial ports.
>>
>> I'd like to keep some form of reporting so that we know the
>> port was properly probed; what about extending uart_report_port()
>> to including CIR + disabled status?
>
> Currently the printed message looks like this:
> "00:01: ttyS2 at I/O 0x3e8 (irq = 7, base_baud = 115200) is a CIR port".
>
> I think it would be best to skip a device file name in this case,
> since this is how user sees (and uses) a real serial port.
> The message would be then:
> "00:01 at I/O 0x3e8 (irq = 7, base_baud = 115200) is a CIR port".
>
> The dev name will always be present since the only current
> "source" of CIR ports is PNP 8250 driver which sets
> dev pointer uncondtionally.
>
>> Secondly, good catch! Because we should not be trying to
>> register a console on this port, nor driving modem signals.
>>
>> So maybe an early exit after uart_report_port?
>
> All right, I will resubmit updated patch tomorrow.
In re-reviewing this, I think the proper solution is actually not
to add the uart port for a CIR port at all. It doesn't make
sense because the tty cannot be changed by setserial/ioctl(TIOCSSERIAL),
so the device node serves no purpose.
This problem is really an artifact of the 8250 driver port management,
and shouldn't involve the serial core at all.
An additional benefit of this approach is that a simple one-line
banner noting the port skip could be emitted instead from
serial8250_register_8250_port().
Regards,
Peter Hurley
next prev parent reply other threads:[~2015-08-05 2:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-02 21:09 [PATCH] serial: don't announce CIR serial ports Maciej S. Szmigiero
2015-08-03 23:40 ` Greg Kroah-Hartman
2015-08-04 0:40 ` Maciej S. Szmigiero
2015-08-04 1:46 ` Peter Hurley
2015-08-04 23:25 ` Maciej S. Szmigiero
2015-08-05 2:03 ` Peter Hurley [this message]
2015-08-05 12:35 ` Maciej S. Szmigiero
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=55C16ED4.7080604@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
/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