linux-kernel - Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases

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:	Wed, 1 Jul 2015 08:55:57 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Christoph Hellwig <hch@....de>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Juergen Gross <jgross@...e.com>, X86 ML <x86@...nel.org>,
	"Kani, Toshimitsu" <toshi.kani@...com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Luis Rodriguez <mcgrof@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stefan Bader <stefan.bader@...onical.com>,
	Andy Lutomirski <luto@...capital.net>,
	Linux MM <linux-mm@...ck.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Michael Ellerman <mpe@...erman.id.au>,
	Tejun Heo <tj@...nel.org>, Paul Mackerras <paulus@...ba.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases

On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig <hch@....de> wrote:
>> One useful feature of the ifdef mess as implemented in the patch is
>> that you could test for whether ioremap_cache() is actually
>> implemented or falls back to default ioremap().  I think for
>> completeness archs should publish an ioremap type capabilities mask
>> for drivers that care... (I can imagine pmem caring), or default to
>> being permissive if something like IOREMAP_STRICT is not set.  There's
>> also the wrinkle of archs that can only support certain types of
>> mappings at a given alignment.
>
> I think doing this at runtime might be a better idea.  E.g. a
> ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
> actually implemented.  On various architectures different CPUs or
> boards will have different capabilities in this area.

So it would be the responsibility of the caller to fall back from
ioremap(..., CACHED) to ioremap(..., UNCACHED)?
I.e. all drivers using it should be changed...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/