linux-kernel - Re: [PATCH v2 1/1] serial: 8250_of: Drop quirk fot NPCM from 8250

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3885f098-140c-bd5a-922d-a010236cc87d@linux.intel.com>
Date: Fri, 16 Feb 2024 16:41:37 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
    LKML <linux-kernel@...r.kernel.org>, 
    linux-serial <linux-serial@...r.kernel.org>, 
    Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v2 1/1] serial: 8250_of: Drop quirk fot NPCM from
 8250_port

On Fri, 16 Feb 2024, Andy Shevchenko wrote:

> On Fri, Feb 16, 2024 at 11:31:01AM +0200, Ilpo Järvinen wrote:
> > On Thu, 15 Feb 2024, Andy Shevchenko wrote:
> > > On Thu, Feb 15, 2024 at 06:40:15PM +0200, Ilpo Järvinen wrote:
> > > > On Thu, 15 Feb 2024, Andy Shevchenko wrote:
> 
> ...
> 
> > > > > +	/*
> > > > > +	 * Nuvoton calls the scratch register 'UART_TOR' (timeout
> > > > > +	 * register). Enable it, and set TIOC (timeout interrupt
> > > > > +	 * comparator) to be 0x20 for correct operation.
> > > > > +	 */
> > > > > +	serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20);
> > > > > +
> > > > > +	return serial8250_do_startup(port);
> > > > 
> > > > I know this matches how it is currently done\
> > > 
> > > Exactly, I haven't changed the workflow.
> > > Does it mean you are okay with the change?
> > 
> > Mostly. Another thing I was let bit unsure if it's okay to move that 
> > serial_port_out() outside of RPM get/put that is inside 
> > serial8250_do_startup().
> 
> We have other (actively used AFAIK) drivers which do the same.
> In any case this driver does not use RPM anyway, and in the future,
> when Tony finalizes his RPM work those 8250 RPM wrappers should gone.
> If somebody implements RPM in this driver, it may be done via standard
> RPM calls.
> 
> TL;DR: for now it's okay, I am sure.

Okay,

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>

-- 
 i.