* Tony Lindgren <tony@xxxxxxxxxxx> [230603 05:41]:
> I don't think 8250_mtk needs to do register access before and after the
> serial port registration, but if it does, then adding custom read/write
> functions can be done that do not rely on initialized port like
> serial_out().
Oh but mtk8250_runtime_suspend() calls serial_in(up, MTK_UART_DEBUG0), so
yeah if that gets called before registration is complete it causes a NULL
pointer exception. If the serial_ctrl and serial_port devices do runtime
suspend before port registration completes, things will fail.
Sounds like doing pm_runtime_resume_and_get() in mtk8250_probe() might
fix the issue. Still seems that adding a custom read function for
mtk8250_runtime_suspend() to use instead of calling serial_in() should
not be needed.
An experimental untested patch below, maye it helps?
Regards,
Tony
8< ------
diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -588,20 +588,24 @@ static int mtk8250_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
pm_runtime_enable(&pdev->dev);
- err = mtk8250_runtime_resume(&pdev->dev);
+ err = pm_runtime_resume_and_get(&pdev->dev);
if (err)
goto err_pm_disable;
data->line = serial8250_register_8250_port(&uart);
if (data->line < 0) {
err = data->line;
- goto err_pm_disable;
+ goto err_pm_put;
}
data->rx_wakeup_irq = platform_get_irq_optional(pdev, 1);
+ pm_runtime_put_sync(&pdev->dev);
+
return 0;
+err_pm_put:
+ pm_runtime_put_sync(&pdev->dev);
err_pm_disable:
pm_runtime_disable(&pdev->dev);
--
2.41.0
