lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100324153550.GK6368@salidar.me.mortis.eu>
Date:	Wed, 24 Mar 2010 16:35:51 +0100
From:	Giel van Schijndel <me@...tis.eu>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Laurens Leemans <laurens@...nips.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for
 F71808E and F71889

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

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ