From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Guo Ren <guoren@kernel.org>, Michal Simek <monstr@monstr.eu>,
Greentime Hu <green.hu@gmail.com>,
Vincent Chen <deanbo422@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
the arch/x86 maintainers <x86@kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>,
openrisc@lists.librecores.org,
Parisc List <linux-parisc@vger.kernel.org>,
linux-riscv@lists.infradead.org,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 10:09:05 +0000 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Guo Ren <guoren@kernel.org>, Michal Simek <monstr@monstr.eu>,
Greentime Hu <green.hu@gmail.com>,
Vincent Chen <deanbo422@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
"the arch/x86 maintainers" <x86@kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>,
openrisc@lists.librecores.org,
Parisc List <linux-parisc@vger.kernel.org>,
linux-riscv@lists.infradead.org,
linux-s390 <linux-s390@vger.kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-xtensa@linux-xtensa.org,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-arch <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Guo Ren <guoren@kernel.org>, Michal Simek <monstr@monstr.eu>,
Greentime Hu <green.hu@gmail.com>,
Vincent Chen <deanbo422@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
the arch/x86 maintainers <x86@kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>,
openrisc@lists.librecores.org,
Parisc List <linux-parisc@vger.kernel.org>,
linux-riscv@lists.infradead.org,
linux-s390 <linux-s390@vger.kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-xtensa@linux-xtensa.org,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-arch <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Guo Ren <guoren@kernel.org>, Michal Simek <monstr@monstr.eu>,
Greentime Hu <green.hu@gmail.com>,
Vincent Chen <deanbo422@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
the arch/x86 maintainers <x86@kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>,
openrisc@lists.librecores.org,
Parisc List <linux-parisc@vger.kernel.org>,
linux-riscv@lists.infradead.org,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Guo Ren <guoren@kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-riscv@lists.infradead.org,
Vincent Chen <deanbo422@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
linux-xtensa@linux-xtensa.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>, Guan Xuetao <gxt@pku.edu.cn>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Michal Simek <monstr@monstr.eu>,
Parisc List <linux-parisc@vger.kernel.org>,
linux-mips@vger.kernel.org, alpha <linux-alpha@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Guo Ren <guoren@kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-riscv@lists.infradead.org,
Vincent Chen <deanbo422@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
linux-xtensa@linux-xtensa.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>, Guan Xuetao <gxt@pku.edu.cn>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Michal Simek <monstr@monstr.eu>,
Parisc List <linux-parisc@vger.kernel.org>,
linux-mips@vger.kernel.org, alpha <linux-alpha@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Guo Ren <guoren@kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-riscv@lists.infradead.org,
Vincent Chen <deanbo422@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
linux-xtensa@linux-xtensa.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>, Guan Xuetao <gxt@pku.edu.cn>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Michal Simek <monstr@monstr.eu>,
Parisc List <linux-parisc@vger.kernel.org>,
linux-mips@vger.kernel.org, alpha <linux-alpha@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Guo Ren <guoren@kernel.org>,
sparclinux <sparclinux@vger.kernel.org>,
linux-riscv@lists.infradead.org,
Vincent Chen <deanbo422@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
linux-xtensa@linux-xtensa.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
"moderated list:NIOS2 ARCHITECTURE"
<nios2-dev@lists.rocketboards.org>, Guan Xuetao <gxt@pku.edu.cn>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Michal Simek <monstr@monstr.eu>,
Parisc List <linux-parisc@vger.kernel.org>,
linux-mips@vger.kernel.org, alpha <linux-alpha@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
Date: Mon, 11 Nov 2019 11:09:05 +0100 [thread overview]
Message-ID: <CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com> (raw)
In-Reply-To: <20191029064834.23438-11-hch@lst.de>
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation. In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default. Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> + return NULL;
> +}
> +#endif
Maybe we could move the definition into the atyfb driver itself?
As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7) those three are meant to be synonyms
anyway.
Arnd
next prev parent reply other threads:[~2019-11-11 10:09 UTC|newest]
Thread overview: 557+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 17:45 generic ioremap (and lots of cleanups) v2 Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 01/21] arm: remove ioremap_cached Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 02/21] unicore32: " Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 03/21] ia64: rename ioremap_nocache to ioremap_uc Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-21 8:47 ` [OpenRISC] " Sergei Shtylyov
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-21 8:47 ` Sergei Shtylyov
2019-10-17 17:45 ` [PATCH 04/21] hexagon: clean up ioremap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 05/21] alpha: remove the unused __ioremap wrapper Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 06/21] nios2: remove __ioremap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 07/21] parisc: " Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 21:35 ` Rolf Eike Beer
2019-10-17 17:45 ` [PATCH 08/21] x86: clean up ioremap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-21 8:23 ` Thomas Gleixner
2019-10-21 8:23 ` [OpenRISC] " Thomas Gleixner
2019-10-21 8:23 ` Thomas Gleixner
2019-10-21 8:23 ` Thomas Gleixner
2019-10-21 8:23 ` Thomas Gleixner
2019-10-21 8:23 ` Thomas Gleixner
2019-10-21 8:23 ` Thomas Gleixner
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` [OpenRISC] " Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-28 15:29 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 09/21] xtensa: " Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 13/21] m68k: rename __iounmap and mark it static Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-18 7:30 ` Geert Uytterhoeven
2019-10-17 17:45 ` [PATCH 14/21] hexagon: remove __iounmap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 15/21] nios2: " Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 16/21] sh: " Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 17/21] lib: provide a simple generic ioremap implementation Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 18/21] riscv: use the generic ioremap code Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-18 3:42 ` Paul Walmsley
2019-10-17 17:45 ` [PATCH 19/21] nds32: use generic ioremap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 20/21] csky: remove ioremap_cache Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-21 7:58 ` Guo Ren
2019-10-21 7:58 ` [OpenRISC] " Guo Ren
2019-10-21 7:58 ` Guo Ren
2019-10-21 7:58 ` Guo Ren
2019-10-21 7:58 ` Guo Ren
2019-10-21 7:58 ` Guo Ren
2019-10-21 7:58 ` Guo Ren
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` [OpenRISC] " Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-11-05 1:26 ` Christoph Hellwig
2019-10-17 17:45 ` [PATCH 21/21] csky: use generic ioremap Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-17 17:45 ` Christoph Hellwig
2019-10-29 6:48 ` generic ioremap (and lots of cleanups) v3 Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 01/21] arm: remove ioremap_cached Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-11-11 10:33 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 02/21] unicore32: " Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 03/21] ia64: rename ioremap_nocache to ioremap_uc Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-11-11 10:36 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 04/21] hexagon: clean up ioremap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 05/21] alpha: remove the unused __ioremap wrapper Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 06/21] nios2: remove __ioremap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 07/21] parisc: " Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` [OpenRISC] " Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-11-05 14:29 ` Helge Deller
2019-10-29 6:48 ` [PATCH 08/21] x86: Clean up ioremap() Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-30 10:39 ` Thomas Gleixner
2019-10-30 10:39 ` [OpenRISC] " Thomas Gleixner
2019-10-30 10:39 ` Thomas Gleixner
2019-10-30 10:39 ` Thomas Gleixner
2019-10-30 10:39 ` Thomas Gleixner
2019-10-30 10:39 ` Thomas Gleixner
2019-10-30 10:39 ` Thomas Gleixner
2019-10-29 6:48 ` [PATCH 09/21] xtensa: clean up ioremap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-06 17:56 ` [OpenRISC] " Palmer Dabbelt
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-06 17:56 ` Palmer Dabbelt
2019-11-11 10:09 ` Arnd Bergmann [this message]
2019-11-11 10:09 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:09 ` Arnd Bergmann
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` [OpenRISC] " Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:15 ` Christoph Hellwig
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:27 ` Arnd Bergmann
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` [OpenRISC] " Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 10:29 ` Christoph Hellwig
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` [OpenRISC] " Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-11-11 19:33 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:11 ` [OpenRISC] " Palmer Dabbelt
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:11 ` Palmer Dabbelt
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` [OpenRISC] " Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:16 ` Geert Uytterhoeven
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` [OpenRISC] " Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-06 18:28 ` Christoph Hellwig
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:31 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-11-11 10:29 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` [OpenRISC] " Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 13/21] m68k: rename __iounmap and mark it static Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` [OpenRISC] " Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-30 8:51 ` Geert Uytterhoeven
2019-10-29 6:48 ` [PATCH 14/21] hexagon: remove __iounmap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 15/21] nios2: " Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 16/21] sh: " Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 17/21] lib: provide a simple generic ioremap implementation Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` [OpenRISC] " Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-07 15:29 ` Palmer Dabbelt
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` [OpenRISC] " Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-11-11 10:10 ` Arnd Bergmann
2019-10-29 6:48 ` [PATCH 18/21] riscv: use the generic ioremap code Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 19/21] nds32: use generic ioremap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` [OpenRISC] " Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-11-12 8:51 ` Greentime Hu
2019-10-29 6:48 ` [PATCH 20/21] csky: remove ioremap_cache Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` [PATCH 21/21] csky: use generic ioremap Christoph Hellwig
2019-10-29 6:48 ` [OpenRISC] " Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-10-29 6:48 ` Christoph Hellwig
2019-11-05 1:31 ` generic ioremap (and lots of cleanups) v3 Christoph Hellwig
2019-11-05 1:31 ` [OpenRISC] " Christoph Hellwig
2019-11-05 1:31 ` Christoph Hellwig
2019-11-05 1:31 ` Christoph Hellwig
2019-11-05 1:31 ` Christoph Hellwig
2019-11-05 1:31 ` Christoph Hellwig
2019-11-05 1:31 ` Christoph Hellwig
2019-11-07 20:47 ` generic-iomap tree for linux-next Christoph Hellwig
2019-11-07 20:47 ` [OpenRISC] " Christoph Hellwig
2019-11-07 20:47 ` Christoph Hellwig
2019-11-07 20:47 ` Christoph Hellwig
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 2:20 ` [OpenRISC] " Stephen Rothwell
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 2:20 ` Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 4:52 ` [OpenRISC] " Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 4:52 ` Stephen Rothwell
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` [OpenRISC] " Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
2019-11-08 5:14 ` Christoph Hellwig
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='CAK8P3a2o4R+E2hTrHrmNy7K1ki3_98aWE5a-fjkQ_NWW=xd_gQ@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=deanbo422@gmail.com \
--cc=green.hu@gmail.com \
--cc=guoren@kernel.org \
--cc=gxt@pku.edu.cn \
--cc=hch@lst.de \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=monstr@monstr.eu \
--cc=nios2-dev@lists.rocketboards.org \
--cc=openrisc@lists.librecores.org \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.