On 28-03-24, 12:39, Allen wrote:
> > I think that is very great idea. having this wrapped in dma_chan would
> > be very good way as well
> >
> > Am not sure if Allen is up for it :-)
>
> Thanks Arnd, I know we did speak about this at LPC. I did start
> working on using completion. I dropped it a
On 28-03-24, 13:01, Allen wrote:
> > >> > Since almost every driver associates the tasklet with the
> > >> > dma_chan, we could go one step further and add the
> > >> > work_queue structure directly into struct dma_chan,
> > >> > with the wrapper operating on the dma_chan rather than
> > >> > the w
There are considerations to drop platform_driver_probe() as a concept
that isn't relevant any more today. It comes with an added complexity
that makes many users hold it wrong. (E.g. this driver should have
marked the driver struct with __refdata to prevent the below mentioned
false positive sectio
Various Kconfig options selected the per-architecture helpers for
fbdev. But none of the contained code depends on fbdev. Standardize
on CONFIG_VIDEO, which will allow to add more general helpers for
video functionality.
CONFIG_VIDEO protects each architecture's video/ directory. This
allows for t
The per-architecture fbdev code has no dependencies on fbdev and can
be used for any video-related subsystem. Rename the files to 'video'.
Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.
On arc, arm, arm64, sh, and um the asm header file is an empty wrapper
around the file
The per-architecture video helpers do not depend on struct fb_info
or anything else from fbdev. Remove it from the interface and replace
fb_is_primary_device() with video_is_primary_device(). The new helper
is similar in functionality, but can operate on non-fbdev devices.
Signed-off-by: Thomas Zi
Make architecture helpers for display functionality depend on general
video functionality instead of fbdev. This avoids the dependency on
fbdev and makes the functionality available for non-fbdev code.
Patch 1 replaces the variety of Kconfig options that control the
Makefiles with CONFIG_VIDEO. Mo
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 26 Mar 2024 23:37:59 +0100 you wrote:
> From: Arnd Bergmann
>
> With randconfig build testing, I found only eight files that produce
> warnings with clang when -Wformat-truncation is enabled. This means
> w
On Wed, Mar 27, 2024 at 02:43:37PM +0530, Manivannan Sadhasivam wrote:
> "core_init_notifier" flag is set by the glue drivers requiring refclk from
> the host to complete the DWC core initialization. Also, those drivers will
> send a notification to the EPF drivers once the initialization is fully
On Wed, Mar 27, 2024 at 02:43:36PM +0530, Manivannan Sadhasivam wrote:
> Currently, dw_pcie_ep_init_registers() API is directly called by the glue
> drivers requiring active refclk from host. But for the other drivers, it is
> getting called implicitly by dw_pcie_ep_init(). This is due to the fact
On 2024-03-29 12:28 PM, Dave Hansen wrote:
> On 3/29/24 00:18, Samuel Holland wrote:
>> +#
>> +# CFLAGS for compiling floating point code inside the kernel.
>> +#
>> +CC_FLAGS_FPU := -msse -msse2
>> +ifdef CONFIG_CC_IS_GCC
>> +# Stack alignment mismatch, proceed with caution.
>> +# GCC < 7.1 cannot
On 3/29/24 00:18, Samuel Holland wrote:
> The include guard should match the filename, or it will conflict with
> the newly-added asm/fpu.h.
Acked-by: Dave Hansen
On 3/29/24 00:18, Samuel Holland wrote:
> +#
> +# CFLAGS for compiling floating point code inside the kernel.
> +#
> +CC_FLAGS_FPU := -msse -msse2
> +ifdef CONFIG_CC_IS_GCC
> +# Stack alignment mismatch, proceed with caution.
> +# GCC < 7.1 cannot compile code using `double` and
> -mpreferred-stac
On Wed, Mar 27, 2024 at 07:39:20PM +, Simon Horman wrote:
[ ... ]
> > >
> > > Hi Guenter,
> > >
> > > a minor nit from my side: this change results in a Kernel doc warning.
> > >
> > > .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY().
> > > Prototype was for HAVE_BUG_F
> Can you check the debug patch below and provide output?
> When I'm right the warning should be gone and you should just get the
> "Modification triggered" instead. When I'm wrong we should at least see,
> how many references d_ref has left.
>
With the debug patch applied, code says d_ref val
On Wed, Mar 27, 2024 at 08:16:13AM -0700, Nathan Chancellor wrote:
> On Wed, Mar 27, 2024 at 08:20:07AM -0400, Sasha Levin wrote:
> > The patch below does not apply to the 5.10-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the bac
> Following WARN_ON_ONCE is triggered while running LTP tests
> (specifically ioctl_sg01) on IBM Power booted with 6.9.0-rc1-next-20240328
>
> [ 64.230233] [ cut here ]
> [ 64.230269] WARNING: CPU: 10 PID: 452 at drivers/scsi/sg.c:2236
> sg_remove_sfp_usercontext+0x270/
Following WARN_ON_ONCE is triggered while running LTP tests
(specifically ioctl_sg01) on IBM Power booted with 6.9.0-rc1-next-20240328
[ 64.230233] [ cut here ]
[ 64.230269] WARNING: CPU: 10 PID: 452 at drivers/scsi/sg.c:2236
sg_remove_sfp_usercontext+0x270/0x280 [sg]
Le 28/03/2024 à 08:57, Christophe Leroy a écrit :
>
>
> Le 28/03/2024 à 07:52, Christophe Leroy a écrit :
>>
>>
>> Le 28/03/2024 à 05:55, Rohan McLure a écrit :
>>> Support page table check on all PowerPC platforms. This works by
>>> serialising assignments, reassignments and clears of page tab
Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile
and run floating-point code, this test is no longer x86-specific.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v1)
lib/Kconfig.debug | 2 +-
lib/Makefile| 25 ++--
This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v2)
Changes in v2:
- Declare test_fpu() in a header
Now that all previously-supported architectures select
ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
of the existing list of architectures. It can also take advantage of the
common kernel-mode FPU API and method of adjusting CFLAGS.
Acked-by: Alex Deucher
Reviewed-by: C
From: Michael Ellerman
The compiler flags enable altivec, but that is not required; hard-float
is sufficient for the code to build and function.
Drop altivec from the compiler flags and adjust the enable/disable code
to only enable FPU use.
Signed-off-by: Michael Ellerman
Acked-by: Alex Deuche
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Support is limited to riscv64 because riscv32 requires runtime (libgcc)
assistance to con
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a
different header. Add a wrapper header, and export the CFLAGS
adjustments as found in lib/Makefile.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v1)
arch/x86/Kconfig | 1 +
The include guard should match the filename, or it will conflict with
the newly-added asm/fpu.h.
Signed-off-by: Samuel Holland
---
Changes in v4:
- New patch for v4
arch/x86/include/asm/fpu/types.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/
PowerPC provides an equivalent to the common kernel-mode FPU API, but in
a different header and using different function names. The PowerPC API
also requires a non-preemptible context. Add a wrapper header, and
export the CFLAGS adjustments.
Acked-by: Michael Ellerman (powerpc)
Reviewed-by: Chris
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.
Acked-by: WANG Xuerui
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v3)
Changes in v3:
- Reb
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
Changes in v4:
- Add missed CFLAGS changes for recov_neon_inner.c
(fixes arm build failures)
lib/ra
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v2)
Changes in v2:
- New patch for v2
arch/arm64/lib/Makefile | 6 ++
1 file ch
arm64 provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v2
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v1)
arch/arm/lib/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
di
This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be called from preemptible or non-preemptible task
context, and
ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Reviewed-by: Christoph Hellwig
Signed-off-by: Samuel Holland
---
(no changes since v2)
Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.
Provide a standard way for archite
35 matches
Mail list logo
