Messages in this thread | | | Date | Sat, 10 Nov 2007 11:43:20 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5] |
| |
On Sat, 10 Nov 2007 12:18:50 +0000 David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> wrote: > > > ho hum, I've seen worse-looking code ;). There's quite a bit of the usual > > stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking > > volatiles > > The vast majority of which are either memory-mapped hardware registers or > interrupt-routine-filled ring buffers.
So? Those are very common things and most drivers don't resort to `volatile' to access them.
> > but I don't need to sit here and emulate checkpatch.pl. > > No, it should be deleted: > > shred -fu scripts/checkpatch.pl > > will do the trick quite nicely.
checkpatch is quite accurate now - Ingo has been following this quite carefully.
If you were to use it there would be improvements in the exceptionally high number of mistakes in your patches.
> | WARNING: do not add new typedefs > | #27265: FILE: include/asm-mn10300/types.h:30: > | +typedef unsigned int __u32; > > Pah!
Bug reports against checkpath should be sent to apw, not used as an excuse to put incorrectly laid-out code into the kernel and for increasing my workload.
> > I googled a bit but most of the mn10300 info pertains to linux kernel and > > gcc. Who is using this CPU and in what applications? > > This CPU is MEI/Matsushita/Panasonic's own CPU. If you've bought a Panasonic > telly, say, in the last few years, the odds are rather good that it's got one > of these CPUs in it running Linux.
How did you know I had a Panasonic flat screen? ;)
> http://www.am-linux.jp/ > > has a couple of examples on it's front page. If you work through the menus of > modern Panasonic tellies, you might find a URL pointing somewhere on this > website that isn't reachable by linking from the index page of the website. > > I don't know who else uses this CPU, but it's possible MEI sell them to other > companies. >
If it is indeed the case that this architecture is used internally by a single organisation then perhaps it doesn't make sense for us to merge it.
One of the main reasons we put code into the kernel is as a means of distribution: to get it into the hands of people who need it. But in this situation there is no advantage to *anyone* from this merge apart from MEI.
IOW, the submitter gains and everyone else loses. It's a curious situation.
I guess if it were possible to install a self-built kernel into a Panasonic gadget then we could look at it on that basis. Do you know if that's the case? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |