diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index d4c6b19..7556887 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
@@ -648,10 +648,10 @@ static int __init isapnp_create_device(struct pnp_card *card,
case _STAG_STARTDEP:
if (size > 1)
goto __skip;
- priority = 0x100 | PNP_RES_PRIORITY_ACCEPTABLE;
+ priority = PNP_RES_PRIORITY_ACCEPTABLE;
if (size > 0) {
isapnp_peek(tmp, size);
- priority = 0x100 | tmp[0];
+ priority = tmp[0];
size = 0;
}
option_flags = pnp_dependent_option(dev, priority);
diff --git a/drivers/pnp/pnpbios/rsparser.c b/drivers/pnp/pnpbios/rsparser.c
index e0bea09..a6c9539 100644
--- a/drivers/pnp/pnpbios/rsparser.c
+++ b/drivers/pnp/pnpbios/rsparser.c
@@ -393,9 +393,9 @@ pnpbios_parse_resource_option_data(unsigned char *p, unsigned char *end,
case SMALL_TAG_STARTDEP:
if (len > 1)
goto len_err;
- priority = 0x100 | PNP_RES_PRIORITY_ACCEPTABLE;
+ priority = PNP_RES_PRIORITY_ACCEPTABLE;
if (len > 0)
- priority = 0x100 | p[1];
+ priority = p[1];
option_flags = pnp_dependent_option(dev, priority);
break;
On Sunday 01 June 2008 01:28:23 pm Rene Herman wrote:
> On 31-05-08 00:48, Bjorn Helgaas wrote:
>
> > This patch series converts the PNP resource option structures
> > to a unified linked list. This preserves resource order, which
> > is important for some devices. There's more detail in the
> > comments for the last patch.
> >
> > Any comments would be welcome.
> >
> > This depends on some patches that are in -mm, but not yet
> > upstream. In mmotm, these would probably go after
> > pnp-dont-sort-by-type-in-sys-resources.patch
>
> Will look at this in more detail but as first testing feedback -- I need
> this on top.
>
> Both ISAPnP and PnPBIOS for some or other reason set the priority to
> 0x100 | prio after which that 0x100 is immediately masked of again in
> pnp_build_option() leaving just the prio. Your new scheme reserves 16
> bits for the priority though meaning the 0x100 survives causing it to be
> considered "invalid" by at least pnp_option_priority_name() for example.
>
> There cannot be any currently valid reason for the 0x100 it seems given
> that it's immediately masked of again in pnp_build_option() so let's
> just get rid of it...
I agree, that bit looks superfluous. I added a patch to remove it.
Thanks,
Bjorn