[PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI

[Andy Shevchenko]

On Tue, 2017-06-27 at 11:30 +0100, Phil Elwell wrote:
> On 27/06/2017 10:15, Andy Shevchenko wrote:
> > On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
> > 
> > > > But this looks like a bug / quirk than a capability?
> > > > 
> > > > It would be better to name this define more self-explaining.
> > > > 
> > > > Btw can't see the definition of UART_CAP_MINI?
> > > 
> > > The capability was added in
> > > d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d,
> > > which
> > > is in linux-next. Given that the "capability" already exists and
> > > the
> > > quirk
> > > is likely to be unique to BCM2835 MINI UART, I don't think we
> > > should
> > > create
> > > a new quirk.
> > > 
> > > Besides, the "HFIFO" capability looks a lot like quirk to me.
> > 
> > To me either, which raises a question "Should it be fixed
> > accordingly?"
> 
> If I was going to make these quirks, are we simply talking about
> renaming the
> capability or is there another mechanism? I've found the 8250_pci
> quirks, and
> they look quite different.

Okay, we have several types of flags in the code
1. Capabilities: UART_CAP: looks like it defines features of hardware
solely for 8250 compatible devices.
2. Flags as quirks UPF_<something, not all of them> (I have a patch to
convert them to quirks, need by the way to update and resend): they are
for any serial devices.
3. Flags as capabilities: UPF_<the rest>, similar function as UART_CAP,
but for any serial device.

> 
> I'm also happy to make this code conditional on
> CONFIG_SERIAL_8250_BCM2835AUX
> if that is more acceptable.

No, it is undesired.

Can you describe which one from the above suits the best for your case?

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy