linux-kernel - Re: [PATCH 07/28] nios2: I/O Mapping

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: <5393488.r5N1ijHzS4@wuerfel>
Date:	Fri, 02 May 2014 14:22:30 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ley Foon Tan <lftan@...era.com>
Cc:	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	cltang@...esourcery.com
Subject: Re: [PATCH 07/28] nios2: I/O Mapping

On Friday 02 May 2014 18:37:55 Ley Foon Tan wrote:
> On Thu, Apr 24, 2014 at 2:02 PM, Ley Foon Tan <lftan@...era.com> wrote:
> > On Tue, Apr 22, 2014 at 9:59 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> On Friday 18 April 2014, Ley Foon Tan wrote:
> >>
> >>> +
> >>> +#include <asm/pgtable-bits.h>
> >>> +
> >>> +#define IO_SPACE_LIMIT 0xffffffff
> >>
> >> Please use 0xffff here, this should work for almost any PCI bus.
> > Ah, CONFIG_PCI is not enable in nios2. So, I think IO_SPACE_LIMIT
> > should set to 0.
> >
> >
> >>> +
> >>> +/* Use "Duff's Device" to unroll the loops. */
> >>> +#define __IO_OUT_LOOP(a, b, l)                               \
> >>> +     do {                                            \
> >>> +             if (l > 0) {                            \
> >>> +                     int _n = (l + 7) / 8;           \
> >>> +                     switch (l % 8) {                \
> >>> +                     case 0:                         \
> >>> +                             do {                    \
> >>> +                                     *a = *b++;      \
> >>
> >> I would recommend just doing all of this in out-of-line implementations
> >> rather than macros and inline functions.
> > Okay. Will move the macros to out-of-line function.
>
> I'm start working on this and found that it is better to keep it as
> macros. This is because the input arguments "a" and "b" can be
> byte/short/int pointers. Otherwise, we need to have separate function
> calls for byte/short/int.

But with the inline implementation, you have a separate instance for each
caller, which seems more wasteful.

You can put the function into a "lib" file to make sure it doesn't get linked
in if there are no callers though. And of course you can keep the macro
in the file implementing it so you don't have to write the same code
three times.

	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/