All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Brad House <brad_mssw@gentoo.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
Date: Tue, 30 Dec 2003 01:35:46 -0500	[thread overview]
Message-ID: <3FF11CC2.7040209@pobox.com> (raw)
In-Reply-To: <65025.68.105.173.45.1072765590.squirrel@mail.mainstreetsoftworks.com>

Brad House wrote:
> Hmm, I don't think this driver is as complex as others may
> be to port.  But then again, I'm probably wrong b/c I'm mainly
> a userland guy, not a kernel guy :/
> But, nonetheless, I've made some changes:

The only thing that matters is the hardware s/g list capabilities. 
Driver complexity is irrelevant.


>>> 			/* Calculate Scatter-Gather info */
>>> 			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
>>>-					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
>>>+					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);
>>
>>Casting just hides a bug.
> 
> 
> Well, the  xferaddr is actually a dma_addr_t now, so that cast really
> does nothing, the only reason it's there is because they previously
> casted it as (u32 *).  I removed the cast just so it couldn't obscure
> warnings, and it didn't.
> 
> Also, I use  dma_addr_t even though it may have nothing to do with dma
> where it's used. I'm more familiar with userland stuff, so I wasn't sure
> what to use. In userland I'd use  uintptr_t.
> 
> 
>>The real fix is to pass a full 64-bit address
> 
> 
> I did find a few instances where they recast the addresses,
> which was improper, but it does appear that the original address
> in the original driver was coming in as 64bit (dma_addr_t as originally
> written), but were passing it around and casting it as a u32, so I
> think the interfaces allowed for it to work, they just wrote it
> unware of 64bit systems.
> 
> Also, they tried to stuff the address returned here :
> ext_inq = pci_alloc_consistent(adapter->dev,
>                                 sizeof(mraid_ext_inquiry), &dma_handle);
> (the dma_handle) into a u32 which I just fixed.
> 
> 
>>into the s/g list, if it supports 64-bit addresses.  if it doesn't, you
>>need to make sure the driver doesn't set highmem_io, make sure the
>>driver doesn't set a 64-bit DMA mask, and make sure the driver does set
>>a 32-bit DMA mask.
> 
> 
> The driver already does this it appears, without me needing to do it,
> Part of which is covered by this:
>  /* Set the Mode of addressing to 64 bit if we can */
>                 if((adapter->flag & BOARD_64BIT)&&(sizeof(dma_addr_t) ==
> 8)) {
>                         pci_set_dma_mask(pdev, 0xffffffffffffffffULL);
>                         adapter->has_64bit_addr = 1;
>                 }
>                 else  {
>                         pci_set_dma_mask(pdev, 0xffffffff);
>                         adapter->has_64bit_addr = 0;
>                 }

This code is completely bogus and wrong (not your fault, but still). 
Take a look at tg3.c for the right way to do it.

The driver continues to have obvious 64-bit issues that your patch 
doesn't address.  Your main test platform should really be a 32-bit 
system with PAE, and >4GB of RAM.

	Jeff




  reply	other threads:[~2003-12-30  6:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-30  5:10 [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64) Brad House
2003-12-30  5:20 ` Jeff Garzik
2003-12-30  6:26   ` Brad House
2003-12-30  6:35     ` Jeff Garzik [this message]
2003-12-30 19:43       ` Samuel Flory
2003-12-30 19:49         ` Brad House
2003-12-30 19:54           ` Samuel Flory
2003-12-30 21:09             ` Brad House
2003-12-30 23:11             ` Matt Domsch
     [not found] <18kst-5Av-1@gated-at.bofh.it>
2003-12-30  5:26 ` Andi Kleen
2004-01-01 14:08   ` Brad House
  -- strict thread matches above, loose matches on Subject: below --
2004-04-16 13:56 Jord Tanner
2004-04-16 16:35 Mukker, Atul
2004-04-16 19:21 ` Jord Tanner
     [not found]   ` <A1E28594-9478-11D8-B5AA-000A95CD704C@wagland.net>
2004-04-22 18:22     ` Jord Tanner
2004-04-22 18:37       ` Christoph Hellwig
2004-04-16 19:24 Mukker, Atul

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=3FF11CC2.7040209@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=brad_mssw@gentoo.org \
    --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.