On Mon, Sep 22, 2025, at 19:05, Nicolas Schichan wrote:
>> On Fri, Sep 19, 2025, at 16:34, Jason Gunthorpe wrote:
>> > On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:
>>
>> I did get an email from Nicolas Schichan (added to Cc here),
>> and he is s
On Fri, Sep 19, 2025, at 16:34, Jason Gunthorpe wrote:
> On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:
>
>> SAM9X7 in 2023 added DDR3 mode with up to 256MB according to
>> the datasheet, no idea why they chose not to support more,
>
> Quite possible the
On Fri, Sep 19, 2025, at 09:17, Geert Uytterhoeven wrote:
> On Thu, 18 Sept 2025 at 15:13, Arnd Bergmann wrote:
>> On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
>> > On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> * Microchip SAM9x7 is the
On Fri, Sep 12, 2025, at 18:49, Nicolas Ferre wrote:
> Arnd,
>
> On 09/09/2025 at 23:23, Arnd Bergmann wrote:
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason.
>
> We have 1GB o
On Wed, Sep 10, 2025, at 03:46, Matthew Wilcox wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>> While removing a feature that is actively used is clearly a regression
>> and not normally done, I expect removing highmem is going to happen
>> at some po
ll 2GB
of RAM. I think in the end this was around the same time
as dove and then armada xp.
> I keep mine up to date, put an LTS kernel on it once a year,
> update to the latest debian sid.
Do you know of any kirkwood machines beside the OpenBlocks A7
that have more than 512MB of RAM?
Arnd
On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason.
>
> O
On Tue, Sep 16, 2025, at 09:00, Willy Tarreau wrote:
> On Tue, Sep 16, 2025 at 08:20:35AM +0200, Arnd Bergmann wrote:
>> > The maintainer of that downstream claims to be able to boot modern
>> > text-mode distros on the GameCube' 24MB, which I find really impressive
On Tue, Sep 16, 2025, at 03:57, Ash Logan wrote:
> On 13/9/25 23:52, Arnd Bergmann wrote:
>
>> Like most other machines, this one is probably fine with a combination
>> of a custom LOWMEM_SIZE setting and using zram-highmem, even if we
>> end up removing support for high
no known users.
Highmem does get in the way, but unless more -mm folks make a strong
argument in favor of removing it all, it's more likely that we'll
go with Willy's suggestion of keeping highmem on page cache (anon
and file mappings) than just keeling zram, and even that would
still work.
Arnd
On Fri, Sep 12, 2025, at 11:32, Andreas Larsson wrote:
> On 2025-09-11 09:53, Arnd Bergmann wrote:
>> On Thu, Sep 11, 2025, at 07:38, Andreas Larsson wrote:
>>>
>>> We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
>>> used in LEON
ill in
this type of workload?
Another type of software that I've seen mentioned struggling with
VMSPLIT_2G is web browsers, but I don't know if that is a similar
problem with a V8/spidermonkey JIT managing its own address space,
or more about general bloat exceeding 2GB of user addresses.
Arnd
mapped into this space instead of executed from the linear
map.
ARnd
v64
kernel on a NOEL-V core on that chip?
Aside from the upcoming SoC and whatever happens to that, what is
the largest LEON Linux memory configuration that you know is used
in production today and still requires kernel updates beyond ~2029?
Arnd
e linux/highmem.h inclusions are probably unnecessary
regardless.
> diff --git a/arch/powerpc/platforms/ps3/system-bus.c
> b/arch/powerpc/platforms/ps3/system-bus.c
> index afbaabf182d0..1f20311ed0c9 100644
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -510,7 +510,7 @@ static void * ps3_alloc_coherent(struct device
> *_dev, size_t size,
> struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
> unsigned long virt_addr;
>
> - flag &= ~(__GFP_DMA | __GFP_HIGHMEM);
> + flag &= ~__GFP_DMA;
> flag |= __GFP_ZERO;
>
> virt_addr = __get_free_pages(flag, get_order(size));
This should never have used __GFP_HIGHMEM since it does not support
32-bit kernels.
Arnd
option.
Unless there is an easy consensus on this on the mailing list,
I would like to lead a discussion session at the kernel summit
in order to get closer to a decision.
Arnd
[1]
https://osseu2025.sched.com/event/25VmZ/32-bit-linux-support-now-and-in-the-future-arnd-bergmann-linaro
[2] h
t; 32-bit architectures.
>
> Signed-off-by: Simon Schuster
Reviewed-by: Arnd Bergmann
VE_SWITCH_STACK
> and RESTORE_SWITCH_STACK.
>
> Signed-off-by: Simon Schuster
Reviewed-by: Arnd Bergmann
_SIGHAND")
> Cc: sta...@vger.kernel.org # linux-5.5+
> Signed-off-by: Simon Schuster
> Reviewed-by: Lorenzo Stoakes
Reviewed-by: Arnd Bergmann
uncation to 32-bit integers occurs on 32-bit architectures.
>
> Signed-off-by: Simon Schuster
> Reviewed-by: Lorenzo Stoakes
Reviewed-by: Arnd Bergmann
)
>Selected by [y]:
>- PPC_8xx [=y] && PPC32 [=y]
>
This is an existing bug on PPC_8xx that got exposed by my patch
but could already be triggered in randconfig builds without
CONFIG_SYSFS.
Arnd
ncern.
> Considering also that we have a bit of space in fsxattr,
> 'fsx_pad[8]', I think it's fine to stick with the current fsxattr
> for now.
You still have to document what you expect to happen with the
padding fields for both the ioctl and the syscall, as the
current behavior of ignoring the padding in the ioctl is not
what we expect for a syscall which tends to check unknown
fields for zero. I don't see a good solution here if you
use the same structure.
Arnd
On Tue, May 13, 2025, at 12:08, Arnd Bergmann wrote:
> On Mon, May 12, 2025, at 20:13, LEROY Christophe wrote:
>> Hi Arnd,
>>
>> Do you know when you will be able to add GCC 15 to
>> https://mirrors.edge.kernel.org/pub/tools/crosstool/ ?
>
> I have to create a
On Mon, May 12, 2025, at 20:13, LEROY Christophe wrote:
> Hi Arnd,
>
> Do you know when you will be able to add GCC 15 to
> https://mirrors.edge.kernel.org/pub/tools/crosstool/ ?
I have to create a new build environment for gcc-15 after I lost
access to the machine I used for the ea
zero"
flags depending on whether it's in the fsx_pad[] field or
after it. This would be fine if it was better documented.
> fsx.fsx_xflags |= FS_XFLAG_NODUMP;
> error = syscall(468, dfd, "./foo", &fsx, 0);
The example still uses the calling conventions from a previous
version.
Arnd
On Wed, Apr 23, 2025, at 22:41, Ben Collins wrote:
> On Wed, Apr 23, 2025 at 03:49:16PM -0500, Arnd Bergmann wrote:
>> Looking at the current code I don't see that any more, so it's
>> possible that now any DMA is allowed even if there is no
>> dma-ranges property a
On Tue, Apr 22, 2025, at 23:10, Ben Collins wrote:
> On Tue, Apr 22, 2025 at 11:25:40AM -0500, Arnd Bergmann wrote:
>> On Tue, Apr 22, 2025, at 10:56, Ben Collins wrote:
>>
>> >> > I'll check on this, but I think it's a seperate issue. The main thing
On Tue, Apr 22, 2025, at 10:56, Ben Collins wrote:
> On Tue, Apr 22, 2025 at 09:59:42AM -0500, Arnd Bergmann wrote:
>>
>> Right, but this could just mean that they end up using SWIOTLB
>> to bounce the high DMA pages or use an IOMMU rather than actually
>> translatin
On Tue, Apr 22, 2025, at 09:12, Ben Collins wrote:
> On Tue, Apr 22, 2025 at 08:34:55AM -0500, Arnd Bergmann wrote:
>>
>> - SoCs that don't set a dma-ranges property in the parent bus
>> are normally still capped to 32 bit DMA. I don't see those
>> pro
uld normally need to be detected based on
the compatible string of the DMA engine itself, not a compile
time setting.
Arnd
On Mon, Mar 24, 2025, at 14:50, Greg Ungerer wrote:
> On 24/3/25 18:02, Arnd Bergmann wrote:
>> On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote:
>>> On 15/3/25 20:59, Arnd Bergmann wrote:
>>
>> Does this fixup work for you?
>
> Yes, this looks good, works fo
On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote:
> Hi Arnd,
>
> On 15/3/25 20:59, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> There is no need to go through the GENERIC_IOMAP wrapper for PIO on
>> nommu platforms, since these always come from PCI I
al on the gcc version
> for s390 only, and make KUNIT_SUPPRESS_BACKTRACE depend on it.
That is probably fine, there are very few users on s390 that build
their own kernels, and they likely all have modern compilers anyway.
I should still send a patch to raise the minimum compiler version to
gcc-8.1, but unfortunately that is not enough here.
Arnd
On Wed, Mar 19, 2025, at 18:30, Nathan Chancellor wrote:
> On Tue, Mar 18, 2025 at 10:13:35PM +0100, Arnd Bergmann wrote:
>> Thanks for the report, I missed that the generic ioport_map() function
>> is missing the PCI_IOBASE macro, we should probably remove that from
>> the as
On Tue, Mar 18, 2025, at 21:39, Nathan Chancellor wrote:
> On Sat, Mar 15, 2025 at 11:59:06AM +0100, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>> diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
>> void __ioread64_copy(void *to, const void __iome
On Tue, Mar 18, 2025, at 14:46, Christophe Leroy wrote:
> Le 18/03/2025 à 11:40, Ioana Ciornei a écrit :
>>
>> Christophe, would you be open to pick up patches for this bus driver
>> through your tree?
>
> Yes its fine for me to take it via my soc fsl subtree unless Arnd
From: Arnd Bergmann
There is no need to go through the GENERIC_IOMAP wrapper for PIO on
nommu platforms, since these always come from PCI I/O space that is
itself memory mapped.
Instead, the generic ioport_map() can just return the MMIO location
of the ports directly by applying the PCI_IO_PA
From: Arnd Bergmann
In previous kernels, there were conflicting definitions for what
ioread64_lo_hi() and similar functions were supposed to do on
architectures with native 64-bit MMIO. Based on the actual usage in
drivers, they are in fact expected to be a pair of 32-bit accesses on
all
From: Arnd Bergmann
All PIO on MIPS platforms is memory mapped, so there is no benefit in
the lib/iomap.c wrappers that switch between inb/outb and readb/writeb
style accessses.
In fact, the '#define PIO_RESERVED 0' setting completely disables
the GENERIC_IOMAP functionality, and th
From: Arnd Bergmann
Alpha has custom definitions for ioread64()/iowrite64(), which now
don't exist in the lib/iomap.c variant. This is an endless source
of build failures, since alpha tries to share a couple of function
declarations.
Change alpha to have its own prototypes that matc
From: Arnd Bergmann
parisc uses custom iomap helpers to map bus specific function calls into
a linear __iomem token, but it tries to use the declarations from the x86
"generic iomap" code.
Untangle the two by duplicating the required declations and dropping
the #include that pulls in
From: Arnd Bergmann
After the previous round of cleanups for asm-generic/io,h on the
ioread64 helpers, I had another look at the architecture specific
versions, especially those that caused build failures in the past.
These are some simplifications that I would like to merge at the same
time
From: Arnd Bergmann
The ioread/iowrite functions on sh only do memory mapped I/O like the
generic verion, and never map onto non-MMIO inb/outb variants, so they
just add complexity. In particular, the use of asm-generic/iomap.h
ties the declaration to the x86 implementation.
Remove the custom
From: Arnd Bergmann
This one is hilariously outdated, it provided a faster downlink over
TV cable for users of analog modems in the 1990s, through an ISA card.
The web page for the userspace tools has been broken for 25 years, and
the driver has only ever seen mechanical updates.
Link:
http
On Tue, Feb 25, 2025, at 11:22, Christian Brauner wrote:
> On Tue, Feb 25, 2025 at 09:02:04AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 24, 2025, at 12:32, Christian Brauner wrote:
>>
>> The ioctl interface relies on the existing behavior, see
>> 0a6eab8bd4e0 ("
TTR/FS_IOC_FSGETXATTR
treats them as optional and just ignores anything it doesn't
understand, while copy_struct_from_user() would treat any unknown
but set bytes as -E2BIG.
The ioctl interface relies on the existing behavior, see
0a6eab8bd4e0 ("vfs: support FS_XFLAG_COWEXTSIZE and get/set of
CoW extent size hint") for how it was previously extended
with an optional flag/word. I think that is fine for the syscall
as well, but should be properly documented since it is different
from how most syscalls work.
Arnd
CC: linux-...@vger.kernel.org
> Signed-off-by: Andrey Albershteyn
I checked the syscall.tbl additions and the ABI to ensure that
it follows the usual guidelines and is portable across
all architectures, this looks good. Thanks for addressing
my v1 comments:
Acked-by: Arnd Bergmann
Disc
the outer barriers,
it seems best to address this at the same time as the internal
eieio() in memcpy_fromio(), provided we agree on removing
those as well.
Arnd
elog here is that
on all other architectures, strcpy_fromio/strcpy_toio are written
to allow prefetching/combining/reordering, while the powerpc
version prevents this in strcpy_fromio for apparently only history
reasons.
Arnd
mips/kernel/syscalls/syscall_o32.tbl
Arnd
also make s390
> __tlb_remove_table() version generic.
>
> Signed-off-by: Qi Zheng
> Reviewed-by: Kevin Brodsky
> Acked-by: Andreas Larsson # sparc
> Acked-by: Alexander Gordeev # s390
Acked-by: Arnd Bergmann # asm-generic
-
> include/asm-generic/pgalloc.h| 45 ++++
> 4 files changed, 45 insertions(+), 58 deletions(-)
Acked-by: Arnd Bergmann # asm-generic
implementation. As far as I can tell, there is very little that is
actually shared between the two anyway.
Arnd
On Sun, Dec 22, 2024, at 03:13, A. Wilcox wrote:
> On Dec 21, 2024, at 3:42 PM, Arnd Bergmann wrote:
>>
>
>
> I can confirm that running 6.12.5 on a P9 host, trying to boot a 6.6
> 32-bit kernel gave me:
>
> Detected RAM kernel at 40 (1330c8c bytes)
>
but that line is a correct
way to allow all of
BACKLIGHT_CLASS_DEVICE=y, FB_NVIDIA=m, FB_NVIDIA_BACKLIGHT=y
BACKLIGHT_CLASS_DEVICE=y, FB_NVIDIA=y, FB_NVIDIA_BACKLIGHT=y
BACKLIGHT_CLASS_DEVICE=m, FB_NVIDIA=m, FB_NVIDIA_BACKLIGHT=y
but disallow the broken
BACKLIGHT_CLASS_DEVICE=m, FB_NVIDIA=y, FB_NVIDIA_BACKLIGHT=y
If you find this line too confusing, can you suggest a different
expression that has the same behavior?
Arnd
From: Arnd Bergmann
There are very few 32-bit machines that support KVM, the main exceptions
are the "Yonah" Generation Xeon-LV and Core Duo from 2006 and the Atom
Z5xx "Silverthorne" from 2008 that were all released just before their
64-bit counterparts.
The main useca
From: Arnd Bergmann
Support for KVM on 32-bit Book III-s implementations was added in 2010
and supports PowerMac, CHRP, and embedded platforms using the Freescale G4
(mpc74xx), e300 (mpc83xx) and e600 (mpc86xx) CPUs from 2003 to 2009.
Earlier 603/604/750 machines might work but would be even
From: Arnd Bergmann
KVM on PowerPC BookE was introduced in 2008 and supported IBM 44x,
Freescale e500v2 (32-bit mpc85xx, QuorIQ P1/P2), e500mc (32bit QorIQ
P2/P3/P4), e5500 (64-bit QorIQ P5/T1) and e6500 (64-bit QorIQ T2/T4).
Support for 44x was dropped in 2014 as it was seeing very little use
From: Arnd Bergmann
KVM support on RISC-V includes both 32-bit and 64-bit host mode, but in
practice, all RISC-V SoCs that may use this are 64-bit:
As of linux-6.13, there is no mainline Linux support for any specific
32-bit SoC in arch/riscv/, although the generic qemu model should work.
The
From: Arnd Bergmann
KVM support on MIPS was added in 2012 with both 32-bit and 64-bit mode
included, but there is only one CPU implementation that actually includes
the required VZ support with the Warrior P5600 core. Support for the
one SoC using this core did not fully get merged into mainline
From: Arnd Bergmann
I've updated my RFC patches based on the feedback, changing mainly
the powerpc code.
I submitted a patch to remove KVM support for x86-32 hosts earlier
this month, but there were still concerns that this might be useful for
testing 32-bit host in general, as that re
On Thu, Dec 19, 2024, at 07:30, Thomas Weißschuh wrote:
> On Wed, Dec 18, 2024 at 05:35:31PM +0100, Arnd Bergmann wrote:
>>
>> > There is precedence in providing 64bit only vDSO functions, for example
>> > __vdso_clock_gettime64() in arm.
>> > I do have a smal
ept
rv32 and sparc32, probably because neither of them have actual
users that are able to test.
Arnd
t; Patch 3 is the second half of the patch provided by Arnd at [1]. It
> could not yet be merged because of the issues fixed by patch 1.
>
> Side note: For the majority of graphics drivers, backlight functionality
> depends on BACKLIGHT_CLASS_DEVICE. In a few cases drivers select the
>
On Fri, Dec 13, 2024, at 11:27, Christophe Leroy wrote:
> Le 13/12/2024 à 11:04, Arnd Bergmann a écrit :
>> diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
>> index 9cba7dbf58dd..24e89dadc74d 100644
>> --- a/arch/powerpc/kernel/head_32.h
>>
On Fri, Dec 13, 2024, at 07:25, Christophe Leroy wrote:
> Le 12/12/2024 à 22:08, Arnd Bergmann a écrit :
>
> So yes it is used on e5500/e6500 but only when they run a 32 bits kernel
> built with CONFIG_PPC_85xx. Isn't it what you want to get rid of with
> this patch ?
>
&
On Thu, Dec 12, 2024, at 19:34, Christophe Leroy wrote:
> Le 12/12/2024 à 13:55, Arnd Bergmann a écrit :
>
> $ git grep KVM_BOOK3S_32_HANDLER
> arch/powerpc/include/asm/processor.h:#ifdef CONFIG_KVM_BOOK3S_32_HANDLER
> arch/powerpc/include/asm/processor.h:#endif /*
> CONFIG_KVM
On Thu, Dec 12, 2024, at 14:20, Andreas Schwab wrote:
> On Dez 12 2024, Arnd Bergmann wrote:
>
>> KVM support on MIPS was added in 2012 with both 32-bit and 32-bit mode
>
> s/32-bit/64-bit/ (once)
>
Fixed now, thanks,
Arnd
>n Thu, Dec 12, 2024, at 17:27, Paolo Bonzini wrote:
> On 12/12/24 13:55, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> There are very few 32-bit machines that support KVM, the main exceptions
>> are the "Yonah" Generation Xeon-LV and Core Duo from
ed this would work the same way as on x86 and arm,
where you can use the 32-bit machine emulation from qemu but
still enable KVM mode.
Arnd
On Fri, Dec 13, 2024, at 04:51, A. Wilcox wrote:
> On Dec 12, 2024, at 6:55 AM, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> I submitted a patch to remove KVM support for x86-32 hosts earlier
>> this month, but there were still concerns that this might be useful
On Thu, Dec 12, 2024, at 19:35, Christophe Leroy wrote:
> Le 12/12/2024 à 13:55, Arnd Bergmann a écrit :
>> From: Arnd Bergmann
>>
>> Support for 64-bit hosts remains unchanged, for both 32-bit and
>> 64-bit guests.
>>
>> arch/powerpc/include/as
ds on'.
I actually have a few more patches like this that I've
been carrying for years now, e.g. one that changes all the
'select I2C' into appropriate dependencies.
Arnd
From: Arnd Bergmann
There are very few 32-bit machines that support KVM, the main exceptions
are the "Yonah" Generation Xeon-LV and Core Duo from 2006 and the Atom
Z5xx "Silverthorne" from 2008 that were all released just before their
64-bit counterparts.
Signed-off-by: Arnd
From: Arnd Bergmann
KVM support on MIPS was added in 2012 with both 32-bit and 32-bit mode
included, but there is only one CPU implementation that actually includes
the required VZ support with the Warrior P5600 core. Support for the
one SoC using this core did not fully get merged into mainline
From: Arnd Bergmann
Support for KVM on 32-bit Book III-s implementations was added in 2010
and supports PowerMac, CHRP, and embedded platforms using the Freescale G4
(mpc74xx), e300 (mpc83xx) and e600 (mpc86xx) CPUs from 2003 to 2009.
Earlier 603/604/750 machines might work but would be even
From: Arnd Bergmann
KVM support on RISC-V includes both 32-bit and 64-bit host mode, but in
practice, all RISC-V SoCs that may use this are 64-bit:
As of linux-6.13, there is no mainline Linux support for any specific
32-bit SoC in arch/riscv/, although the generic qemu model should work.
The
From: Arnd Bergmann
KVM on PowerPC BookE was introduced in 2008 and supported IBM 44x,
Freescale e500v2 (32-bit mpc85xx, QuorIQ P1/P2), e500mc (32bit QorIQ
P2/P3/P4), e5500 (64-bit QorIQ P5/T1) and e6500 (64-bit QorIQ T2/T4).
Support for 44x was dropped in 2014 as it was seeing very little use
From: Arnd Bergmann
I submitted a patch to remove KVM support for x86-32 hosts earlier
this month, but there were still concerns that this might be useful for
testing 32-bit host in general, as that remains supported on three other
architectures. I have gone through those three now and prepared
IDIA
default y
help
Say Y here if you want to control the backlight of your display.
while your patch causes a link failure with
CONFIG_FB_NVIDIA=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
Arnd
arently this originally had a PPC_PMAC
dependency instead of PPC_CHRP, which explains the !PPC_PMAC64
part.
I also found the promotional video from 1996 at
https://www.youtube.com/watch?v=NrvrIEPeSNA .
Arnd
is to either refer to newer standards or
>> left as-is when that's correct.
>>
>> The CHRP code was copied from arch/ppc, and before that it mostly
>> predates git, so the original authorship is largely lost. If anyone
>> wrote any of this code and would like a CREDITS entry just let me know.
>>
>> Signed-off-by: Michael Ellerman
>
> Acked-by: Geert Uytterhoeven
>
Whole series
Acked-by: Arnd Bergmann
qs22_blade
> [2]:
> https://lore.kernel.org/linuxppc-dev/60581044-df82-40ad-b94c-56468007a...@app.fastmail.com
>
> Signed-off-by: Michael Ellerman
Nice clearnup! Whole series
Acked-by: Arnd Bergmann
Everything here looks good, I had a few comments, but those
are all for follow-up work.
Arnd
On Thu, Nov 14, 2024, at 13:51, Michael Ellerman wrote:
> Some of the __do_xxx() defines do nothing useful, they just existed to
> make the previous hooking macros work. So remove them.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Arnd Bergmann
> @@ -607,27 +600,27 @@ st
On Thu, Nov 14, 2024, at 13:51, Michael Ellerman wrote:
> Now that PPC_INDIRECT_MMIO is removed, PCI_FIX_ADDR does nothing, so
> remove it.
>
> Signed-off-by: Michael Ellerman
Acked-by: Arnd Bergmann
> static inline unsigned char __raw_readb(const volatile voi
eoff to CREDITS.
>
> Signed-off-by: Michael Ellerman
> ---
Reviewed-by: Arnd Bergmann
(cc netdev)
This means we can also move drivers/net/sungem_phy.c back
into drivers/net/ethernet/sun/ since it is no longer shared
infrastructure.
This was an early bit of MII/PHY library code that alon
rnv side only uses parts of PPC_INDIRECT_PIO,
so there is a good chance of simplifying that code further if
we want to.
This bit looks great so far.
Reviewed-by: Arnd Bergmann
d users.
>
> Provide generic versions in to make these
> helpers more easily usable.
>
I've applied this to the asm-generic tree now.
Thanks for the cleanup!
Arnd
-patching.h and add an empty
> header in asm-generic for architectures that do not support text patching.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Acked-by: Arnd Bergmann
hys/phys_to_virt. Most architectures define one
of the two pairs in terms of the other, which leads to
confusion with header include order.
Arnd
On Tue, Oct 8, 2024, at 15:48, Jakub Kicinski wrote:
> Konstantin reports the maintainer's address bounces.
> There is no other maintainer and the driver is quite old.
> There is a good chance nobody is using this driver any more.
> Let's try to remove it completely, we can revert it back in
> if s
way that iowrite64/ioread64/ioread32 do,
but actually using them on x86 port I/O (from pci_iomap or
ioport_map) would lead to a NULL pointer dereference.
Arnd
e lines, I would change lib/Makefile to build
this file unconditionally even on architectures that don't
set CONFIG_HAS_IOMEM. Again, strengthening the driver dependencies
is good, but it feels like a distraction here when we just need the
common implementation to be available.
Arnd
On Thu, Sep 26, 2024, at 08:46, David Hildenbrand wrote:
> On 25.09.24 23:06, Arnd Bergmann wrote:
>
> The first, uncontroversial step could indeed be to make
> MAP_UNINITIALIZED a nop, but still leave the definitions in mman.h etc
> around.
>
> This is the same we did with
On Thu, Sep 26, 2024, at 09:21, Helge Deller wrote:
> On 9/25/24 23:06, Arnd Bergmann wrote:
>> -/* not used by linux, but here to make sure we don't clash with OSF/1
>> defines */
>> -#define _MAP_HASSEMAPHORE 0x0200
>> -#define _MAP_INHERIT0x0400
>&g
From: Arnd Bergmann
MAP_UNINITIALIZED was added back in 2009 for NOMMU kernels, specifically
for blackfin, which is long gone. MAP_HUGE_SHIFT/MAP_HUGE_MASK were
added in 2012 for architectures supporting hugepages, which at the time
did not overlap with the ones supporting NOMMU.
Adding the
From: Arnd Bergmann
These two architectures each have their own set of MAP_* flags, like
powerpc, mips and others do. In addition, the msync() flags are also
different, here both define the same flags but in a different order.
Finally, alpha also has a custom MADV_DONTNEED flag for madvise
From: Arnd Bergmann
mips and xtensa have almost the same asm/mman.h, aside from an
unintentional difference in MAP_UNINITIALIZED that has no effect in
practice.
Now that the MAP_* flags are moved out of asm-generic/mman-common.h,
the only difference from the its contents and the mips/xtensa
From: Arnd Bergmann
powerpc and sparc include asm-generic/mman-common.h to get the MAP_* flags
0x008000 through 0x400, but those flags are all different on alpha,
mips, parisc and xtensa.
Add duplicate definitions for these along with the MAP_* flags for 0x100
through 0x4000 that are
From: Arnd Bergmann
All but four architectures use asm-generic/mman-common.h, and the
differences between these are mostly accidental. Rearrange them
slightly to make it possible to 'vimdiff' them to see the actual
relevant differences:
- Move MADV_HWPOISON/MADV_SOFT_OFFLINE to the
1 - 100 of 1159 matches
Mail list logo
