linux-kernel - Re: [PATCH 0/4] 8250: DMA Fixes

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: <Y2j0EmqkH8f57q9N@smile.fi.intel.com>
Date:   Mon, 7 Nov 2022 14:03:30 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Ilpo Jďż˝rvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] 8250: DMA Fixes

On Mon, Nov 07, 2022 at 01:50:38PM +0200, Ilpo Jďż˝rvinen wrote:
> On Mon, 7 Nov 2022, Andy Shevchenko wrote:
> 
> > On Mon, Nov 07, 2022 at 01:07:04PM +0200, Ilpo Järvinen wrote:
> > > Here are a number of 8250 DMA related fixes. The last one seems the
> > > most serious problem able to corrupt the payload ordering.
> > > 
> > > Ilpo Järvinen (4):
> > >   serial: 8250: Fall back to non-DMA Rx if IIR_RDI occurs
> > 
> > 8250_port?
> > 
> > >   serial: 8250_lpss: Configure DMA also w/o DMA filter
> > >   serial: 8250_lpss: Use 16B DMA burst with Elkhart Lake
> > >   serial: 8250: Flush DMA Rx on RLSI
> > 
> > 8250_port?
> 
> Why?

> To me this 8250_core/port split is still integral part of the same 
> 8250 even if they're in the end technically loaded into different modules
> or the code is in a different file. There's even some trickery to access 
> internals of the other part to workaround the circular module dependency 
> logic that would otherwise prevent the split (like we learned not so long 
> time ago with that setup_irq change).

> I can start to use 8250_port if you insist but it seems pointless 5 extra 
> characters out from a resource that is scarse to begin with, IMHO (the 
> summary line is not that long).

No strong opinion here, I just follow (in my patches) the following logic:
- if it touches a single file, I use full prefix,
- otherwise I use 8250

-- 
With Best Regards,
Andy Shevchenko