From: Pete Zaitcev <zaitcev@redhat.com>
To: "Christoph Baumann" <cb@sorcus.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Resolving physical addresses (change in 2.4.x?)
Date: Wed, 24 Jul 2002 16:14:02 -0400 [thread overview]
Message-ID: <200207242014.g6OKE2K21460@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1027491420.32334.linux-kernel2news@redhat.com>
> Even recognizing these as unmapped and resolving anew, produced a frozen
> machine once the DMA used these addresses. Was there a change in 2.4.x so
> that my resolving routine now works incorrect?
>
> /*resolve virt. addresses to phys.*/
> unsigned long ch_get_physpage(unsigned long virtaddr)
> {
> /*Stuff for browsing through the memory page tables*/
> pgd_t *pgd_t_dir;
> pmd_t *pmd_t_dir;
> pte_t *pte_t_dir;
>
> /*Get physical address*/
> pgd_t_dir=pgd_offset(current->mm,virtaddr);
> pmd_t_dir=pmd_offset(pgd_t_dir,virtaddr);
> pte_t_dir=pte_offset(pmd_t_dir,virtaddr);
> return virt_to_bus((void *)pte_page(*pte_t_dir));
> }
Are you crazy? This routing could NEVER work; pge_page returns
a pointer to a struct page. I always was suspicious of this
technique; even if you find out how to use page_address,
what do you do about the bus address? On some architectures,
the bus address is only known to the part that manages a
north bridge; it may even be stored in hardware registers.
No matter how popular this trick is, it is highly illegal.
To work properly, your driver has to remember virtual and bus
addresses that were mapped with pci_alloc_sg. They are returned to
you for this very purpose. In most cases you have to to track I/Os
anyway, so just add a field to whatever management structure you use.
-- Pete
next parent reply other threads:[~2002-07-24 20:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1027491420.32334.linux-kernel2news@redhat.com>
2002-07-24 20:14 ` Pete Zaitcev [this message]
2002-07-24 6:11 Resolving physical addresses (change in 2.4.x?) Christoph Baumann
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=200207242014.g6OKE2K21460@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=cb@sorcus.com \
--cc=linux-kernel@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.