Re: [PATCH v5 17/17] serial: 8250: Add 8250_acpi driver
From: Sunil V L <sunilvl@ventanamicro.com>
Date: 2024-05-02 09:50:21
Also in:
linux-acpi, linux-pci, linux-riscv, linux-serial, lkml
On Thu, May 02, 2024 at 12:17:59PM +0300, Andy Shevchenko wrote:
On Wed, May 01, 2024 at 05:47:42PM +0530, Sunil V L wrote:quoted
RISC-V has non-PNP generic 16550A compatible UART which needs to be enumerated as ACPI platform device. Add driver support for such devices similar to 8250_of....quoted
+ * This driver is for generic 16550 compatible UART enumerated via ACPI + * platform bus instead of PNP bus like PNP0501. This is not a fullThis has to be told in the commit message. Anyway, we don't need a duplication code, please use 8250_pnp.
Hi Andy, Thank you for the review!. Major issue with PNP0501 is, it gets enumerated in a different way which causes issue to get _DEP to work. pnpacpi_init() creates PNP data structures which gets skipped if the UART puts _DEP on the GSI provider (interrupt controller). In that case, we need to somehow reinitialize such PNP devices after interrupt controller gets probed. I tried a solution [1] but it required several functions to be moved out of __init. This driver is not a duplicate of 8250_pnp. It just relies on UART enumerated as platform device instead of using PNP interfaces. Isn't it better and simple to have an option to enumerate as platform device instead of PNP? [1] - https://patchwork.kernel.org/project/linux-pci/patch/20240415170113.662318-14-sunilvl@ventanamicro.com/ Thanks, Sunil
...quoted
+ { "RSCV0003", 0 },Does it have _CID to be PNP0501? If not, add this ID to the 8250_pnp. ... P.S. The code you submitted has a lot of small style issues, I can comment on them if you want, but as I said this code is not needed at all. -- With Best Regards, Andy Shevchenko
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel