This patch affords each architecture the ability to condition the
population of page middle directory entries on the virtual address being
allocated, matching existing PTE infrastructure, easing the necessity of
performing a reverse page table walk in cases where the population
context is not
Future changes will need to add a new member to struct
vm_unmapped_area_info. This would cause trouble for any call site that
doesn't initialize the struct. Currently every caller sets each member
manually, so if new ones are added they will be uninitialized and the
core code parsing the struct
On Tue, 2024-03-12 at 20:18 -0700, Kees Cook wrote:
>
> Thanks! This looks to do exactly what it describes. :)
>
> Reviewed-by: Kees Cook
Thanks!
On Tue, Mar 12, 2024 at 03:28:39PM -0700, Rick Edgecombe wrote:
> So to be reduce the chance of bugs via uninitialized fields, perform a
> tree wide change using the consensus for the best general way to do this
> change. Use C99 static initializing to zero the struct and remove and
> statements
Future changes will need to add a new member to struct
vm_unmapped_area_info. This would cause trouble for any call site that
doesn't initialize the struct. Currently every caller sets each member
manually, so if new ones are added they will be uninitialized and the
core code parsing the struct
On 06/03/2024 14:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Naresh noticed that the newly added usage of the PAGE_SIZE macro in
> include/vdso/datapage.h introduced a build regression. I had an older
> patch that I revived to have this defined through Kconfig rather than
> through
On Wed, 6 Mar 2024, Vincent Guittot wrote:
> Hi Prateek,
>
> Adding Julia who could be interested in this patchset. Your patchset
> should trigger idle load balance instead of newly idle load balance
> now when the polling is used. This was one reason for not migrating
> task in idle CPU
My
On 2024-03-06 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
> only the
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
> leaving the arhcitecture specific ones as the
Hi Arnd,
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
> ---
> Changes from v1:
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Naresh noticed that the newly added usage of the PAGE_SIZE macro in
> include/vdso/datapage.h introduced a build regression. I had an older
> patch that I revived to have this defined through Kconfig rather than
>
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
>
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
> leaving the
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
On Wed, Mar 6, 2024 at 3:15 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
>
From: Arnd Bergmann
Most architectures only support a single hardcoded page size. In order
to ensure that each one of these sets the corresponding Kconfig symbols,
change over the PAGE_SHIFT definition to the common one and allow
only the hardware page size to be selected.
Acked-by: Guo Ren
From: Arnd Bergmann
arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones as the user visible
place for
From: Arnd Bergmann
These four architectures define the same Kconfig symbols for configuring
the page size. Move the logic into a common place where it can be shared
with all other architectures.
Signed-off-by: Arnd Bergmann
---
Changes from v1:
- improve Kconfig help texts
- fix Hexagon
From: Arnd Bergmann
Naresh noticed that the newly added usage of the PAGE_SIZE macro in
include/vdso/datapage.h introduced a build regression. I had an older
patch that I revived to have this defined through Kconfig rather than
through including asm/page.h, which is not allowed in vdso code.
On Wed, 6 Mar 2024 at 11:18, K Prateek Nayak wrote:
>
> Hello Vincent,
>
> Thank you for taking a look at the series.
>
> On 3/6/2024 3:29 PM, Vincent Guittot wrote:
> > Hi Prateek,
> >
> > Adding Julia who could be interested in this patchset. Your patchset
> > should trigger idle load balance
Hello Vincent,
Thank you for taking a look at the series.
On 3/6/2024 3:29 PM, Vincent Guittot wrote:
> Hi Prateek,
>
> Adding Julia who could be interested in this patchset. Your patchset
> should trigger idle load balance instead of newly idle load balance
> now when the polling is used. This
Hi Prateek,
Adding Julia who could be interested in this patchset. Your patchset
should trigger idle load balance instead of newly idle load balance
now when the polling is used. This was one reason for not migrating
task in idle CPU
On Tue, 20 Feb 2024 at 18:15, K Prateek Nayak wrote:
>
>
On Mon, 2024-02-26 at 17:14 +0100, Arnd Bergmann wrote:
>
> arch/um/Kconfig| 1 +
> arch/um/include/asm/page.h | 2 +-
LGTM, thanks.
Acked-by: Johannes Berg
johannes
On Mon, 2024-03-04 at 18:00 +, Christophe Leroy wrote:
> > Personally, I think a single patch that sets "= {}" for all of them
> > and
> > drop the all the "= 0" or "= NULL" assignments would be the
> > cleanest way
> > to go.
>
> I agree with Kees, set = {} and drop all the "something = 0;"
Le 02/03/2024 à 02:51, Kees Cook a écrit :
> On Sat, Mar 02, 2024 at 12:47:08AM +, Edgecombe, Rick P wrote:
>> On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
>>> I totally understand. If the "uninitialized" warnings were actually
>>> reliable, I would agree. I look at it this way:
>>>
On Sat, Mar 02, 2024 at 12:47:08AM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> > I totally understand. If the "uninitialized" warnings were actually
> > reliable, I would agree. I look at it this way:
> >
> > - initializations can be missed either in
On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> I totally understand. If the "uninitialized" warnings were actually
> reliable, I would agree. I look at it this way:
>
> - initializations can be missed either in static initializers or via
> run time initializers. (So the risk of mistake
Le 28/02/2024 à 18:01, Edgecombe, Rick P a écrit :
> On Wed, 2024-02-28 at 13:22 +, Christophe Leroy wrote:
>>> Any preference? Or maybe am I missing your point and talking
>>> nonsense?
>>>
>>
>> So my preference would go to the addition of:
>>
>> info.new_field = 0;
>>
>> But
On Mon, Feb 26, 2024 at 05:14:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and
On Wed, Feb 28, 2024 at 01:22:09PM +, Christophe Leroy wrote:
> [...]
> My worry with initialisation at declaration is it often hides missing
> assignments. Let's take following simple exemple:
>
> char *colour(int num)
> {
> char *name;
>
> if (num == 0) {
> name
On Wed, 2024-02-28 at 13:22 +, Christophe Leroy wrote:
> > Any preference? Or maybe am I missing your point and talking
> > nonsense?
> >
>
> So my preference would go to the addition of:
>
> info.new_field = 0;
>
> But that's very minor and if you think it is easier to manage and
Le 27/02/2024 à 21:25, Edgecombe, Rick P a écrit :
> On Tue, 2024-02-27 at 18:16 +, Christophe Leroy wrote:
Why doing a full init of the struct when all fields are re-
written a few
lines after ?
>>>
>>> It's a nice change for robustness and makes future changes easier.
>>>
On Mon, Feb 26, 2024 at 11:09:47AM -0800, Rick Edgecombe wrote:
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 5db88b627439..dd6801bb9240 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1218,7 +1218,7 @@ static unsigned long
>
On Tue, 2024-02-27 at 18:16 +, Christophe Leroy wrote:
> > > Why doing a full init of the struct when all fields are re-
> > > written a few
> > > lines after ?
> >
> > It's a nice change for robustness and makes future changes easier.
> > It's
> > not actually wasteful since the compiler
Le 27/02/2024 à 19:07, Kees Cook a écrit :
> On Tue, Feb 27, 2024 at 07:02:59AM +, Christophe Leroy wrote:
>>
>>
>> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
>>> Future changes will need to add a field to struct vm_unmapped_area_info.
>>> This would cause trouble for any archs that
On Tue, Feb 27, 2024 at 07:02:59AM +, Christophe Leroy wrote:
>
>
> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> > Future changes will need to add a field to struct vm_unmapped_area_info.
> > This would cause trouble for any archs that don't initialize the
> > struct. Currently every
On Tue, Feb 27, 2024, at 16:44, Christophe Leroy wrote:
> Le 27/02/2024 à 16:40, Arnd Bergmann a écrit :
>> On Mon, Feb 26, 2024, at 17:55, Samuel Holland wrote:
>
>
> For 256K pages, powerpc has the following help. I think you should have
> it too:
>
> The kernel will only be able to run
Le 27/02/2024 à 16:40, Arnd Bergmann a écrit :
> On Mon, Feb 26, 2024, at 17:55, Samuel Holland wrote:
>> On 2024-02-26 10:14 AM, Arnd Bergmann wrote:
>>>
>>> +config HAVE_PAGE_SIZE_4KB
>>> + bool
>>> +
>>> +config HAVE_PAGE_SIZE_8KB
>>> + bool
>>> +
>>> +config HAVE_PAGE_SIZE_16KB
>>> +
On Tue, Feb 27, 2024, at 09:45, Geert Uytterhoeven wrote:
>
>> +config PAGE_SIZE_4KB
>> + bool "4KB pages"
>
> Now you got rid of the 4000-byte ("4kB") pages and friends, please
> do not replace these by Kelvin-bytes, and use the official binary
> prefixes => "4 KiB".
>
Done, thanks.
On Mon, Feb 26, 2024, at 20:02, Christophe Leroy wrote:
> Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
>> From: Arnd Bergmann
>
> That's a nice re-factor.
>
> The only drawback I see is that we are loosing several interesting
> arch-specific comments/help text. Don't know if there could be an
On Mon, Feb 26, 2024, at 17:55, Samuel Holland wrote:
> On 2024-02-26 10:14 AM, Arnd Bergmann wrote:
>>
>> +config HAVE_PAGE_SIZE_4KB
>> +bool
>> +
>> +config HAVE_PAGE_SIZE_8KB
>> +bool
>> +
>> +config HAVE_PAGE_SIZE_16KB
>> +bool
>> +
>> +config HAVE_PAGE_SIZE_32KB
>> +bool
>>
On Tue, 2024-02-27 at 07:02 +, Christophe Leroy wrote:
> > It could be possible to initialize the new field for each arch to
> > 0, but
> > instead simply inialize the field with a C99 struct inializing
> > syntax.
>
> Why doing a full init of the struct when all fields are re-written a
> few
On Tue, Feb 27, 2024, at 12:12, Geert Uytterhoeven wrote:
> On Tue, Feb 27, 2024 at 11:59 AM Arnd Bergmann wrote:
>> On Tue, Feb 27, 2024, at 09:54, Geert Uytterhoeven wrote:
>> I was a bit unsure about how to best do this since there
>> is not really a need for a fixed page size on nommu
On Mon, Feb 26, 2024 at 05:14:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and
On 2/26/24 17:14, Arnd Bergmann wrote:
From: Arnd Bergmann
arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones
On Mon, Feb 26, 2024 at 05:14:14PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The recent change to the vdso_data_store broke building compat VDSO
> on at least arm64 because it includes headers outside of the include/vdso/
> namespace:
>
> In file included from
On Mon, Feb 26, 2024 at 05:14:12PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
>
Christophe Leroy writes:
> Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
>> From: Arnd Bergmann
>>
>> The recent change to the vdso_data_store broke building compat VDSO
>> on at least arm64 because it includes headers outside of the include/vdso/
>> namespace:
>
> I understand that powerpc64
Hi Arnd,
CC Greg
On Tue, Feb 27, 2024 at 11:59 AM Arnd Bergmann wrote:
> On Tue, Feb 27, 2024, at 09:54, Geert Uytterhoeven wrote:
> >> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> >> index 9dcf245c9cbf..c777a129768a 100644
> >> --- a/arch/m68k/Kconfig.cpu
> >> +++
On Tue, Feb 27, 2024, at 09:54, Geert Uytterhoeven wrote:
> Hi Arnd,
>> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
>> index 9dcf245c9cbf..c777a129768a 100644
>> --- a/arch/m68k/Kconfig.cpu
>> +++ b/arch/m68k/Kconfig.cpu
>> @@ -30,6 +30,7 @@ config COLDFIRE
>> select
Hi Arnd,
On Mon, Feb 26, 2024 at 5:15 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and
Hi Arnd,
On Mon, Feb 26, 2024 at 5:14 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd
Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> Future changes will need to add a field to struct vm_unmapped_area_info.
> This would cause trouble for any archs that don't initialize the
> struct. Currently every user sets each field, so if new fields are
> added, the core code parsing the
On Tue, Feb 27, 2024 at 12:15 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
Future changes will need to add a field to struct vm_unmapped_area_info.
This would cause trouble for any archs that don't initialize the
struct. Currently every user sets each field, so if new fields are
added, the core code parsing the struct will see garbage in the new
field.
It could be
Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
> leaving the
Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
> ---
Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> The recent change to the vdso_data_store broke building compat VDSO
> on at least arm64 because it includes headers outside of the include/vdso/
> namespace:
I understand that powerpc64 also has an issue, see
On 2024-02-26 10:14 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
> ---
>
From: Arnd Bergmann
The recent change to the vdso_data_store broke building compat VDSO
on at least arm64 because it includes headers outside of the include/vdso/
namespace:
In file included from arch/arm64/include/asm/lse.h:5,
from arch/arm64/include/asm/cmpxchg.h:14,
From: Arnd Bergmann
Most architectures only support a single hardcoded page size. In order
to ensure that each one of these sets the corresponding Kconfig symbols,
change over the PAGE_SHIFT definition to the common one and allow
only the hardware page size to be selected.
Signed-off-by: Arnd
From: Arnd Bergmann
arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones as the user visible
place for
From: Arnd Bergmann
These four architectures define the same Kconfig symbols for configuring
the page size. Move the logic into a common place where it can be shared
with all other architectures.
Signed-off-by: Arnd Bergmann
---
arch/Kconfig | 58
From: Arnd Bergmann
Naresh noticed that the newly added usage of the PAGE_SIZE macro in
include/vdso/datapage.h introduced a build regression. I had an older
patch that I revived to have this defined through Kconfig rather than
through including asm/page.h, which is not allowed in vdso code.
I
From: "Gautham R. Shenoy"
Problem statement
=
When measuring IPI throughput using a modified version of Anton
Blanchard's ipistorm benchmark [1], configured to measure time taken to
perform a fixed number of smp_call_function_single() (with wait set to
1), an increase in
From: "Gautham R. Shenoy"
Currently TIF_NEED_RESCHED is being overloaded, to wakeup an idle CPU in
TIF_POLLING mode to service an IPI even if there are no new tasks being
woken up on the said CPU.
In preparation of a proper fix, introduce a new helper
"need_resched_or_ipi()" which is intended
From: "Gautham R. Shenoy"
Introduce the notion of TIF_NOTIFY_IPI flag. When a processor in
TIF_POLLING mode needs to process an IPI, the sender sets NEED_RESCHED
bit in idle task's thread_info to pull the target out of idle and avoids
sending an interrupt to the idle CPU. When NEED_RESCHED is
Hello everyone,
Before jumping into the issue, let me clarify the Cc list. Everyone have
been cc'ed on Patch 0 through Patch 3. Respective arch maintainers,
reviewers, and committers returned by scripts/get_maintainer.pl have
been cc'ed on the respective arch side changes. Scheduler and CPU Idle
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: abb240f7a2bd14567ab53e602db562bb683391e6 Add linux-next specific
files for 20231212
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202312121926.gc7oytbz-...@intel.com
On Thu, Nov 30, 2023 at 7:31 PM Jiri Slaby (SUSE) wrote:
>
> The last user of virtio_cons_early_init() was dropped in commit
> 7fb2b2d51244 ("s390/virtio: remove the old KVM virtio transport").
>
> So now, drop virtio_cons_early_init() and the logic and headers behind
> too.
>
> Signed-off-by:
Hello:
This list has been migrated to the new vger infrastructure. You should't need
to change anything about how you participate with the list or how you receive
mail.
If something isn't working right, please reach out to helpd...@kernel.org.
Best regards,
Konstantin
[[PATCH 2/2] rtc/alpha: remove legacy rtc driver] On 23/10/2019 (Wed 17:01)
Arnd Bergmann wrote:
> The old drivers/char/rtc.c driver was originally the implementation
> for x86 PCs but got subsequently replaced by the rtc class driver
> on all architectures except alpha.
>
> Move alpha over to
On 23/10/2019 17:01:59+0200, Arnd Bergmann wrote:
> The old drivers/char/rtc.c driver was originally the implementation
> for x86 PCs but got subsequently replaced by the rtc class driver
> on all architectures except alpha.
>
> Move alpha over to the portable driver and remove the old one
> for
The old drivers/char/rtc.c driver was originally the implementation
for x86 PCs but got subsequently replaced by the rtc class driver
on all architectures except alpha.
Move alpha over to the portable driver and remove the old one
for good.
The CONFIG_JS_RTC option was only ever used on SPARC32
On Wed, Oct 23, 2019 at 5:29 AM Mike Rapoport wrote:
>
> These patches convert several architectures to use page table folding and
> remove __ARCH_HAS_4LEVEL_HACK along with include/asm-generic/4level-fixup.h.
Thanks for doing this.
The patches look sane from a quick scan, and it's definitely
diff --git a/arch/parisc/include/asm/page.h
b/arch/parisc/include/asm/page.h
index 93caf17..1d339ee 100644
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -42,48 +42,54 @@ typedef struct { unsigned long pte; } pte_t; /*
either 32 or 64bit */
/* NOTE: even on 64
On Wed, Oct 23, 2019 at 12:28:51PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The generic nommu implementation of page table manipulation takes care of
> folding of the upper levels and does not require fixups.
>
> Simply replace of include/asm-generic/4level-fixup.h with
>
From: Mike Rapoport
parisc has two or three levels of page tables and can use appropriate
pgtable-nopXd and folding of the upper layers.
Replace usage of include/asm-generic/4level-fixup.h and explicit
definitions of __PAGETABLE_PxD_FOLDED in parisc with
include/asm-generic/pgtable-nopmd.h for
From: Mike Rapoport
32-bit version of sparc has three-level page tables and can use
pgtable-nopud and folding of the upper layers.
Replace usage of include/asm-generic/4level-fixup.h with
include/asm-generic/pgtable-nopud.h and adjust page table manipulation
macros and functions accordingly.
From: Mike Rapoport
c6x is a nommu architecture and does not require fixup for upper layers of
the page tables because it is already handled by the generic nommu
implementation.
Replace usage of include/asm-generic/4level-fixup.h with
include/asm-generic/pgtable-nopud.h
Signed-off-by: Mike
Hello!
On 17.10.2019 20:45, Christoph Hellwig wrote:
On ia64 ioremap_nocache fails if attributs don't match. Not other
Attributes?
architectures does this, and we plan to get rid of ioremap_nocache.
So get rid of the special semantics and define ioremap_nocache in
terms of ioremap as no
Acked-by: Guo Ren
On Fri, Oct 18, 2019 at 1:47 AM Christoph Hellwig wrote:
>
> No driver that can be used on csky uses ioremap_cache, and this
> interface has been deprecated in favor of memremap.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/csky/include/asm/io.h | 2 --
>
Ich bringe dir gute Nachrichten. Wir vergeben Kredite zu einem
niedrigen Zinssatz von 2% über einen bestimmten Zeitraum. Müssen Sie
ein Haus, ein Auto kaufen, ein Unternehmen gründen, ein Projekt
finanzieren und vieles mehr? Wir vergeben schnelle und legitime
Kredite sowohl an Privatpersonen als
Hi Christoph,
On Thu, Oct 17, 2019 at 7:53 PM Christoph Hellwig wrote:
> m68k uses __iounmap as the name for an internal helper that is only
> used for some CPU types. Mark it static and give it a better name.
>
> Signed-off-by: Christoph Hellwig
Thanks for your patch!
> ---
On Mon, Apr 23, 2018 at 10:34 AM Ivan Kokshaysky
wrote:
>
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
> > wrote:
> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> > >> On Mon, Apr 16, 2018 at 09:43:42PM
On Thu, 17 Oct 2019, Christoph Hellwig wrote:
> Use the generic ioremap code instead of providing a local version.
> Note that this relies on the asm-generic no-op definition of
> pgprot_noncached.
>
> Signed-off-by: Christoph Hellwig
According to the series introduction E-mail:
Christoph Hellwig wrote:
> __ioremap is always called with the _PAGE_NO_CACHE, so fold the whole
> thing and rename it to ioremap. This allows allows to remove the
^
> special EISA quirk to force _PAGE_NO_CACHE.
Eike
signature.asc
Description:
__ioremap is always called with the _PAGE_NO_CACHE, so fold the whole
thing and rename it to ioremap. This allows allows to remove the
special EISA quirk to force _PAGE_NO_CACHE.
Signed-off-by: Christoph Hellwig
---
arch/parisc/include/asm/io.h | 11 +--
arch/parisc/mm/ioremap.c |
A lot of architectures reuse the same simple ioremap implementation, so
start lifting the most simple variant to lib/ioremap.c. It provides
ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
although that can be overridden by asm/io.h.
Signed-off-by: Christoph Hellwig
Various architectures that use asm-generic/io.h still defined their
own default versions of ioremap_nocache, ioremap_wt and ioremap_wc
that point back to plain ioremap directly or indirectly. Remove these
definitions and rely on asm-generic/io.h instead. For this to work
the backup ioremap_*
No need to indirect iounmap for nios2.
Signed-off-by: Christoph Hellwig
---
arch/nios2/include/asm/io.h | 7 +--
arch/nios2/mm/ioremap.c | 6 +++---
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
index
m68k uses __iounmap as the name for an internal helper that is only
used for some CPU types. Mark it static and give it a better name.
Signed-off-by: Christoph Hellwig
---
arch/m68k/include/asm/kmap.h | 1 -
arch/m68k/mm/kmap.c | 9 ++---
2 files changed, 6 insertions(+), 4
Use the generic ioremap code instead of providing a local version.
Note that this relies on the asm-generic no-op definition of
pgprot_noncached.
Signed-off-by: Christoph Hellwig
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/io.h | 3 --
No need to indirect iounmap for hexagon.
Signed-off-by: Christoph Hellwig
---
arch/hexagon/include/asm/io.h | 7 +--
arch/hexagon/kernel/hexagon_ksyms.c | 2 +-
arch/hexagon/mm/ioremap.c | 2 +-
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git
All MMU-enabled ports have a non-trivial ioremap and should thus provide
the prototype for their implementation instead of providing a generic
one unless a different symbol is not defined. Note that this only
affects sparc32 nds32 as all others do provide their own version.
Also update the
No need to indirect iounmap for sh.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/io.h | 9 ++---
arch/sh/mm/ioremap.c | 4 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index ac0561960c52..1495489225ac
Use the generic ioremap_prot and iounmap helpers.
Signed-off-by: Christoph Hellwig
---
arch/csky/Kconfig | 1 +
arch/csky/include/asm/io.h | 8 +++---
arch/csky/include/asm/pgtable.h | 4 +++
arch/csky/mm/ioremap.c | 45 -
4 files
No driver that can be used on csky uses ioremap_cache, and this
interface has been deprecated in favor of memremap.
Signed-off-by: Christoph Hellwig
---
arch/csky/include/asm/io.h | 2 --
arch/csky/mm/ioremap.c | 7 ---
2 files changed, 9 deletions(-)
diff --git
Use the generic ioremap_prot and iounmap helpers.
Note that the io.h include in pgtable.h had to be removed to not create
an include loop. As far as I can tell there was no need for it to
start with.
Signed-off-by: Christoph Hellwig
---
arch/nds32/Kconfig | 1 +
Use ioremap as the main implemented function, and defined
ioremap_nocache to it as a deprecated alias.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/io.h | 8 ++--
arch/x86/mm/ioremap.c | 8
arch/x86/mm/pageattr.c| 4 ++--
3 files changed, 8 insertions(+), 12
1 - 100 of 2609 matches
Mail list logo
