Re: sio => uart: one port is gone

On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote:
> 
> On Sep 15, 2008, at 12:22 PM, John Baldwin wrote:
> 
> > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote:
> >>
> >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote:
> >>
> >>> on 15/09/2008 19:41 Marcel Moolenaar said the following:
> >>>> So, if you compile acpi(4) as a module, you must compile all
> >>>> it's depending drivers as modules as well. Or you compile acpi
> >>>> into the kernel...
> >>>
> >>> I understand the logic, but OTOH uart can work without acpi too, so
> >>> it's not a strict dependency.
> >>
> >> Well, yes. That's what's causing your "problem". You compile a
> >> kernel without acpi but with uart. As such, uart will be built
> >> without acpi support. uart does indeed work without acpi.
> >>
> >> The problem is that people then load the acpi module at runtime
> >> and expect uart to work with acpi. That's not going to fly. If
> >> one builds uart as a module, all possible support is included
> >> and it works as expected.
> >>
> >>> Also, this (acpi dependency) doesn't seem to be documented.
> >>
> >> It's standard behaviour.
> >
> > The problem is that right now we ship with acpi.ko as a module by  
> > default and
> > have the loader auto-load acpi.ko IFF the machine supports ACPI.
> 
> Well, don't do that then. Just have the device probe check if acpi is
> supported and attach if yes.

It does that, the loader stuff is from someone trying to be fancy and save the 
memory of not having acpi.ko around if the system doesn't support it.  This 
may in fact be dubious. :)

-- 
John Baldwin