All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [RFC-patch] pc87360 - unchecked
Date: Wed, 16 Aug 2006 21:04:19 +0000	[thread overview]
Message-ID: <20060816230419.d23f878d.khali@linux-fr.org> (raw)
In-Reply-To: <44D2514B.2090202@gmail.com>

Hi Jim,

> Im not sure which parts bother you most, so I'll break it down as I see it.
> 
> 1.  static decls of ATTRs  intrinsically limits driver to 1 instance, I 
> agree.
> 
> As you note, the chip wouldnt be used 2x on a board, so designing for that
> wasnt valuable (Im guessing).  I dont see the value now in re-doing the 
> driver
> to change this, unless theres something about the migration plan ( that
> has effects, requirements that I dont appreciate yet)

All drivers for Super-I/O chips based on i2c-isa suffer from that
problem. i2c-isa doesn't provide a way to transfer Super-I/O
configuration data up to the device registration function, other than
globals. But once we convert them to platform drivers, things will get
much better and cleaner.

Now I agree that, even then, we probably will never see two Super-I/O
chip on the same board, so that's not really an issue.

> 2.  Previous patch built groups at runtime - thats now gone.
> 
> This patch version declares a separate sub-group for each sensor-type,
> which allows the same runtime-choices, but now creating attr-groups,
> instead of looping thru and creating single attrs.
> As I see it, this copies Marks approach closely.
> 
> patch includes a code-move to bring 3 volts-related attrs and callbacks up
> with the code for VIN, so theyre in-scope for the vin-attr-grp declaration.
> 
> Its had cursory testing, will test over next few days.

Yeah, I like this one much better, however it does change the code,
which isn't OK. Not all chips have 3 fans, and not all chips have 3
temperature sensors. The original code did only create the files for
existing inputs, and I'd like the new code to do the same. It shouldn't
be too difficult, see how Mark did for the w83627hf driver, it looks
nice enough to me. For these entries you'll have to keep registering
them manually, even though you can delete them as a group.

You can probably avoid moving the code around by adding the arrays of
pointers at the end of the attribute declarations.

Thanks,
-- 
Jean Delvare


  parent reply	other threads:[~2006-08-16 21:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03 19:40 [lm-sensors] [RFC-patch] pc87360 - unchecked Jim Cromie
2006-08-13 19:45 ` Mark M. Hoffman
2006-08-14 13:17 ` Jean Delvare
2006-08-16  5:35 ` Jim Cromie
2006-08-16 21:04 ` Jean Delvare [this message]
2006-08-17 19:35 ` Jim Cromie
2006-08-17 20:01 ` Greg KH
2006-08-17 21:45 ` Jim Cromie
2006-08-18  2:45 ` Mark M. Hoffman
2006-08-18  4:35 ` Greg KH
2006-08-18 11:48 ` Jean Delvare
2006-08-18 21:21 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060816230419.d23f878d.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.