public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>, Adam M Belay <abelay@mit.edu>,
	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>,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [patch 15/15] PNP: convert resource options to single linked list
Date: Wed, 04 Jun 2008 02:03:06 +0200	[thread overview]
Message-ID: <4845DBBA.9010607@keyaccess.nl> (raw)
In-Reply-To: <200806031703.48648.bjorn.helgaas@hp.com>

On 04-06-08 01:03, Bjorn Helgaas wrote:

> That's definitely backwards.  I reversed the sizes, so we'll have
> 8 bits for the priority byte (including compatibility/performance/
> robustness) and 16 bits for the dependent set number.  Actually,
> I made the priority field 12 bits so we'd have space to keep
> PNP_RES_PRIORITY_INVALID as a truly out-of-band value.

Sounds perfect.

>>> +	for (i = 0; i == 0 || i < dev->num_dependent_sets; i++) {
>>> +		ret = pnp_assign_resources(dev, i);
>>> +		if (ret == 0)
>>>  			return 0;
>> Eeeew. Perhaps:
>>
>> i = 0;
>> do {
>> 	ret = pnp_assign_resources(dev, i);
>> 	if (ret == 0)
>> 		return 0;
>> } while (++i < dev->num_dependent_sets);
> 
> Heh :-)  I vacillated on that one because I have a personal aversion
> to "do { ... } while ()", especially with a pre-increment.  How would
> you feel about this alternative?
> 
>         ret = pnp_assign_resources(dev, 0);
>         if (ret == 0)
>                 return 0;
> 
>         for (i = 1; i < dev->num_dependent_sets; i++) {
>                 ret = pnp_assign_resources(dev, i);
>                 if (ret == 0)
>                         return 0;
>         }

You could fix the pre-increment by sticking a i++ inside the loop body 
but there's no arguing with personal aversions...

Yes, I think the latter is better. Straight-forward and clear.

>> Why do you do 0x800, 0x400 in that order? Shouldn't it just be 0x400, 
>> 0x800 to mimick the old order?
> 
> I think they do end up in the correct order because I'm passing the
> same list_head to both list_add() calls, e.g., we'll have something
> like this:
> 
>     io -> ...
>     io -> (io + 0x800) -> ...
>     io -> (io + 0x400) -> (io + 0x800) -> ...

Yep. Just needed to see it happen once in the quirk testing I just now did.

> I need to go back over all your comments and make sure I've addressed
> them all, then I'll post the revised patches, hopefully tomorrow.
> 
> Thanks again for all your work reviewing and testing these.  It's
> been incredibly useful.

I've been impressed by this work. This is a good redesign of PnP with a 
fully bisectable way to get there. And PnP was in need of some work...

Rene.

  reply	other threads:[~2008-06-04  0:03 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30 22:48 [patch 00/15] PNP: convert resource options to unified dynamic list, v1 Bjorn Helgaas
2008-05-30 22:48 ` [patch 01/15] serial: when guessing, check only active resources, not options Bjorn Helgaas
2008-06-01 19:42   ` Rene Herman
2008-06-02 15:21     ` Bjorn Helgaas
2008-05-30 22:48 ` [patch 02/15] PNP: whitespace/coding style fixes Bjorn Helgaas
2008-06-01 19:52   ` Rene Herman
2008-05-30 22:48 ` [patch 03/15] PNP: define PNP-specific IORESOURCE_IO_* flags alongside IRQ, DMA, MEM Bjorn Helgaas
2008-06-01 21:03   ` Rene Herman
2008-05-30 22:48 ` [patch 04/15] PNP: make resource option structures private to PNP subsystem Bjorn Helgaas
2008-06-01 21:06   ` Rene Herman
2008-05-30 22:48 ` [patch 05/15] PNP: introduce pnp_irq_mask_t typedef Bjorn Helgaas
2008-06-01 21:25   ` Rene Herman
2008-05-30 22:48 ` [patch 06/15] PNP: increase I/O port & memory option address sizes Bjorn Helgaas
2008-06-01 21:39   ` Rene Herman
2008-05-30 22:49 ` [patch 07/15] PNP: improve resource assignment debug Bjorn Helgaas
2008-06-01 21:41   ` Rene Herman
2008-05-30 22:49 ` [patch 08/15] PNP: in debug resource dump, make empty list obvious Bjorn Helgaas
2008-06-01 21:44   ` Rene Herman
2008-05-30 22:49 ` [patch 09/15] PNP: make resource assignment functions return 0 (success) or -EBUSY (failure) Bjorn Helgaas
2008-06-01 21:59   ` Rene Herman
2008-05-30 22:49 ` [patch 10/15] PNP: remove redundant pnp_can_configure() check Bjorn Helgaas
2008-06-01 22:00   ` Rene Herman
2008-05-30 22:49 ` [patch 11/15] PNP: centralize resource option allocations Bjorn Helgaas
2008-06-01 23:21   ` Rene Herman
2008-06-02 15:29     ` Bjorn Helgaas
2008-05-30 22:49 ` [patch 12/15] PNPACPI: ignore _PRS interrupt numbers larger than PNP_IRQ_NR Bjorn Helgaas
2008-06-01 23:23   ` Rene Herman
2008-05-30 22:49 ` [patch 13/15] PNP: rename pnp_register_*_resource() local variables Bjorn Helgaas
2008-06-01 23:25   ` Rene Herman
2008-05-30 22:49 ` [patch 14/15] PNP: support optional IRQ resources Bjorn Helgaas
2008-06-03 17:37   ` Rene Herman
2008-06-03 20:20     ` Bjorn Helgaas
2008-06-03 20:25       ` Rene Herman
2008-05-30 22:49 ` [patch 15/15] PNP: convert resource options to single linked list Bjorn Helgaas
2008-06-03 19:57   ` Rene Herman
2008-06-03 23:03     ` Bjorn Helgaas
2008-06-04  0:03       ` Rene Herman [this message]
2008-06-03 23:52     ` Rene Herman
2008-06-04 11:48       ` Rene Herman
2008-06-04 20:50         ` Bjorn Helgaas
2008-06-04 22:31           ` Rene Herman
2008-06-04 23:06             ` Bjorn Helgaas
2008-06-03 21:13   ` Rene Herman
2008-06-04 21:26     ` Bjorn Helgaas
2008-06-01 19:28 ` [patch 00/15] PNP: convert resource options to unified dynamic list, v1 Rene Herman
2008-06-02 15:56   ` 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=4845DBBA.9010607@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=abelay@mit.edu \
    --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=tiwai@suse.de \
    --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