> On 13 Jul 2024, at 2:55 AM, Namhyung Kim wrote:
>
> On Sun, Jul 07, 2024 at 08:14:18PM +0530, Athira Rajeev wrote:
>> Currently data_type_cmp() only compares size and type name.
>> But in cases where the type name of two data type entries
>> is same, but var_name is different, the comparison
> On 13 Jul 2024, at 2:57 AM, Namhyung Kim wrote:
>
> On Sun, Jul 07, 2024 at 08:14:19PM +0530, Athira Rajeev wrote:
>> Since the "ins.name" is not set while using raw instruction,
>> perf annotate with insn-stat gives wrong data:
>>
>> Result from "./perf annotate --data-type --insn-stat":
>
On Sun, Jul 07, 2024 at 08:14:19PM +0530, Athira Rajeev wrote:
> Since the "ins.name" is not set while using raw instruction,
> perf annotate with insn-stat gives wrong data:
>
> Result from "./perf annotate --data-type --insn-stat":
>
> Annotate Instruction stats
> total 615, ok 419 (68.1%), bad
On Sun, Jul 07, 2024 at 08:14:18PM +0530, Athira Rajeev wrote:
> Currently data_type_cmp() only compares size and type name.
> But in cases where the type name of two data type entries
> is same, but var_name is different, the comparison can't distinguish
> two different types.
>
> Consider there
Hi Lizhi,
On 2024/07/11 02:18 PM, Lizhi Hou wrote:
>
> On 7/11/24 11:48, Amit Machhiwal wrote:
> > On 2024/07/10 09:48 PM, Lizhi Hou wrote:
> > > On 7/5/24 12:20, Bjorn Helgaas wrote:
> > > > [+cc Lukas, FYI]
> > > >
> > > > On Wed, Jul 03, 2024 at 07:46:34PM +0530, Amit Machhiwal wrote:
> > > >
On 7/12/24 09:14, Athira Rajeev wrote:
>
>
>> On 7 Jul 2024, at 8:14 PM, Athira Rajeev wrote:
>>
>> The patchset from Namhyung added support for data type profiling
>> in perf tool. This enabled support to associate PMU samples to data
>> types they refer using DWARF debug information. With t
On Fri, Jul 12, 2024 at 12:40:39PM +1000, Alistair Popple wrote:
>
> Peter Xu writes:
>
> > On Tue, Jul 09, 2024 at 02:07:31PM +1000, Alistair Popple wrote:
> >>
> >> Peter Xu writes:
> >>
> >> > Hi, Alistair,
> >> >
> >> > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote:
> >>
On 12/07/2024 15:34, Kees Cook wrote:
On July 12, 2024 2:59:30 AM PDT, Jocelyn Falempe wrote:
Gentle ping, I need reviews from powerpc, usermod linux, mtd, pstore and
hyperv, to be able to push it in the drm-misc tree.
Oops, I thought I'd Acked already!
Acked-by: Kees Cook
And, yeah,
On Fri, Jul 12, 2024 at 03:14:00PM +0300, Vladimir Oltean wrote:
> On Thu, Jul 11, 2024 at 02:00:25AM +0300, Vladimir Oltean wrote:
> > From: Breno Leitao
> >
> > As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
> > depend on COMPILE_TEST for compilation and testing.
> >
> >
On July 12, 2024 2:59:30 AM PDT, Jocelyn Falempe wrote:
>Gentle ping, I need reviews from powerpc, usermod linux, mtd, pstore and
>hyperv, to be able to push it in the drm-misc tree.
Oops, I thought I'd Acked already!
Acked-by: Kees Cook
And, yeah, as mpe said, you're all good to take this
On Wed, 10 Jul 2024 23:54:17 -0400, Nick Bowler wrote:
> The of_device_unregister call in therm_windtunnel's module_exit procedure
> does not fully reverse the effects of of_platform_device_create in the
> module_init prodedure. Once you unload this module, it is impossible
> to load it ever again
On Thu, 09 May 2024 22:12:46 +1000, Michael Ellerman wrote:
> The CPU/MMU feature code has build-time checks that the feature value is
> a builtin constant.
>
> Back when the code was added clang wasn't able to compile the
> checks, so an ifdef was added to avoid the checks for clang builds.
> See
On Thu, 11 Jul 2024 12:49:01 +0200, Christophe Leroy wrote:
>
Applied to powerpc/next.
[1/1] powerpc: Remove 40x leftovers
https://git.kernel.org/powerpc/c/3efe19a9b1549d4a35ec5790ad49f0a0234c
cheers
On Thu, 11 Jul 2024 12:50:21 +0200, Christophe Leroy wrote:
> Commit 732b32daef80 ("powerpc: Remove core support for 40x") removed 40x.
>
> Update documentation accordingly.
>
>
Applied to powerpc/next.
[1/1] Documentation/powerpc: Mention 40x is removed
https://git.kernel.org/powerpc/c/
On Fri, 17 May 2024 09:56:45 +0200, Artem Savkov wrote:
> Add support for recently added cpuv4 instructions fixing test_bpf module
> failures. This is mostly based on 8ecf3c1dab1c6 (powerpc/bpf/32: Fix
> failing test_bpf tests, 2024-03-05)
>
> Artem Savkov (5):
> powerpc64/bpf: jit support for 3
LEROY Christophe writes:
> Le 04/07/2024 à 05:01, Michael Ellerman a écrit :
>> Mark Brown writes:
>>> On Mon, Jul 01, 2024 at 01:30:34PM +0200, Herve Codina wrote:
qmc_chan_get_byphandle() and the resource managed version retrieve a
channel from a simple phandle.
Extend the A
Jocelyn Falempe writes:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new struct kmsg_dump_detail, that will hold the
> reason and description, and pass it to the dump() callback.
>
> To avoid updating all kmsg_dump() call, it adds a kmsg_du
Jocelyn Falempe writes:
> On 02/07/2024 14:26, Jocelyn Falempe wrote:
>> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
>> callback.
>> This patch adds a new struct kmsg_dump_detail, that will hold the
>> reason and description, and pass it to the dump() callback.
>>
>> To a
On Thu, Jul 11, 2024 at 02:00:25AM +0300, Vladimir Oltean wrote:
> From: Breno Leitao
>
> As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
> depend on COMPILE_TEST for compilation and testing.
>
> # grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
> 29
>
FREESCALE SOC DRIVERS has been orphaned since
commit eaac25d026a1 ("MAINTAINERS: Drop Li Yang as their email address
stopped working")
QUICC ENGINE LIBRARY has Qiang Zhao as maintainer but he hasn't
responded for years and when Li Yang was still maintaining FREESCALE
SOC DRIVERS he was also handlin
On 02/07/2024 14:26, Jocelyn Falempe wrote:
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new struct kmsg_dump_detail, that will hold the
reason and description, and pass it to the dump() callback.
To avoid updating all kmsg_dump() call, it adds
The blamed commit performed a lossy transformation of the original logic.
Due to it, on Arm DPAA1 platforms, we are now faced with this WARN on
each boot:
[ cut here ]
Unexpected architecture using non shared-dma-mem reservations
WARNING: CPU: 0 PID: 1 at drivers/soc/fsl/qb
This is effectively a revert of commit 6ea4c0fe4570 ("soc/fsl/qbman:
Update device tree with reserved memory").
What that commit intended to do: Fix up the device tree that is passed
to a subsequent kexec-loaded kernel, so that the reserved-memory nodes
have the same base addresses as the currentl
Hi Bjorn,
Kindly ping, this series got Reviewed-by and no comments for a month.
Will you think about picking it or further improvements are needed.
Look forward to your suggestions.
Thanks
Zhenzhong
>-Original Message-
>From: Duan, Zhenzhong
>Subject: [PATCH v5 0/2] PCI/AER: Handle Advi
Add a new .note section containing type, size, offset and flags of every
xfeature that is present.
This information will be used by debuggers to understand the XSAVE
layout of the machine where the core file has been dumped, and to read
XSAVE registers, especially during cross-platform debugging.
This patch proposes to add an extra .note section in the corefile to dump the
CPUID information of a machine. This is being done to solve the issue of tools
like the debuggers having to deal with coredumps from machines with varying
XSAVE layouts in spite of having the same XCR0 bits. The new pr
Le 04/07/2024 à 05:01, Michael Ellerman a écrit :
> Mark Brown writes:
>> On Mon, Jul 01, 2024 at 01:30:34PM +0200, Herve Codina wrote:
>>> qmc_chan_get_byphandle() and the resource managed version retrieve a
>>> channel from a simple phandle.
>>>
>>> Extend the API and introduce qmc_chan_get_by
27 matches
Mail list logo
