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 code. > 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() [1] has been acked [2] 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. [1] <1280669455-31283-1-git-send-email-me@mortis.eu> [2] <4C59514A.7090401@redhat.com> -- Met vriendelijke groet, With kind regards, Giel van Schijndel -- "Nine people can't make a baby in a month." -- Fred Brooks
Attachment:
signature.asc
Description: Digital signature