From: Andrew Morton <akpm@linux-foundation.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-am33-list@redhat.com
Subject: Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Date: Sat, 10 Nov 2007 11:43:20 -0800 [thread overview]
Message-ID: <20071110114320.1fa6e94c.akpm@linux-foundation.org> (raw)
In-Reply-To: <24343.1194697130@redhat.com>
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?
next prev parent reply other threads:[~2007-11-10 19:43 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 15:34 [PATCH 0/6] MN10300: Add the MN10300 architecture to Linux kernel [try #5] David Howells
2007-11-09 15:34 ` [PATCH 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT " David Howells
2007-11-11 2:14 ` Andrew Morton
2007-11-11 11:25 ` Adrian Bunk
2007-11-11 13:59 ` David Howells
2007-11-11 14:22 ` Adrian Bunk
2007-11-11 15:03 ` David Howells
2007-11-11 15:19 ` Adrian Bunk
2007-11-11 15:46 ` Andi Kleen
2007-11-11 16:05 ` Adrian Bunk
2007-11-11 16:31 ` David Howells
2007-11-12 15:34 ` David Howells
2007-11-12 19:53 ` Andrew Morton
2007-11-12 22:50 ` SL Baur
2007-11-12 23:14 ` David Howells
2007-11-13 3:09 ` SL Baur
2007-11-13 10:57 ` David Howells
2007-11-13 11:18 ` Andrew Morton
2007-11-13 12:46 ` Peter Zijlstra
2007-11-13 20:40 ` Matt Mackall
2007-11-13 20:46 ` Peter Zijlstra
2007-12-03 15:15 ` David Howells
2007-12-03 16:00 ` Ralf Baechle
2007-12-03 16:17 ` Adrian Bunk
2007-11-09 15:34 ` [PATCH 2/6] MTD: Add support for the SST 39VF1601 flash chip " David Howells
2007-11-09 22:34 ` David Woodhouse
2007-11-09 15:34 ` [PATCH 3/6] USB: net2280 can't have a function called show_registers() " David Howells
2007-11-09 15:34 ` [PATCH 4/6] MN10300: Allocate serial port UART IDs for on-chip serial ports " David Howells
2007-11-09 15:35 ` [PATCH 6/6] MN10300: Add MTD flash support for the ASB2303 board " David Howells
2007-11-10 4:05 ` David Woodhouse
2007-11-11 14:01 ` David Howells
[not found] ` <20071109153458.20803.10594.stgit@warthog.procyon.org.uk>
2007-11-10 3:53 ` [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel " Andrew Morton
2007-11-10 12:18 ` David Howells
2007-11-10 19:43 ` Andrew Morton [this message]
2007-11-10 20:02 ` Alan Cox
2007-11-12 7:44 ` Adrian Bunk
2007-11-10 20:09 ` Alan Cox
2007-11-11 14:32 ` David Howells
2007-11-11 14:48 ` David Howells
2007-11-11 15:18 ` Alan Cox
2007-11-11 16:36 ` David Howells
2007-11-11 16:42 ` Alan Cox
2007-11-12 12:19 ` David Howells
2007-11-11 15:07 ` David Howells
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=20071110114320.1fa6e94c.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-am33-list@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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).