On Thu, Dec 13, 2012 at 3:13 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Oh, okay. That's easy. "They don't work," but "it87_find() seems to have identified the correct features" -- the features exist, independently confirmed by the OEM Asus BIOS. So it87_find() reports data consistent with the Asus BIOS. I'd like to leave them in the experimental driver because I think it87_find() is operating correctly.
All that needs to be done to get them to work is a datasheet or equivalent technical description of the I/O interface. I don't think Asus is going to provide one, but another motherboard with the same chip could be extremely useful for A/B testing.
Thanks,
David
"they don't work ... " and "identified the correct features" seems toOn Thu, Dec 13, 2012 at 02:27:57PM -0700, David Hubbard wrote:
> Hi Guenter,
>
> On Thu, Dec 13, 2012 at 9:07 AM, Guenter Roeck <groeck-dsl@xxxxxxxxxxxxx>wrote:
>
> > On Thu, Dec 13, 2012 at 01:00:30AM -0700, David Hubbard wrote:
> > > I'd like to send the same patch again but add signed-off-by this time :)
> > I
> > > apologize.
> > >
> > > * * * * *
> > >
> > > Add experimental support for the it8603e chip (Asus f2a85-m motherboard)
> > > Write only tested for pwmN and pwmN_enable.
> > > Read tested, but the following appear broken:
> > > alarms
> > > fanN_alarm
> > > inN_alarm
> > > inN_max
> > > inN_min
> > > intrusionN_alarm
> > > pwmN_auto_channels_temp
> > > pwmN_freq
> >
> > I don't think it is a good idea to report attributes which "appear to be
> > broken". At least for the voltage limits and the alarms it should be
> > relatively
> > easy to find out if they work/don't work. Whatever doesn't work should not
> > be
> > there.
> >
>
> They don't work but I don't know why. Until we have a datasheet, I'd like
> to leave them in the *experimental* driver and wait for a second opinion
> from someone who actually has the chip.
>
>
> >
> > > temp3_input (there is no 3rd analog temp input to the chip)
> > >
> > Other IT87xx chips report the AMDSTI/PCH temperature as one of the inputs.
> > This
> > is usually configurable.
> >
> >
> Ok, fine with me.
>
> Another question is to what extend we can depend on the logic in
> > it87_find() to
> > detect enabled chip features. It might make more sense to create another
> > if case
> > in that function to handle the IT8603 separately.
> >
>
> it87_find() seems to have identified the correct features of the IT8603. I
> don't understand your concern with the way it is currently working.
>
somewhat contradict each other.
Oh, okay. That's easy. "They don't work," but "it87_find() seems to have identified the correct features" -- the features exist, independently confirmed by the OEM Asus BIOS. So it87_find() reports data consistent with the Asus BIOS. I'd like to leave them in the experimental driver because I think it87_find() is operating correctly.
All that needs to be done to get them to work is a datasheet or equivalent technical description of the I/O interface. I don't think Asus is going to provide one, but another motherboard with the same chip could be extremely useful for A/B testing.
Thanks,
David
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
