lkml.org 
[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [lm-sensors] Could the k8temp driver be interfering with ACPI?
    Hi!

    > > Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
    > > sure that 90%+ of ACPI notebook implementations *will* want to talk to
    > > their monitoring chips... for temperature readings.
    > >
    > > So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
    > > lm-sensors would break at least on all the notebooks.
    >
    > That's a secondary problem. The primary issue is the concurrent access
    > to resources, which cause lots of trouble which are hard to investigate.
    > If ACPI reserves the ports, then the SMBus or hardware monitoring
    > drivers (or any other conflicting driver) will cleanly fail to load,
    > which would be a move in the right direction. Ideally we would be able
    > to synchronize the accesses between ACPI and the other drivers, but if
    > we can't, I'd already be _very happy_ to just prevent conflicting
    > drivers from being loaded at the same time.
    >
    > So, can ACPI actually reserve the ports it accesses?

    No idea, talk to Len Brown (or start reading the code) :-(. I don't
    think it will be easy.

    > > > 1* As far as I know, we currently have no way to know if the ACPI code
    > > > plans to ever access the hardware monitoring chip. If the acpi
    > > > subsystem could export this information somehow, it would help a lot.
    > > > But I'm not familiar with ACPI, so I don't know if this is feasable or
    > > > not. We just can't prevent the SMBus and hardware monitoring drivers
    > > > drivers from being loaded as soon as ACPI is enabled. This would
    > > > prevent a majority of users from using them, while they work fine for
    > > > most of them.
    > >
    > > What about whitelist? DMI-based? That's only way to do it, I'm afraid.
    >
    > What kind of whitelist do you have in mind? We can't realistically
    > maintain an ever-growing whitelist of hundreds of entries in the
    > kernel. We could block all laptops by default and maintain a white list
    > only for them, and a black list for other systems, the would probably
    > limit the maintenance work, maybe not to an acceptable level though.

    I'm afraid something like that is way to go.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-02 15:29    [W:0.024 / U:61.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site