Hi!
> > > To take a concrete example, I suggested to Doug to mention fan status. I
> > > get the feeling that you possibly think that this would be better
> > > integrated into lmsensors, or something like that.
> >
> > Yes it should. That way you get the benifit of all userspace
> > applications that already use the lmsensors library without having to be
> > rewritten in order to support your new library.
>
> Little did I know when I first mentioned it how big of a mistake it
> would be to mention the sensor functions. *sigh*
>
> The dcdbas driver allows access to all of the Dell SMIs. Sensors are
> only one instance of SMI code (only two functions, in fact, if I am
> reading this spec correctly). The other (roughly) 58 functions have
> nothing to do with sensors. The presence of the dcdbas driver would not
Perhaps it is okay to export 2 values through lmsensors and the remaining 58
by some other approach, but I think we could find sensible way to export more
than two functions...
> stop anybody from writing another driver to provide a hwmon interface to
> just the sensors pieces.
Good, hwmon can use dcdbas interface internally.
> Ok, here is a short list of the things you can do with the Dell SMI
> implementation. Note that this is a rough categorization of functions.
> As implemented, get and set are normally separate SMI calls, so for each
> that says get/set or read/write, read that as two SMI calls.
>
> I am in the process of writing detailed docs for these (at least the
> ones I have docs for) in libsmbios and hope to be done in a few days.
>
> 1) Read/Write Non-Volatile Storage
> -- main use case for libsmbios. This lets us set all of the rest of the
> BIOS F2 options that are settable. To rehash from an earlier email, BIOS
> stores some options in CMOS, these are already available in libsmbios.
> The rest of the options are stored in SMI, and in fact almost all the
> new options being added are SMI-only, as CMOS has run out of room.
> -- There are roughly 300 different tokens (usually equivalent to a BIOS
> F2 option, but not always). These are split between CMOS and SMI, but a
> good percentage of these are SMI.
This one is going to be tough, altrough sysfs file with ascii representation of
all 300 options would be cool.
> 2) Read/Write Battery/AC mode settings. Read system status.
> -- Fans/Voltage. This interface is only used by laptops (currently used
> by i8k driver).
> -- Systems status gives failing sensor count.
We already have interfaces for battery status. One in /proc/apm, one in /proc/acpi.
> 3) Dynamic system status:
> AC Available
> Lid Closed
> Battery Available
See acpi.
> Docked
Other notebooks can dock, too. It would be nice to do just one interface.
> Main Battery Critical
> Main Battery Avail
> Aux. Battery Critical
> Aux. Battery Avail.
Thats battery status, see above.
> SCSI Available
> Network Available
> Module bay contents (floppy, cd, ls120, etc)
Does it get any info you can't get in other way?
> 4) Get/Set Boot Device Priority
> -- set system boot order (floppy, cd, hard drive, pxe, etc)
Sounds like cmos options above...
> 5) Get/Set BBS IPL/BCV priority
> -- more fine grained way to set boot priority. lets you choose which
> add-in card gets to be C: drive.
Cmos options.
> 6) Get display type
> -- laptops. gets display res + misc attributes
> 7) Get display resolution
Framebuffer driver already knows about this.
> 8) Get/Set active display
> -- laptops: switch between crt/lcd
> 9) Get battery information
Acpi again.
> 10) Get/set/verify user/user II/administrator passwords
Looks like cmos; not sure how to solve that one.
> 11) Get/Set asset/service/property/eppid tags
cmos again.
> 12) Get/Set monitor refresh rate
This should go through fbdev somehow, but I see its hard.
> 13) Get slice type. (laptop expansion thingy, I suppose)
If even you don't know what its good for, we probably don't want to support it
anyway.
> 14) Onboard NIC status (laptops)
Redundant.
> 15) Get/Set onboard radio status
> -- turn on/off wifi antenna
Should integrate with wlan support.
> 16) Application Program Registration (your guess is as good as mine.)
> 17) User customization control (same)
Then do not support it.
> 18) Get Message information.
> --returns bios event information (english only) for stuff like overtemp
Wow, nice; acpi has something similar. Common solution needed...
> 19) Get hard drive size (why? I don't know)
No support, then.
> 20) Get/Clear ECC memory single-bit error status
> 21) Get memory test support information.
> 22) Start/Stop memory test
> 23) Get memory test error information/ map error information
Not sure about those.
> 24) Get/set server boot device priority
Looks like cmos again.
> 25) Issue Read-only SBDS Command
> -- "Smart Battery Data Specification" -- whatever that is.
>
There's spec somewhere. Some acer notebooks have only smart battery interface.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |