Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Oct 2011 20:45:02 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Edward Tomasz Napiera?a <trasz@freebsd.org>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: Fixing bus_dma_tag_create(NULL, ?).
Message-ID:  <20111031194501.GA34421@alchemy.franken.de>
In-Reply-To: <52DDA484-9D3D-4305-9692-ADBD7C68BD0B@FreeBSD.org>
References:  <52DDA484-9D3D-4305-9692-ADBD7C68BD0B@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 31, 2011 at 02:52:58PM +0100, Edward Tomasz Napiera?a wrote:
> On sparc64, calling bus_dma_tag_create(9) with NULL tag will result in instant
> panic due to KASSERT.  Patch below fixes all the instances I could find.  It also fixes
> several places unrelated to sparc64, just to give a good example.
> 
> Now, the problem is - the changes are trivial and mechanical, but I have no way
> to test most of it, simply because I don't have hardware handled by these drivers.
> And I'm not really sure how to proceed from this point.  Any ideas?
> 
> Patch can be found at:
> 
> http://people.freebsd.org/~trasz/sparc64-bus_dma_tag_create.diff
> 

I prefer to leave the NULL parent tag usage in as a marker that a driver
hasn't been reviewed and fixed to also work on !x86 as typically drivers
only written with x86 in mind also have other bus_dma(9) and endianness
related bugs, miss bus barriers, have alignment issues or even aren't
actually 64-bit clean etc. Also I think it's better that a users gets
a clean panic when trying to use such a driver than a randomly broken
driver that could cause data corruption etc. I won't stop you from
committing that patch though. It certainly doesn't matter to commit it
untested for asr(4), which likely will be i386-only forever, as well as
blkfront(4) and ndis(4).

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111031194501.GA34421>