From: "Michael Chan" <mchan@broadcom.com>
To: "Jeff Garzik" <jeff@garzik.org>
Cc: "David Miller" <davem@davemloft.net>, "netdev" <netdev@vger.kernel.org>
Subject: Re: [PATCH 3/20][BNX2]: Add 40-bit DMA workaround for 5708.
Date: Wed, 02 May 2007 13:02:41 -0700 [thread overview]
Message-ID: <1178136161.4820.91.camel@dell> (raw)
In-Reply-To: <4638D775.3010905@garzik.org>
On Wed, 2007-05-02 at 14:24 -0400, Jeff Garzik wrote:
> Michael Chan wrote:
> > On Wed, 2007-05-02 at 11:29 -0400, Jeff Garzik wrote:
> >> Michael Chan wrote:
> >>> A non-IOMMU system using 64-bit dma_addr_t will always set
> >>> CONFIG_HIGHMEM, right?
> >> No.
> >>
> > May be I misunderstood the code in illegal_highdma() in net/core/dev.c
> > where it is checking to see if it needs to linearize the SKB when the
> > device does not support 64-bit DMA. I'm using similar assumptions for
> > the 40-bit address check in the patch.
>
> That function is just checking for highmem pages, no more, no less.
>
Let's say I have a 32-bit card that cannot do dual address cycle on a
64-bit dma_addr_t system without IOMMU. If CONFIG_HIGHMEM is not set,
wouldn't the device get > 32-bit DMA addresses that it cannot handle?
> Your question quoted far above presumes that no 64-bit systems exist
> lacking IOMMUs, which is not the case. 64-bit platforms with a 64-bit
> dma_addr_t will /not/ set CONFIG_HIGHMEM, regardless of IOMMU presence.
I know that there are 64-bit systems without IOMMUs. That's why we need
the workaround code. Otherwise we can always just set the DMA mask to
40-bit and let the IOMMU handle the translation. I'm trying to come up
with the right conditions to determine whether the address checking is
needed or not. These systems without IOMMU must support 32-bit only
cards, right? How do they do that if they are not using CONFIG_HIGHMEM?
>
> Probably you want to base your actions on some combination of
>
> * CONFIG_64BIT
> * sizeof(dma_addr_t)
> * pci_set_dma_mask() for >32 bit platforms
>
Sure I can use these if CONFIG_HIGHMEM is not right.
next prev parent reply other threads:[~2007-05-02 20:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-02 1:13 [PATCH 3/20][BNX2]: Add 40-bit DMA workaround for 5708 Michael Chan
2007-05-02 7:06 ` Jeff Garzik
2007-05-02 7:12 ` David Miller
2007-05-02 15:23 ` Michael Chan
2007-05-02 15:28 ` Christoph Hellwig
2007-05-02 15:29 ` Jeff Garzik
2007-05-02 18:23 ` Michael Chan
2007-05-02 18:24 ` Jeff Garzik
2007-05-02 20:02 ` Michael Chan [this message]
2007-05-02 20:30 ` Jeff Garzik
2007-05-02 22:48 ` Christoph Hellwig
2007-05-02 22:50 ` David Miller
2007-05-02 19:40 ` David Miller
2007-05-02 21:27 ` Michael Chan
2007-05-02 21:45 ` David Miller
2007-05-02 23:28 ` Michael Chan
2007-05-02 22:48 ` David Miller
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=1178136161.4820.91.camel@dell \
--to=mchan@broadcom.com \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).