linux-kernel - Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 03 Mar 2007 18:08:27 +0100
From:	Rudolf Marek <r.marek@...embler.cz>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	David Hubbard <david.c.hubbard@...il.com>, Rudolf@...pms.net,
	Pavel Machek <pavel@....cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	Chuck Ebbert <cebbert@...hat.com>
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Hello all,

I was already thinking about some very general port forwarder,
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)

But I'm not able to find out how to do that painlessly. Even don't know if to
use the classes or even some new "bus" in driver model :/ some suggestions on
this would be very welcome.

Let start with some very naive 1:1 solution which would try out if we can handle
"transactions" (typically write to one port read from other operation)
and preserve the "banks". As was already written some virtualization in driver
would be required, but it may be done because we know how the hardware is
supposed to work.

It seems that most simple solution to try out would be to add a possible
callback structure into a IORESOURCE structure. Please don't blame me for this,
it is just for testing purpose, we must think of better place, but as I said I
dont know where or how :/

Here is some concept:

When the request_region fails, ACPI could call request_region_acpi
which will return a pointer to some structure with defined callbacks
like do->outb do->inb. ACPI will first chekc if the pointer is not NULL ;)

This callback would end up in let say other linux driver.

For the typical hwmon chip things works similar way as CMOS access. Port is
written 0x295 with register address and port 0x296 is read or written.

Therefore:
void outb(port, val) {

if (port == 0x295) {
	reg_pointer=val;
} else if (port == 0x296) {
	// ACPI wants to write to the chip
	if (reg_pointer == BANKREG)
		reg_bank=val;
	}
	do_chip_write(reg_pointer, reg_bank_val);
}
}

void inb(port, val) {

if (port == 0x296) {

	return do_read_chip(reg_pointer, reg_bank);
}

}

The code above shows how the IO access could be synchronized with the ACPI, to
make everyone happy again. The driver could snoop what ACPI tries to change, so
it for example force reloading the cached values...

The second device which might be a challange is the SMBus controller. The
virtualization could be done same/similar way.

For PCI memory regions, the situation is same as for IO, however for the
pci_config space I cannot see any straight solution.

Regards
Rudolf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/