Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Sun, Oct 03, 2010 at 01:14:24AM +0200, Giel van Schijndel wrote:
> On Sat, Oct 02, 2010 at 08:42:19PM +0100, Ben Hutchings wrote:
> > On Tue, 2010-09-28 at 10:36 +0200, Mike Hommey wrote:
> >> On Thu, Sep 23, 2010 at 12:36:04PM +0200, Mike Hommey wrote:
> >>> Package: linux-2.6
> >>> Version: 2.6.32-23
> >>> Severity: wishlist
> >>> Tags: squeeze
> >>> I installed a fresh squeeze on a new PC with a MSI P55M-GD45 motherboard
> >>> that uses a f71889fg sensor chip. Unfortunately, while lm-sensors'
> >>> sensor-detect is able to find the chip and suggest a kernel module, the
> >>> module doesn't load because it lacks support for the chip.
> >>> The support was added somewhen between 2.6.32 and 2.6.33, and was added
> >>> by commit 7669896f. I hear that you add support for hardware when the
> >>> backport is simple, this one is pretty trivial.
> >>> For other reasons, I already switched to 2.6.35 on that machine, so it's
> >>> not a problem for me anymore, but the motherboard is already quite old, so
> >>> other people may have similar problems with a fresh squeeze.
> >> I would also be interested in the watchdog support for the same chip,
> That patch does *not* add watchdog support for the Fintek F71889FG chip,
> it *only* adds support for the F71808E and the F71882FG.
> Additionally a
> patch for the F71862FG is currently pending review and inclusion.
> That being said, this driver should be fairly easy to expand to include
> support for the F71889FG chip (AFAIK only pin-configuration should be
> added, which probably is just a datasheet-reading exercise). Adding
> support however would be something I'd suggest doing across the LKML
> *first*, then (optionally) backport it later.
> >> coming in 96cb4eb019ce3185ec0d946a74b5a2202f5067c9. AFAICT, it requires
> >> 8b6d043b7ee2d1b819dc833d677ea2aead71a0c0 and possibly
> >> 729d273aa7c86eb1406ade4eadf249cff188bf9a. I'm not sure how intrusive
> >> these could be considered.
> > They seem a bit intrusive but probably safe.
> I would consider 729d273 to be safe. 8b6d043 is a bit more complex,
> though it should only affect I/O resources acquired with the newly
> introduced flag IORESOURCE_MUXED, it thus shouldn't affect pre-existing
> > However, the last patch (729d273aa7c86eb1406ade4eadf249cff188bf9a)
> > doesn't look right; surely it should be using the new
> > request_muxed_region() macro too?
> IIRC that patch was submitted and applied *before* 8b6d043, hence
> request_muxed_region() wasn't available and thus not used.
> The patch to make use of request_muxed_region()  has been acked 
> but not yet applied yet, I've just sent out a poke-mail (CC-ed to this
> bug) with the request for it to be committed.
>  <firstname.lastname@example.org>
AFAICS, this id refers to the patch that ended in
The one you are referring to must be
I will give a try to your patch for the F71889FG watchdog, thanks.