Re: [PATCH 1/1] tty: serial: handle HAS_IOPORT dependencies

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

On Fri, Dec 06, 2024 at 05:02:04PM +0100, Arnd Bergmann wrote:
> 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.

So, that's what I meant under resurrecting 8250.c or so, we can leave platform
driver to be still platform driver and call the respective init and exit
routines from the (newly) created module that will have the main
module_init/module_exit calls along with non-library common code.

-- 
With Best Regards,
Andy Shevchenko