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
From: Arnd Bergmann
While thinking about the changes to linux/mman.h in
https://lore.kernel.org/all/20240923141943.133551-1-vincenzo.frasc...@arm.com/
I ended up trying to clean up the duplicate definitions in order to
better see what's in there, and then I found a clash between two MAP_*
On Wed, Sep 11, 2024, at 00:45, Charlie Jenkins wrote:
> On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote:
>
> I responded to Arnd in the other thread, but I am still not convinced
> that the solution that x86 and arm64 have selected is the best solution.
>
On Mon, Sep 9, 2024, at 23:22, Charlie Jenkins wrote:
> On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote:
>> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote:
>> The intent is to optionally be able to run a process that keeps higher bits
>> free for t
On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote:
> On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann wrote:
>>
>> It's also unclear to me how we want this flag to interact with
>> the existing logic in arch_get_mmap_end(), which attempts to
>> limit the default mapping t
On Fri, Sep 6, 2024, at 08:14, Lorenzo Stoakes wrote:
> On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote:
>> On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote:
>> > Create a personality flag ADDR_LIMIT_47BIT to support applications
>> > that wish to
#x27; case which is inconsistentn with
the other architectures, so we should probably fix that
part first, possibly moving more of that logic into a
shared implementation.
Arnd
the ucc_mux_set_grant_tsa_bkpt symbol is not exported.
>>
>> Simply export ucc_mux_set_grant_tsa_bkpt.
>>
>> Reported-by: kernel test robot
>> Closes:
>> https://lore.kernel.org/oe-kbuild-all/202409051409.fszn8reo-...@intel.com/
>> Signed-off-by: Herve
On Tue, Sep 3, 2024, at 06:36, Christophe Leroy wrote:
> Hi Arnd,
>
> Please pull the following Freescale Soc Drivers changes for 6.12
>
> There are no conflicts with latest linux-next tree.
Thanks, pulled now.
Arnd
On Wed, Aug 28, 2024, at 13:44, Christophe Leroy wrote:
> Hi Arnd,
>
> Please pull the following Freescale Soc Drivers changes for 6.12:
> - A series from Hervé Codina that bring support for the newer version of
> QMC (QUICC Multi-channel Controller) and TSA (Time Slots Assigner)
neither add nor
remove standard library calls. Not sure if that causes other problems,
e.g. if the calling conventions are different.
Arnd
1UL << CONFIG_PAGE_SHIFT)
> +#define PAGE_MASK (~(PAGE_SIZE - 1))
Since these are now the same across all architectures, maybe we
can just have the PAGE_SIZE definitions a vdso header instead
and include that from asm/page.h.
Including uapi/linux/mman.h may still be problematic on
some architectures if they change it in a way that is
incompatible with compat vdso, but at least that can't
accidentally rely on CONFIG_64BIT or something else that
would be wrong there.
Arnd
On Wed, Aug 7, 2024, at 20:18, Mike Rapoport wrote:
> On Wed, Aug 07, 2024 at 08:58:37AM +0200, Arnd Bergmann wrote:
>> On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
>> >
>> > void __init arch_numa_init(void);
>> > int __init numa_add_memblk(int nod
ikely break a lot of assumptions, so
max(SZ_4K, PAGE_SIZE) is really the same as PAGE_SIZE
in practice.
Arnd
ut is still declared as __init in the header, so it is
still put in that section and discarded after boot.
I was confused by this at first, since the 'early' name
seems to imply that you shouldn't call it once the system
is up, but now you do.
Arnd
tion(+)
>>
>> Patch applied. Thanks.
>
> Great, that was the last of my MODULE_DESCRIPTION patches!!!
>
> There are a few more instances of the warning that Arnd has patches for,
> covering issues that appear in randconfigs that I didn't test.
Are all of your patches in linux-next now, or is there a another
git tree that has them all?
I can send the ones I have left, but I want to avoid duplication.
Arnd
It does look like CONFIG_WERROR did not fail the build before
505d66d1abfb ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro")
as it probably was intended.
Arnd
On Fri, Jul 26, 2024, at 14:33, Michael Ellerman wrote:
> Arnd is no longer actively maintaining Cell, mark it as orphan.
>
> Also drop the dead developerworks link.
>
> Signed-off-by: Michael Ellerman
Acked-by: Arnd Bergmann
The platform contains two separate bits, so we need
On Fri, Jul 26, 2024, at 14:33, Michael Ellerman wrote:
> Jeremy is no longer actively maintaining spufs, mark it as orphan.
>
> Also drop the dead developerworks link.
>
> Signed-off-by: Michael Ellerman
> Acked-by: Jeremy Kerr
Acked-by: Arnd Bergmann
;
>
> Lets add .bss..L* to BSS_MAIN macro to catch those sections into BSS.
>
> Fixes: 9a427556fb8e ("vmlinux.lds.h: catch compound literals into data
> and BSS")
> Signed-off-by: Christophe Leroy
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202404031349.nmkhyuug-...@intel.com/
Applied to the asm-generic tree, thanks!
Arnd
On Wed, Jul 10, 2024, at 14:59, Bartosz Golaszewski wrote:
> On Wed, Jul 10, 2024 at 2:49 PM Arnd Bergmann wrote:
>>
>> On Mon, Jul 1, 2024, at 15:53, Marco Felsch wrote:
>> > The EEPROM_AT24 Kconfig symbol is marked as deprecated. Make use of the
>> > new Kconfi
fconfig | 2 +-
> arch/arm/configs/ixp4xx_defconfig | 2 +-
> arch/arm/configs/keystone_defconfig| 2 +-
> arch/arm/configs/lpc18xx_defconfig | 2 +-
Applied to soc/defconfig, thanks
Arnd
1 - 100 of 1138 matches
Mail list logo
