linux-kernel - Re: How should I handle device with two PNP-BIOS ids?

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: <20090127094255.fc038987.krzysztof.h1@wp.pl>
Date:	Tue, 27 Jan 2009 09:42:55 +0100
From:	Krzysztof Helt <krzysztof.h1@...pl>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Adam Belay <abelay@....edu>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: How should I handle device with two PNP-BIOS ids?

On Mon, 26 Jan 2009 15:13:31 -0700
Bjorn Helgaas <bjorn.helgaas@...com> wrote:

> Hi Krzysztof,
> 
> Systems with the old chip probably report the device with a single
> PNP ID.  For PNPBIOS, that would be the "device product identifier."
> For ACPI, it would be the _HID.
> 
> Systems with the new chip should report both PNP IDs.  The PNPBIOS
> device product identifier or the ACPI _HID should be the new ID, and
> the older ID for backward compatibility should be reported in the
> PNPBIOS "compatible device identifiers" list or the ACPI _CID.
> 
> The driver would list both IDs in the pnp_device_id table, and it
> looks like the driver probe routine gets called with the ID that
> matched.
> 
> I don't see any drivers that actually do this, but I think the
> probe routine should be able to look at the ID that matched and
> determine whether the additional I/O range is present.
> 

The laptop in question is the Dell Latitude CPi and it does not
have ACPI only the PnP BIOS. 
The both ids are reported as unrelated (two separate nodes in 
the /sys/bus/pnp/). I don't know how to set up the "compatible device 
identifiers" list. It is not defined in the include/linux/pnp.h.
If I know that I will test this.

> Oops, looking at match_device() in drivers/pnp/driver.c, I think
> we look at all the device IDs supported by the driver, but we only
> look at the first ID associated with the device.  That means an old
> driver that only knows about the old device ID would fail to claim
> a new device (the new device will have the new ID first and old IDs
> in the compatibility list).  That looks like a bug in the PNP core --
> the old driver should be able to claim any new compatible devices.
> 
> Let me know if you think you're seeing this bug, and I'll look into
> it some more.
> 

Currently, I iterate over pnpbios_protocol to find out if the second 
id exists. It is not elegant but works.

Regards,
Krzysztof
--
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/