linux-kernel - Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update

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]

Date:	Mon, 5 Mar 2007 09:47:09 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Aubrey Li" <aubreylee@...il.com>
Cc:	bryan.wu@...log.com, "Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update

On Monday 05 March 2007, Aubrey Li wrote:
> On 3/4/07, Arnd Bergmann <arnd@...db.de> wrote:

> > In general, please put EXPORT_SYMBOL lines below the definition
> > of the symbol itself. This list of exports should only be used
> > for symbols that come from assembly files.
> 
> What is the right way to export symbol coming from c files?
 
As I said, below the symbol definition, like

int global_var;
EXPORT_SYMBOL(global_var);

int global_function(void)
{
	return 3;
}
EXPORT_SYMBOL(global_function);

> > This detection seems to me like a strange thing to do in setup_arch().
> > It should be possible to do this much later, at a point where the system
> > is much less fragile and e.g. printk works. It could even be moved into
> > some place in the mtd code itself, since other architectures might want
> > to do the same thing.
> 
> After download the rootfs image from host to the target ram, we need
> to move the image to the right place, so we need to know the size of
> the image at this time.

Well, it doesn't have to be in the modular part of the kernel, but some
place later than setup_arch() would be a step in the right direction.
If you need it before the file systems, an arch_initcall() might be
the right place.

> > I'm curious: In your dual-core bf561, don't you actually need to implement
> > something that maintains atomicity across cores rather than just across
> > processes?
> 
> Yes, bf561 is a dual-core processor, but we are using only one core of
> bf561 now.
> IMHO, BF561 architecture was not designed for SMP or NUMA.

Interesting, so what is the intended use of the other core? Does the
hardware have any way of supporting concurrency between the cores,
other than sending interrupts between them?

> > How does this fit in with the generic SPI code? Does it duplicate stuff
> > from there, or do you use it?
> 
> We use our own. We have dma which can be used for SPI operations.

I just looked again at your code. My question was more directed at whether
you use your own SPI abstraction layer instead of drivers/spi, which
you fortunately don't. The piece I was missing however is the spi_bfin5xx.c
driver, which was not part of this patch, though you seem to rely on it.
Is that already part of the -mm kernel?

	Arnd <><
-
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/