Re: [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for F71808E and F71889

[Giel van Schijndel <me@mortis.eu>]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

On Wed, Mar 24, 2010 at 11:33:00AM +0100, Hans de Goede wrote:
> On 03/24/2010 10:36 AM, Giel van Schijndel wrote:
>>On Wed, Mar 24, 2010 at 09:37:43AM +0100, Hans de Goede wrote:
>>> Nack:
>>> As the watchdog has its own SIO logical device number, it should
>>> have a separate driver, not have support glued to the hwmon driver.
>>
>> Thus, if I understand correctly, you would suggest for me to
>> implement a new driver in drivers/watchdog/ to implement this
>> feature?
> 
> Yes, correct.

So I've now started out working on moving the watchdog code to a
separate driver.

  I/O port conflict

However, this driver would have to lock the SIO port range as well.
Unlike the hardware monitor, however, the watchdog (VID controller on
some datasheets) doesn't appear to provide for an alternative I/O port
mapping. Meaning the wathdog driver would have to maintain a permanent
hold on the SIO port range. This would thus interfere with the operation
of the f71882fg driver. I.e. it would prevent the device probing stage
from working, thus preventing it from loading *after* my in-development
watchdog driver.

  Alternative logical device port mapping

Regarding address mapping: the 16 bit SIO_REG_ADDR(0x60) register does
exist for this logical device, though according to the datasheet it is
set to 0x0000 by default. Reading the value from hardware it claims to
be mapped on 0x0AE0, trying to read from that port range (using
f71882fg_read8) yields nothing more than 0xFF for any register mentioned
in the datasheet.

  Hardware monitor alternate port range

Further, when looking at the way that SIO_REG_ADDR is currently used by
the f71882fg driver I get more confused:
> *hwmon_addr = superio_inw(sioaddr, SIO_REG_ADDR);
>     /* error checking: *hwmon_addr != 0 */
> *hwmon_addr &= ~(REGION_LENGTH - 1);	/* Ignore 3 LSB */

For the F71808E and F71889, which both have 0x295, for hardware monitor
base address that code ^^ combined with the addition of ADDR_REG_OFFSET
and DATA_REG_OFFSET (see f71882fg_(read|write)8) all of this basically
amounts to mangling 0x295 -> 0x290 -> (0x295,0x296).

So my question: is there any particular reason for performing this
address mangling? Mostly: is there anything there that I should try
replicating in order to get mapping of the watchdog device on an
alternate port range working?

PS Perhaps this would be easier to converse about if you had the
   datasheet?

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]