[PATCH 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section
The testcase "Object code reading" fails in somecases
for "fs_something" sub test as below:
Reading object code for memory address: 0xc00807f0142c
File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
On file address is: 0x1114cc
Objdump command is: objdump -z -d --start-address=0x11142c
--stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
objdump read too few bytes: 128
test child finished with -1
This can alo be reproduced when running perf record with
workload that exercises fs_something() code. In the test
setup, this is exercising xfs code since root is xfs.
# perf record ./a.out
# perf report -v |grep "xfs.ko"
0.76% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
0xc00807de5efc B [k] xlog_cil_commit
0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
0xc00807d5ae18 B [k] xfs_btree_key_offset
0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
0xc00807e11fd4 B [k] 0x00112074
Here addr "0xc00807e11fd4" is not resolved. since this is a
kernel module, its offset is from the DSO. Xfs module is loaded
at 0xc00807d0
# cat /proc/modules | grep xfs
xfs 2228224 3 - Live 0xc00807d0
And size is 0x22. So its loaded between 0xc00807d0
and 0xc00807f2. From objdump, text section is:
text 0010f7bc 00a0 2**4
Hence perf captured ip maps to 0x112074 which is:
( ip - start of module ) + a0
This offset 0x112074 falls out .text section which is up to 0x10f7bc
In this case for module, the address 0xc00807e11fd4 is pointing
to stub instructions. This address range represents the module stubs
which is allocated on module load and hence is not part of DSO offset.
To address this issue in "object code reading", skip the sample if
address falls out of text section and is within the module end.
Use the "text_end" member of "struct dso" to do this check.
To address this issue in "perf report", exploring an option of
having stubs range as part of the /proc/kallsyms, so that perf
report can resolve addresses in stubs range
However this patch uses text_end to skip the stub range for
Object code reading testcase.
Signed-off-by: Athira Rajeev
---
tools/perf/tests/code-reading.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index ed3815163d1b..911f8fa13677 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -269,6 +269,14 @@ static int read_object_code(u64 addr, size_t len, u8
cpumode,
if (addr + len > map__end(al.map))
len = map__end(al.map) - addr;
+ /* Check if the ip offset falls in stubs sections for kernel modules */
+ if (strstr(dso->long_name, ".ko")) {
+ if ((al.addr < map__end(al.map)) && (al.addr > dso->text_end)) {
+ pr_debug(" - skipping\n");
+ goto out;
+ }
+ }
+
/* Read the object code using perf */
ret_len = dso__data_read_offset(dso,
maps__machine(thread__maps(thread)),
al.addr, buf1, len);
--
2.31.1
[PATCH 1/2] tools/perf: Add text_end to "struct dso" to save .text section size
Update "struct dso" to include new member "text_end".
This new field will represent the offset for end of text
section for a dso. This value is derived as:
sh_size (Size of section in byes) + sh_offset (Section file
offst) of the elf header for text.
Signed-off-by: Athira Rajeev
---
tools/perf/util/dso.h| 1 +
tools/perf/util/symbol-elf.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index b41c9782c754..70fe0fe69bef 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -181,6 +181,7 @@ struct dso {
u8 rel;
struct build_id bid;
u64 text_offset;
+ u64 text_end;
const char *short_name;
const char *long_name;
u16 long_name_len;
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 8bd466d1c2bd..252d26a59e64 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1512,8 +1512,10 @@ dso__load_sym_internal(struct dso *dso, struct map *map,
struct symsrc *syms_ss,
}
if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
- ".text", NULL))
+ ".text", NULL)) {
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
+ dso->text_end = tshdr.sh_offset + tshdr.sh_size;
+ }
if (runtime_ss->opdsec)
opddata = elf_rawdata(runtime_ss->opdsec, NULL);
--
2.31.1
[PATCH] tools/perf: Fix dso kernel load and symbol process to correctly map dso to its long_name, type and adjust_symbols
Test "object cocde reading" fails sometimes for kernel address
as below:
Reading object code for memory address: 0xc0004c3c
File is: [kernel.kallsyms]
On file address is: 0x14c3c
dso__data_read_offset failed
test child finished with -1
end
Object code reading: FAILED!
Here the dso__data_read_offset fails for symbol address
0xc0004c3c. This is because, the dso long_name here
is [kernel.kallsyms] and hence open_dso fails to open this
file. There is an incorrect dso to map handling here. The
key points here is:
- dso long_name is set to [kernel.kallsyms]. This file is
not present and hence returns error
- DSO binary type is set to DSO_BINARY_TYPE__NOT_FOUND
- dso adjust_symbols is set to zero
In the end dso__data_read_offset() returns -1 and the address
0x14c3c can not be resolved. Hence the test fails. But the
address actually maps to kernel dso
# objdump -z -d --start-address=0xc0004c3c
--stop-address=0xc0004cbc /home/athira/linux/vmlinux
/home/athira/linux/vmlinux: file format elf64-powerpcle
Disassembly of section .head.text:
c0004c3c :
c0004c3c: a6 02 9b 7d mfsrr1 r12
c0004c40: 78 13 42 7c mr r2,r2
c0004c44: 18 00 4d e9 ld r10,24(r13)
c0004c48: 60 c6 4a 61 ori r10,r10,50784
c0004c4c: a6 03 49 7d mtctr r10
Fix the dso__process_kernel_symbol function to set the
binary_type and adjust_symbols. adjust_symbols is used by
function "map__rip_2objdump" which converts symbol start
address to objdump address. Also set the dso long_name during
dso__load_vmlinux function.
Suggested-by: Adrian Hunter
Signed-off-by: Athira Rajeev
---
Note: Found similar discussion here in thread:
https://www.spinics.net/lists/linux-perf-users/msg06337.html
where Adrian proposed the fix, but looks like this was
not added to the perf. Hence addeed Suggested-by from Adrian.
Additional to the fix proposed by Adrian, the patch also
adds setting of adjust_symbols which is needed for
map__rip_2objdump to convert symbol start to objdump address.
tools/perf/util/symbol-elf.c | 2 ++
tools/perf/util/symbol.c | 15 ++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 252d26a59e64..9e7eeaf616b8 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1440,6 +1440,8 @@ static int dso__process_kernel_symbol(struct dso *dso,
struct map *map,
curr_dso->kernel = dso->kernel;
curr_dso->long_name = dso->long_name;
curr_dso->long_name_len = dso->long_name_len;
+ curr_dso->binary_type = dso->binary_type;
+ curr_dso->adjust_symbols = dso->adjust_symbols;
curr_map = map__new2(start, curr_dso);
dso__put(curr_dso);
if (curr_map == NULL)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index f849f9ef68e6..3f36675b7c8f 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2204,15 +2204,20 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
if (symsrc__init(, dso, symfs_vmlinux, symtab_type))
return -1;
+ /*
+* dso__load_sym() may copy 'dso' which will result in the copies having
+* an incorrect long name unless we set it here first.
+*/
+ dso__set_long_name(dso, vmlinux, vmlinux_allocated);
+ if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
+ dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
+ else
+ dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
+
err = dso__load_sym(dso, map, , , 0);
symsrc__destroy();
if (err > 0) {
- if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
- dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
- else
- dso->binary_type = DSO_BINARY_TYPE__VMLINUX;
- dso__set_long_name(dso, vmlinux, vmlinux_allocated);
dso__set_loaded(dso);
pr_debug("Using %s for symbols\n", symfs_vmlinux);
}
--
2.31.1
[PATCH v2] powerpc/rtas_flash: allow user copy to flash block cache objects
From: Nathan Lynch
With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2
Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf04 of:IBM,FW860.50
(SV860_146) hv:phyp pSeries
NIP: c05991d0 LR: c05991cc CTR:
REGS: c000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+)
MSR: 80029033 CR: 24002242 XER: 000c
CFAR: c01fbd34 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c05991d0] usercopy_abort+0xa0/0xb0
LR [c05991cc] usercopy_abort+0x9c/0xb0
Call Trace:
[c000148c7940] [c05991cc] usercopy_abort+0x9c/0xb0 (unreliable)
[c000148c79b0] [c0536814] __check_heap_object+0x1b4/0x1d0
[c000148c79f0] [c0599080] __check_object_size+0x2d0/0x380
[c000148c7a30] [c0045ed4] rtas_flash_write+0xe4/0x250
[c000148c7a80] [c068a0fc] proc_reg_write+0xfc/0x160
[c000148c7ab0] [c05a381c] vfs_write+0xfc/0x4e0
[c000148c7b70] [c05a3e10] ksys_write+0x90/0x160
[c000148c7bc0] [c002f2c8] system_call_exception+0x178/0x320
[c000148c7e50] [c000d520] system_call_common+0x160/0x2c4
--- interrupt: c00 at 0x7fff9f17e5e4
The blocks of the firmware image are copied directly from user memory
to objects allocated from flash_block_cache, so flash_block_cache must
be created using kmem_cache_create_usercopy() to mark it safe for user
access.
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Nathan Lynch
---
I believe it's much more common to update Power system firmware
without involving a Linux partition, which may explain why this has
gone unreported for so long.
---
Changes in v2:
- Drop excessive local const variables. No functional change.
- Link to v1:
https://lore.kernel.org/r/20230801-rtas-flash-vs-hardened-usercopy-v1-1-2e99cf9e2...@linux.ibm.com
---
arch/powerpc/kernel/rtas_flash.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index 4caf5e3079eb..359577ec1680 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -709,9 +709,9 @@ static int __init rtas_flash_init(void)
if (!rtas_validate_flash_data.buf)
return -ENOMEM;
- flash_block_cache = kmem_cache_create("rtas_flash_cache",
- RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
- NULL);
+ flash_block_cache = kmem_cache_create_usercopy("rtas_flash_cache",
+ RTAS_BLK_SIZE,
RTAS_BLK_SIZE,
+ 0, 0, RTAS_BLK_SIZE,
NULL);
if (!flash_block_cache) {
printk(KERN_ERR "%s: failed to create block cache\n",
__func__);
---
base-commit: c3cad890877f59aeeaf5a638aa7a7c0612c16fa1
change-id: 20230731-rtas-flash-vs-hardened-usercopy-09a6d236b011
Best regards,
--
Nathan Lynch
Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
On Tue, Aug 8, 2023 at 2:13 PM Sean Christopherson wrote: > ... > > + When binding a memslot to the file, if a kvm pointer exists, it must > > be the same kvm as the one in this binding > > + When the binding to the last memslot is removed from a file, NULL the > > kvm pointer. > > Nullifying the KVM pointer isn't sufficient, because without additional > actions > userspace could extract data from a VM by deleting its memslots and then > binding > the guest_memfd to an attacker controlled VM. Or more likely with TDX and > SNP, > induce badness by coercing KVM into mapping memory into a guest with the wrong > ASID/HKID. > TDX/SNP have mechanisms i.e. PAMT/RMP tables to ensure that the same memory is not assigned to two different VMs. Deleting memslots should also clear out the contents of the memory as the EPT tables will be zapped in the process and the host will reclaim the memory. Regards, Vishal
Re: [PATCH v2 6/6] integrity: PowerVM support for loading third party code signing keys
On Wed Aug 9, 2023 at 10:53 PM EEST, Nayna Jain wrote:
> On secure boot enabled PowerVM LPAR, third party code signing keys are
> needed during early boot to verify signed third party modules. These
> third party keys are stored in moduledb object in the Platform
> KeyStore(PKS).
^ space
>
> Load third party code signing keys onto .secondary_trusted_keys keyring.
>
> Signed-off-by: Nayna Jain
> ---
> certs/system_keyring.c| 23 +++
> include/keys/system_keyring.h | 7 ++
> security/integrity/integrity.h| 1 +
> .../platform_certs/keyring_handler.c | 8 +++
> .../platform_certs/keyring_handler.h | 5
> .../integrity/platform_certs/load_powerpc.c | 18 ++-
> 6 files changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index b348e0898d34..3435d4936fb2 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -396,3 +396,26 @@ void __init set_platform_trusted_keys(struct key
> *keyring)
> platform_trusted_keys = keyring;
> }
> #endif
> +
spurious newline character
> +void __init add_to_secondary_keyring(const char *source, const void *data,
> + size_t len)
Documentation is lacking, and should be in a single line, as it totals
less than 100 characters.
> +{
> + key_ref_t key;
> + key_perm_t perm; the following structure
> + int rc = 0;
int rc;
> +
> + perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW;
> +
> + key = key_create_or_update(make_key_ref(secondary_trusted_keys, 1),
> +"asymmetric",
> +NULL, data, len, perm,
> +KEY_ALLOC_NOT_IN_QUOTA);
> + if (IS_ERR(key)) {
> + rc = PTR_ERR(key);
This helper variable is not very useful.
> + pr_err("Problem loading X.509 certificate %d\n", rc);
Why pr_err()? What kind of object is "a problem"?
Also X.509 certificates are everywhere. If these are printed to the
klog, how can e.g. an admin deduce the problem over here?
Even without having these log messages at all I could trace the called
function and be informed that some X.509 cert has an issues. Actually
then I could even deduce the location, thanks to call backtrace.
These have a potential to lead into wrong conclusions.
> + } else {
> + pr_notice("Loaded X.509 cert '%s'\n",
> + key_ref_to_ptr(key)->description);
single line
> + key_ref_put(key);
> + }
I'd suggest instead the following structure:
if (IS_ERR(key)) {
pr_err("Problem loading X.509 certificate %d\n", PTR_ERR(key));
return;
}
pr_notice("Loaded X.509 cert '%s'\n", key_ref_to_ptr(key)->description);
key_ref_put(key);
}
BR, Jarkko
Re: [PATCH v2 5/6] integrity: PowerVM machine keyring enablement
On Wed Aug 9, 2023 at 10:53 PM EEST, Nayna Jain wrote: > Update Kconfig to enable machine keyring and limit to CA certificates > on PowerVM. Only key signing CA keys are allowed. > > Signed-off-by: Nayna Jain > Reviewed-and-tested-by: Mimi Zohar > > --- > security/integrity/Kconfig | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > index ec6e0d789da1..232191ee09e3 100644 > --- a/security/integrity/Kconfig > +++ b/security/integrity/Kconfig > @@ -67,7 +67,9 @@ config INTEGRITY_MACHINE_KEYRING > depends on SECONDARY_TRUSTED_KEYRING > depends on INTEGRITY_ASYMMETRIC_KEYS > depends on SYSTEM_BLACKLIST_KEYRING > - depends on LOAD_UEFI_KEYS > + depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > + select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > + select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > help >If set, provide a keyring to which Machine Owner Keys (MOK) may >be added. This keyring shall contain just MOK keys. Unlike keys > -- > 2.31.1 Reviewed-by: Jarkko Sakkinen BR, Jarkko
Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking
On Wed, Aug 9, 2023 at 2:07 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 6:06 PM Mateusz Guzik wrote:
> >>
> >> On 8/5/23, Linus Torvalds wrote:
> >> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >> >>
> >> >> I know of these guys, I think they are excluded as is -- they go
> >> >> through access_remote_vm, starting with:
> >> >> if (mmap_read_lock_killable(mm))
> >> >> return 0;
> >> >>
> >> >> while dup_mmap already write locks the parent's mm.
> >> >
> >> > Oh, you're only worried about vma_start_write()?
> >> >
> >> > That's a non-issue. It doesn't take the lock normally, since it starts
> >> > off
> >> > with
> >> >
> >> > if (__is_vma_write_locked(vma, _lock_seq))
> >> > return;
> >> >
> >> > which catches on the lock sequence number already being set.
> >> >
> >> > So no extra locking there.
> >> >
> >> > Well, technically there's extra locking because the code stupidly
> >> > doesn't initialize new vma allocations to the right sequence number,
> >> > but that was talked about here:
> >> >
> >> >
> >> > https://lore.kernel.org/all/CAHk-=wicrwaoeesbuogoqqufvesicbgp3cx0lykgevsfazn...@mail.gmail.com/
> >> >
> >> > and it's a separate issue.
> >> >
> >>
> >> I'm going to bet one beer this is the issue.
> >>
> >> The patch I'm responding to only consists of adding the call to
> >> vma_start_write and claims the 5% slowdown from it, while fixing
> >> crashes if the forking process is multithreaded.
> >>
> >> For the fix to work it has to lock something against the parent.
> >>
> >> VMA_ITERATOR(old_vmi, oldmm, 0);
> >> [..]
> >> for_each_vma(old_vmi, mpnt) {
> >> [..]
> >> vma_start_write(mpnt);
> >>
> >> the added line locks an obj in the parent's vm space.
> >>
> >> The problem you linked looks like pessimization for freshly allocated
> >> vmas, but that's what is being operated on here.
> >
> > Sorry, now I'm having trouble understanding the problem you are
> > describing. We are locking the parent's vma before copying it and the
> > newly created vma is locked before it's added into the vma tree. What
> > is the problem then?
> >
>
> Sorry for the late reply!
>
> Looks there has been a bunch of weird talking past one another in this
> thread and I don't think trying to straighten it all out is worth any
> time.
>
> I think at least the two of us agree that if a single-threaded process
> enters dup_mmap an
> down_writes the mmap semaphore, then no new thread can pop up in said
> process, thus no surprise page faults from that angle. 3rd parties are
> supposed to interfaces like access_remote_vm, which down_read said
> semaphore and are consequently also not a problem. The only worry here
> is that someone is messing with another process memory without the
> semaphore, but is very unlikely and patchable in the worst case -- but
> someone(tm) has to audit. With all these conditions satisfied one can
> elide vma_start_write for a perf win.
>
> Finally, I think we agreed you are going to do the audit ;)
Ack. I'll look into this once the dust settles. Thanks!
>
> Cheers,
> --
> Mateusz Guzik
Re: [PATCH v14 00/15] phy: Add support for Lynx 10G SerDes
Hi Vladimir, On 8/10/23 06:26, Vladimir Oltean wrote: > Hi Sean, > > On Tue, Jun 13, 2023 at 05:27:54PM +0300, Vladimir Oltean wrote: >> The way things are supposed to work (*if* this works at all) is that the >> reset state machine starts with a supported PLL / refclk configuration >> that permits a certain subset of protocols, and the SERDES protocols can >> be changed from the reset state, as desired, for the individual lanes. >> >> What is self-inflicted is that the refclks on your board design are not >> supportable by any reset state machine configuration, and wiring them >> that way was a conscious decision. Did your company's board designers >> receive the recommendation to disconnect RESET_REQ from NXP, and has NXP >> said that the end result will be something that continues to be supportable? >> I've searched the customer support database and the answer seems to be no. >> In any case, if you have to disconnect RESET_REQ from the SoC to make >> the driver in this form useful, then... yeah, no. You're obviously free >> to do whatever you want with your products, but that's not how mainline >> Linux works, it needs to be useful beyond you. As explained previously (and noted by yourself below) 1G and 10G RCWs have mutally-incompatible clocking requirements. Now that you have documented an alternate solution, it is possible to boot up with one RCW and switch to another. But without that it was not possible to have one board support both RCWs (without e.g. a microcontroller or FPGA to configure the clock generator before releasing the processor reset). I do not think that the silicon should assert the reset request line if the serdes doesn't lock, but it does and it can't really be disabled. As it happens, our board is set up so that the reference clocks are configured for 10G by default. During this boot, reset request is never requested. If we did not have to support software configuration of the serdes speed (to support 1G SFPs) we would not have to disconnect reset request. That said, I have evaluated the various reasons that reset request can be asserted, and I have determined that for our product they are not necessary. The only major limitation is the lack of a watchdog, but that was not a requirement for us. Because of this, using a GPIO for reset is sufficient and neatly avoids the issue. We did not see the need to contact NXP support because we internally came up with a reliable solution. I suspect that they would not have suggested the solution you present below, but if you think otherwise I will try them in the future :) I would appreciate if you are not so derisive in your comments. I do not like reading your emails because they are very abrasive. >> If protocol switching works, I will maintain that your board should have >> wired the refclks to PLLs the other way around (which is supported by >> the RCW), and then proceed to do protocol switching to reach the desired >> configuration. > > It was quite a journey to piece everything together. > > There is one thing to be mentioned right from the start, and that is > that on some SoCs (including the LS1043A and LS1046A), the SerDes data > path is partially controlled by the RCW, and thus, dynamically performing > a major SerDes protocol reconfiguration requires a RCW override procedure > (undocumented in the SerDes reconfiguration steps, but all the info you > need is summarized below). > > The DCFG block has a set of RCWSR0 - RCWSR15 read-only status registers > relative to DCFG_CCSR. What we don't document in the SoC RM, but I got > permission to say here, is that the DCFG block exposes a second set of > Expert Mode registers in the DCSR address space (base address 2000_h). > The DCFG_DCSR register region spans from offset 2_h to 2_05AC into > the DCSR base address. At the exact same offsets into DCFG_DCSR as > RCWSR0 - RCWSR15 are into DCFG_CCSR (aka 100h-13ch), one can find the > shadow RCWCR0 - RCWCR15 (Reset Control Word Control Register) registers > which are also writable. There is a one-to-one mapping between each > register (and field) in RCWSR and RCWCR, so I won't detail the > contents of the RCWCR registers, because we document RCWSR fully. > > RCW override means modifying some of the RCWCR registers. In this > particular case, finalizing the major SerDes reconfiguration requires > overriding SRDS_PRTCL_S1 in RCWCR5 with the new per-lane settings, to mux > the correct PCS to the MAC. In the general case, random RCW overrides > that don't come from the hardware validation team are unsupported by > NXP, and you should expect the procedure to yield unpredictable results. Good to see these finally documented (in some form or other). Perhaps these could also be used to enable e.g. a UART in the hard-coded RCW without requiring e.g. JTAG... > I don't know how much of the above steps is applicable to the other 10G Lynx > SoCs (LS1088, LS2088 etc). Not all SoCs may require RCW override, and > the RCW override
Re: [PATCH 06/17] macintosh/ams: mark ams_init() static
Le 10/08/2023 à 16:19, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> This is the module init function, which by definition is used only
> locally, so mark it static to avoid a warning:
>
> drivers/macintosh/ams/ams-core.c:179:12: error: no previous prototype for
> 'ams_init' [-Werror=missing-prototypes]
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Christophe Leroy
> ---
> drivers/macintosh/ams/ams-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/macintosh/ams/ams-core.c
> b/drivers/macintosh/ams/ams-core.c
> index 877e8cb231283..c978b4272daa5 100644
> --- a/drivers/macintosh/ams/ams-core.c
> +++ b/drivers/macintosh/ams/ams-core.c
> @@ -176,7 +176,7 @@ int ams_sensor_attach(void)
> return result;
> }
>
> -int __init ams_init(void)
> +static int __init ams_init(void)
> {
> struct device_node *np;
>
Re: [PATCH v3 00/28] Add support for QMC HDLC, framer infrastruture and PEF2256 framer
On Wed, 9 Aug 2023 15:27:27 +0200 Herve Codina wrote: > The series contains the full story and detailed modifications. > If needed, the series can be split and/or commmits can be squashed. > Let me know. Are there any dependencies in one of the -next trees? As it the series doesn't seem to build on top of net-next with allmodconfig.
Re: [PATCH v2 3/6] integrity: remove global variable from machine_keyring.c
On Wed Aug 9, 2023 at 10:53 PM EEST, Nayna Jain wrote:
> trust_mok variable is accessed within a single function locally.
>
> Change trust_mok from global to local static variable.
>
> Signed-off-by: Nayna Jain
> Reviewed-and-tested-by: Mimi Zohar
> ---
> security/integrity/platform_certs/machine_keyring.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/platform_certs/machine_keyring.c
> b/security/integrity/platform_certs/machine_keyring.c
> index 389a6e7c9245..9482e16cb2ca 100644
> --- a/security/integrity/platform_certs/machine_keyring.c
> +++ b/security/integrity/platform_certs/machine_keyring.c
> @@ -8,8 +8,6 @@
> #include
> #include "../integrity.h"
>
> -static bool trust_mok;
> -
> static __init int machine_keyring_init(void)
> {
> int rc;
> @@ -65,9 +63,11 @@ static __init bool uefi_check_trust_mok_keys(void)
> bool __init trust_moklist(void)
> {
> static bool initialized;
> + static bool trust_mok;
>
> if (!initialized) {
> initialized = true;
> + trust_mok = false;
>
> if (uefi_check_trust_mok_keys())
> trust_mok = true;
Nice catch.
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
[PATCH 14/17] kprobes: unify kprobes_exceptions_nofify() prototypes
From: Arnd Bergmann
Most architectures that support kprobes declare this function in their
own asm/kprobes.h header and provide an override, but some are missing
the prototype, which causes a warning for the __weak stub implementation:
kernel/kprobes.c:1865:12: error: no previous prototype for
'kprobe_exceptions_notify' [-Werror=missing-prototypes]
1865 | int __weak kprobe_exceptions_notify(struct notifier_block *self,
Move the prototype into linux/kprobes.h so it is visible to all
the definitions.
Signed-off-by: Arnd Bergmann
---
arch/arc/include/asm/kprobes.h | 3 ---
arch/arm/include/asm/kprobes.h | 2 --
arch/arm64/include/asm/kprobes.h | 2 --
arch/ia64/include/asm/kprobes.h| 2 --
arch/mips/include/asm/kprobes.h| 2 --
arch/powerpc/include/asm/kprobes.h | 2 --
arch/s390/include/asm/kprobes.h| 2 --
arch/sh/include/asm/kprobes.h | 2 --
arch/sparc/include/asm/kprobes.h | 2 --
arch/x86/include/asm/kprobes.h | 2 --
include/linux/kprobes.h| 4
11 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/arc/include/asm/kprobes.h b/arch/arc/include/asm/kprobes.h
index de1566e32cb89..68e8301c0df2c 100644
--- a/arch/arc/include/asm/kprobes.h
+++ b/arch/arc/include/asm/kprobes.h
@@ -32,9 +32,6 @@ struct kprobe;
void arch_remove_kprobe(struct kprobe *p);
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
-
struct prev_kprobe {
struct kprobe *kp;
unsigned long status;
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index e26a278d301ab..5b8dbf1b0be49 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -40,8 +40,6 @@ struct kprobe_ctlblk {
void arch_remove_kprobe(struct kprobe *);
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
/* optinsn template addresses */
extern __visible kprobe_opcode_t optprobe_template_entry[];
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 05cd82eeca136..be7a3680dadff 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -37,8 +37,6 @@ struct kprobe_ctlblk {
void arch_remove_kprobe(struct kprobe *);
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
void __kretprobe_trampoline(void);
void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
diff --git a/arch/ia64/include/asm/kprobes.h b/arch/ia64/include/asm/kprobes.h
index 9e956768946cc..56004f97df6d2 100644
--- a/arch/ia64/include/asm/kprobes.h
+++ b/arch/ia64/include/asm/kprobes.h
@@ -107,8 +107,6 @@ struct arch_specific_insn {
};
extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
-extern int kprobe_exceptions_notify(struct notifier_block *self,
- unsigned long val, void *data);
extern void arch_remove_kprobe(struct kprobe *p);
diff --git a/arch/mips/include/asm/kprobes.h b/arch/mips/include/asm/kprobes.h
index 68b1e5d458cfb..bc27d99c94363 100644
--- a/arch/mips/include/asm/kprobes.h
+++ b/arch/mips/include/asm/kprobes.h
@@ -71,8 +71,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
};
-extern int kprobe_exceptions_notify(struct notifier_block *self,
- unsigned long val, void *data);
#endif /* CONFIG_KPROBES */
#endif /* _ASM_KPROBES_H */
diff --git a/arch/powerpc/include/asm/kprobes.h
b/arch/powerpc/include/asm/kprobes.h
index c8e4b4fd4e330..4525a9c68260d 100644
--- a/arch/powerpc/include/asm/kprobes.h
+++ b/arch/powerpc/include/asm/kprobes.h
@@ -84,8 +84,6 @@ struct arch_optimized_insn {
kprobe_opcode_t *insn;
};
-extern int kprobe_exceptions_notify(struct notifier_block *self,
- unsigned long val, void *data);
extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
extern int kprobe_handler(struct pt_regs *regs);
extern int kprobe_post_handler(struct pt_regs *regs);
diff --git a/arch/s390/include/asm/kprobes.h b/arch/s390/include/asm/kprobes.h
index 83f732ca3af4d..3f87125dd9b0d 100644
--- a/arch/s390/include/asm/kprobes.h
+++ b/arch/s390/include/asm/kprobes.h
@@ -72,8 +72,6 @@ struct kprobe_ctlblk {
void arch_remove_kprobe(struct kprobe *p);
int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
-int kprobe_exceptions_notify(struct notifier_block *self,
- unsigned long val, void *data);
#define flush_insn_slot(p) do { } while (0)
diff --git a/arch/sh/include/asm/kprobes.h b/arch/sh/include/asm/kprobes.h
index eeba83e0a7d29..65d4c3316a5bd 100644
--- a/arch/sh/include/asm/kprobes.h
+++ b/arch/sh/include/asm/kprobes.h
@@ -46,8 +46,6 @@ struct
[PATCH 06/17] macintosh/ams: mark ams_init() static
From: Arnd Bergmann
This is the module init function, which by definition is used only
locally, so mark it static to avoid a warning:
drivers/macintosh/ams/ams-core.c:179:12: error: no previous prototype for
'ams_init' [-Werror=missing-prototypes]
Signed-off-by: Arnd Bergmann
---
drivers/macintosh/ams/ams-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/ams/ams-core.c b/drivers/macintosh/ams/ams-core.c
index 877e8cb231283..c978b4272daa5 100644
--- a/drivers/macintosh/ams/ams-core.c
+++ b/drivers/macintosh/ams/ams-core.c
@@ -176,7 +176,7 @@ int ams_sensor_attach(void)
return result;
}
-int __init ams_init(void)
+static int __init ams_init(void)
{
struct device_node *np;
--
2.39.2
[PATCH 02/17] [RESEND] irq_work: consolidate arch_irq_work_raise prototypes
From: Arnd Bergmann
The prototype was hidden on x86, which causes a warning:
kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise'
[-Werror=missing-prototypes]
Fix this by providing it in only one place that is always visible.
Acked-by: Catalin Marinas
Acked-by: Palmer Dabbelt
Acked-by: Guo Ren
Reviewed-by: Alexander Gordeev
Signed-off-by: Arnd Bergmann
---
arch/arm/include/asm/irq_work.h | 2 --
arch/arm64/include/asm/irq_work.h | 2 --
arch/csky/include/asm/irq_work.h| 2 +-
arch/powerpc/include/asm/irq_work.h | 1 -
arch/riscv/include/asm/irq_work.h | 2 +-
arch/s390/include/asm/irq_work.h| 2 --
arch/x86/include/asm/irq_work.h | 1 -
include/linux/irq_work.h| 3 +++
8 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 3149e4dc1b540..8895999834cc0 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -9,6 +9,4 @@ static inline bool arch_irq_work_has_interrupt(void)
return is_smp();
}
-extern void arch_irq_work_raise(void);
-
#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm64/include/asm/irq_work.h
b/arch/arm64/include/asm/irq_work.h
index 81bbfa3a035bd..a1020285ea750 100644
--- a/arch/arm64/include/asm/irq_work.h
+++ b/arch/arm64/include/asm/irq_work.h
@@ -2,8 +2,6 @@
#ifndef __ASM_IRQ_WORK_H
#define __ASM_IRQ_WORK_H
-extern void arch_irq_work_raise(void);
-
static inline bool arch_irq_work_has_interrupt(void)
{
return true;
diff --git a/arch/csky/include/asm/irq_work.h b/arch/csky/include/asm/irq_work.h
index 33aaf39d6f94f..d39fcc1f5395f 100644
--- a/arch/csky/include/asm/irq_work.h
+++ b/arch/csky/include/asm/irq_work.h
@@ -7,5 +7,5 @@ static inline bool arch_irq_work_has_interrupt(void)
{
return true;
}
-extern void arch_irq_work_raise(void);
+
#endif /* __ASM_CSKY_IRQ_WORK_H */
diff --git a/arch/powerpc/include/asm/irq_work.h
b/arch/powerpc/include/asm/irq_work.h
index b8b0be8f1a07e..c6d3078bd8c3b 100644
--- a/arch/powerpc/include/asm/irq_work.h
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -6,6 +6,5 @@ static inline bool arch_irq_work_has_interrupt(void)
{
return true;
}
-extern void arch_irq_work_raise(void);
#endif /* _ASM_POWERPC_IRQ_WORK_H */
diff --git a/arch/riscv/include/asm/irq_work.h
b/arch/riscv/include/asm/irq_work.h
index b53891964ae03..b27a4d64fc6a0 100644
--- a/arch/riscv/include/asm/irq_work.h
+++ b/arch/riscv/include/asm/irq_work.h
@@ -6,5 +6,5 @@ static inline bool arch_irq_work_has_interrupt(void)
{
return IS_ENABLED(CONFIG_SMP);
}
-extern void arch_irq_work_raise(void);
+
#endif /* _ASM_RISCV_IRQ_WORK_H */
diff --git a/arch/s390/include/asm/irq_work.h b/arch/s390/include/asm/irq_work.h
index 603783766d0ab..f00c9f610d5a8 100644
--- a/arch/s390/include/asm/irq_work.h
+++ b/arch/s390/include/asm/irq_work.h
@@ -7,6 +7,4 @@ static inline bool arch_irq_work_has_interrupt(void)
return true;
}
-void arch_irq_work_raise(void);
-
#endif /* _ASM_S390_IRQ_WORK_H */
diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
index 800ffce0db29e..6b4d36c951655 100644
--- a/arch/x86/include/asm/irq_work.h
+++ b/arch/x86/include/asm/irq_work.h
@@ -9,7 +9,6 @@ static inline bool arch_irq_work_has_interrupt(void)
{
return boot_cpu_has(X86_FEATURE_APIC);
}
-extern void arch_irq_work_raise(void);
#else
static inline bool arch_irq_work_has_interrupt(void)
{
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 8cd11a2232605..136f2980cba30 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -66,6 +66,9 @@ void irq_work_sync(struct irq_work *work);
void irq_work_run(void);
bool irq_work_needs_cpu(void);
void irq_work_single(void *arg);
+
+void arch_irq_work_raise(void);
+
#else
static inline bool irq_work_needs_cpu(void) { return false; }
static inline void irq_work_run(void) { }
--
2.39.2
Re: [PATCH v3 21/28] net: wan: Add framer framework support
Hi Herve, On Wed, Aug 9, 2023 at 3:28 PM Herve Codina wrote: > A framer is a component in charge of an E1/T1 line interface. > Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 > frames. It also provides information related to the E1/T1 line. > > The framer framework provides a set of APIs for the framer drivers > (framer provider) to create/destroy a framer and APIs for the framer > users (framer consumer) to obtain a reference to the framer, and > use the framer. > > This basic implementation provides a framer abstraction for: > - power on/off the framer > - get the framer status (line state) > - be notified on framer status changes > - get/set the framer configuration > > Signed-off-by: Herve Codina > Reviewed-by: Christophe Leroy I love it, very clear commit message telling us what it is all about. The placement in the WAN subsystem also hints that this has something to do with long distance links (relative to something) so maybe mention that? > +menu "Framer Subsystem" > + > +config GENERIC_FRAMER > + bool "Framer Core" > + help > + Generic Framer support. > + > + This framework is designed to provide a generic interface for framer > + devices present in the kernel. This layer will have the generic > + API by which framer drivers can create framer using the framer > + framework and framer users can obtain reference to the framer. > + All the users of this framework should select this config. But this description just says this is a framing framer that frames frames ;) So please copy some of the nice description from the commit message into this Kconfig helptext. Is "long distance link time division multiplexing (TDM) framer" more to the point for example? Or is the ambition to frame other multiplexing techniques as well with this subsystem? Such as FDM? Then mention that. Yours, Linus Walleij
Re: [PATCH v6 2/3] PCI/AER: Disable AER interrupt on suspend
On Thu, Aug 10, 2023 at 04:17:21PM +0800, Kai-Heng Feng wrote:
> On Thu, Aug 10, 2023 at 2:52 AM Bjorn Helgaas wrote:
> > On Fri, Jul 21, 2023 at 11:58:24AM +0800, Kai-Heng Feng wrote:
> > > On Tue, Jul 18, 2023 at 7:17 PM Bjorn Helgaas wrote:
> > > > On Fri, May 12, 2023 at 08:00:13AM +0800, Kai-Heng Feng wrote:
> > > > > PCIe services that share an IRQ with PME, such as AER or DPC,
> > > > > may cause a spurious wakeup on system suspend. To prevent this,
> > > > > disable the AER interrupt notification during the system suspend
> > > > > process.
> > > >
> > > > I see that in this particular BZ dmesg log, PME, AER, and DPC do share
> > > > the same IRQ, but I don't think this is true in general.
> > > >
> > > > Root Ports usually use MSI or MSI-X. PME and hotplug events use the
> > > > Interrupt Message Number in the PCIe Capability, but AER uses the one
> > > > in the AER Root Error Status register, and DPC uses the one in the DPC
> > > > Capability register. Those potentially correspond to three distinct
> > > > MSI/MSI-X vectors.
> > > >
> > > > I think this probably has nothing to do with the IRQ being *shared*,
> > > > but just that putting the downstream component into D3cold, where the
> > > > link state is L3, may cause the upstream component to log and signal a
> > > > link-related error as the link goes completely down.
> > >
> > > That's quite likely a better explanation than my wording.
> > > Assuming AER IRQ and PME IRQ are not shared, does system get woken up
> > > by AER IRQ?
> >
> > Rafael could answer this better than I can, but
> > Documentation/power/suspend-and-interrupts.rst says device interrupts
> > are generally disabled during suspend after the "late" phase of
> > suspending devices, i.e.,
> >
> > dpm_suspend_noirq
> > suspend_device_irqs <-- disable non-wakeup IRQs
> > dpm_noirq_suspend_devices
> > ...
> > pci_pm_suspend_noirq # (I assume)
> > pci_prepare_to_sleep
> >
> > I think the downstream component would be put in D3cold by
> > pci_prepare_to_sleep(), so non-wakeup interrupts should be disabled by
> > then.
> >
> > I assume PME would generally *not* be disabled since it's needed for
> > wakeup, so I think any interrupt that shares the PME IRQ and occurs
> > during suspend may cause a spurious wakeup.
>
> Yes, that's the case here.
>
> > If so, it's exactly as you said at the beginning: AER/DPC/etc sharing
> > the PME IRQ may cause spurious wakeups, and we would have to disable
> > those other interrupts at the source, e.g., by clearing
> > PCI_ERR_ROOT_CMD_FATAL_EN etc (exactly as your series does).
>
> So is the series good to be merged now?
If we merge as-is, won't we disable AER & DPC interrupts unnecessarily
in the case where the link goes to D3hot? In that case, there's no
reason to expect interrupts related to the link going down, but things
like PTM messages still work, and they may cause errors that we should
know about.
> > > > I don't think D0-D3hot should be relevant here because in all those
> > > > states, the link should be active because the downstream config space
> > > > remains accessible. So I'm not sure if it's possible, but I wonder if
> > > > there's a more targeted place we could do this, e.g., in the path that
> > > > puts downstream devices in D3cold.
> > >
> > > Let me try to work on this.
> > >
> > > Kai-Heng
> > >
> > > >
> > > > > As Per PCIe Base Spec 5.0, section 5.2, titled "Link State Power
> > > > > Management",
> > > > > TLP and DLLP transmission are disabled for a Link in L2/L3 Ready
> > > > > (D3hot), L2
> > > > > (D3cold with aux power) and L3 (D3cold) states. So disabling the AER
> > > > > notification during suspend and re-enabling them during the resume
> > > > > process
> > > > > should not affect the basic functionality.
> > > > >
> > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
> > > > > Reviewed-by: Mika Westerberg
> > > > > Signed-off-by: Kai-Heng Feng
> > > > > ---
> > > > > v6:
> > > > > v5:
> > > > > - Wording.
> > > > >
> > > > > v4:
> > > > > v3:
> > > > > - No change.
> > > > >
> > > > > v2:
> > > > > - Only disable AER IRQ.
> > > > > - No more check on PME IRQ#.
> > > > > - Use helper.
> > > > >
> > > > > drivers/pci/pcie/aer.c | 22 ++
> > > > > 1 file changed, 22 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > > > > index 1420e1f27105..9c07fdbeb52d 100644
> > > > > --- a/drivers/pci/pcie/aer.c
> > > > > +++ b/drivers/pci/pcie/aer.c
> > > > > @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static int aer_suspend(struct pcie_device *dev)
> > > > > +{
> > > > > + struct aer_rpc *rpc = get_service_data(dev);
> > > > > + struct pci_dev *pdev = rpc->rpd;
> > > > > +
> > > > > + aer_disable_irq(pdev);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > >
Re: [PATCH v14 00/15] phy: Add support for Lynx 10G SerDes
Hi Sean, On Tue, Jun 13, 2023 at 05:27:54PM +0300, Vladimir Oltean wrote: > The way things are supposed to work (*if* this works at all) is that the > reset state machine starts with a supported PLL / refclk configuration > that permits a certain subset of protocols, and the SERDES protocols can > be changed from the reset state, as desired, for the individual lanes. > > What is self-inflicted is that the refclks on your board design are not > supportable by any reset state machine configuration, and wiring them > that way was a conscious decision. Did your company's board designers > receive the recommendation to disconnect RESET_REQ from NXP, and has NXP > said that the end result will be something that continues to be supportable? > I've searched the customer support database and the answer seems to be no. > In any case, if you have to disconnect RESET_REQ from the SoC to make > the driver in this form useful, then... yeah, no. You're obviously free > to do whatever you want with your products, but that's not how mainline > Linux works, it needs to be useful beyond you. > > If protocol switching works, I will maintain that your board should have > wired the refclks to PLLs the other way around (which is supported by > the RCW), and then proceed to do protocol switching to reach the desired > configuration. It was quite a journey to piece everything together. There is one thing to be mentioned right from the start, and that is that on some SoCs (including the LS1043A and LS1046A), the SerDes data path is partially controlled by the RCW, and thus, dynamically performing a major SerDes protocol reconfiguration requires a RCW override procedure (undocumented in the SerDes reconfiguration steps, but all the info you need is summarized below). The DCFG block has a set of RCWSR0 - RCWSR15 read-only status registers relative to DCFG_CCSR. What we don't document in the SoC RM, but I got permission to say here, is that the DCFG block exposes a second set of Expert Mode registers in the DCSR address space (base address 2000_h). The DCFG_DCSR register region spans from offset 2_h to 2_05AC into the DCSR base address. At the exact same offsets into DCFG_DCSR as RCWSR0 - RCWSR15 are into DCFG_CCSR (aka 100h-13ch), one can find the shadow RCWCR0 - RCWCR15 (Reset Control Word Control Register) registers which are also writable. There is a one-to-one mapping between each register (and field) in RCWSR and RCWCR, so I won't detail the contents of the RCWCR registers, because we document RCWSR fully. RCW override means modifying some of the RCWCR registers. In this particular case, finalizing the major SerDes reconfiguration requires overriding SRDS_PRTCL_S1 in RCWCR5 with the new per-lane settings, to mux the correct PCS to the MAC. In the general case, random RCW overrides that don't come from the hardware validation team are unsupported by NXP, and you should expect the procedure to yield unpredictable results. I don't know how much of the above steps is applicable to the other 10G Lynx SoCs (LS1088, LS2088 etc). Not all SoCs may require RCW override, and the RCW override procedure may not be the same. That is TBD, and we'd appreciate if support for other SoCs than the LS1046 to be added no earlier than when we have a validated SerDes reconfiguration procedure. I believe this is enough information to permit the creation of a Linux driver on the DCFG_DCSR registers which permits RCW override at runtime. It seems this will be necessary at least on LS1046. We should discuss who and when picks up your patches, removes the unsupported, untested and unnecessary code and adds the RCW override procedure. It can be you, it can also be someone from NXP. If it will be you, please let me know, because there are concrete implementation choices I want to leave comments on. There is also the previous observation from Ioana that you should not delete PHY interrupts without finding out why they don't work. Only what was thoroughly tested and is based on a hardware validated procedure should be submitted. This means only a 1G <-> 10G transition on LS1046 for now. Nonetheless, below is a functional example of how NXP would recommend you to achieve the desired PLL mapping for any RCW-based SerDes protocol. My testing platform was the LS1046A-QDS with PLL1 at 100 MHz and PLL2 at 156.25 MHz. I believe that this should eliminate the need for a clk driver for the PLLs, and should make your Ethernet lanes usable much earlier than Linux. That being said, our position at NXP is that you don't need a clk driver for the PLLs, and I would like to see the clk portion removed from future patch revisions. This patch is on top of https://github.com/nxp-qoriq/rcw/tree/lf-6.1.22-2.0.0 >From 9f90d6805883f23a898f9d66826f89b7ba73afe3 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Thu, 25 May 2023 11:23:41 +0300 Subject: [PATCH] LS1046A: implement a PBI-based SerDes protocol switching mechanism The LS1046A reset state machine
[PATCH 32/36] tty: hvc: convert counts to size_t
Unify the type of tty_operations::write() counters with the 'count'
parameter. I.e. use size_t for them.
Signed-off-by: Jiri Slaby (SUSE)
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvc_console.c | 2 +-
drivers/tty/hvc/hvcs.c| 6 +++---
drivers/tty/hvc/hvsi.c| 10 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index e93e8072ec86..959fae54ca39 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -500,7 +500,7 @@ static ssize_t hvc_write(struct tty_struct *tty, const u8
*buf, size_t count)
{
struct hvc_struct *hp = tty->driver_data;
unsigned long flags;
- int rsize, written = 0;
+ size_t rsize, written = 0;
/* This write was probably executed during a tty close. */
if (!hp)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 1de91fa23b04..d29fdfe9d93d 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -1263,8 +1263,8 @@ static ssize_t hvcs_write(struct tty_struct *tty, const
u8 *buf, size_t count)
unsigned int unit_address;
const unsigned char *charbuf;
unsigned long flags;
- int total_sent = 0;
- int tosend = 0;
+ size_t total_sent = 0;
+ size_t tosend = 0;
int result = 0;
/*
@@ -1299,7 +1299,7 @@ static ssize_t hvcs_write(struct tty_struct *tty, const
u8 *buf, size_t count)
unit_address = hvcsd->vdev->unit_address;
while (count > 0) {
- tosend = min_t(unsigned, count,
+ tosend = min_t(size_t, count,
(HVCS_BUFF_LEN - hvcsd->chars_in_buffer));
/*
* No more space, this probably means that the last call to
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index c57bd85aa488..a94068bce76f 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -909,8 +909,8 @@ static ssize_t hvsi_write(struct tty_struct *tty, const u8
*source,
{
struct hvsi_struct *hp = tty->driver_data;
unsigned long flags;
- int total = 0;
- int origcount = count;
+ size_t total = 0;
+ size_t origcount = count;
spin_lock_irqsave(>lock, flags);
@@ -928,7 +928,7 @@ static ssize_t hvsi_write(struct tty_struct *tty, const u8
*source,
* will see there is no room in outbuf and return.
*/
while ((count > 0) && (hvsi_write_room(tty) > 0)) {
- int chunksize = min_t(int, count, hvsi_write_room(tty));
+ size_t chunksize = min_t(size_t, count, hvsi_write_room(tty));
BUG_ON(hp->n_outbuf < 0);
memcpy(hp->outbuf + hp->n_outbuf, source, chunksize);
@@ -952,8 +952,8 @@ static ssize_t hvsi_write(struct tty_struct *tty, const u8
*source,
spin_unlock_irqrestore(>lock, flags);
if (total != origcount)
- pr_debug("%s: wanted %i, only wrote %i\n", __func__, origcount,
- total);
+ pr_debug("%s: wanted %zu, only wrote %zu\n", __func__,
+origcount, total);
return total;
}
--
2.41.0
Re: [PATCH v4 00/10] Introduce SMT level and add PowerPC support
Le 10/08/2023 à 08:23, Michael Ellerman a écrit : Thomas Gleixner writes: Laurent, Michael! On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's one. Thanks for getting this into shape. I've merged it into: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core and tagged it at patch 7 for consumption into the powerpc tree, so the powerpc specific changes can be applied there on top: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-for-ppc-23-07-28 Thanks. I've merged this and applied the powerpc patches on top. I've left it sitting in my topic/cpu-smt branch for the build bots to chew on: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/cpu-smt I'll plan to merge it into my next in the next day or two. Thanks Michael!
Re: [PATCH v3 22/28] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
Hi Herve, thanks for your patch! On Wed, Aug 9, 2023 at 3:28 PM Herve Codina wrote: > The Lantiq PEF2256 is a framer and line interface component designed to > fulfill all required interfacing between an analog E1/T1/J1 line and the > digital PCM system highway/H.100 bus. > > Signed-off-by: Herve Codina (...) > +patternProperties: > + '-pins$': > +type: object > +$ref: /schemas/pinctrl/pincfg-node.yaml# Shouldn't that be pinmux-node.yaml? > +additionalProperties: false > + > +properties: > + pins: > +enum: [ RPA, RPB, RPC, RPD, XPA, XPB, XPC, XPD ] > + > + function: > +enum: [ SYPR, RFM, RFMB, RSIGM, RSIG, DLR, FREEZE, RFSP, LOS, > +SYPX, XFMS, XSIG, TCLK, XMFB, XSIGM, DLX, XCLK, XLT, > +GPI, GPOH, GPOL ] > + > +required: > + - pins > + - function Because those are certainly defined in that file. Yours, Linus Walleij
Re: [PATCH v6 2/3] PCI/AER: Disable AER interrupt on suspend
On Thu, Aug 10, 2023 at 2:52 AM Bjorn Helgaas wrote:
>
> On Fri, Jul 21, 2023 at 11:58:24AM +0800, Kai-Heng Feng wrote:
> > On Tue, Jul 18, 2023 at 7:17 PM Bjorn Helgaas wrote:
> > > On Fri, May 12, 2023 at 08:00:13AM +0800, Kai-Heng Feng wrote:
> > > > PCIe services that share an IRQ with PME, such as AER or DPC,
> > > > may cause a spurious wakeup on system suspend. To prevent this,
> > > > disable the AER interrupt notification during the system suspend
> > > > process.
> > >
> > > I see that in this particular BZ dmesg log, PME, AER, and DPC do share
> > > the same IRQ, but I don't think this is true in general.
> > >
> > > Root Ports usually use MSI or MSI-X. PME and hotplug events use the
> > > Interrupt Message Number in the PCIe Capability, but AER uses the one
> > > in the AER Root Error Status register, and DPC uses the one in the DPC
> > > Capability register. Those potentially correspond to three distinct
> > > MSI/MSI-X vectors.
> > >
> > > I think this probably has nothing to do with the IRQ being *shared*,
> > > but just that putting the downstream component into D3cold, where the
> > > link state is L3, may cause the upstream component to log and signal a
> > > link-related error as the link goes completely down.
> >
> > That's quite likely a better explanation than my wording.
> > Assuming AER IRQ and PME IRQ are not shared, does system get woken up
> > by AER IRQ?
>
> Rafael could answer this better than I can, but
> Documentation/power/suspend-and-interrupts.rst says device interrupts
> are generally disabled during suspend after the "late" phase of
> suspending devices, i.e.,
>
> dpm_suspend_noirq
> suspend_device_irqs <-- disable non-wakeup IRQs
> dpm_noirq_suspend_devices
> ...
> pci_pm_suspend_noirq # (I assume)
> pci_prepare_to_sleep
>
> I think the downstream component would be put in D3cold by
> pci_prepare_to_sleep(), so non-wakeup interrupts should be disabled by
> then.
>
> I assume PME would generally *not* be disabled since it's needed for
> wakeup, so I think any interrupt that shares the PME IRQ and occurs
> during suspend may cause a spurious wakeup.
Yes, that's the case here.
>
> If so, it's exactly as you said at the beginning: AER/DPC/etc sharing
> the PME IRQ may cause spurious wakeups, and we would have to disable
> those other interrupts at the source, e.g., by clearing
> PCI_ERR_ROOT_CMD_FATAL_EN etc (exactly as your series does).
So is the series good to be merged now?
Kai-Heng
>
> > > I don't think D0-D3hot should be relevant here because in all those
> > > states, the link should be active because the downstream config space
> > > remains accessible. So I'm not sure if it's possible, but I wonder if
> > > there's a more targeted place we could do this, e.g., in the path that
> > > puts downstream devices in D3cold.
> >
> > Let me try to work on this.
> >
> > Kai-Heng
> >
> > >
> > > > As Per PCIe Base Spec 5.0, section 5.2, titled "Link State Power
> > > > Management",
> > > > TLP and DLLP transmission are disabled for a Link in L2/L3 Ready
> > > > (D3hot), L2
> > > > (D3cold with aux power) and L3 (D3cold) states. So disabling the AER
> > > > notification during suspend and re-enabling them during the resume
> > > > process
> > > > should not affect the basic functionality.
> > > >
> > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
> > > > Reviewed-by: Mika Westerberg
> > > > Signed-off-by: Kai-Heng Feng
> > > > ---
> > > > v6:
> > > > v5:
> > > > - Wording.
> > > >
> > > > v4:
> > > > v3:
> > > > - No change.
> > > >
> > > > v2:
> > > > - Only disable AER IRQ.
> > > > - No more check on PME IRQ#.
> > > > - Use helper.
> > > >
> > > > drivers/pci/pcie/aer.c | 22 ++
> > > > 1 file changed, 22 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > > > index 1420e1f27105..9c07fdbeb52d 100644
> > > > --- a/drivers/pci/pcie/aer.c
> > > > +++ b/drivers/pci/pcie/aer.c
> > > > @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
> > > > return 0;
> > > > }
> > > >
> > > > +static int aer_suspend(struct pcie_device *dev)
> > > > +{
> > > > + struct aer_rpc *rpc = get_service_data(dev);
> > > > + struct pci_dev *pdev = rpc->rpd;
> > > > +
> > > > + aer_disable_irq(pdev);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int aer_resume(struct pcie_device *dev)
> > > > +{
> > > > + struct aer_rpc *rpc = get_service_data(dev);
> > > > + struct pci_dev *pdev = rpc->rpd;
> > > > +
> > > > + aer_enable_irq(pdev);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > /**
> > > > * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
> > > > * @dev: pointer to Root Port, RCEC, or RCiEP
> > > > @@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver
> > > > = {
> > > > .service= PCIE_PORT_SERVICE_AER,
> > > >
> > > >
Re: [PATCH v4 00/10] Introduce SMT level and add PowerPC support
Thomas Gleixner writes: > Laurent, Michael! > > On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: >> I'm taking over the series Michael sent previously [1] which is smartly >> reviewing the initial series I sent [2]. This series is addressing the >> comments sent by Thomas and me on the Michael's one. > > Thanks for getting this into shape. > > I've merged it into: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core > > and tagged it at patch 7 for consumption into the powerpc tree, so the > powerpc specific changes can be applied there on top: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > smp-core-for-ppc-23-07-28 Thanks. I've merged this and applied the powerpc patches on top. I've left it sitting in my topic/cpu-smt branch for the build bots to chew on: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/cpu-smt I'll plan to merge it into my next in the next day or two. cheers
Re: [PATCH] powerpc/ep8248e: Mark driver as non removable
On Wed, 26 Jul 2023 10:14:42 +0200, Uwe Kleine-König wrote: > Instead of resorting to BUG() ensure that the driver isn't unbound by > suppressing its bind and unbind sysfs attributes. As the driver is > built-in there is no way to remove a device once bound. > > As a nice side effect this allows to drop the remove function. > > > [...] Applied to powerpc/next. [1/1] powerpc/ep8248e: Mark driver as non removable https://git.kernel.org/powerpc/c/bbfa509d632946578d4f19aa2cedf1ca2f34565d cheers
Re: [PATCH v3] powerpc: Explicitly include correct DT includes
On Mon, 24 Jul 2023 15:02:42 -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > [...] Applied to powerpc/next. [1/1] powerpc: Explicitly include correct DT includes https://git.kernel.org/powerpc/c/81d7cac4d11cc65f29be68c72759429d5194347a cheers
Re: [PATCH v3 0/9] Cleanup/Optimise KUAP (v3)
On Tue, 11 Jul 2023 17:59:12 +0200, Christophe Leroy wrote: > This series is cleaning up a bit KUAP in preparation of using objtool > to validate UACCESS. > > There are two main changes in this series: > > 1/ Simplification of KUAP on book3s/32 > > [...] Applied to powerpc/next. [1/9] powerpc/kuap: Avoid unnecessary reads of MD_AP https://git.kernel.org/powerpc/c/880df2d46a3f23f30f954f6e64c576d7f411cc46 [2/9] powerpc/kuap: Avoid useless jump_label on empty function https://git.kernel.org/powerpc/c/1bec4adcd59e923df6b7f5d492a9e4b8dfd22039 [3/9] powerpc/kuap: Fold kuep_is_disabled() into its only user https://git.kernel.org/powerpc/c/38bb171b958480b484e8e980be76c7d3656881ea [4/9] powerpc/features: Add capability to update mmu features later https://git.kernel.org/powerpc/c/6b289911c80d45fd8da3d24ea14706361381b78d [5/9] powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP https://git.kernel.org/powerpc/c/4589a2b7894d4266380b65e13291f609cf19dd19 [6/9] powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap https://git.kernel.org/powerpc/c/26e041208291bfdea1cb9e26bc94a0f9499efe15 [7/9] powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32 https://git.kernel.org/powerpc/c/5222a1d5142ec4f9ec063b274b80e20639584dbc [8/9] powerpc/kuap: KUAP enabling/disabling functions must be __always_inline https://git.kernel.org/powerpc/c/eb52f66f0abd468caf8be4e690d7fdef96250c2f [9/9] powerpc/kuap: Use ASM feature fixups instead of static branches https://git.kernel.org/powerpc/c/3a24ea0df83e32355d897a18bbd82e05986dcdc3 cheers
Re: [PATCH 1/2] powerpc/crypto: fix missing skcipher dependency for aes-gcm-p10
On Mon, 10 Jul 2023 09:46:46 -0700, Omar Sandoval wrote: > My stripped down configuration fails to build with: > > ERROR: modpost: "skcipher_walk_aead_encrypt" > [arch/powerpc/crypto/aes-gcm-p10-crypto.ko] undefined! > ERROR: modpost: "skcipher_walk_done" > [arch/powerpc/crypto/aes-gcm-p10-crypto.ko] undefined! > ERROR: modpost: "skcipher_walk_aead_decrypt" > [arch/powerpc/crypto/aes-gcm-p10-crypto.ko] undefined! > > Fix it by selecting CRYPTO_SKCIPHER. > > [...] Applied to powerpc/next. [1/2] powerpc/crypto: fix missing skcipher dependency for aes-gcm-p10 https://git.kernel.org/powerpc/c/9d6e1c21e1be4643628ee343e0b8d79828485ba2 [2/2] powerpc/crypto: don't build aes-gcm-p10 by default https://git.kernel.org/powerpc/c/026fa6c52da5fc559d896a62cb6f8e208c22738d cheers
Re: [PATCH 0/4] powerpc: mm_cpumask cleanups and lazy tlb mm
On Wed, 24 May 2023 16:08:17 +1000, Nicholas Piggin wrote: > In the process of doing patch 4, I found a few things we could improve > and tighten up with mm_cpumask handling, so added those first. They're > mostly just debugging, no real fixes or dependency on patch 4 there. > > Thanks, > Nick > > [...] Applied to powerpc/next. [1/4] powerpc: Account mm_cpumask and active_cpus in init_mm https://git.kernel.org/powerpc/c/c3c2e93753484bb4e935ed8205c1f569907f5970 [2/4] powerpc/64s: Use dec_mm_active_cpus helper https://git.kernel.org/powerpc/c/f74b2a6c01a0b319070ccee7dea0cc4dad694041 [3/4] powerpc: Add mm_cpumask warning when context switching https://git.kernel.org/powerpc/c/177255afb40548fdf504384b361d18d6cbe35d1e [4/4] powerpc/64s/radix: combine final TLB flush and lazy tlb mm shootdown IPIs https://git.kernel.org/powerpc/c/e43c0a0c3c2870e1ee29519dc249471adf19ab5f cheers
Re: [PATCH] powerpc/64: Enable accelerated crypto algorithms in defconfig
On Mon, 17 Jul 2023 21:52:23 +1000, Michael Ellerman wrote: > Enable all the acclerated crypto algorithms as modules in the 64-bit > defconfig, to get more test coverage. > > Applied to powerpc/next. [1/1] powerpc/64: Enable accelerated crypto algorithms in defconfig https://git.kernel.org/powerpc/c/ab481817912ec5c882a6a42ce12c57aed3cfd506 cheers
Re: [PATCH] powerpc/kexec: fix minor typo
On Tue, 25 Jul 2023 15:27:59 +0200, Laurent Dufour wrote: > Function name in the descriptor was not correct. > > Applied to powerpc/next. [1/1] powerpc/kexec: fix minor typo https://git.kernel.org/powerpc/c/7f96539437eafec8fd062fb13f31cf53251ea18d cheers
Re: (subset) [PATCH v1 0/4] Improve ptrace selftest usability
On Tue, 25 Jul 2023 10:58:37 +1000, Benjamin Gray wrote: > While trying to test changes to the breakpoint implementation in the kernel, I > tried to run the ptrace tests and met many unexplained skips and failures. > > This series addresses the pain points of trying to run these tests and learn > what they are doing. > > Benjamin Gray (4): > Documentation/powerpc: Fix ptrace request names > selftests/powerpc/ptrace: Explain why tests are skipped > selftests/powerpc/ptrace: Fix typo in pid_max search error > selftests/powerpc/ptrace: Declare test temporary variables as volatile > > [...] Applied to powerpc/next. [2/4] selftests/powerpc/ptrace: Explain why tests are skipped https://git.kernel.org/powerpc/c/68877ff20a7f4f773069784cfe4f6fe9c7b9a841 [3/4] selftests/powerpc/ptrace: Fix typo in pid_max search error https://git.kernel.org/powerpc/c/fc6732a8556c1099b89f4777a96bd6a1ae5a4378 [4/4] selftests/powerpc/ptrace: Declare test temporary variables as volatile https://git.kernel.org/powerpc/c/c3062ede9927053754ba27b280afe00b9b31b37a cheers
Re: [PATCH] powerpc: address missing-prototypes warnings
On Thu, 27 Jul 2023 14:26:50 +0200, Arnd Bergmann wrote: > There are a few warnings in powerpc64 defconfig builds after > -Wmissing-prototypes > gets promoted from W=1 to the default warning set: > > arch/powerpc/mm/book3s64/pgtable.c:422:6: error: no previous prototype for > 'arch_report_meminfo' [-Werror=missing-prototypes] > arch/powerpc/mm/init_64.c:311:12: error: no previous prototype for > '__vmemmap_free' [-Werror=missing-prototypes] > arch/powerpc/platforms/cell/ras.c:275:5: error: no previous prototype for > 'cbe_sysreset_hack' [-Werror=missing-prototypes] > arch/powerpc/platforms/cell/spu_manage.c:29:21: error: no previous prototype > for 'spu_devnode' [-Werror=missing-prototypes] > arch/powerpc/platforms/pasemi/time.c:12:17: error: no previous prototype for > 'pas_get_boot_time' [-Werror=missing-prototypes] > arch/powerpc/platforms/powermac/feature.c:1532:13: error: no previous > prototype for 'g5_phy_disable_cpu1' [-Werror=missing-prototypes] > arch/powerpc/platforms/86xx/pic.c:28:13: error: no previous prototype for > 'mpc86xx_init_irq' [-Werror=missing-prototypes] > drivers/pci/pci-sysfs.c:936:13: error: no previous prototype for > 'pci_adjust_legacy_attr' [-Werror=missing-prototypes] > > [...] Applied to powerpc/next. [1/1] powerpc: address missing-prototypes warnings https://git.kernel.org/powerpc/c/54f30b83fe627453082f15d83d7820b28b2d24bb cheers
