linux-kernel - Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071110114320.1fa6e94c.akpm@linux-foundation.org>
Date:	Sat, 10 Nov 2007 11:43:20 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-am33-list@...hat.com
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@...hat.com> wrote:

> Andrew Morton <akpm@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/