From: Rene Herman <rene.herman@keyaccess.nl>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Adam Belay <ambx1@neo.rr.com>, Li Shaohua <shaohua.li@intel.com>,
Matthieu Castet <castet.matthieu@free.fr>,
Thomas Renninger <trenn@suse.de>,
Jaroslav Kysela <perex@perex.cz>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 00/37] PNP resource_table cleanups, v2
Date: Thu, 03 Apr 2008 19:12:16 +0200 [thread overview]
Message-ID: <47F50FF0.40602@keyaccess.nl> (raw)
In-Reply-To: <200804031043.43068.bjorn.helgaas@hp.com>
On 03-04-08 18:43, Bjorn Helgaas wrote:
> On Thursday 03 April 2008 09:54:51 am Rene Herman wrote:
>> However, now that you made me look closer and in context -- there's actually
>> a possibly somewhat serious problem here.
>>
>> isapnp_read_resources() stores the resources as read from the hardware at
>> the index in the table that matches the actual index in the hardware and
>> isapnp_set_resources() stores them back into those same hardware indices.
>>
>> Now by using pnp_add_foo_resource() which just scans for the first _UNSET
>> resource, the resources might not end up in the same linear position in
>> table/list if intermediate resources were unset in hardware (!ret). A
>> subsequent isapnp_set_resources() would them restore the value to the wrong
>> hardware index.
>>
>> The IORESOURCE_ flags currently reserve too few bits (IORESOURCE_BITS, 8)
>> to be able to store the hardware index: IORESOURCE_MEM and IORESOURCE_DMA
>> need 2 and 1 respectively and there are 1 and 0 available respectively. It's
>> ofcourse possible to hijack a few more bits in IORESOURCE_ flags but you're
>> turning this into a list. I suppose the idea is to make it a simple list of
>> struct resource, but perhaps a resource-private "driver_data" sort of field
>> comes in handy for more than this already? Swiping more of IORESOURCE_ is a
>> bit ugly...
>>
>> In any case, I missed this, but ISAPnP is still (at least in principle)
>> broken with the current set therefore.
>
> Hmm... you're right. And I think it could bite PNPBIOS and PNPACPI
> as well -- they don't read/write hardware registers directly, but the
> firmware still depends on preserving the resource order. I'll have to
> ponder that for a while.
Both PNPBIOS and PNPACPI should be fine it seems:
pnpbios_get_resources()
pnpbios_read_resources_from_node()
pnpbios_parse_allocated_resource_data()
pnpbios_parse_allocated_irqresource()
pnpbios_parse_allocated_dmaresource()
pnpbios_parse_allocated_ioresource()
pnpbios_parse_allocated_memresource()
where the latter do the same scan for the first _UNSET resource as the new
code does. Same thing for ACPI in the path
pnpacpi_get_resources()
pnpacpi_parse_allocated_resource()
pnpacpi_allocated_resource()
pnpacpi_parse_allocated_irqresource()
pnpacpi_parse_allocated_dmaresource()
pnpacpi_parse_allocated_ioresource()
pnpacpi_parse_allocated_memresource()
pnpacpi_parse_allocated_address_space()
pnpacpi_parse_allocated_memresource()
Rene.
next prev parent reply other threads:[~2008-04-03 17:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-01 15:16 [patch 00/37] PNP resource_table cleanups, v2 Bjorn Helgaas
2008-04-01 15:16 ` [patch 01/37] ISAPNP: move config register addresses out of isapnp.h Bjorn Helgaas
2008-04-01 15:16 ` [patch 02/37] PNPACPI: continue after _CRS and _PRS errors Bjorn Helgaas
2008-04-01 15:16 ` [patch 03/37] PNP: make pnp_add_id() internal to PNP core Bjorn Helgaas
2008-04-01 15:16 ` [patch 04/37] PNP: change pnp_add_id() to allocate its own pnp_id structures Bjorn Helgaas
2008-04-01 15:16 ` [patch 05/37] PNP: add pnp_eisa_id_to_string() Bjorn Helgaas
2008-04-01 15:16 ` [patch 06/37] PNP: add pnp_alloc_dev() Bjorn Helgaas
2008-04-01 15:16 ` [patch 07/37] PNP: make pnp_add_card_id() internal to PNP core Bjorn Helgaas
2008-04-01 15:16 ` [patch 08/37] PNP: change pnp_add_card_id() to allocate its own pnp_id structures Bjorn Helgaas
2008-04-01 15:16 ` [patch 09/37] ISAPNP: pull pnp_add_card_id() out of isapnp_parse_card_id() Bjorn Helgaas
2008-04-01 15:16 ` [patch 10/37] PNP: add pnp_alloc_card() Bjorn Helgaas
2008-04-01 15:16 ` [patch 11/37] PNPACPI: pnpacpi_encode_ext_irq() wrongly set "irq" instead of "extended_irq" Bjorn Helgaas
2008-04-01 15:16 ` [patch 12/37] PNPACPI: use temporaries to reduce repetition Bjorn Helgaas
2008-04-01 15:16 ` [patch 13/37] PNPACPI: hoist dma_flags() out of pnpacpi_parse_allocated_dmaresource() Bjorn Helgaas
2008-04-01 15:16 ` [patch 14/37] PNPACPI: extend irq_flags() to set IORESOURCE_IRQ_SHAREABLE when appropriate Bjorn Helgaas
2008-04-01 15:16 ` [patch 15/37] PNPACPI: pass pnp_dev instead of acpi_handle Bjorn Helgaas
2008-04-01 15:16 ` [patch 16/37] PNP: remove pnp_resource_table from internal get/set interfaces Bjorn Helgaas
2008-04-01 15:16 ` [patch 17/37] PNP: remove more pnp_resource_table arguments Bjorn Helgaas
2008-04-01 15:16 ` [patch 18/37] PNP: add pnp_init_resources(struct pnp_dev *) interface Bjorn Helgaas
2008-04-01 15:16 ` [patch 19/37] PNP: remove pnp_resource_table from internal pnp_clean_resource_table interface Bjorn Helgaas
2008-04-01 15:16 ` [patch 20/37] PNP: make generic pnp_add_irq_resource() Bjorn Helgaas
2008-04-01 15:16 ` [patch 21/37] PNP: make generic pnp_add_dma_resource() Bjorn Helgaas
2008-04-01 15:16 ` [patch 22/37] PNP: make generic pnp_add_io_resource() Bjorn Helgaas
2008-04-01 15:16 ` [patch 23/37] PNP: make generic pnp_add_mem_resource() Bjorn Helgaas
2008-04-01 15:16 ` [patch 24/37] PNP: use dev_printk when possible Bjorn Helgaas
2008-04-01 15:16 ` [patch 25/37] PNPACPI: remove redundant warnings about _CRS/_PRS failures Bjorn Helgaas
2008-04-01 15:17 ` [patch 26/37] PNPACPI: remove some pnp_dbg calls Bjorn Helgaas
2008-04-01 15:17 ` [patch 27/37] PNP: use conventional "i" for loop indices Bjorn Helgaas
2008-04-01 15:17 ` [patch 28/37] PNP: add pnp_get_resource() interface Bjorn Helgaas
2008-04-01 15:17 ` [patch 29/37] PNP: convert encoders to use pnp_get_resource(), not pnp_resource_table Bjorn Helgaas
2008-04-01 15:17 ` [patch 30/37] PNP: convert resource accessors " Bjorn Helgaas
2008-04-01 15:17 ` [patch 31/37] PNP: convert resource checks " Bjorn Helgaas
2008-04-01 15:17 ` [patch 32/37] PNP: convert resource assign functions " Bjorn Helgaas
2008-04-01 15:17 ` [patch 33/37] PNP: remove PNP_MAX_* uses Bjorn Helgaas
2008-04-01 15:17 ` [patch 34/37] PNP: remove unused interfaces using pnp_resource_table Bjorn Helgaas
2008-04-01 15:17 ` [patch 35/37] rtc: dont reference pnp_resource_table directly Bjorn Helgaas
2008-04-01 15:17 ` [patch 36/37] PNP: make pnp_resource_table private to PNP core Bjorn Helgaas
2008-04-01 15:17 ` [patch 37/37] PNP: make interfaces private to the " Bjorn Helgaas
2008-04-01 23:43 ` [patch 00/37] PNP resource_table cleanups, v2 Rene Herman
2008-04-02 21:35 ` Bjorn Helgaas
2008-04-03 15:54 ` Rene Herman
2008-04-03 16:43 ` Bjorn Helgaas
2008-04-03 17:12 ` Rene Herman [this message]
2008-04-03 19:29 ` Rene Herman
2008-05-01 20:47 ` Bjorn Helgaas
2008-05-04 14:14 ` Rene Herman
2008-05-04 14:19 ` Rene Herman
2008-05-05 14:48 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47F50FF0.40602@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=akpm@linux-foundation.org \
--cc=ambx1@neo.rr.com \
--cc=bjorn.helgaas@hp.com \
--cc=castet.matthieu@free.fr \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=shaohua.li@intel.com \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).