Looks good,
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
put_user() along the same lines as __get_user()/get_user()
Looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
normal access_ok()
> though, because on x86 that contains a WARN_ON_IN_IRQ() check that cannot
> be used inside of NMI context while tracing.
>
> Suggested-by: Al Viro
> Suggested-by: Christoph Hellwig
> Link: https://lore.kernel.org/lkml/ygsukcxgr7r4n...@zeniv-ca.linux.org.uk/
d an extraneous
> check in __get_user(), but lost the check it needs in
> __put_user().
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Feb 15, 2022 at 12:37:41AM +, Al Viro wrote:
> Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
> (and trim the comment down to "coldfire and 68000 will pick generic
> variant")?
I wonder if we should invert CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE,
select
On Mon, Feb 14, 2022 at 08:45:52PM +0100, Arnd Bergmann wrote:
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
> TASK_SIZ
> void prom_world(int enter)
> {
> - if (!enter)
> - set_fs(get_fs());
> -
> __asm__ __volatile__("flushw");
> }
The enter argument is now unused.
On Mon, Feb 14, 2022 at 05:34:48PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On almost all architectures, there are no remaining callers
> of set_fs(), so CONFIG_SET_FS can be disabled, along with
> removing the thread_info field and any references to it.
>
> This turns access_ok() i
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 14, 2022 at 05:34:42PM +0100, Arnd Bergmann wrote:
> +#define __range_not_ok(addr, size, limit)(!__access_ok(addr, size))
> +#define __chk_range_not_ok(addr, size, limit)(!__access_ok((void
> __user *)addr, size))
Can we just kill these off insted of letting themm obsfucat
On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The get_user()/put_user() functions are meant to check for
> access_ok(), while the __get_user()/__put_user() functions
> don't.
>
> This broke in 4.19 for nds32, when it gained an extraneous
> check in __ge
Looks good,
Reviewed-by: Christoph Hellwig
> +int
> +isolate_single_pageblock(unsigned long boundary_pfn, gfp_t gfp_flags, int
> isolate_before_boundary);
Please avoid the completely unreadably long line. i.e.
int isolate_single_pageblock(unsigned long boundary_pfn, gfp_t gfp_flags,
int isolate_before_boundary);
Same in
On Tue, Feb 01, 2022 at 11:05:39PM +0800, guo...@kernel.org wrote:
> +bool compat_elf_check_arch(Elf32_Ehdr *hdr)
> +{
> + if (compat_mode_support && (hdr->e_machine == EM_RISCV))
> + return true;
> + else
> + return false;
> +}
This can be simplified to:
r
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig wrote:
> >
> > Given that most rv64 implementations can't run in rv32 mode, what is the
> > failure mode if someone tries it with the compat mode enabled
On Tue, Feb 01, 2022 at 09:16:27AM +0800, Guo Ren wrote:
> Right?
>
> Seems you've based on an old tree, right?
This was a fairly recent Linus tree. I don't have the tree at hand
right now due to travel, but what changed there recently?
On Mon, Jan 31, 2022 at 11:19:32PM +0100, Arnd Bergmann wrote:
> I think it would be best to merge this through the risc-v tree along
> with the coming compat support
> that depends on it.
Sounds perfect to me!
On Mon, Jan 31, 2022 at 01:48:58PM +0100, Arnd Bergmann wrote:
> I thought that is what the patch does, there is already the normal 64-bit
> defconfig, and the new makefile target makes this shared with 32-bit
> to prevent them from diverging again.
I ment using a common fragment and the deriving
Given that most rv64 implementations can't run in rv32 mode, what is the
failure mode if someone tries it with the compat mode enabled?
On Sat, Jan 29, 2022 at 08:17:16PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> Let's follow the origin patch's spirit:
>
> The only difference between rv32_defconfig and defconfig is that
> rv32_defconfig has CONFIG_ARCH_RV32I=y.
>
> This is helpful to compare rv64-compat-rv32 v.s. rv3
> Reviewed-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
On Sat, Jan 29, 2022 at 08:17:14PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> There are 7 64bit architectures that support Linux COMPAT mode to
> run 32bit applications. A lot of definitions are duplicate:
> - COMPAT_USER_HZ
> - COMPAT_RLIM_INFINITY
> - COMPAT_OFF_T_MAX
> - __compat_
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. Another extra define is added for the packing required on
x86.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h | 16
gets the values wrong currently).
Note that before this change they were never visible to userspace due
to the fact that CONFIG_64BIT is only set for kernel builds.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
Don't bother to define the symbols empty, just don't use them. That
makes the intent a little more clear.
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 12
tools/include/uapi/asm-generic/fcntl.h | 12
2 files changed, 8
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++---
include/uapi/asm-generic/fcntl.h
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index ecd0f5bdfc1d6..caa482e3b01af 100644
--- a
Hi all,
currenty the compat fcnt definitions are duplicate for all compat
architectures, and the native fcntl64 definitions aren't even usable
from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
to sort out all that.
Changes since v1:
- only make the F*64 defines uapi visible fo
On Mon, Jan 24, 2022 at 09:22:15AM +, Christophe Leroy wrote:
> +static inline bool within_range(unsigned long addr, void *base, unsigned int
> size)
Please avoid the overly long line.
.. But given that this function only has a single caller I see no
point in factoring it out anyway.
On Wed, Jan 12, 2022 at 01:08:24PM +0100, Arnd Bergmann wrote:
> > I don't have a strong opinion here. If we were taking symbols away that
> > were previously visible to userland it would be one thing, but since
> > we're just adding symbols that may not have been there before, this
> > seems less
On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> This is a very subtle change to the exported UAPI header contents:
> On 64-bit architectures, the three unusable numbers are now always
> shown, rather than depending on a user-controlled symbol.
Well, the change is bigger and less s
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. Another extra define is added for the packing required on
x86.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h | 16
ff-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
arch/mips/include/uapi/asm/fcntl.h | 2 --
arch/powerpc/include/asm/compat.h | 4
arch/s390/include/asm/compat.h | 4
arch/sparc/include/asm/com
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index ecd0f5bdfc1d6..caa482e3b01af 100644
--- a
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++---
include/uapi/asm-generic/fcntl.h
Hi all,
currenty the compat fcnt definitions are duplicate for all compat
architectures, and the native fcntl64 definitions aren't even usable
from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
to sort out all that.
Diffstat:
arch/arm64/include/asm/compat.h| 20 --
Don't bother to define the symbols empty, just don't use them. That
makes the intent a little more clear.
Signed-off-by: Christoph Hellwig
---
include/uapi/asm-generic/fcntl.h | 12
tools/include/uapi/asm-generic/fcntl.h | 12
2 files changed, 8
On Mon, Jan 10, 2022 at 02:35:19PM +0100, Arnd Bergmann wrote:
> > +#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> > #ifndef F_GETLK64
> > #define F_GETLK64 12 /* using 'struct flock64' */
> > #define F_SETLK64 13
>
> The problem here is that include/uapi/ headers cannot
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Can you check if your tree already includes this commit:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.17/block&id=3f39d47d7ad858c024bd777f5f2a86fa7f6a9f14
and if not see if that fixes the problem?
Thanks,
applied to nvme-5.16.
65c24b596 ("powerpc: use the generic dma_ops_bypass mode")
> Signed-off-by: Alexey Kardashevskiy
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Sep 28, 2021 at 03:53:47PM +0530, Abdul Haleem wrote:
>
> On 9/1/21 7:06 PM, Christoph Hellwig wrote:
>> On Wed, Sep 01, 2021 at 04:47:26PM +0530, Abdul Haleem wrote:
>>> Greeting's
>>>
>>> multiple task hung while adding the vfc disk back to
On Thu, Sep 23, 2021 at 10:26:47AM -0700, Ben Widawsky wrote:
> */
> static int siov_find_pci_dvsec(struct pci_dev *pdev)
> {
> + return pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_INTEL, 5);
> }
I hink the siov_find_pci_dvsec helper is pretty pointless now and can be
folded into its on
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Because now we get architectures to all subly differ. Look at the mess
for ioremap and the ioremap* varian
On Wed, Sep 15, 2021 at 03:49:52PM +0200, Jan Beulich wrote:
> But the question remains: Why does the framebuffer need to be mapped
> in a single giant chunk?
More importantly: if you use dynamic dma mappings for your framebuffer
you're doing something wrong.
On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> I'm not convinced the swiotlb use describe there falls under "intended
> use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> the bottom of this page is also confusing, as following "Then we can
> confirm the modifie
On Mon, Aug 23, 2021 at 03:35:53PM +, Christophe Leroy wrote:
> In the same spirit as commit fb05121fd6a2 ("signal: Add
> unsafe_get_compat_sigset()"), implement an 'unsafe' version of
> copy_siginfo_to_user() in order to use it within user access blocks.
>
> For that, also add an 'unsafe' ver
On Mon, Aug 23, 2021 at 03:35:51PM +, Christophe Leroy wrote:
> Access the function descriptor of the handler within a
> user access block.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal_64.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
>
On Wed, Sep 01, 2021 at 04:47:26PM +0530, Abdul Haleem wrote:
> Greeting's
>
> multiple task hung while adding the vfc disk back to the multipath on my
> powerpc box running linux-next kernel
Can you retry to reproduce this with lockdep enabled to see if there
is anything interesting holding this
Are you sure this is the very latest linux-next? This should hav been
fixed by:
"block: add back the bd_holder_dir reference in bd_link_disk_holder"
On Thu, Aug 19, 2021 at 01:33:09PM -0500, Tom Lendacky wrote:
> I did it as inline originally because the presence of the function will be
> decided based on the ARCH_HAS_PROTECTED_GUEST config. For now, that is
> only selected by the AMD memory encryption support, so if I went out of
> line I coul
On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote:
> +static inline bool prot_guest_has(unsigned int attr)
No reall need to have this inline. In fact I'd suggest we havea the
prototype in a common header so that everyone must implement it out
of line.
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
> While the name suggests this is intended mainly for guests, it will
> also be used for host memory encryption checks in place of sme_active().
Which suggest that the name is not good to start with. Maybe protected
hardware, system or
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
> +#define PATTR_MEM_ENCRYPT0 /* Encrypted memory */
> +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted
> memory */
> +#define PATTR_GUEST_MEM_ENCRYPT 2 /* Guest encrypted
> m
On Thu, Aug 12, 2021 at 10:14:25AM +0200, Uwe Kleine-K??nig wrote:
> dev_driver_string() might return "" (via dev_bus_name()). If that happens
> *drvstr == '\0' becomes true.
>
> Would the following be better?:
>
> const char *drvstr;
>
> if (pdev)
> return "";
>
>
On Wed, Aug 11, 2021 at 10:06:33AM +0200, Uwe Kleine-K??nig wrote:
> static inline const char *eeh_driver_name(struct pci_dev *pdev)
> {
> - return (pdev && pdev->driver) ? pdev->driver->name : "";
> + const char *drvstr = pdev ? dev_driver_string(&pdev->dev) : "";
> +
> + if (*drvstr
Thanks,
I've applied this to the dma-mapping tree with a few minor cosmetic
tweaks.
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for g
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to e
finally!
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote:
> Since these patches are now all that remains, it would be nice to
> merge it all through Andrew's Linux-mm tree, which is already based
> on top of linux-next.
Is it?
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bio-integrity.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/t10-pi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a
Rewrite the actual bounce buffering loop in __blk_queue_bounce to that
the memcpy_to_bvec helper can be used to perform the data copies.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bounce.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions
Use memcpy_from_bvec instead of open coding the logic.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/blk-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index 3743158ddaeb..d1448aaad980 100644
--- a/block
Use memcpy_to_bvec instead of opencoding the logic.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bounce.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 94081e013c58..7e9e666c04dc
Use the proper helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
block/bio.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 2e436bccb1e2..0c89fa2f7a85
These two helpers are entirely unused now.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
include/linux/bio.h | 42 --
1 file changed, 42 deletions(-)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 2203b686e1f0
Use the bvec helpers instead of open coding the copy.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Tested-by: Geoff Levand
---
drivers/block/ps3disk.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/block/ps3disk.c b/drivers
There is no need to disable interrupts in bio_copy_block, and the local
only mappings helps to avoid any sort of problems with stray writes
into the bio data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
drivers/md/dm-writecache.c | 5 ++---
1
Use memzero_bvec instead of reimplementing it.
Signed-off-by: Christoph Hellwig
Acked-by: Ilya Dryomov
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
drivers/block/rbd.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/block/rbd.c b
Use memzero_bvec to zero each segment in the bio instead of manually
mapping and zeroing the data.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
block/bio.c | 9 ++---
1 file changed, 2 insertions(+), 7
Add helpers to perform common memory operation on a bvec.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 33 +
1 file changed, 33 insertions(+)
diff --git a
Add a helper to call kmap_local_page on a bvec. There is no need for
an unmap helper given that kunmap_local accept any address in the mapped
page.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux
Fix the include guards to match the file naming.
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
include/linux/bvec.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
There is no need to include genhd.h from a random arch header, and not
doing so prevents the possibility for nasty include loops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
Reviewed-by: Martin K. Petersen
Reviewed-by: Ira Weiny
---
arch/mips/include/asm/mach-rc32434
Hi all,
this series switches the core block layer code and all users of the
existing bvec kmap helpers to use kmap_local_page. Drivers that
currently use open coded kmap_atomic calls will converted in a follow
on series.
To do so a new kunmap variant is added that calls
flush_kernel_dcache_page.
> +int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
> + enum dma_data_direction dir, unsigned long attrs)
> +{
> + int nents;
> +
> + nents = __dma_map_sg_attrs(dev, sgt->sgl, sgt->orig_nents, dir, attrs);
> + if (nents == 0)
> + return -EIO;
> +
On Thu, Jul 22, 2021 at 05:23:51PM -0500, Bjorn Helgaas wrote:
> Marking both of these as "not applicable" for now because I don't
> think we really understand what's going on.
>
> Apparently a DMA occurs during suspend or resume and triggers an ACS
> violation. I don't think think such a DMA sho
> +
> +/*
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
> + * disables preemption so be careful if you intend to use it for long periods
> + * of time.
> + * TODO: If you intend to use the FPU in irq/softirq you need to check first
> with
> + * irq_fpu_usable() if
On Wed, Jul 21, 2021 at 08:29:43AM +0200, Christian K??nig wrote:
> Looks good in general, but question is what about other architectures like
> ARM?
DRM_AMD_DC_DCN currently requires X86 || PPC64.
Maybe a good think would be to add a new KERNEL_FPU_API Kconfig symbol,
selected by x86 and powerpc
> #define DC_FP_END() kernel_fpu_end()
> #elif defined(CONFIG_PPC64)
> #include
> +#define DC_FP_START() kernel_fpu_begin()
> +#define DC_FP_END() kernel_fpu_end()
> #endif
Please use the same header as x86 in your first patch and then kill
this ifdefered and the DC_FP_START/DC_FP_END definit
On Mon, Jul 19, 2021 at 03:52:10PM -0400, Anson Jacob wrote:
> - Add kernel_fpu_begin & kernel_fpu_end API as x86
> - Add logic similar to x86 to ensure fpu
> begin/end call correctness
> - Add kernel_fpu_enabled to know if FPU is enabled
>
> Signed-off-by: Anson Jacob
All the x86 FPU support
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
> @@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
> scatterlist *sg,
> else
> ents = ops->map_sg(dev, sg, nents, dir, attrs);
>
> + WARN_ON_ONCE(ents == 0);
Turns this into a ne
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
> @@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
> scatterlist *sg, int nents,
> iommu_full(dev, pages << PAGE_SHIFT, dir);
> for_each_sg(sg, s, nents, i)
> s->dma_address = DMA_MAPPIN
Careful here. What do all these errors from the low-level code mean
here? I think we need to clearly standardize on what we actually
return from ->map_sg and possibly document what the callers expect and
can do, and enforce that only those error are reported.
On Thu, Jul 15, 2021 at 10:45:29AM -0600, Logan Gunthorpe wrote:
> + * dma_map_sgtable() will return the error code returned and convert
> + * a zero return (for legacy implementations) into -EINVAL.
> + *
> + * dma_map_sg() will always return zero on any negative or zero
> +
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> FWIW I was pondering the question of whether to do something along those
> lines or just scrap the default assignment entirely, so since I hadn't got
> round to saying that I've gone ahead and hacked up the alternative
> (similarly
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> So at this point, the AMD IOMMU driver does:
>
> swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
>
> where 'swiotlb' is a global variable indicating whether or not swiotlb
> is in use. It's picked up a bit
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
>
> is_swiotlb_force_bounce() was the new function introduced in this patch here.
>
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> +
301 - 400 of 2738 matches
Mail list logo
