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

[Phil Elwell]

On 27/06/2017 18:52, Andy Shevchenko wrote:
> 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?

This bug I am trying to work around is found in the 8250 implementation of
one family of CPUs, so I would say capabilities are the best fit because
they are specific to 8250 drivers.

Phil