On Fri, Dec 6, 2024, at 16:44, Andy Shevchenko wrote:
> On Wed, Dec 04, 2024 at 11:17:56PM +0100, Arnd Bergmann wrote:
>> On Wed, Dec 4, 2024, at 22:09, Guenter Roeck wrote:
>
>> I got stuck in this rabbit hole of running into more issues
>> with the 8250 driver. Any time you touch something, it breaks
>> elsewhere.
>>
>> I've uploaded what I have here now:
>
> FWIW, I have briefly looked at it, some patches I appreciate very much, some of
> them I think need more testing and one thing I don't really like is putting
> code back to 8250_core. Thinking about that, perhaps we need to restore 8250.c
> (or alike) for collecting non-library / non-_particular_-driver-leaf?
Thanks for taking a look!
I thought you might have different ideas on where some of the
code needs to go, as you were the one who moved it out
previously.
However, I think the two bits that I ended up moving back
really belong in the core:
- serial8250_setup_ports() is needed to get the
serial8250_ports[] into a sane state. Ideally this
array would just be statically initialized, but I don't
think we can actually express that in C code.
- serial8250_init()/serial8250_exit() are required for
registering the driver itself (serial8250_reg) Having
that part in the ISA driver made no sense to me.
The bit that is definitely ugly is how serial8250_isa_init()
gets called from serial8250_init() and univ8250_console_init(),
and I would prefer to remove that, but any attempt to do
that made it worse.
The problem here is that we can't just rely on link order:
For the console initcall and serial8250_isa_init_ports(),
we have to call this before the core driver initialization,
but the serial8250-isa platform device has to be registered
after the core driver does. If we link both files into
a loadable module, there is an additional problem of
not being able to have more than one module_init() call.
Arnd
