On Sat, May 10, 2025 at 01:50:02PM +0800, Herbert Xu wrote:
> On Sat, May 10, 2025 at 01:49:13PM +0800, Herbert Xu wrote:
> >
> > Did I do something wrong?
>
> OK perhaps it's just that the qemu emulation being slow.
Yes, non-native QEMU usually isn't any good for benchmarking the
architecture-op
On Sat, May 10, 2025 at 01:49:13PM +0800, Herbert Xu wrote:
>
> Did I do something wrong?
OK perhaps it's just that the qemu emulation being slow.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, May 09, 2025 at 10:33:08PM -0700, Eric Biggers wrote:
>
> Yes, the PowerPC Poly1305 code incorrectly uses VSX without first checking
> crypto_simd_usable(). And PowerPC also doesn't support VSX in softirqs, or at
> least it doesn't claim to (it doesn't override may_use_simd(), so it gets t
On Sat, May 10, 2025 at 01:10:22PM +0800, Herbert Xu wrote:
> On Fri, May 09, 2025 at 09:44:50PM -0700, Eric Biggers wrote:
> >
> > This fixes "-cpu Power10", but older CPUs (e.g. "-cpu POWER9") are still
> > failing.
>
> You're right. I'll revert this and apply the following patch
> instead.
>
The kernel uses 3100 to indicate ISA version 3.1, not 3010, so
fix the Microwatt device tree to use 3100.
Signed-off-by: Paul Mackerras
---
arch/powerpc/boot/dts/microwatt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/microwatt.dts
b/arch/powerpc/
On Fri, May 9, 2025 at 11:39 AM wrote:
>
> Hello:
>
> This series was applied to bpf/bpf-next.git (master)
> by Alexei Starovoitov :
>
> On Thu, 1 May 2025 09:35:51 +0200 you wrote:
> > This improves the expressiveness of unprivileged BPF by inserting
> > speculation barriers instead of rejecting
Hello:
This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov :
On Thu, 1 May 2025 09:35:51 +0200 you wrote:
> This improves the expressiveness of unprivileged BPF by inserting
> speculation barriers instead of rejecting the programs.
>
> The approach was previously presente
On Wed, May 07, 2025 at 02:23:02PM +0200, Michal Suchánek wrote:
> Hello,
>
> On Wed, May 07, 2025 at 02:36:57PM +0530, Amit Machhiwal wrote:
> > Hi Michal,
> >
> > I can recreate this issue on sles16 distro kernel but I don't observe this
> > issue
> > with upstream Linux 6.15-rc5 on the **same
On Fri, 9 May 2025 09:48:45 +0200
Christophe Leroy wrote:
> In non-interleaved mode, several QMC channels are used in sync.
> More details can be found in commit 188d9cae5438 ("ASoC: fsl:
> fsl_qmc_audio: Add support for non-interleaved mode.")
> At the time being, an interrupt is requested on e
Le 09/05/2025 à 16:28, Krzysztof Kozlowski a écrit :
On Mon, 20 Mar 2023 08:52:02 -0400, Tom Rix wrote:
clang with W=1 reports
drivers/soc/fsl/qe/qe_ic.c:235:29: error: unused function
'qe_ic_from_irq' [-Werror,-Wunused-function]
static inline struct qe_ic *qe_ic_from_irq(unsigned int vir
Le 09/05/2025 à 16:28, Krzysztof Kozlowski a écrit :
>
> On Mon, 20 Mar 2023 08:52:02 -0400, Tom Rix wrote:
>> clang with W=1 reports
>> drivers/soc/fsl/qe/qe_ic.c:235:29: error: unused function
>>'qe_ic_from_irq' [-Werror,-Wunused-function]
>> static inline struct qe_ic *qe_ic_from_irq(unsig
On Mon, 20 Mar 2023 08:52:02 -0400, Tom Rix wrote:
> clang with W=1 reports
> drivers/soc/fsl/qe/qe_ic.c:235:29: error: unused function
> 'qe_ic_from_irq' [-Werror,-Wunused-function]
> static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
> ^
> The use of thi
I tested this on both KOP and PowerNV, LGTM
Tested-by: Gautam Menghani
When no post-completion processing is expected, don't waste time
handling useless interrupts.
Only set QMC_BD_[R/T]X_I and QMC_BD_[R/T]X_UB when a completion
function is passed in.
Signed-off-by: Christophe Leroy
---
drivers/soc/fsl/qe/qmc.c | 18 +++---
1 file changed, 11 insertion
On 5/8/25 11:23, Sourabh Jain wrote:
Hi Sourabh.
On 05/05/25 13:23, Shrikanth Hegde wrote:
use scoped_guard for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/2023
On Thu, May 8, 2025 at 3:07 PM Markus Burri wrote:
>
> Check that the input size does not exceed the buffer size.
> If a caller write more characters, count is truncated to the max available
> space in "simple_write_to_buffer".
> Write a zero termination afterwards.
>
> Signed-off-by: Markus Burri
Hi Christophe,
On Fri, 9 May 2025 11:13:12 +0200
Christophe Leroy wrote:
> Hi Hervé,
>
> Le 09/05/2025 à 10:45, Herve Codina a écrit :
> > On Fri, 9 May 2025 09:48:45 +0200
> > Christophe Leroy wrote:
> >
> >> In non-interleaved mode, several QMC channels are used in sync.
> >> More detail
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
On Thu, May 8, 2025 at 3:06 PM Markus Burri wrote:
>
> Several drivers are using debugfs and follow the same pattern.
>
> A buffer is created on the stack with a limited size to copy the given data
> from user space. The copy is performed using simple_write_to_buffer.
> This function limits the in
: b4432656b36e5cc1d50a1f2dc15357543add530e
patch link:
https://lore.kernel.org/r/20250508130612.82270-5-markus.burri%40mt.com
patch subject: [PATCH v4 4/6] gpio: fix potential out-of-bound write
config: x86_64-buildonly-randconfig-003-20250509
(https://download.01.org/0day-ci/archive/20250509/202505091754.285hhbr2-...@intel.com
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
In non-interleaved mode, several QMC channels are used in sync.
More details can be found in commit 188d9cae5438 ("ASoC: fsl:
fsl_qmc_audio: Add support for non-interleaved mode.")
At the time being, an interrupt is requested on each channel to
perform capture/playback completion, allthough the com
Hi Christophe,
On Fri, 9 May 2025 09:48:44 +0200
Christophe Leroy wrote:
> When no post-completion processing is expected, don't waste time
> handling useless interrupts.
>
> Only set QMC_BD_[R/T]X_I and QMC_BD_[R/T]X_UB when a completion
> function is passed in.
>
> Signed-off-by: Christophe
Hi Hervé,
Le 09/05/2025 à 10:45, Herve Codina a écrit :
On Fri, 9 May 2025 09:48:45 +0200
Christophe Leroy wrote:
In non-interleaved mode, several QMC channels are used in sync.
More details can be found in commit 188d9cae5438 ("ASoC: fsl:
fsl_qmc_audio: Add support for non-interleaved mode.
From: Stefano Garzarella
Add a new `buf_size` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `buf_now` is
not used, but it will be used to implement devices wit
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
This series is a follow-up to the discussion we had about whether or not
to add send_recv() op in tpm_class_ops[1]. Much boilerplate code has
already been removed by Jarkko with commit 980a573621ea ("tpm: Make
chip->{status,cancel,req_canceled} opt"). With this series we try to
avoid also the tempo
On 5/8/2025 3:10 PM, Manivannan Sadhasivam wrote:
A PCI device is just another peripheral in a system. So failure to
recover it, must not result in a kernel panic. So remove the TODO which
is quite misleading.
Could you explain what the result would be if A PCI device failed to
recovery from
28 matches
Mail list logo
