[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo6Fh+zTMiSG+mjkNuA03cCEK7bej9y2oX+HfsScSYGFsw@mail.gmail.com>
Date: Thu, 11 Aug 2011 15:11:10 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: stufever@...il.com
Cc: linux-kernel@...r.kernel.org, abelay@....edu,
Wang Shaoyan <wangshaoyan.pt@...bao.com>,
linux-acpi@...r.kernel.org
Subject: Re: [PATCH] pnp: replace deprecated __check_region to request_region
On Mon, Aug 8, 2011 at 9:38 AM, <stufever@...il.com> wrote:
> From: Wang Shaoyan <wangshaoyan.pt@...bao.com>
>
> The function __check_region is deprecated, use proper function request_region to replace it.
>
> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@...bao.com>
> ---
> drivers/pnp/resource.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
> index b0ecacb..b1d8cae 100644
> --- a/drivers/pnp/resource.c
> +++ b/drivers/pnp/resource.c
> @@ -179,7 +179,7 @@ int pnp_check_port(struct pnp_dev *dev, struct resource *res)
> /* check if the resource is already in use, skip if the
> * device is active because it itself may be in use */
> if (!dev->active) {
> - if (__check_region(&ioport_resource, *port, length(port, end)))
> + if (!request_region(*port, length(port, end), "pnp"))
> return 0;
> }
>
> --
We usually funnel PNP stuff through the linux-acpi@...r.kernel.org
mailing list, so I added a cc: to it.
request_region() is not a drop-in replacement for __check_region()
because __check_region() releases the resource before it returns
success. I agree that it would be good to get rid of
__check_region(), but I think it's a little more work than just this.
I suppose you could just do the release_resource() in
pnp_check_port(), after request_region() was successful. But the
problem with __check_region() is that it's racy, and moving the
release_resource() into pnp_check_port() doesn't remove the race. It
just moves the problem from __check_region() (which is easy to grep
for) into PNP (where it's not so obvious).
Part of the problem is that the PNP core doesn't actually request any
of the resources used by PNP devices. The PCI core *does* reserve
resources, independent of any drivers, and it would certainly be
reasonable to expect the PNP core to do the same, but it doesn't.
This is mostly because there are a bunch of hardcoded legacy resources
that conflict with PNP devices, and we haven't figured out a good way
to resolve the conflicts.
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/
Powered by blists - more mailing lists