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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
