[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201303151229.52997.arnd@arndb.de>
Date: Fri, 15 Mar 2013 12:29:52 +0000
From: Arnd Bergmann <arnd@...db.de>
To: David Miller <davem@...emloft.net>
Cc: geert@...ux-m68k.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, isdn@...ux-pingi.de,
netdev@...r.kernel.org, dhowells@...hat.com
Subject: Re: [PATCH] isdn: hisax: netjet requires VIRT_TO_BUS
On Friday 15 March 2013, David Miller wrote:
> I do not want to see us add such a Kconfig dependency knob.
>
> Then the real tendency will exist to make new drivers little-endian
> only, refuse to fix endian-broken old drivers, etc.
>
> Which means that allmodconfig on my architecture will have build
> coverage on less code, which is really the only thing that matters
> for me. I want all drivers that could be effected by my changes
> to be compile testable on as many platforms as possible.
There are two separate issues here. The first one that David Howells
brought up was ill-defined __BIG_ENDIAN/__LITTLE_ENDIAN macros.
Using CONFIG_CPU_IS_BIG_ENDIAN/CONFIG_CPU_IS_LITTLE_ENDIAN in the code
is what Linus suggested as a replacement, although I see little
incentive to do mass conversion there, it would be mainly for new
code.
The other issue is the Kconfig logic where Geert would replace
all the instances of "depends on BROKEN || !(SPARC || PPC || PARISC ||
M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA &&
!CPU_LITTLE_ENDIAN))" with something that actually reflects what
we mean. I think it would be a nice cleanup, but I can also understand
your hesitation there.
Do you object to both uses of that symbol, or just to using it in order
to disable drivers in Kconfig? I don't care too much right now, since
nothing is actually broken at the moment, I would just like to get
the VIRT_TO_BUS patch merged so people can also build allmodconfig
on my architecture ;-)
Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists