Re: [PATCH v2 1/4] serial: 8250_dw: Keep the BUSY-safe divisor hook when DLF is present

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Oct 21, 2026 at 12:37:32PM -0300, Vinicius Pedrosa wrote:
> On Wed, 21 Oct 2026, Andy Shevchenko wrote:
> 
> > Ah, dw8250_idle_*() are already BUSY-functionality aware. So, what we need
> > is to provide dw8250_idle_*() callbacks via struct dw8250_port_data and
> > make current 8250_dw::dw8250_set_divisor() to be part of dwlib.
> >
> > Patch 1 (dwlib): Add callback definitions for dw8250_idle_*() to struct dw8250_port_data
> > Patch 2 (dw): Assign new callbacks and use them in dw8250_set_divisor()
> > Patch 3 (lpss): Introduce stubs and assign new callbacks to them
> > Patch 4 (dwlib): Use dw8250_idle_*() in dw8250_set_divisor()
> > Patch 5 (dw): Kill now duplicate code pieces
> >
> > Would it work?
> 
> Yes, I think the approach works. Two details from checking the call
> paths.
> 
> dw8250_setup_port() is skipped for Octeon (skip_autocfg), so 8250_dw
> would still have to install the setter from probe.

No, just pass that as a 'bool autoconf' to it, and assign those callbacks
there, while calling dw8250_setup_port() unconditionally from _probe().

It might require another patch, though (to make it a parameter first).

> For LPSS, I wonder if the idle callbacks could simply be optional.
> 8250_dw would provide them and LPSS could leave them NULL, avoiding
> stubs and a separate LPSS patch. The common setter in dwlib would use
> them when present.

I think it would be less flexible, also it will add an additional branch
(actually two) each time the set_divisor is called (not that it's critical
but just wanted to mentioned that).

> I'd still prefer to keep patch 1 as the small fix with the stable tag
> and do the refactoring as a separate follow-up series. Would that work
> for you?

I dunno, I prefer just a longer solution, but I don't know how big this issue
is that we need to backport in that way (and not taking the whole series as a
fix).

> I don't have LPSS hardware, but I can build-test the LPSS side.

I have Intel Galileo board that uses 8250_lpss.

-- 
With Best Regards,
Andy Shevchenko