Adding ben and the linuxppc list.
Context: pata_macio initialization now fails as we enforce that the
segment size is set properly.
On Wed, May 15, 2024 at 04:52:29PM -0700, Guenter Roeck wrote:
> pata_macio_common_init() Calling ata_host_activate() with limit 65280
> ...
> max_segment_size is
On Tue, Feb 20, 2024 at 02:32:53PM -0600, Maxwell Bland wrote:
> Present non-uniform use of __vmalloc_node and __vmalloc_node_range makes
> enforcing appropriate code and data seperation untenable on certain
> microarchitectures, as VMALLOC_START and VMALLOC_END are monolithic
> while the use of
On Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote:
> Well, better compression ratios for one :)
>
> I think a long time ago there were complaints that zsmalloc had higher
> latency than zbud/z3fold, but since then a lot of things have changed
> (including nice compaction optimization
On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
> >
> > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > well.
>
> Makes sense to me. Should we do the same thing to zbud? We probably
> have
On Sun, Jan 07, 2024 at 10:39:07AM +0800, Huacai Chen wrote:
> > Do you mean that LoongArch32 does not support double-precision FP in
> > hardware?
> > At least both of the consumers in this series use double-precision, so my
> > first
> > thought is that LoongArch32 could not select
Looks good:
Reviewed-by: Christoph Hellwig
> Signed-off-by: Samuel Holland
Looks good:
Reviewed-by: Christoph Hellwig
Thanks for all the great documentation!
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> Actually tracking all possibly-FPU-tainted functions and their call sites is
> probably possible, but a much larger task.
I think objtool should be able to do that reasonably easily, it already
does it for checking section where
On Mon, Dec 11, 2023 at 10:12:27AM -0600, Samuel Holland wrote:
> On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
>
> Unfortunately, not all of the relevant options can be no-prefixed:
Ok. That is another good argument for having the obj-fpu += syntax
I proposed. You might need
Looks good:
Reviewed-by: Christoph Hellwig
> obj-$(CONFIG_TEST_FPU) += test_fpu.o
> -CFLAGS_test_fpu.o += $(FPU_CFLAGS)
> +test_fpu-y := test_fpu_glue.o test_fpu_impl.o
> +CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
Btw, I really wonder if having a
modname-fpu += foo.o
syntax in kbuild wouldn't be preferable to this. Of coure that
> +#ifdef __riscv_f
> +
> +#define kernel_fpu_begin() \
> + static_assert(false, "floating-point code must use a separate
> translation unit")
> +#define kernel_fpu_end() kernel_fpu_begin()
> +
> +#else
> +
> +void kernel_fpu_begin(void);
> +void kernel_fpu_end(void);
> +
> +#endif
I'll
Looks good:
Reviewed-by: Christoph Hellwig
> export the CFLAGS adjustments.
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:36PM -0800, Samuel Holland wrote:
> LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
> asm/fpu.h, so it only needs to add kernel_fpu_available() and export
> the CFLAGS adjustments.
Looks good:
Reviewed-by: Christoph Hellwig
options work so that if you add a
no-prefixed version of the option later it transparently gets removed?
Except for that:
Reviewed-by: Christoph Hellwig
> + * linux/arch/arm64/include/asm/fpu.h
Same comment as for arm here. Except for that:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:33PM -0800, Samuel Holland wrote:
> Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
> tree, use it instead of duplicating the flags here.
Looks good:
Reviewed-by: Christoph Hellwig
t of date.
Except for that:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Nov 22, 2023 at 10:22:11AM -0500, Peter Xu wrote:
> The other reason I feel like hugepd may or may not be further developed for
> new features like large folio is that I saw Power9 started to shift to
> radix pgtables, and afaics hugepd is only supported in hash tables
> (hugepd_ok()).
> - select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) ||
> (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
> + select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG
> + select DRM_AMD_DC_FP if PPC64 && ALTIVEC
> + select DRM_AMD_DC_FP if RISCV && FPU
> +
On Tue, Nov 21, 2023 at 10:59:35AM -0500, Peter Xu wrote:
> > What prevents us from ever using hugepd with file mappings? I think
> > it would naturally fit in with how large folios for the pagecache work.
> >
> > So keeping this check and generalizing it seems like the better idea to
> > me.
>
On Wed, Nov 15, 2023 at 08:29:02PM -0500, Peter Xu wrote:
> Hugepd format is only used in PowerPC with hugetlbfs. In commit
> a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> file-backed mappings"), we added a check to fail gup-fast if there's
> potential risk of violating GUP
Looks good:
Reviewed-by: Christoph Hellwig
> + /* set 64-bit DMA mask and coherent DMA mask */
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
The comment is a bit silly :)
> + if (ret)
> + return ret;
Also no need to check the return value when setting a 64-bit mask,
but I guess it desn't hurt here.
On Thu, Aug 10, 2023 at 08:09:27AM +0800, Ming Lei wrote:
> 1) some archs support 'nr_cpus=1' for kdump kernel, which is fine, since
> num_possible_cpus becomes 1.
>
> 2) some archs do not support 'nr_cpus=1', and have to rely on
> 'max_cpus=1', so num_possible_cpus isn't changed, and kernel just
Thanks,
applied to the dma-mapping tree for 6.6.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
> Thanks for your patch, which is now commit 322dbe898f82fd8a
> ("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
> esmil/jh7100-dmapool.
Well, something is wrong with that branch then, and this series still
needs more work, and should eventually be merged through the dma-mapping
This should be fixed by
"btrfs: fix the uptodate assert in btree_csum_one_bio"
on the list.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
ameter from GUP altogether.
>
> Acked-by: David Hildenbrand
> Acked-by: Dennis Dalessandro (for
> qib)
> Signed-off-by: Lorenzo Stoakes
Looks good:
Reviewed-by: Christoph Hellwig
Thanks,
applied to the dma-mapping tree for 6.4.
On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote:
> >
> > Is patch a 6.3 candidate or should all of it go into 6.4?
>
> Please leave it for 6.4, as corresponding MIPS arch part will be a part of
> 6.4.
Ok. I'll really need review from the MIPS and drivers/of/ maintainers,
through.
> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> + dma_cache_wback(paddr, size);
> +}
>
> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
> +{
> + dma_cache_inv(paddr, size);
> }
> +static inline void
On Thu, Mar 23, 2023 at 09:07:31PM +, Jiaxun Yang wrote:
>
>
> > 2023年3月23日 07:29，Christoph Hellwig 写道：
> >
> > The series looks fine to me. How should we merge it?
>
> Perhaps go through dma-mapping tree?
Is patch a 6.3 candidate or should all of it go into 6.4?
The series looks fine to me. How should we merge it?
> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
Doesn't powerpc need to select CONFIG_ARCH_DMA_DEFAULT_COHERENT now,
or even better should be doing that in the patch adding that
symbol?
In fact I wonder if adding CONFIG_ARCH_DMA_DEFAULT_COHERENT and removing
> +config ARCH_DMA_DEFAULT_COHERENT
> + bool
Please add a comment here explaining when an architecture should
ѕelect this symbol.
On Thu, Feb 23, 2023 at 11:36:41AM +, Jiaxun Yang wrote:
> dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
> but only decleared when any of non-coherent options is enabled in
> dma-map-ops.h.
Overly lone line here.
> }
> #else
> +#define dma_default_coherent
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
On Tue, Feb 21, 2023 at 12:46:11PM +, Jiaxun Yang wrote:
> Provide a kconfig option to allow arches to manipulate default
> value of dma_default_coherent in Kconfig.
I don't see the win over just doing this by setting dma_default_coherent
in the early boot code.
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
> dma_default_coherent can be useful for determine default coherency
> even on arches without noncoherent support.
How?
On Tue, Feb 21, 2023 at 12:46:07PM +, Jiaxun Yang wrote:
> As now we are always managing DMA coherence on per dev bias,
> there is no need to have such option. And it's not selected
> by any platform.
I think the real point here is that this is dead code, so it can
obviously go away, but:
>
> +/**
> + * vm_account_init - Initialise a new struct vm_account.
> + * @vm_account: pointer to uninitialised vm_account.
> + * @task: task to charge against.
> + * @user: user to charge against. Must be non-NULL for VM_ACCOUNT_USER.
> + * @flags: flags to use when charging to vm_account.
> + *
>
ps3vram iterates over the bio one segment, that is page aligned and max
page sized chunk, a time. Because of that there is no point in
calling bio_split_to_limits, or explicitly setting the default limits
that are only used by bio_split_to_limits.
Signed-off-by: Christoph Hellwig
---
drivers
I would have split this into one patch that adds the new
zap_vma_pages helper, and one to remove zap_page_range to split the
separate changes.
But the overall result looks fine, so feel free to add:
Reviewed-by: Christoph Hellwig
to this or the split patches.
> unsigned long size = vma->vm_end - vma->vm_start;
>
> if (vma_is_special_mapping(vma, vdso_info[VDSO_ABI_AA64].dm))
> - zap_page_range(vma, vma->vm_start, size);
> + zap_vma_page_range(vma, vma->vm_start, size);
> #ifdef
ps3_system_bus_type is only used inside of system-bus.c, so remove
the external declaration and the very outdated comment next to it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/ps3.h | 4
arch/powerpc/platforms/ps3/system-bus.c | 2 +-
2 files changed, 1
Thanks, this is long overdue!
Acked-by: Christoph Hellwig
> +#if IS_ENABLED(CONFIG_EEH) && IS_ENABLED(CONFIG_VFIO_IOMMU_SPAPR_TCE)
> #include
> #endif
>
> @@ -689,7 +689,7 @@ void vfio_pci_core_close_device(struct vfio_device
> *core_vdev)
> vdev->sriov_pf_core_dev->vf_token->users--;
>
On Mon, Aug 22, 2022 at 01:40:23PM +1000, Michael Ellerman wrote:
> Randy Dunlap writes:
> > drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> > This is an inline function on powerpc which references
> > cpu_smallcore_map.
> >
> > Fixes: 425752c63b6f ("powerpc: Detect the presence
Miguel,
handwaiving and pointing to git trees is not how Linux development
works. Please make sure all the patches go to the relevant lists
and maintainers first, and actually do have ACKs.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Sun, Jul 17, 2022 at 12:34:52PM +0900, Stafford Horne wrote:
> The generic pci.h header now only provides a definition of
> pci_get_legacy_ide_irq which is used by architectures that support PNP.
> Of the architectures that use asm-generic/pci.h this is only x86.
Please move this into a
On Wed, Jun 29, 2022 at 09:38:00AM +1200, Michael Schmitz wrote:
> That's one of the 'liberties' I alluded to. The reason I left these in is
> that I'm none too certain what device feature the DMA API uses to decide a
> device isn't cache-coherent.
The DMA API does not look at device features at
On Wed, Jun 29, 2022 at 11:09:00AM +1200, Michael Schmitz wrote:
> And all SCSI buffers are allocated using kmalloc? No way at all for user
> space to pass unaligned data?
Most that you will see actually comes from the page allocator. But
the block layer has a dma_alignment limit, and when
On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
> The watchdog_mutex is exported to allow some variable to be changed under
> its protection and prevent any conflict.
> The lockup_detector_reconfigure() function is exported and is expected to
> be called under the protection of
On Fri, Jun 24, 2022 at 10:50:33AM +0530, Anshuman Khandual wrote:
> > On most architectures this should be const now, only very few ever
> > modify it.
>
> Will make it a 'static const pgprot_t protection_map[16] __ro_after_init'
> on platforms that do not change the protection_map[] even during
On Fri, Jun 24, 2022 at 10:13:13AM +0530, Anshuman Khandual wrote:
> vm_get_page_prot(), in order for it to be reused on platforms that do not
> require custom implementation. Finally, ARCH_HAS_VM_GET_PAGE_PROT can just
> be dropped, as all platforms now define and export vm_get_page_prot(), via
>
Looks good:
Reviewed-by: Christoph Hellwig
On Fri, Jun 24, 2022 at 10:13:29AM +0530, Anshuman Khandual wrote:
index d466ec670e1f..f976580500b1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -288,6 +288,26 @@ static pmd_t __maybe_unused early_dtb_pmd[PTRS_PER_PMD]
> __initdata __aligned(PAG
> #define early_pg_dir
Looks good:
Reviewed-by: Christoph Hellwig
On Fri, Jun 24, 2022 at 10:13:15AM +0530, Anshuman Khandual wrote:
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Jun 14, 2022 at 08:18:14PM +0200, Sebastian Andrzej Siewior wrote:
> Disable the unused softirqs stacks on PREEMPT_RT to safe some memory and
s/safe/save/
Did you verify that all architectures actually provide a ioremap_prot
prototype?
The header situation for ioremap* is a mess unfortunately.
As pointed out last time: uio is the wrong interface to expose sram,
and any kind of ioremap is the wrong way to map it.
UIO seems like the wrong kind of interface for this. Why isn't this
a simple character device?
On Tue, Jun 14, 2022 at 08:45:25PM +1000, Michael Ellerman wrote:
> Wang Wenhu writes:
> > The function ioremap_coherent may be called by modules such as
> > fsl_85xx_cache_sram. So export it for access in other modules.
>
> ioremap_coherent() is powerpc specific, and only has one other caller,
On Fri, Jun 10, 2022 at 02:56:08PM -0700, Dongli Zhang wrote:
> Since this patch file has 200+ lines, would you please help clarify what does
> 'this' indicate?
This indicates that any choice of a different swiotlb pools needs to
be hidden inside of ѕwiotlb. The dma mapping API already provides
s...@kernel.org>, Will Deacon , Masahiro Yamada
, Jarkko Sakkinen , Sami Tolvanen
, "Naveen N. Rao" , Marco
Elver , Kees Cook , Steven Rostedt
, Nathan Chancellor , "Russell King
\(Oracle\)" , Mark Brown ,
Borislav Petkov , Alexander Egorenkov ,
Thomas Bogendoerfer , Parisc List
,
On Wed, Jun 08, 2022 at 05:55:49PM -0700, Dongli Zhang wrote:
> @@ -109,19 +110,25 @@ int xen_swiotlb_fixup(void *buf, unsigned long nslabs,
> bool high)
> int rc;
> unsigned int order = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT);
> unsigned int i, dma_bits = order + PAGE_SHIFT;
On Wed, Jun 08, 2022 at 05:55:53PM -0700, Dongli Zhang wrote:
> +#define slot_addr(start, idx)((start) + \
> + (((unsigned long)idx) << IO_TLB_SHIFT))
Please just convert it to an inline function.
On Wed, Jun 08, 2022 at 05:55:52PM -0700, Dongli Zhang wrote:
> /* Unique numbering for virtio devices. */
> @@ -241,6 +243,12 @@ static int virtio_dev_probe(struct device *_d)
> u64 device_features;
> u64 driver_features;
> u64 driver_features_legacy;
> + struct device
This should be handled under the hood without the driver even knowing.
All this really needs to be hidden under the hood.
On Wed, Jun 08, 2022 at 05:55:47PM -0700, Dongli Zhang wrote:
> @@ -109,6 +109,7 @@ struct io_tlb_mem {
> } *slots;
> };
> extern struct io_tlb_mem io_tlb_default_mem;
> +extern struct io_tlb_mem io_tlb_high_mem;
Tis should not be exposed.
> +extern bool swiotlb_high_active(void);
And
On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrot
On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > Can you send me the full dmesg and the content of
> > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
>
> Sure thi
Can you send me the full dmesg and the content of
/sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
Thanks!
untangle the state transition failure from the lack of methods to
improve the debugging output in case it will happen ever again.
Signed-off-by: Christoph Hellwig
---
drivers/pci/pcie/err.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers
On Tue, May 31, 2022 at 04:16:19PM +1000, Michael Ellerman wrote:
> I was thinking of doing it in C, similar to the way arm64 handles it.
>
> Something like below. It means we always double the stack size when
> KASAN is enabled. I think it's preferable, as it will always work
> regardless of
On Fri, May 20, 2022 at 02:06:56PM +0530, Maninder Singh wrote:
> kallsyms functionality depends on KSYM_NAME_LEN directly.
> but if user passed array length lesser than it, sprintf
> can cause issues of buffer overflow attack.
>
> So changing *sprint* and *lookup* APIs in this patch set
> to
csum_and_copy_from_user and csum_and_copy_to_user are exported by
a few architectures, but not actually used in modular code. Drop
the exports.
Signed-off-by: Christoph Hellwig
---
arch/alpha/lib/csum_partial_copy.c | 1 -
arch/m68k/lib/checksum.c | 2 --
arch/powerpc/lib
On Mon, Apr 04, 2022 at 07:05:44AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series tries to clean up the swiotlb initialization, including
> that of swiotlb-xen. To get there is also removes the x86 iommu table
> infrastructure that massively obsfucates the init
On Wed, Apr 06, 2022 at 08:25:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/powerpc/platforms/pseries/svm.c
> > b/arch/powerpc/platforms/pseries/svm.c
> > index c5228f4969eb2..3b4045d508ec8 100644
> > --- a/arch/powerpc/platforms/pseries/svm.c
> > +++
gets pulled in by all drivers using the DMA API.
Remove x86 internal variables and unnecessary includes from it.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/dma-mapping.h | 11 ---
arch/x86/include/asm/iommu.h | 2 ++
2 files changed, 2 insertions(+), 11 deletions
No users left.
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 2 --
kernel/dma/swiotlb.c| 77 +++--
2 files changed, 20 insertions(+), 59 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7b50c82f84ce9
based value with this patch, but that is fine as the
2MB value used in Xen before was just an optimization and is not the
hard lower bound.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 21 +++---
arch/x86/include/asm/xen/page.h | 5
To shared more code between swiotlb and xen-swiotlb, offer a
swiotlb_init_remap interface and add a remap callback to
swiotlb_init_late that will allow Xen to remap the buffer the
buffer without duplicating much of the logic.
Signed-off-by: Christoph Hellwig
---
arch/x86/pci/sta2x11-fixup.c
Let the caller chose a zone to allocate from. This will be used
later on by the xen-swiotlb initialization on arm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
arch/x86/pci/sta2x11-fixup.c | 2 +-
include/linux/swiotlb.h | 2 +-
kernel/dma/swiotlb.c | 7
on x86 (arm and arm64
never supported that), but this interface will be restored shortly.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/init.c | 6 +
arch/arm64/mm/init.c | 6 +
arch/ia64/mm/init.c| 4 +--
arch/mips/cavium-octeon
1 - 100 of 2608 matches
Mail list logo
