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
On Tue, Apr 22, 2025, at 04:49, Ben Collins wrote:
> On 64-bit QorIQ platforms like T4240, the CPU supports 40-bit addressing
> and memory configurations > 64GiB. The fsldma driver is limiting itself
> to only 64GiB in all Elo configurations.
>
> Setup fsldma driver to make use of the full 40-bit a
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
On Fri, Mar 21, 2025, at 18:05, Guenter Roeck wrote:
> On 3/13/25 04:43, Alessandro Carminati wrote:
>
> gcc 10.3.0 and later do not have this problem. I also tried s390 builds
> with gcc 9.4
> and 9.5 but they both crash for unrelated reasons.
>
> If this is a concern, the best idea I have is to
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 tells
> different. But be
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 ("
On Mon, Feb 24, 2025, at 12:32, Christian Brauner wrote:
> On Fri, Feb 21, 2025 at 08:15:24PM +0100, Amir Goldstein wrote:
>> On Fri, Feb 21, 2025 at 7:13 PM Darrick J. Wong wrote:
>> > > @@ -23,6 +23,9 @@
>> > > #include
>> > > #include
>> > > #include
>> > > +#include
>> > > +#include
>
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
On Wed, Jan 29, 2025, at 12:14, Segher Boessenkool wrote:
> On Wed, Jan 29, 2025 at 10:45:10AM +0100, Julian Vetter wrote:
>> Remove the eieio() calls in IO functions for PowerPC. While other
>> architectures permit prefetching, combining, and reordering, the eieio()
>> calls on PowerPC prevent suc
On Tue, Jan 28, 2025, at 16:34, Christophe Leroy wrote:
> Le 28/01/2025 à 16:24, Christophe Leroy a écrit :
>> Le 28/01/2025 à 16:07, Julian Vetter a écrit :
>>> With 'ppc' I was refering to 'include/asm-ppc/io.h'. But you're right,
>>> when going back a bit, in the 'include/asm-powerpc/io.h' there
On Thu, Jan 9, 2025, at 18:45, Andrey Albershteyn wrote:
>
> arch/alpha/kernel/syscalls/syscall.tbl | 2 +
> arch/m68k/kernel/syscalls/syscall.tbl | 2 +
> arch/microblaze/kernel/syscalls/syscall.tbl | 2 +
> arch/parisc/kernel/syscalls/syscall.tbl | 2 +
> arch/powerpc/kern
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
On Fri, Jan 3, 2025, at 13:44, Johannes Berg wrote:
> On Fri, 2025-01-03 at 07:44 +0100, Philipp Hortmann wrote:
>>
>> One of my big fears is the hand over to the next generation maintainers
>> and developers. The less code and the less exceptions due to old
>> interfaces the easier it will be.
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)
>
On Sun, Dec 22, 2024, at 21:15, Helge Deller wrote:
> On 12/22/24 17:09, Thomas Zimmermann wrote:
+ depends on BACKLIGHT_CLASS_DEVICE=y ||
BACKLIGHT_CLASS_DEVICE=FB_NVIDIA
>>>
>>> Seems wrong. BACKLIGHT_CLASS_DEVICE is of type tristate.
>>> There are more of those, please check.
>>
>
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
On Wed, Dec 18, 2024, at 16:46, Thomas Weißschuh wrote:
> On Wed, Dec 18, 2024 at 03:08:28PM +, Conor Dooley wrote:
>> On Mon, Dec 16, 2024 at 03:10:03PM +0100, Thomas Weißschuh wrote:
>> Might be a clang thing, allmodconfig with clang doesn't build either.
>
> The proposed generic storage inf
rsion
in my randconfig test tree and have replaced it with yours now
to do some more regression testing, but I expect this to be fine.
Reviewed-by: Arnd Bergmann
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
On Fri, Dec 13, 2024, at 09:42, A. Wilcox wrote:
>
> As for Power: I will admit I haven’t tested lately, but well into
> the 5 series (5.4, at least), you couldn’t boot a ppc32 Linux kernel
> on any 64-bit capable hardware. It would throw what I believe was an
> alignment error while quiescing Ope
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
On Thu, Dec 12, 2024, at 19:44, Helge Deller wrote:
> On 12/12/24 11:04, Thomas Zimmermann wrote:
>> Do not select BACKLIGHT_CLASS_DEVICE from FB_BACKLIGHT. The latter
>> only controls backlight support within fbdev core code and data
>> structures.
>>
>> Make fbdev drivers depend on BACKLIGHT_CLAS
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
On Tue, Dec 10, 2024, at 15:09, Thomas Zimmermann wrote:
> Do not select BACKLIGHT_CLASS_DEVICE from FB_BACKLIGHT. The latter
> only controls backlight support within fbdev core code and data
> structures.
>
> Make fbdev drivers depend on BACKLIGHT_CLASS_DEVICE and let users
> select it explicitly.
On Thu, Nov 14, 2024, at 14:11, Michael Ellerman wrote:
>
> -config ADB_MACIO
> - bool "Include MacIO (CHRP) ADB driver"
> - depends on ADB && PPC_CHRP && !PPC_PMAC64
The dependency looked weird to me, so I had to look up
what that thing is. Apparently this originally had a PPC_PMAC
depen
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
On Wed, Oct 23, 2024, at 05:36, Christoph Hellwig wrote:
> page_to_phys is duplicated by all architectures, and from some strange
> reason placed in where it doesn't fit at all.
>
> phys_to_page is only provided by a few architectures despite having a lot
> of open coded users.
>
> Provide gene
-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
On Wed, Oct 9, 2024, at 11:43, Christoph Hellwig wrote:
> page_to_phys is duplicated by all architectures, and from some strange
> reason placed in where it doesn't fit at all.
>
> phys_to_page is only provided by a few architectures despite having a lot
> of open coded users.
>
> Provide generic
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
On Tue, Oct 8, 2024, at 11:46, Christoph Hellwig wrote:
> On Tue, Oct 08, 2024 at 09:50:09AM +0200, Julian Vetter wrote:
>> lib/iomap_copy.c | 127 +++
>
> On top of the previous comments: this really should be iomem_copy.c
> instead.
Right, I suggested
On Tue, Oct 8, 2024, at 07:50, Julian Vetter wrote:
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 80de699bf6af..f14655ed4d9d 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -102,6 +102,12 @@ static inline void log_post_read_mmio(u64 val, u8
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.
> The solution of defaulting
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
On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote:
> Create a personality flag ADDR_LIMIT_47BIT to support applications
> that wish to transition from running in environments that support at
> most 47-bit VAs to environments that support larger VAs. This
> personality can be set to cause all all
On Thu, Sep 5, 2024, at 07:31, Christophe Leroy wrote:
> Le 05/09/2024 à 09:22, Herve Codina a écrit :
>> When TSA is compiled as module the following error is reported:
>>"ucc_mux_set_grant_tsa_bkpt" [drivers/soc/fsl/qe/tsa.ko] undefined!
>>
>> Indeed, the ucc_mux_set_grant_tsa_bkpt symbol is
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) found
> on MPC 8
On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
>> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
>> >
>> > Is there a compiler flag that could be used to disable the generation of
>> > calls
>> > to me
On Tue, Aug 27, 2024, at 10:40, Jason A. Donenfeld wrote:
> I don't love this, but it might be the lesser of evils, so sure, let's
> do it.
>
> I think I'll combine these header fixups so that the whole operation is
> a bit more clear. The commit is still pretty small. Something like
> below:
>
> F
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
On Wed, Aug 7, 2024, at 17:17, Stewart Hildebrand wrote:
> In this context, "small" is defined as max(SZ_4K, PAGE_SIZE).
>
> This series sets the default minimum resource alignment to
> max(SZ_4K, PAGE_SIZE) for memory BARs. In preparation, it makes an
> optimization and addresses some corner cases
On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Until now arch_numa was directly translating firmware NUMA information
> to memblock.
I get a link time warning from this:
WARNING: modpost: vmlinux: section mismatch in reference:
numa_set_cpumask+0
On Fri, Aug 2, 2024, at 16:27, Jeff Johnson wrote:
> On 8/2/2024 6:15 AM, Herbert Xu wrote:
>> On Thu, Jul 18, 2024 at 06:14:18PM -0700, Jeff Johnson wrote:
>>> Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
>>> description is missing"), a module without a MODULE_DESCRIPTION()
On Mon, Jul 29, 2024, at 11:35, Geert Uytterhoeven wrote:
>
>> + /kisskb/src/kernel/fork.c: error: #warning clone3() entry point is
>> missing, please fix [-Werror=cpp]: => 3072:2
>
> sh4-gcc13/se{7619,7750}_defconfig
> sh4-gcc13/sh-all{mod,no,yes}config
> sh4-gcc13/sh-defconfig
> sparc64-gcc5/s
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
On Fri, Jul 12, 2024, at 07:51, Christophe Leroy wrote:
> Commit 9a427556fb8e ("vmlinux.lds.h: catch compound literals into
> data and BSS") added catches for .data..L* and .rodata..L* but missed
> .bss..L*
>
> Since commit 5431fdd2c181 ("ptrace: Convert ptrace_attach() to use
> lock guards") the f
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
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 Kconfig symbol to select the I2C EEPROM driver support.
>
> Signed-off-by: Marco Felsch
> ---
> arch/arm/configs/aspeed_g4_defconfig | 2 +-
> arch/arm/configs/aspe
On Sat, Jun 29, 2024, at 19:46, Guenter Roeck wrote:
> Building parisc:allmodconfig ... failed
> --
> Error log:
> In file included from fs/notify/fanotify/fanotify_user.c:14:
> include/linux/syscalls.h:248:25: error: conflicting types for
> 'sys_fanotify_mark'; have 'long int(int, u
On Thu, Jun 27, 2024, at 14:49, Naresh Kamboju wrote:
> The powerpc builds failed on Linux next-20240626 tag due to following
>
> arch/powerpc/kernel/nvram_64.c:79:17: error: initialization of 'void
> (*)(struct kmsg_dumper *, enum kmsg_dump_reason, const char *)' from
> incompatible pointer
From: Arnd Bergmann
Both of these architectures require u64 function arguments to be
passed in even/odd pairs of registers or stack slots, which in case of
sync_file_range would result in a seven-argument system call that is
not currently possible. The system call is therefore incompatible with
From: Arnd Bergmann
The unusual function calling conventions on SuperH ended up causing
sync_file_range to have the wrong argument order, with the 'flags'
argument getting sorted before 'nbytes' by the compiler.
In userspace, I found that musl, glibc, uclibc and strace a
1 - 100 of 1134 matches
Mail list logo
