From: Ben Dooks <ben-linux@fluff.org>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: netdev@vger.kernel.org, Ben Dooks <ben-linux@fluff.org>
Subject: Re: DM9000 issue with mem resource management
Date: Thu, 5 Jun 2008 18:40:30 +0100 [thread overview]
Message-ID: <20080605174030.GM11277@trinity.fluff.org> (raw)
In-Reply-To: <200806051743.00614.laurentp@cse-semaphore.com>
On Thu, Jun 05, 2008 at 05:42:58PM +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> I ran into a resource-related bug in the DM9000 driver.
>
> When the platform device has only 2 resources, dm9000_probe() doesn't set
> db->irq_res, which results in a segfault when the pointer gets dereferenced
> in dm9000_open().
>
> I tried to fix the issue, and found out that the resource management code is
> quite broken.
Personally, I'm thinking about just removing the case for 2, and making it
three resources only. The following in-kernel machines use the following
resources:
arch/arm/mach-at91/board-sam9261ek.c 3
arch/arm/mach-pxa/cm-x270.c 3
arch/arm/mach-pxa/em-x270.c 3
arch/arm/mach-pxa/trizeps4.c 3
arch/arm/mach-pxa/colibri.c 3
arch/arm/mach-s3c2410/mach-bast.c 3
arch/arm/mach-s3c2410/mach-vr1000.c 3
arch/blackfin/mach-bf527/boards/ezkit.c 2
arch/blackfin/mach-bf533/boards/H8606.c 2
arch/blackfin/mach-bf533/boards/ip0x.c 3
arch/blackfin/mach-bf537/boards/generic_board.c 2
arch/blackfin/mach-bf537/boards/stamp.c 2
As you can see, the #3 outweigh the #2. Unless anyone else objects, I
will add a patch to reduce this to the case where the driver expects
3 resources, and ask the users of #2 to submit changes for their
bots.
> If I understand things correctly, specifying 3 resources makes the DM9000
> driver ioremap() the memory, while specifying 2 resources implies that the
> platform code already ioremap()ed the memory. Is that right ?
>
> If so, why does dm9000_probe() call request_mem_region() on ioremap()ed
> memory ?
Hmm, dunno. I really have no idea why this happened. I don't think this
was my fault!
> Wouldn't it also be simpler to use release_mem_region() in
> dm9000_release_board() instead of release_resource() + kfree() ?
If you already have the resource, this is a reasonably simple way of
ensuring you're disposing of the right resource.
> I'd be grateful if someone could confirm my assumptions. I'll then submit a
> patch to fix those issues.
My recommendation is that we remove the 2 case completely, so I'd not bother
trying to fix this.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2008-06-05 18:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 15:42 DM9000 issue with mem resource management Laurent Pinchart
2008-06-05 17:40 ` Ben Dooks [this message]
2008-06-06 9:01 ` Laurent Pinchart
2008-06-07 21:35 ` Ben Dooks, g
2008-06-09 13:41 ` Laurent Pinchart
2008-06-06 9:11 ` Laurent Pinchart
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=20080605174030.GM11277@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=laurentp@cse-semaphore.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.