From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Maciej S. Szmigiero" Subject: Re: [PATCH] serial: don't announce CIR serial ports Date: Wed, 05 Aug 2015 14:35:48 +0200 Message-ID: <55C20324.2030305@maciej.szmigiero.name> References: <55BE8725.6090303@maciej.szmigiero.name> <55C0196C.7090308@hurleysoftware.com> <55C149E6.7040407@maciej.szmigiero.name> <55C16ED4.7080604@hurleysoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55C16ED4.7080604@hurleysoftware.com> Sender: linux-kernel-owner@vger.kernel.org To: Peter Hurley Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman , Jiri Slaby , linux-kernel List-Id: linux-serial@vger.kernel.org On 05.08.2015 04:03, Peter Hurley wrote: > 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(). That's a good idea, checks for PORT_8250_CIR in serial port callbacks can be removed too this way, since these callbacks won't ever be called. I've submitted an updated patch. > Regards, > Peter Hurley Best regards, Maciej Szmigiero