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: <20070703150627.GA32367@khazad-dum.debian.net>
Date:	Tue, 3 Jul 2007 12:06:27 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Len Brown <lenb@...nel.org>
Cc:	Thomas Renninger <trenn@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Kay Sievers <kasievers@...e.de>
Subject: Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table
	symbol for all acpi drivers.

On Tue, 03 Jul 2007, Len Brown wrote:
> My $0.02 on thinkpad_acpi & HID's...
> 
> 1. moving to DMI binding from PNP-id binding
> sounds like a step in the wrong direction.

IBM made real use of the DMI data, so they even issued BIOS fixes to get it
right when crap made it to the DMI tables.  I am not sure Lenovo will keep
up the good work, but so far they did not do anything braindamaged to the
DMI tables AFAIK.

And we have a damn good table of the more interesting DMI data, which the
community maintains.  It is at http://www.thinkwiki.org/wiki/List_of_DMI_IDs
so I have a lot of support to take DMI-based decisions.

Note that I can use PNP-id autoload as well as the DMI-based one, it just
won't buy much.  AFAIK the driver already auto-loads on every supported
thinkpad, including new ones.

As for using PNP-id autoloading instead of DMI-based autoloading, I have two
problems with it:

	1. I don't trust IBM0068 more than the dmi data.  If you can assure
	me IBM0068 is only used for thinkpad laptops, because that's how
	these things work or somesuch, then I might change my mind.

	2. Lots of what thinkpad-acpi does has nothing to do with IBM0068.
	Autoloading based only on IBM0068 seems wrong to me, in this case.

> Are there thinkpads that you need to support that don't export IBM0068?

There could be, especially the very old ones that thinkpad-acpi partially
supports.  AFAIK, IBM0068 is a firmware-OS message-passing device, and also
hot key handler.  But it does little else.  Most of the other stuff is done
by directly poking stuff in different ACPI subtrees, or ACPI EC registers,
or accessing the CMOS NVRAM, and those have no unique HIDs...

> There is a long tradition of DMI information being copy/pasted
> and being invalid.  While the thinkpad BIOS guys are probably
> above average here, they're probably not immune from this issue.

No, they are not imune :-)  Some thinkpads have had slightly screwed up dmi
tables, but none due to something as ridiculous as copy-and-paste, and IBM
issued BIOS updates to fix the breakages.  Lenovo didn't break anything in
DMI so far, either (AFAIK, anyway).

> At the end of the day, I'd be astonished if somebody told me that
> the Windows thinkpad platform driver binds via DMI strings instead
> of binding to IBM0068 -- which was likely invented for this sole purpose.

They bind by HID, I think.  But I don't know what *else* they check before
they decide to load sucessfully.  If anyone would like to do some clean-room
reverse engineering of the windows drivers and send us the information,
fine, I'd welcome the information and use it.  But I am not touching the
Windows drivers.

Also, there are a number of different drivers, and AFAIK only the hot keys
one bind by HID.  I have not ever touched the Windows drivers, I just used
the thinkpad for a while with Windows to learn how it was supposed to act to
different events, but that's it.

> 2. IBM_PCI_HID = ACPI_PCI_HOST_HID = PCI_ROOT_HID_STRING = "PNP0A03"
> 
> There is nothing IBM specific about a PCI root bridge.
> If you need to use this one, please call it PCI_ROOT_HID_STRING.

Sure, it is something internal to the driver, and *IT MUST NOT BE USED FOR
AUTOLOADING*.  I will rename it, or get rid of it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ