From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: netdev@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Don't call request_region() for 3C90x chips
Date: Thu, 27 Jul 2006 23:22:06 +0400 [thread overview]
Message-ID: <44C9125E.8030404@ru.mvista.com> (raw)
In-Reply-To: <44BE865A.6060307@pobox.com>
Hello.
Jeff Garzik wrote:
>>>> It's generally not a good idea to call request_region() on an
>>>> address returned by pci_iomap(), even less so on a MMIO address. And
>>>> there was absolutely no point in claiming the region already claimed
>>>> by the PCI core, especially with the same PCI generic owner's name.
>>>> As this is the only case of the must_free_region flag being set,
>>>> this flag may go away as well...
>>>> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>> I agree you have identified a bug, but this is not a solution.
>>> The current driver bug is that it calls request_region() potentially
>>> on an MMIO address, but the solution is _not_ to completely avoid
>>> reserving the resource.
>> It's not even a MMIO/PIO address anymore after pci_iomap() -- it
>> either went thru ioremap() or ioport_map() which both change the
>> mapping from the physical to the virtual address (or some equivalent
>> of it for I/O ports).
> Yes. _Obviously_ you must reserve the resource passed to
> pci_iomap/ioremap, not the cookie returned by such.
What somewhat puzzled me is the words "Cardbus drivers already allocate
for us" in the current driver's vortex_probe1(). What extra drivers, and why
should they call request_region() for us? :-/
>>> The region registered with the PCI core, but _not_ claimed by anyone.
>>> Someone still needs to either call pci_{request,release}_regions() or
>>> request_[mem_]region() to indicate that the resource is reserved.
>> Sigh, it seems I've missed that difference. So, I'll recast...
> IMO it would be easiest to do pci_{request,release}_regions() in the
> PCI-only code. I believe this matches up well with the existing
> EISA-specific code, which also performs request_region().
Ugh, I've looked at vortex_remove_one() and found another buglet: they're
trying to reset the chip there... after calling pci_disable_device(). Guess
whether they really reset anything. I wonder whether it's accpetable for this
fix to be put in the same patch...
> Jeff
WBR, Sergei
prev parent reply other threads:[~2006-07-27 19:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-10 18:25 [PATCH] Don't call request_region() for 3C90x chips Sergei Shtylylov
2006-07-19 17:57 ` Jeff Garzik
2006-07-19 19:08 ` Sergei Shtylyov
2006-07-19 19:22 ` Jeff Garzik
2006-07-27 19:22 ` Sergei Shtylyov [this message]
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=44C9125E.8030404@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.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.