Le 25/11/2022 à 06:38, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>>
>>
>> Le 24/11/2022 à 14:49, Naveen N. Rao a écrit :
>>> Christophe Leroy wrote:
Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
In what direction could that change
Christophe Leroy wrote:
Le 24/11/2022 à 14:49, Naveen N. Rao a écrit :
Christophe Leroy wrote:
Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
Christophe Leroy wrote:
In what direction could that change in the future ?
For me if they change that it becomes an API change.
More of an
Christophe Leroy writes:
> Hi,
>
> Le 23/11/2022 à 10:06, zhang.son...@zte.com.cn a écrit :
>> From: zhang songyi
>>
>> Fix the following coccicheck warning:
>> /arch/powerpc/platforms/cell/axon_msi.c:457:0-23: WARNING:
>> fops_msic should be defined with DEFINE_DEBUGFS_ATTRIBUTE
>
> What's the
On Sun, 2022-11-06 at 15:58 -0500, Nayna Jain wrote:
> PAPR Spec defines H_P1 actually as H_PARAMETER and maps H_ABORTED to
> a different numerical value.
>
> Fix the error codes as per PAPR Specification.
>
> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform
> KeyStore")
>
On Sun, 2022-11-06 at 15:58 -0500, Nayna Jain wrote:
> OS_VAR_LINUX enum in PLPKS driver should be 0x02 instead of 0x01.
This should be PLPKS_VAR_LINUX. And it's a macro, not an enum.
The new value does indeed match the (currently IBM internal)
specification - 0x01 is AIX.
>
> Fixes:
On Sun, 2022-11-06 at 15:58 -0500, Nayna Jain wrote:
> Replace kmalloc with kzalloc in construct_auth() function to default
> initialize structure with zeroes.
>
> Signed-off-by: Nayna Jain
This seems sensible.
> ---
> arch/powerpc/platforms/pseries/plpks.c | 8 ++--
> 1 file changed, 2
Hi all,
After merging the powerpc-objtool tree, today's linux-next build (powerpc
pseries_le_defconfig) produced these warnings:
arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): can't find
starting instruction
arch/powerpc/kernel/optprobes_head.o: warning: objtool:
On Wed, 2022-11-09 at 15:51 +1100, Benjamin Gray wrote:
> Remove the extern keyword from function declarations. It is redundant
> and would cause inconsistent style when new functions are added
> without
> it.
>
> Signed-off-by: Benjamin Gray
Reviewed-by: Andrew Donnellan
> ---
> v10:*
On Wed, 2022-11-09 at 15:51 +1100, Benjamin Gray wrote:
> The generic implementation of this function isn't really generic
> (Hash
> is not implemented). Unfortunately, the runtime warnings cannot be
> replaced with BUILD_BUG's, so it seems safer not to provide a stub in
> the first place.
>
>
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: c5bddc0ab18cfbcf1898d15d20050c92f039c613 selftests/powerpc:
Account for offline cpus in perf-hwbreak test
elapsed time: 728m
configs tested: 33
configs skipped: 2
The following configs have
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: a9ffb8ee7b65a468474d6a2be7e9cca4b8f8ea5f powerpc: Use "grep -E"
instead of "egrep"
elapsed time: 728m
configs tested: 33
configs skipped: 2
The following configs have been built successfully.
On Wed, 2022-11-23 at 10:10 +1100, Benjamin Gray wrote:
> No need to write inline asm for mtspr/mfspr, we have macros for this
> in reg.h
>
> Signed-off-by: Benjamin Gray
Good cleanup.
Reviewed-by: Andrew Donnellan
> ---
> tools/testing/selftests/powerpc/dscr/dscr.h | 17 +--
defconfig
x86_64 defconfig
arc randconfig-r043-20221124
x86_64 rhel-8.3
x86_64 allyesconfig
i386 randconfig-a001
i386 randconfig-a003
i386
Le 24/11/2022 à 14:49, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>>
>>
>> Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
>>> Christophe Leroy wrote:
ldimm64 is not only used for loading function addresses, and
>>>
>>> That's probably true today, but I worry that that can change
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: c35bd4e428856ed8c1fae7f7dfa08a9141c153d1 Add linux-next specific
files for 20221124
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com
https
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Thu, 24 Nov 2022 17:14:27 +0530
"Naveen N. Rao" wrote:
> Jinyang He wrote:
> > 在 2022/11/17 21:09, Masami Hiramatsu (Google) 写道:
> >
> >> On Thu, 17 Nov 2022 09:07:37 +0800
> >> Tiezhu Yang wrote:
> >>
> >>> Hi KPROBES maintainers,
> >>>
> >>> There are some differences of kprobe handler
The of node returned by of_find_compatible_node() with refcount
decremented, of_node_put() need be called after using it to avoid
refcount leak.
Fixes: abc3aeae3aaa ("fsl-rio: Add two ports and rapidio message units support")
Signed-off-by: Yang Yingliang
---
v2 -> v3:
drop of_node_put() in
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
Christophe Leroy wrote:
Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
Christophe Leroy wrote:
ldimm64 is not only used for loading function addresses, and
That's probably true today, but I worry that that can change upstream
and we may not notice at all.
Not sure what you mean.
Today
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
On Fri, 18 Nov 2022 23:35:34 +0100, Uwe Kleine-König wrote:
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
>
> This series completes all drivers to this new callback (unless I
Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> ldimm64 is not only used for loading function addresses, and
>
> That's probably true today, but I worry that that can change upstream
> and we may not notice at all.
Not sure what you mean.
Today POWERPC considers
Ping. Gentle reminder
On 11/5/22 1:20 AM, Zhuo Chen wrote:
Hi Bjorn, a gentle reminder.
Thanks and regards.
On 9/28/22 6:59 PM, Zhuo Chen wrote:
Hello.
Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.
v3:
Kajol Jain writes:
> Based on getPerfCountInfo v1.018 documentation, some of the
> hv_gpci events got deprecated for platforms firmware that
^ ^
were platform
> supports counter_info_version 0x8 or above.
>
> Patch fixes the
Jinyang He wrote:
在 2022/11/17 21:09, Masami Hiramatsu (Google) 写道:
On Thu, 17 Nov 2022 09:07:37 +0800
Tiezhu Yang wrote:
Hi KPROBES maintainers,
There are some differences of kprobe handler implementations on various
archs, the implementations are almost same on arm64, riscv, csky, the
Deming Wang writes:
> We should avoid use the return value directly after call
> iommu_pseries_alloc_group. Because it_may return a null.
We should probably at least print a warning in that case though?
Otherwise someone's PCI device will not work with no indication why, or
more likely the
Christophe Leroy writes:
> Le 23/05/2022 à 01:27, Andrew Donnellan a écrit :
>> On 21/5/22 21:11, Julia Lawall wrote:
>>> Spelling mistake (triple letters) in comment.
>>> Detected with the help of Coccinelle.
>>>
>>> Signed-off-by: Julia Lawall
>>
>> Acked-by: Andrew Donnellan
>>
>>
>
> How
Christophe Leroy writes:
> Le 24/11/2022 à 02:29, Stephen Rothwell a écrit :
>> Hi all,
>>
>> Today's linux-next merge of the tip tree got a conflict in:
>>
>>tools/objtool/check.c
>>
>> between commit:
>>
>>efb11fdb3e1a ("objtool: Fix SEGFAULT")
>>
>> from the powerpc-objtool tree
Christophe Leroy wrote:
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
Christophe Leroy wrote:
ldimm64 is not only used for loading function addresses, and
That's probably true today, but I worry that that can change upstream
and we may not notice at all.
the NOPs added for padding are impacting performance, so avoid
them when not necessary.
On QEMU mac99,
On 11/24/22 09:31, Pingfan Liu wrote:
On Mon, Nov 21, 2022 at 8:57 PM Cédric Le Goater wrote:
On 11/21/22 12:57, Pingfan Liu wrote:
Sorry that forget a subject.
On Mon, Nov 21, 2022 at 7:54 PM Pingfan Liu wrote:
Hello Powerpc folks,
I encounter an kdump bug, which I bisect and pin
ldimm64 is not only used for loading function addresses, and
the NOPs added for padding are impacting performance, so avoid
them when not necessary.
On QEMU mac99, with the patch:
test_bpf: #829 ALU64_MOV_K: all immediate value magnitudes jited:1 167436810
PASS
test_bpf: #831 ALU64_OR_K: all
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
test_bpf: #5 Tail call
On Mon, Nov 21, 2022 at 8:57 PM Cédric Le Goater wrote:
>
> On 11/21/22 12:57, Pingfan Liu wrote:
> > Sorry that forget a subject.
> >
> > On Mon, Nov 21, 2022 at 7:54 PM Pingfan Liu wrote:
> >>
> >> Hello Powerpc folks,
> >>
> >> I encounter an kdump bug, which I bisect and pin commit
On 21/11/2022 16:43, Yang Yingliang wrote:
get_function_0() calls pci_get_domain_bus_and_slot(), as comment
says, it returns a pci device with refcount increment, so after
using it, pci_dev_put() needs be called.
Get the device reference when get_function_0() is not called, so
pci_dev_put()
42 matches
Mail list logo
