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: <200901270852.52153.bjorn.helgaas@hp.com>
Date:	Tue, 27 Jan 2009 08:52:51 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Krzysztof Helt <krzysztof.h1@...pl>
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 Tuesday 27 January 2009 01:42:55 am Krzysztof Helt wrote:
> On Mon, 26 Jan 2009 15:13:31 -0700
> Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> > 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/).

Oh.  That sounds like a BIOS bug.  If there's only one actual
chip, the BIOS should not report it as two separate devices.
I guess it might report two devices if only one of them is
enabled at a time.  In that case, there might be a BIOS setup
switch to toggle between them.

Can you turn on CONFIG_PNP_DEBUG_MESSAGES and boot with the
pnp.debug kernel parameter?  Then collect the dmesg log and
the output of "grep . /sys/devices/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.

The compatible device identifiers list is built by the kernel
based on the information from the BIOS.  Drivers don't have to
worry about it.

> > 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.

Can you point me to the driver?

If this is a BIOS defect, we might be able to write a quirk to work
around it so the driver doesn't have to get messy.

Bjorn
--
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/