Re: [Bisected] PowerMac G4 getting "BUG: Unable to handle kernel data access on write at 0x00001ff0" at boot with CONFIG_VMAP_STACK=y on kernels 6.5.x (regression over 6.4.x)

[Bagas Sanjaya]

On Tue, Sep 26, 2023 at 01:01:59AM +0200, Erhard Furtner wrote:
> Greetings!
> 
> Had a chat on #gentoo-powerpc with another user whose G4 Mini fails booting 
> kernel 6.5.0 when CONFIG_VMAP_STACK=y is enabled. I was able to replicate the 
> issue on my PowerMac G4. Also I was able to bisect the issue.
> 
> Kernels 6.4.x boot ok with CONFIG_VMAP_STACK=y but on 6.5.5 I get:
> 
> [...]
> Kernel attempted to write user page (1ff0) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel data access on write at 0x1ff0
> Faulting instruction address: 0xc0008750
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MMU=Hash PowerMac
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.5-PMacG4 #5
> Hardware name: PowerMac3,6 7455 0x80010303 PowerMac
> NIP:  c0008750 LR: c0041848 CTR: c0070988
> REGS: c0d3dcd0 TRAP: 0300   Not tainted (6.5.5-PMacG4)
> MSR:  1032   CR: 22d3ddc0 XER: 2000
> DAR: 1ff0 DSISR: 4200
> GPR00: c0041848 c0d3dd90 c0d06360 c0d3ddd0 c0d06360 c0d3dea8 c0d3adc0 
> GPR08:  c0d4  c0d3ddc0    0004
> GPR16: 0002  0002 00402dc2 00402dc2 2000 f1004000 
> GPR24: c0d45220 c0d06644 c0843c34 0002 c0d06360 c0d0ce00 c0d06360 
> NIP [c0008750] do_softirq_own_stack+0x18/0x3c
> LR [c0041848] irq_exit+0x98/0xc4
> Call Trace:
> [c0d3dd90] [c0d69564] 0xc0d69564 (unreliable)
> [c0d3ddb0] [c0041848] irq_exit+0x98/0xc4
> [c0d3ddc0] [c0004a98] Decrementer_virt+0x108/0x10c
> --- interrupt: 900 at __schedule+0x43c/0x4e0
> NIP:  c0843940 LR: c084398c CTR: c0070988
> REGS: c0d3ddd0 TRAP: 0900   Not tainted  (6.5.5-PMacG4)
> MSR:  9032   CR: 22024484  XER: 
> 
> GPR00: c0843574 c0d3de90 c0d06360 c0d06360 c0d06360 c0d3dea8 0001 
> GPR08:  9032 c099ce2c 0007ffbf 22024484   0004
> GPR16: 0002  0002 00402dc2 00402dc2 2000 f1004000 
> GPR24: c0d45220 c0d06644 c0843c34 0002 c0d06360 c0d0ce00 c0d06360 c0d063ac
> NIP [c0843940] __schedule+0x43c/0x4e0
> LR [c084390c] __schedule+0x408/0x4e0
> --- interrupt: 900
> [c0d3de90] [c0843574] __schedule+0x70/0x4e0 (unreliable)
> [c0d3ded0] [c0843c34] __cond_resched+0x34/0x54
> [c0d3dee0] [c0141068] __vmalloc_node_range+0x27c/0x64c
> [c0d3de60] [c0141794] __vmalloc_node+0x44/0x54
> [c8d3df80] [c0c06510] init_IRQ+0x34/0xd4
> [c8d3dfa0] [c0c03440] start_kernel+0x424/0x558
> [c8d3dff0] [3540] 0x3540
> Code: 39490999 7d4901a4 39290aaa 7d2a01a4 4c00012c 4b20 9421ffe0 
> 7c08002a6 3d20c0d4 93e1001c 90010024 83e95278 <943f1ff0> 7fe1fb78 48840c6d 
> 8021
> ---[ end trace  ]---
> 
> Kernel panic - not syncing: Attempted to kill the idle task!
> Rebooting in 48 seconds..
> 
> 
> The bisect revealed this commit:
>  # git bisect good
> cfeb6ae8bcb96ccf674724f223661bbcef7b0d0b is the first bad commit
> commit cfeb6ae8bcb96ccf674724f223661bbcef7b0d0b
> Author: Liam R. Howlett 
> Date:   Fri Aug 18 20:43:55 2023 -0400
> 
> maple_tree: disable mas_wr_append() when other readers are possible
> 
> The current implementation of append may cause duplicate data and/or
> incorrect ranges to be returned to a reader during an update.  Although
> this has not been reported or seen, disable the append write operation
> while the tree is in rcu mode out of an abundance of caution.
> 
> During the analysis of the mas_next_slot() the following was
> artificially created by separating the writer and reader code:
> 
> Writer: reader:
> mas_wr_append
> set end pivot
> updates end metata
> Detects write to last slot
> last slot write is to start of slot
> store current contents in slot
> overwrite old end pivot
> mas_next_slot():
> read end metadata
> read old end pivot
> return with incorrect 
> range
> store new value
> 
> Alternatively:
> 
> Writer: reader:
> mas_wr_append
> set end pivot
> updates end metata
> Detects write to last slot
> last lost write to end of slot
> store value
> mas_next_slot():
> read end metadata
> read old end pivot
> read new end pivot
> return with incorrect 
> range
> set old end pivot
> 
> There may be other accesses that are not safe since we are now updating
> both metadata and pointers, so disabling append if there could be rcu
> readers i

Re: [Bisected] PowerMac G5 fails booting kernel 6.6-rc3 (BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe)

[Bagas Sanjaya]

On Fri, Sep 29, 2023 at 01:27:50PM +0200, Erhard Furtner wrote:
> Greetings!
> 
> Kernel 6.5.5 boots fine on my PowerMac G5 11,2 but kernel 6.6-rc3 fails to 
> boot with following dmesg shown on the OpenFirmware console (transcribed 
> screenshot):
> 
> [...]
> SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> rcu: Hierarchical RCU implementation.
>  Tracing variant of Tasks RCU enabled.
> rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies.
> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
> mpic: Setting up MPIC " MPIC 1   " version 1.2 at f804, max 2 CPUs
> mpic: ISU size: 124, shift: 7, mask: 7f
> mpic: Initializing for 124 sources
> mpic: Setting up HT PICs workarounds for U3/U4
> BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe
> Faulting instruction address: 0xc005dc40
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT  6.6.0-rc3-PMacGS #1
> Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac
> NIP:  c005dc40 LR: c000 CTR: c0007730
> REGS: c22bf510 TRAP: 0380   Tainted: GT 
> (6.6.0-rc3-PMacGS)
> MSR:  90001032   CR: 44004242  XER: 
> IRQMASK: 3
> GPR00:  c22bf7b0 c10c0b00 01ac
> GPR04: 03c8 0300 c000f20001ae 0300
> GPR08: 0006 feffbb62ffec65ff 0001 
> GPR12: 90001032 c2362000 c0f76b80 0349ecd8
> GPR16: 02367ba8 02367f08 0006 
> GPR20: 01ac c0f6f920 c22cd985 000c
> GPR24: 0300 0003b0a3691d c0003e00803e 
> GPR28: c00c c000f20001ee feffbb62ffec65fe 01ac
> NIP [c005dc40] hash_page_do_lazy_icache+0x50/0x100
> LR [c000] __hash_page_4K+0x420/0x590
> Call Trace:
> [c22bf7e0] [] 0x
> [c22bf8c0] [c005e164] hash_page_mm+0x364/0x6f0
> [c22bf990] [c005e684] do_hash_fault+0x114/0x2b0
> [c22bf9c0] [c00078e8] data_access_common_virt+0x198/0x1f0
> --- interrupt: 300 at mpic_init+0x4bc/0x10c4
> NIP:  c2020a5c LR: c2020a04 CTR: 
> REGS: c22bf9f0 TRAP: 0300   Tainted: GT 
> (6.6.0-rc3-PMacGS)
> MSR:  90001032   CR: 24004248  XER: 
> DAR: c0003e00803e DSISR: 4000 IRQMASK: 1
> GPR00:  c22bfc90 c10c0b00 c0003e008030
> GPR04:    
> GPR08:  221b80894c06df2f  
> GPR12:  c2362000 c0f76b80 0349ecd8
> GPR16: 02367ba8 02367f08 02367c70 
> GPR20: 567ce25e8c9202b7 c0f6f920 0001 c0003e008030
> GPR24: c226f348 0004 c404c640 
> GPR28: c0003e008030 c404c000 45886d8559cb69b4 c22bfc90
> NIP [c005dc40] mpic_init+0x4bc/0x10c4
> LR [c000] mpic_init+0x464/0x10c4
> ~~~ interrupt: 300
> [c22bfd90] [c2022ae4] pmac_setup_one_mpic+0x258/0x2dc
> [c22bf2e0] [c2022df4] pmac_pic_init+0x28c/0x3d8
> [c22bfef0] [c200b750] init_IRQ+0x90/0x140
> [c22bff30] [c20053c0] start_kernel+0x57c/0x78c
> [c22bffe0] [c000cb48] start_here_common+0x1c/0x20
> Code: 0929 7c292040 4081007c fbc10020 3d220127 78843664 3929d700 ebc9 
> 7fde2214 e93e 712a0001 40820064  71232000 40820048 e93e
> ---[ end trace  ]---
> 
> Kernel panic - not syncing: Fatal exception
> Rebooting in 40 seconds..
> 
> 
> I bisected the issue and got 9fee28baa601f4dbf869b1373183b312d2d5ef3d as 1st 
> bad commit:
> 
>  # git bisect good
> 9fee28baa601f4dbf869b1373183b312d2d5ef3d is the first bad commit
> commit 9fee28baa601f4dbf869b1373183b312d2d5ef3d
> Author: Matthew Wilcox (Oracle) 
> Date:   Wed Aug 2 16:13:49 2023 +0100
> 
> powerpc: implement the new page table range API
> 
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().  Change
> the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to per-folio.
> 
> [wi...@infradead.org: re-export flush_dcache_icache_folio()]
>   Link: https://lkml.kernel.org/r/zmx1daywvd9em...@casper.infradead.org
> Link: 
> https://lkml.kernel.org/r/20230802151406.3735276-22-wi...@infradead.org
> Signed-off-by: Matthew Wilcox (Oracle) 
> Acked-by: Mike Rapoport (IBM) 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> Signed-off-by: Andrew Morton 
> 
>  arch/powerpc/include/asm/book3s/32/pgtabl

Re: [Bisected] PowerMac G5 fails booting kernel 6.6-rc3 (BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe)

[Bagas Sanjaya]

On 06/10/2023 08:19, Matthew Wilcox wrote:
> On Fri, Oct 06, 2023 at 08:11:12AM +0700, Bagas Sanjaya wrote:
>> Matthew Wilcox, did you miss this regression report? You should look into it
>> since it is (apparently) cause by a commit of yours.
> 
> No, I didn't miss it.  I'm simply choosing to work on other things.
> All this regression tracking nonsense and being told to work on things
> by people who've appointed themselves my manager has completely sapped
> my motivation to work on bugs.  If you want me to work on things, *don't*
> harass me.
> 

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara

Fwd: The PCIe AER error flood between PCIe bridge and Realtek's RTL8723BE makes system hang

[Bagas Sanjaya]

Hi,

I notice a bug report on Bugzilla [1]. Quoting from it:

> We have an ASUS X555UQ laptop equipped with Intel i7-6500U CPU and Realtek 
> RTL8723BE PCIe Wireless adapter.
> 
> We tested it with kernel 6.6.  System keeps showing AER error message flood, 
> even hangs up, until rtl8723be's ASPM is disabled.
> 
> kernel: pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, 
> type=Physical Layer, (Receiver ID)
> kernel: pcieport :00:1c.5:   device [8086:9d15] error 
> status/mask=0001/2000
> kernel: pcieport :00:1c.5:[ 0] RxErr  (First)
> kernel: pcieport :00:1c.5: AER: Corrected error received: :00:1c.5
> kernel: pcieport :00:1c.5: AER: can't find device of ID00e5
> kernel: pcieport :00:1c.5: AER: Corrected error received: :00:1c.5
> kernel: pcieport :00:1c.5: AER: can't find device of ID00e5
> kernel: pcieport :00:1c.5: AER: Multiple Corrected error received: 
> :00:1c.5
> kernel: pcieport :00:1c.5: AER: can't find device of ID00e5
> 
> Here is the PCI tree:
> $ lspci -tv
> -[:00]-+-00.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
> Processor Host Bridge/DRAM Registers
>+-02.0  Intel Corporation Skylake GT2 [HD Graphics 520]
>+-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
> Processor Thermal Subsystem
>+-14.0  Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
>+-14.2  Intel Corporation Sunrise Point-LP Thermal subsystem
>+-15.0  Intel Corporation Sunrise Point-LP Serial IO I2C 
> Controller #0
>+-15.1  Intel Corporation Sunrise Point-LP Serial IO I2C 
> Controller #1
>+-16.0  Intel Corporation Sunrise Point-LP CSME HECI #1
>+-17.0  Intel Corporation Sunrise Point-LP SATA Controller [AHCI 
> mode]
>+-1c.0-[01]00.0  NVIDIA Corporation GM108M [GeForce 940MX]
>+-1c.4-[02]00.0  Realtek Semiconductor Co., Ltd. 
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>+-1c.5-[03]00.0  Realtek Semiconductor Co., Ltd. RTL8723BE 
> PCIe Wireless Network Adapter
>+-1f.0  Intel Corporation Sunrise Point-LP LPC Controller
>+-1f.2  Intel Corporation Sunrise Point-LP PMC
>+-1f.3  Intel Corporation Sunrise Point-LP HD Audio
>\-1f.4  Intel Corporation Sunrise Point-LP SMBus

And then the reporter found that it was ASPM bug:

> Notice a long time ago discussion mail: Dmesg filled with "AER: Corrected 
> error received" [1]
> 
> So, I force write 1 to clear Receiver Error Status bit of Correctable Error 
> Status Register, like
> 
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 9c8fd69ae5ad..39faedd2ec8e 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1141,8 +1160,9 @@ static void aer_isr_one_error(struct aer_rpc *rpc,
> e_info.multi_error_valid = 0;
> aer_print_port_info(pdev, &e_info);
>  
> -   if (find_source_device(pdev, &e_info))
> -   aer_process_err_devices(&e_info);
> +   //if (find_source_device(pdev, &e_info))
> +   //  aer_process_err_devices(&e_info);
> +   pci_write_config_dword(pdev, pdev->aer_cap + 
> PCI_ERR_COR_STATUS, 0x1);
> }
>  
> if (e_src->status & PCI_ERR_ROOT_UNCOR_RCV) {
> 
> Then, system should clear the error right away.  However, system still get 
> the AER flood ...
> 
> Seems that we still have to disable rtl8723be's ASPM.

See Bugzilla for the full thread and attached full kernel logs.

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218127

-- 
An old man doll... just what I always wanted! - Clara

Fwd: Memory corruption in multithreaded user space program while calling fork

[Bagas Sanjaya]

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:

> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent but 
> random crashes in a user space program.  After a lot of reduction, I have 
> come up with the following reproducer program:
> 
> $ uname -a
> Linux jacob 6.4.1-gentoo #1 SMP PREEMPT_DYNAMIC Sat Jul  1 19:02:42 EDT 2023 
> x86_64 AMD Ryzen 9 7950X3D 16-Core Processor AuthenticAMD GNU/Linux
> $ cat repro.c
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> 
> void *threadSafeAlloc(size_t n) {
> static size_t end_index = 0;
> static char buffer[1 << 25];
> size_t start_index = __atomic_load_n(&end_index, __ATOMIC_SEQ_CST);
> while (1) {
> if (start_index + n > sizeof(buffer)) _exit(1);
> if (__atomic_compare_exchange_n(&end_index, &start_index, start_index 
> + n, 1, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST)) return buffer + start_index;
> }
> }
> 
> int thread(void *arg) {
> size_t i;
> size_t n = 1 << 7;
> char *items;
> (void)arg;
> while (1) {
> items = threadSafeAlloc(n);
> for (i = 0; i != n; i += 1) items[i] = '@';
> for (i = 0; i != n; i += 1) if (items[i] != '@') _exit(2);
> }
> }
> 
> int main(void) {
> static size_t stacks[2][1 << 9];
> size_t i;
> for (i = 0; i != 2; i += 1) clone(&thread, &stacks[i] + 1, CLONE_THREAD | 
> CLONE_VM | CLONE_SIGHAND, NULL);
> while (1) {
> if (fork() == 0) _exit(0);
> (void)wait(NULL);
> }
> }
> $ cc repro.c
> $ ./a.out
> $ echo $?
> 2
> 
> After tuning the various parameters for my computer, exit code 2, which 
> indicates that memory corruption was detected, occurs approximately 99% of 
> the time.  Exit code 1, which occurs approximately 1% of the time, means it 
> ran out of statically-allocated memory before reproducing the issue, and 
> increasing the memory usage any more only leads to diminishing returns.  
> There is also something like a 0.1% chance that it segfaults due to memory 
> corruption elsewhere than in the statically-allocated buffer.
> 
> With this reproducer in hand, I was able to perform the following bisection:
> 
> git bisect start
> # status: waiting for both good and bad commits
> # bad: [6995e2de6891c724bfeb2db33d7b87775f913ad1] Linux 6.4
> git bisect bad 6995e2de6891c724bfeb2db33d7b87775f913ad1
> # status: waiting for good commit(s), bad commit known
> # good: [457391b0380335d5e9a5babdec90ac53928b23b4] Linux 6.3
> git bisect good 457391b0380335d5e9a5babdec90ac53928b23b4
> # good: [d42b1c47570eb2ed818dc3fe94b2678124af109d] Merge tag 
> 'devicetree-for-6.4-1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> git bisect good d42b1c47570eb2ed818dc3fe94b2678124af109d
> # bad: [58390c8ce1bddb6c623f62e7ed36383e7fa5c02f] Merge tag 
> 'iommu-updates-v6.4' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
> git bisect bad 58390c8ce1bddb6c623f62e7ed36383e7fa5c02f
> # good: [888d3c9f7f3ae44101a3fd76528d3dd6f96e9fd0] Merge tag 'sysctl-6.4-rc1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux
> git bisect good 888d3c9f7f3ae44101a3fd76528d3dd6f96e9fd0
> # bad: [86e98ed15b3e34460d1b3095bd119b6fac11841c] Merge tag 'cgroup-for-6.4' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
> git bisect bad 86e98ed15b3e34460d1b3095bd119b6fac11841c
> # bad: [7fa8a8ee9400fe8ec188426e40e481717bc5e924] Merge tag 
> 'mm-stable-2023-04-27-15-30' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> git bisect bad 7fa8a8ee9400fe8ec188426e40e481717bc5e924
> # bad: [0120dd6e4e202e19a0e011e486fb2da40a5ea279] zram: make zram_bio_discard 
> more self-contained
> git bisect bad 0120dd6e4e202e19a0e011e486fb2da40a5ea279
> # good: [fce0b4213edb960859dcc65ea414c8efb11948e1] mm/page_alloc: add helper 
> for checking if check_pages_enabled
> git bisect good fce0b4213edb960859dcc65ea414c8efb11948e1
> # bad: [59f876fb9d68a4d8c20305d7a7a0daf4ee9478a8] mm: avoid passing 0 to 
> __ffs()
> git bisect bad 59f876fb9d68a4d8c20305d7a7a0daf4ee9478a8
> # good: [0050d7f5ee532f92e8ab1efcec6547bfac527973] afs: split 
> afs_pagecache_valid() out of afs_validate()
> git bisect good 0050d7f5ee532f92e8ab1efcec6547bfac527973
> # good: [2ac0af1b66e3b66307f53b1cc446514308ec466d] mm: fall back to mmap_lock 
> if vma->anon_vma is not yet set
> git bisect good 2ac0af1b66e3b66307f53b1cc446514308ec466d
> # skip: [0d2ebf9c3f7822e7ba3e4792ea3b6b19aa2da34a] mm/mmap: free 
> vm_area_struct without call_rcu in exit_mmap
> git bisect skip 0d2ebf9c3f7822e7ba3e4792ea3b6b19aa2da34a
> # skip: [70d4cbc80c88251de0a5b3e8df3275901f1fa99a] powerc/mm: try VMA 
> lock-based page fault handling first
> git bisect skip 70d4cbc80c88251de0a5b3e8df3275901f1fa99a
> # good: [444eeb17437a0ef526c606e9141a415d3b7dfddd] mm: prevent userfaults to 
> be handled under per-vma lock
> git bisect good 444eeb17437a0ef526c606e9141a415d3b7dfddd
> # bad: [e06f47a16573decc57498f2d02f9af3bb3e84cf2] s390/mm: try VMA lock

Re: Memory corruption in multithreaded user space program while calling fork

[Bagas Sanjaya]

On 7/2/23 19:40, Jacob Young wrote:
>> Jacob: Can you repeat bisection please? Why did you skip VMA lock-based
> page fault commits in your bisection?
> 
> All skips were due to compile errors of the form:
> make[3]: 'install_headers' is up to date.
> In file included from ./include/linux/memcontrol.h:20,
>                  from ./include/linux/swap.h:9,
>                  from ./include/linux/suspend.h:5,
>                  from arch/x86/kernel/asm-offsets.c:14:
> ./include/linux/mm.h: In function ‘vma_try_start_write’:
> ./include/linux/mm.h:702:37: error: ‘struct vm_area_struct’ has no member 
> named ‘vm_lock’
>   702 |         if (!down_write_trylock(&vma->vm_lock->lock))
>       |                                     ^~
> ./include/linux/mm.h:706:22: error: ‘struct vm_area_struct’ has no member 
> named ‘vm_lock’
>   706 |         up_write(&vma->vm_lock->lock);
>       |                      ^~
> make[1]: *** [scripts/Makefile.build:114: arch/x86/kernel/asm-offsets.s] 
> Error 1
> make: *** [Makefile:1286: prepare0] Error 2
> 

1. Please don't send HTML emails as mailing lists reject them.
2. Reply inline with appropriate context, rather than top-post reply.

-- 
An old man doll... just what I always wanted! - Clara

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Bagas Sanjaya]

On Thu, Jul 13, 2023 at 09:11:10AM -0700, Randy Dunlap wrote:
> 
> 
> On 7/12/23 19:37, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20230712:
> > 
> 
> on ppc64:
> 
> In file included from ../include/linux/device.h:15,
>  from ../arch/powerpc/include/asm/io.h:22,
>  from ../include/linux/io.h:13,
>  from ../include/linux/irq.h:20,
>  from ../arch/powerpc/include/asm/hardirq.h:6,
>  from ../include/linux/hardirq.h:11,
>  from ../include/linux/interrupt.h:11,
>  from ../drivers/video/fbdev/ps3fb.c:25:
> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member 
> named 'dev'
>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>   |^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
> 'dev_printk_index_wrap'
>   110 | _p_func(dev, fmt, ##__VA_ARGS__); 
>   \
>   | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
> memory\n",
>   | ^~~~
> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member 
> named 'dev'
>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>   | ^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
> 'dev_printk_index_wrap'
>   110 | _p_func(dev, fmt, ##__VA_ARGS__); 
>   \
>   | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
> memory\n",
>   | ^~~~
> 
> 

Hmm, there is no response from Thomas yet. I guess we should go with
reverting bdb616479eff419, right? Regardless, I'm adding this build regression
to regzbot so that parties involved are aware of it:

#regzbot ^introduced: bdb616479eff419
#regzbot title: build regression in PS3 framebuffer

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Bagas Sanjaya]

On 7/18/23 17:06, Thorsten Leemhuis wrote:
> I'm missing something here:
> 
> * What makes you think this is caused by bdb616479eff419? I didn't see
> anything in the thread that claims this, but I might be missing something
> * related: if I understand Randy right, this is only happening in -next;
> so why is bdb616479eff419 the culprit, which is also in mainline since
> End of June?
> 

Actually drivers/video/fbdev/ps3bf.c only had two non-merge commits during
previous cycle: 25ec15abb06194 and bdb616479eff419. The former was simply
adding .owner field in ps3fb_ops (hence trivial), so I inferred that the
culprit was likely the latter (due to it was being authored by Thomas).

Thanks for the question.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] floppy: ERROR: that open brace { should be on the previous line

[Bagas Sanjaya]

On Fri, Aug 04, 2023 at 04:05:09PM +, Christophe Leroy wrote:
> Hello,
> 
> Le 20/07/2023 à 12:17, zhangyongle...@208suo.com a écrit :
> > [Vous ne recevez pas souvent de courriers de zhangyongle...@208suo.com. 
> > D?couvrez pourquoi ceci est important ? 
> > https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Fix twoce occurrences of the checkpatch.pl error:
> > ERROR: that open brace { should be on the previous line
> 
> 
> Can you please explain the purpose of those changes ? Do you use some 
> tools that get disturbed by such cosmetic errors ? Otherwise what is 
> your reason ?

Hi,

208suo.com people do checkpatch fixes (that is, they run
scripts/checkpatch.pl -f  then try to make the script
happy). Steven warned them to not submitting such patches again [1] but
they keep spamming maintainers with checkpatch patches (ignoring the review
warning). I voiced this concern when reviewing one of their patches and
Jani replied that such one-way interaction with kernel communty is
detrimental [2].

The exact same situation happened last year involving developers from
cdjrlc.com domain. They also did trivial patches, including mostly
(and notoriously known for) redundant word stripping. While some of these
patches were accepted, others were not with reviews requesting changes in
v2, yet they also ignored reviews. In fact, in the early waves of 208suo.com
patches, they used the same email infra as 208suo.com people and they sent
patches as HTML emails (which were rejected by mailing lists obviously)
so that the latter people have to send their patches on their behalf
(but corrupted since 208suo.com people used Roundcube instead of
git-send-email(1)).

Regarding 208suo.com's mail infra, after I pointed out this [3], they
changed the infra so that patches sent didn't get corrupted. Thus, they did
listen in regard of tooling and infra changes, but they deliberately
doesn't answer code reviews.

Thanks.

[1]: https://lore.kernel.org/lkml/20230720134501.01f9f...@gandalf.local.home/
[2]: https://lore.kernel.org/lkml/87cz07vvwu@intel.com/
[3]: https://lore.kernel.org/lkml/zjk7sc4i+mk98k%...@debian.me/

> 
> We don't accept such standelone minor cosmetic changes at the first 
> place because it looks like a waste of time.

PS: And in fact, complicating stable backports...

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH] KVM: PPC: BOOK3S: book3s_hv_nested.c: improve branch prediction for k.alloc

[Bagas Sanjaya]

On Fri, Apr 07, 2023 at 05:31:47AM -0400, Kautuk Consul wrote:
> I used the unlikely() macro on the return values of the k.alloc
> calls and found that it changes the code generation a bit.
> Optimize all return paths of k.alloc calls by improving
> branch prediction on return value of k.alloc.

What about below?

"Improve branch prediction on kmalloc() and kzalloc() call by using
unlikely() macro to optimize their return paths."

That is, try to avoid first-person construct (I).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1

[Bagas Sanjaya]

On Mon, May 08, 2023 at 01:29:22PM +0200, Linux regression tracking #adding 
(Thorsten Leemhuis) wrote:
> [CCing the regression list, as it should be in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> 
> [TLDR: I'm adding this report to the list of tracked Linux kernel
> regressions; the text you find below is based on a few templates
> paragraphs you might have encountered already in similar form.
> See link in footer if these mails annoy you.]
> 
> On 02.05.23 04:22, Christian Zigotzky wrote:
> > Hello,
> > 
> > Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 [2].
> > 
> > The kernel hangs right after the booting Linux via __start() @
> > 0x ...
> > 
> > I was able to revert the PowerPC updates 6.4-1 [2] with the following
> > command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1
> > 
>  ... 
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
> 
> #regzbot ^introduced e4ab08be5b4902e5

Hi Thorsten,

Why and how can you conclude that the culprit is e4ab08be5b4902 
("powerpc/isa-bridge:
Remove open coded "ranges" parsing") rather than powerpc PR merge commit
70cc1b5307e8ee ("Merge tag 'powerpc-6.4-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux")? 

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1

[Bagas Sanjaya]

On 5/8/23 20:17, Linux regression tracking (Thorsten Leemhuis) wrote:
>> Why and how can you conclude that the culprit is e4ab08be5b4902 
>> ("powerpc/isa-bridge:
>> Remove open coded "ranges" parsing") rather than powerpc PR merge commit
>> 70cc1b5307e8ee ("Merge tag 'powerpc-6.4-1' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux")? 
> 
> I looked at the thread and noticed it was mentioned later (
> https://lore.kernel.org/all/3fa42c8c-09bd-d0f0-401b-315b484f4...@xenosoft.de/
> ).
> 

Oops, I wasn't seeing the whole thread. Thanks anyway.

-- 
An old man doll... just what I always wanted! - Clara

Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Bagas Sanjaya]

Hi,

I notice a regression report on bugzilla ([1]). As many developers
don't keep an eye on it, I decide to forward it by email.

Quoting from it:

>  darkbasic 2023-05-10 13:36:37 UTC
> 
> I'm using Gentoo Linux on a Raptor CS Talos 2 ppc64le, GPU is an AMD RX 570. 
> So far the past dozen of kernels (up to 6.2.14) worked flawlessly, but with 
> 6.3.1 I don't get any video output and I get the following in journalctl:
> 
> May 10 15:09:01 talos2 kernel: Kernel attempted to read user page (1128) - 
> exploit attempt? (uid: 0)
> May 10 15:09:01 talos2 kernel: BUG: Unable to handle kernel data access on 
> read at 0x1128
> May 10 15:09:01 talos2 kernel: Faulting instruction address: 
> 0xc0080d1a805c
> May 10 15:09:01 talos2 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
> May 10 15:09:01 talos2 kernel: LE PAGE_SIZE=4K MMU=Radix SMP NR_CPUS=512 NUMA 
> PowerNV
> May 10 15:09:01 talos2 kernel: Modules linked in: rfkill(+) 8021q garp mrp 
> stp llc binfmt_misc amdgpu uvcvideo uvc videobuf2_vmalloc videobuf2_memops 
> gpu_sched snd_hda_codec_hdmi i2c_algo_bit at24(+) videobuf2_v4l2 
> drm_ttm_helper regmap_i2c videobuf2_common ttm snd_usb_audio drm_di>
> May 10 15:09:01 talos2 kernel: CPU: 0 PID: 188 Comm: kworker/0:3 Not tainted 
> 6.3.1-gentoo-dist #1
> May 10 15:09:01 talos2 kernel: Hardware name: T2P9S01 REV 1.01 POWER9 
> 0x4e1202 opal:skiboot-9858186 PowerNV
> May 10 15:09:01 talos2 kernel: Workqueue: events_long 
> drm_dp_check_and_send_link_address [drm_display_helper]
> May 10 15:09:01 talos2 kernel: NIP:  c0080d1a805c LR: c0080d1a8018 
> CTR: c0c87900
> May 10 15:09:01 talos2 kernel: REGS: cbeb3370 TRAP: 0300   Not 
> tainted  (6.3.1-gentoo-dist)
> May 10 15:09:01 talos2 kernel: MSR:  9280b033 
>   CR: 88048223  XER: 005a
> May 10 15:09:01 talos2 kernel: CFAR: c0c87980 DAR: 1128 
> DSISR: 4000 IRQMASK: 0 
>GPR00: c0080d1a8018 cbeb3610 
> c0080d690f00  
>GPR04: 0002 c0080d6297c0 
>  c0002a00b740 
>GPR08:  1124 
>  c0080d431560 
>GPR12: c0c87900 c2a6b000 
> c0170ad8 c0001a460310 
>GPR16: 0045 c00022858388 
> c00026000340 0001 
>GPR20:  0001 
> c000260001a0 4000 
>GPR24: 4000 c0002610 
> c000228580b8 fffd 
>GPR28:  c000228580a0 
> c00022856000 c00022858000 
> May 10 15:09:01 talos2 kernel: NIP [c0080d1a805c] 
> is_synaptics_cascaded_panamera+0x244/0x600 [amdgpu]
> May 10 15:09:01 talos2 kernel: LR [c0080d1a8018] 
> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu]
> May 10 15:09:01 talos2 kernel: Call Trace:
> May 10 15:09:01 talos2 kernel: [cbeb3610] [c0080d1a8018] 
> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu] (unreliable)
> May 10 15:09:01 talos2 kernel: [cbeb36d0] [c0080b7c2b18] 
> drm_helper_probe_single_connector_modes+0x230/0x698 [drm_kms_helper]
> May 10 15:09:01 talos2 kernel: [cbeb3810] [c0c57174] 
> drm_client_modeset_probe+0x2b4/0x16c0
> May 10 15:09:01 talos2 kernel: [cbeb3a10] [c0080b7c7a30] 
> __drm_fb_helper_initial_config_and_unlock+0x68/0x640 [drm_kms_helper]
> May 10 15:09:01 talos2 kernel: [cbeb3af0] [c0080b7c5b08] 
> drm_fbdev_client_hotplug+0x40/0x1d0 [drm_kms_helper]
> May 10 15:09:01 talos2 kernel: [cbeb3b70] [c0c55480] 
> drm_client_dev_hotplug+0x120/0x1b0
> May 10 15:09:01 talos2 kernel: [cbeb3c00] [c0080b7c1130] 
> drm_kms_helper_hotplug_event+0x58/0x80 [drm_kms_helper]
> May 10 15:09:01 talos2 kernel: [cbeb3c30] [c0080b80b298] 
> drm_dp_check_and_send_link_address+0x330/0x3a0 [drm_display_helper]
> May 10 15:09:01 talos2 kernel: [cbeb3cd0] [c0162d84] 
> process_one_work+0x2f4/0x580
> May 10 15:09:01 talos2 kernel: [cbeb3d70] [c01630b8] 
> worker_thread+0xa8/0x600
> May 10 15:09:01 talos2 kernel: [cbeb3e00] [c0170bf4] 
> kthread+0x124/0x130
> May 10 15:09:01 talos2 kernel: [cbeb3e50] [c000dd14] 
> ret_from_kernel_thread+0x5c/0x64
> May 10 15:09:01 talos2 kernel: --- interrupt: 0 at 0x0
> May 10 15:09:01 talos2 kernel: NIP:   LR:  
> CTR: 
> May 10 15:09:01 talos2 kernel: REGS: cbeb3e80 TRAP:    Not 
> tainted  (6.3.1-gentoo-dist)
> May 10 15:09:01 talos2 kernel: MSR:   <>  CR:   XER: 
> 
> May 10 15:09:01 talos2 kernel: CFAR:  IRQMASK: 0 
>GPR00: 000

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Bagas Sanjaya]

On 5/11/23 15:06, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on bugzilla ([1]). As many developers
> don't keep an eye on it, I decide to forward it by email.
> 
> Quoting from it:
> 
>>  darkbasic 2023-05-10 13:36:37 UTC
>>
>> I'm using Gentoo Linux on a Raptor CS Talos 2 ppc64le, GPU is an AMD RX 570. 
>> So far the past dozen of kernels (up to 6.2.14) worked flawlessly, but with 
>> 6.3.1 I don't get any video output and I get the following in journalctl:
>>
>> May 10 15:09:01 talos2 kernel: Kernel attempted to read user page (1128) - 
>> exploit attempt? (uid: 0)
>> May 10 15:09:01 talos2 kernel: BUG: Unable to handle kernel data access on 
>> read at 0x1128
>> May 10 15:09:01 talos2 kernel: Faulting instruction address: 
>> 0xc0080d1a805c
>> May 10 15:09:01 talos2 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
>> May 10 15:09:01 talos2 kernel: LE PAGE_SIZE=4K MMU=Radix SMP NR_CPUS=512 
>> NUMA PowerNV
>> May 10 15:09:01 talos2 kernel: Modules linked in: rfkill(+) 8021q garp mrp 
>> stp llc binfmt_misc amdgpu uvcvideo uvc videobuf2_vmalloc videobuf2_memops 
>> gpu_sched snd_hda_codec_hdmi i2c_algo_bit at24(+) videobuf2_v4l2 
>> drm_ttm_helper regmap_i2c videobuf2_common ttm snd_usb_audio drm_di>
>> May 10 15:09:01 talos2 kernel: CPU: 0 PID: 188 Comm: kworker/0:3 Not tainted 
>> 6.3.1-gentoo-dist #1
>> May 10 15:09:01 talos2 kernel: Hardware name: T2P9S01 REV 1.01 POWER9 
>> 0x4e1202 opal:skiboot-9858186 PowerNV
>> May 10 15:09:01 talos2 kernel: Workqueue: events_long 
>> drm_dp_check_and_send_link_address [drm_display_helper]
>> May 10 15:09:01 talos2 kernel: NIP:  c0080d1a805c LR: c0080d1a8018 
>> CTR: c0c87900
>> May 10 15:09:01 talos2 kernel: REGS: cbeb3370 TRAP: 0300   Not 
>> tainted  (6.3.1-gentoo-dist)
>> May 10 15:09:01 talos2 kernel: MSR:  9280b033 
>>   CR: 88048223  XER: 005a
>> May 10 15:09:01 talos2 kernel: CFAR: c0c87980 DAR: 1128 
>> DSISR: 4000 IRQMASK: 0 
>>GPR00: c0080d1a8018 cbeb3610 
>> c0080d690f00  
>>GPR04: 0002 c0080d6297c0 
>>  c0002a00b740 
>>GPR08:  1124 
>>  c0080d431560 
>>GPR12: c0c87900 c2a6b000 
>> c0170ad8 c0001a460310 
>>GPR16: 0045 c00022858388 
>> c00026000340 0001 
>>GPR20:  0001 
>> c000260001a0 4000 
>>GPR24: 4000 c0002610 
>> c000228580b8 fffd 
>>GPR28:  c000228580a0 
>> c00022856000 c00022858000 
>> May 10 15:09:01 talos2 kernel: NIP [c0080d1a805c] 
>> is_synaptics_cascaded_panamera+0x244/0x600 [amdgpu]
>> May 10 15:09:01 talos2 kernel: LR [c0080d1a8018] 
>> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu]
>> May 10 15:09:01 talos2 kernel: Call Trace:
>> May 10 15:09:01 talos2 kernel: [cbeb3610] [c0080d1a8018] 
>> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu] (unreliable)
>> May 10 15:09:01 talos2 kernel: [cbeb36d0] [c0080b7c2b18] 
>> drm_helper_probe_single_connector_modes+0x230/0x698 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3810] [c0c57174] 
>> drm_client_modeset_probe+0x2b4/0x16c0
>> May 10 15:09:01 talos2 kernel: [cbeb3a10] [c0080b7c7a30] 
>> __drm_fb_helper_initial_config_and_unlock+0x68/0x640 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3af0] [c0080b7c5b08] 
>> drm_fbdev_client_hotplug+0x40/0x1d0 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3b70] [c0c55480] 
>> drm_client_dev_hotplug+0x120/0x1b0
>> May 10 15:09:01 talos2 kernel: [cbeb3c00] [c0080b7c1130] 
>> drm_kms_helper_hotplug_event+0x58/0x80 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3c30] [c0080b80b298] 
>> drm_dp_check_and_send_link_address+0x330/0x3a0 [drm_display_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3cd0] [c0162d84] 
>> process_one_work+0x2f4/0x580
>> May 10 15:09:01 talos2 kernel: [cbeb3d70] [c01630b8] 
>> worker_thread+0xa8/0x600
>> May 10 15:09:01 talos2 kernel: [cbeb3

Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)

[Bagas Sanjaya]

Hi,

I notice a powerpc[64?] build regression on Bugzilla [1]. Quoting from it:

>  CC  arch/powerpc/kernel/asm-offsets.s
> In file included from ./include/linux/gfp.h:7,
> from ./include/linux/xarray.h:15,
> from ./include/linux/list_lru.h:14,
> from ./include/linux/fs.h:13,
> from ./include/linux/compat.h:17,
> from arch/powerpc/kernel/asm-offsets.c:12:
> ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds 
> SECTION_SIZE
> 1735 | #error Allocator MAX_ORDER exceeds SECTION_SIZE
>  |  ^
> make[5]: *** [scripts/Makefile.build:114: arch/powerpc/kernel/asm-offsets.s] 
> Error 1

Apparently removing the errored line solves the problem for the reporter
(the attached dmesg on [2] looks fine at a glance).

Anyway, I'm adding it to regzbot:

#regzbot introduced: 23baf831a32c04f 
https://bugzilla.kernel.org/show_bug.cgi?id=217477
#regzbot title: Allocator MAX_ORDER exceeds SECTION_SIZE caused by MAX_ORDER 
redefinition

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217477
[2]: https://bugzilla.kernel.org/show_bug.cgi?id=217477#c1

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)

[Bagas Sanjaya]

On 5/24/23 17:58, Bagas Sanjaya wrote:
> Anyway, I'm adding it to regzbot:
> 
> #regzbot introduced: 23baf831a32c04f 
> https://bugzilla.kernel.org/show_bug.cgi?id=217477
> #regzbot title: Allocator MAX_ORDER exceeds SECTION_SIZE caused by MAX_ORDER 
> redefinition
> 

>From bugzilla [1], the reporter had successfully tried the proposed
kernel config fix, so:

#regzbot resolve: reducing CONFIG_ARCH_FORCE_MAX_ORDER to 8 resolves the 
regression

Thanks for all who participates in this regression report!

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217477#c8

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)

[Bagas Sanjaya]

On 5/24/23 20:11, Doru Iorgulescu wrote:
> Glad to hear it! 
> Thank you

tl;dr:

> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top

(IOW, I have no idea what you're referring to. Please stop top-posting;
reply inline with appropriate context instead.)

Also, don't send HTML emails as many mailing lists (including LKML)
don't like it.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)

[Bagas Sanjaya]

On Thu, May 25, 2023 at 01:03:22AM +1000, Michael Ellerman wrote:
> Should be fixed properly by:
> 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230519113806.370635-1-...@ellerman.id.au/
> 
> Which is in powerpc-fixes as 358e526a1648.

Telling regzbot:

#regzbot fix: 358e526a1648cd

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: Fwd: ./include/linux/mmzone.h:1735:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE (v6.4-rc3 build regression)

[Bagas Sanjaya]

On Wed, May 24, 2023 at 06:13:52PM +0300, Doru Iorgulescu wrote:
> Awesome, thanks!

tl;dr: see [1].

(Hey, looks like complimenting noise here.)

[1]: 
https://lore.kernel.org/regressions/5df92692-296e-3956-24fa-2bd439337...@gmail.com/

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH v3 4/5] treewide: use get_random_bytes when possible

[Bagas Sanjaya]

On 10/6/22 23:53, Jason A. Donenfeld wrote:
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
> 
> Reviewed-by: Kees Cook 
> Signed-off-by: Jason A. Donenfeld 
> ---
>  arch/powerpc/crypto/crc-vpmsum_test.c   |  2 +-
>  block/blk-crypto-fallback.c |  2 +-
>  crypto/async_tx/raid6test.c |  2 +-
>  drivers/dma/dmatest.c   |  2 +-
>  drivers/mtd/nand/raw/nandsim.c  |  2 +-
>  drivers/mtd/tests/mtd_nandecctest.c |  2 +-
>  drivers/mtd/tests/speedtest.c   |  2 +-
>  drivers/mtd/tests/stresstest.c  |  2 +-
>  drivers/net/ethernet/broadcom/bnxt/bnxt.c   |  2 +-
>  drivers/net/ethernet/rocker/rocker_main.c   |  2 +-
>  drivers/net/wireguard/selftest/allowedips.c | 12 ++--
>  fs/ubifs/debug.c|  2 +-
>  kernel/kcsan/selftest.c |  2 +-
>  lib/random32.c  |  2 +-
>  lib/test_objagg.c   |  2 +-
>  lib/uuid.c  |  2 +-
>  net/ipv4/route.c|  2 +-
>  net/mac80211/rc80211_minstrel_ht.c  |  2 +-
>  net/sched/sch_pie.c |  2 +-
>  19 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/powerpc/crypto/crc-vpmsum_test.c 
> b/arch/powerpc/crypto/crc-vpmsum_test.c
> index c1c1ef9457fb..273c527868db 100644
> --- a/arch/powerpc/crypto/crc-vpmsum_test.c
> +++ b/arch/powerpc/crypto/crc-vpmsum_test.c
> @@ -82,7 +82,7 @@ static int __init crc_test_init(void)
>  
>   if (len <= offset)
>   continue;
> - prandom_bytes(data, len);
> + get_random_bytes(data, len);
>   len -= offset;
>  
>   crypto_shash_update(crct10dif_shash, data+offset, len);
> diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c
> index 621abd1b0e4d..ad9844c5b40c 100644
> --- a/block/blk-crypto-fallback.c
> +++ b/block/blk-crypto-fallback.c
> @@ -539,7 +539,7 @@ static int blk_crypto_fallback_init(void)
>   if (blk_crypto_fallback_inited)
>   return 0;
>  
> - prandom_bytes(blank_key, BLK_CRYPTO_MAX_KEY_SIZE);
> + get_random_bytes(blank_key, BLK_CRYPTO_MAX_KEY_SIZE);
>  
>   err = bioset_init(&crypto_bio_split, 64, 0, 0);
>   if (err)
> diff --git a/crypto/async_tx/raid6test.c b/crypto/async_tx/raid6test.c
> index c9d218e53bcb..f74505f2baf0 100644
> --- a/crypto/async_tx/raid6test.c
> +++ b/crypto/async_tx/raid6test.c
> @@ -37,7 +37,7 @@ static void makedata(int disks)
>   int i;
>  
>   for (i = 0; i < disks; i++) {
> - prandom_bytes(page_address(data[i]), PAGE_SIZE);
> + get_random_bytes(page_address(data[i]), PAGE_SIZE);
>   dataptrs[i] = data[i];
>   dataoffs[i] = 0;
>   }
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index 9fe2ae794316..ffe621695e47 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -312,7 +312,7 @@ static unsigned long dmatest_random(void)
>  {
>   unsigned long buf;
>  
> - prandom_bytes(&buf, sizeof(buf));
> + get_random_bytes(&buf, sizeof(buf));
>   return buf;
>  }
>  
> diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
> index 4bdaf4aa7007..c941a5a41ea6 100644
> --- a/drivers/mtd/nand/raw/nandsim.c
> +++ b/drivers/mtd/nand/raw/nandsim.c
> @@ -1393,7 +1393,7 @@ static int ns_do_read_error(struct nandsim *ns, int num)
>   unsigned int page_no = ns->regs.row;
>  
>   if (ns_read_error(page_no)) {
> - prandom_bytes(ns->buf.byte, num);
> + get_random_bytes(ns->buf.byte, num);
>   NS_WARN("simulating read error in page %u\n", page_no);
>   return 1;
>   }
> diff --git a/drivers/mtd/tests/mtd_nandecctest.c 
> b/drivers/mtd/tests/mtd_nandecctest.c
> index 1c7201b0f372..440988562cfd 100644
> --- a/drivers/mtd/tests/mtd_nandecctest.c
> +++ b/drivers/mtd/tests/mtd_nandecctest.c
> @@ -266,7 +266,7 @@ static int nand_ecc_test_run(const size_t size)
>   goto error;
>   }
>  
> - prandom_bytes(correct_data, size);
> + get_random_bytes(correct_data, size);
>   ecc_sw_hamming_calculate(correct_data, size, correct_ecc, sm_order);
>   for (i = 0; i < ARRAY_SIZE(nand_ecc_test); i++) {
>   nand_ecc_test[i].prepare(error_data, error_ecc,
> diff --git a/drivers/mtd/tests/speedtest.c b/drivers/mtd/tests/speedtest.c
> index c9ec7086bfa1..075bce32caa5 100644
> --- a/drivers/mtd/tests/speedtest.c
> +++ b/drivers/mtd/tests/speedtest.c
> @@ -223,7 +223,7 @@ static int __init mtd_speedtest_init(void)
>   if (!iobuf)
>   goto out;
>  
> - 

Re: [PATCH v7 0/8] phy: Add support for Lynx 10G SerDes

[Bagas Sanjaya]

On 10/19/22 06:11, Sean Anderson wrote:
> This adds support for the Lynx 10G SerDes found on the QorIQ T-series
> and Layerscape series. Due to limited time and hardware, only support
> for the LS1046ARDB is added in this initial series. There is a sketch
> for LS1088ARDB support, but it is incomplete.
> 
> Dynamic reconfiguration does not work. That is, the configuration must
> match what is set in the RCW. From my testing, SerDes register settings
> appear identical. The issue appears to be between the PCS and the MAC.
> The link itself comes up at both ends, and a mac loopback succeeds.
> However, a PCS loopback results in dropped packets. Perhaps there is
> some undocumented register in the PCS?
> 
> I suspect this driver is around 95% complete, but, unfortunately, I no
> longer have time to investigate this further. At the very least it is
> useful for two cases:
> - Although this is untested, it should support 2.5G SGMII as well as
>   1000BASE-KX. The latter needs MAC and PCS support, but the former
>   should work out of the box.
> - It allows for clock configurations not supported by the RCW. This is
>   very useful if you want to use e.g. SRDS_PRTCL_S1=0x and =0x1133
>   on the same board. This is because the former setting will use PLL1
>   as the 1G reference, but the latter will use PLL1 as the 10G
>   reference. Because we can reconfigure the PLLs, it is possible to
>   always use PLL1 as the 1G reference.
> 
> Changes in v7:
> - Use double quotes everywhere in yaml
> - Break out call order into generic documentation
> - Refuse to switch "major" protocols
> - Update Kconfig to reflect restrictions
> - Remove set/clear of "pcs reset" bit, since it doesn't seem to fix
>   anything.
> 
> Changes in v6:
> - Bump PHY_TYPE_2500BASEX to 13, since PHY_TYPE_USXGMII was added in the
>   meantime
> - fsl,type -> phy-type
> - frequence -> frequency
> - Update MAINTAINERS to include new files
> - Include bitfield.h and slab.h to allow compilation on non-arm64
>   arches.
> - Depend on COMMON_CLK and either layerscape/ppc
> - XGI.9 -> XFI.9
> 
> Changes in v5:
> - Update commit description
> - Dual id header
> - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this
>   series to be applied directly to linux/master.
> - Add fsl,lynx-10g.h to MAINTAINERS
> 
> Changes in v4:
> - Add 2500BASE-X and 10GBASE-R phy types
> - Use subnodes to describe lane configuration, instead of describing
>   PCCRs. This is the same style used by phy-cadence-sierra et al.
> - Add ids for Lynx 10g PLLs
> - Rework all debug statements to remove use of __func__. Additional
>   information has been provided as necessary.
> - Consider alternative parent rates in round_rate and not in set_rate.
>   Trying to modify out parent's rate in set_rate will deadlock.
> - Explicitly perform a stop/reset sequence in set_rate. This way we
>   always ensure that the PLL is properly stopped.
> - Set the power-down bit when disabling the PLL. We can do this now that
>   enable/disable aren't abused during the set rate sequence.
> - Fix typos in QSGMII_OFFSET and XFI_OFFSET
> - Rename LNmTECR0_TEQ_TYPE_PRE to LNmTECR0_TEQ_TYPE_POST to better
>   reflect its function (adding post-cursor equalization).
> - Use of_clk_hw_onecell_get instead of a custom function.
> - Return struct clks from lynx_clks_init instead of embedding lynx_clk
>   in lynx_priv.
> - Rework PCCR helper functions; T-series SoCs differ from Layerscape SoCs
>   primarily in the layout and offset of the PCCRs. This will help bring a
>   cleaner abstraction layer. The caps have been removed, since this handles 
> the
>   only current usage.
> - Convert to use new binding format. As a result of this, we no longer need to
>   have protocols for PCIe or SATA. Additionally, modes now live in lynx_group
>   instead of lynx_priv.
> - Remove teq from lynx_proto_params, since it can be determined from
>   preq_ratio/postq_ratio.
> - Fix an early return from lynx_set_mode not releasing serdes->lock.
> - Rename lynx_priv.conf to .cfg, since I kept mistyping it.
> 
> Changes in v3:
> - Manually expand yaml references
> - Add mode configuration to device tree
> - Rename remaining references to QorIQ SerDes to Lynx 10G
> - Fix PLL enable sequence by waiting for our reset request to be cleared
>   before continuing. Do the same for the lock, even though it isn't as
>   critical. Because we will delay for 1.5ms on average, use prepare
>   instead of enable so we can sleep.
> - Document the status of each protocol
> - Fix offset of several bitfields in RECR0
> - Take into account PLLRST_B, SDRST_B, and SDEN when considering whether
>   a PLL is "enabled."
> - Only power off unused lanes.
> - Split mode lane mask into first/last lane (like group)
> - Read modes from device tree
> - Use caps to determine whether KX/KR are supported
> - Move modes to lynx_priv
> - Ensure that the protocol controller is not already in-use when we try
>   to configure a new mode. This should only occur if t

Re: [PATCH v8 4/9] phy: fsl: Add Lynx 10G SerDes driver

[Bagas Sanjaya]

On Thu, Oct 27, 2022 at 03:11:08PM -0400, Sean Anderson wrote:
>  .. only::  subproject and html
> diff --git a/Documentation/driver-api/phy/lynx_10g.rst 
> b/Documentation/driver-api/phy/lynx_10g.rst
> new file mode 100644
> index ..ebbf4dd86726
> --- /dev/null
> +++ b/Documentation/driver-api/phy/lynx_10g.rst
> @@ -0,0 +1,58 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +Lynx 10G Phy (QorIQ SerDes)
> +===
> +
> +Using this phy
> +--
> +
> +:c:func:`phy_get` just gets (or creates) a new :c:type:`phy` with the lanes
> +described in the phandle. :c:func:`phy_init` is what actually reserves the
> +lanes for use. Unlike some other drivers, when the phy is created, there is 
> no
> +default protocol. :c:func:`phy_set_mode ` must be called in
> +order to set the protocol.
> +
> +Supporting SoCs
> +---
> +
> +Each new SoC needs a :c:type:`struct lynx_conf `, containing the
> +number of lanes in each device, the endianness of the device, and the helper
> +functions to use when selecting protocol controllers. For example, the
> +configuration for the LS1046A is::

Did you mean struct lynx_cfg as in below snippet?

> +
> +static const struct lynx_cfg ls1046a_cfg = {
> +.lanes = 4,
> +.endian = REGMAP_ENDIAN_BIG,
> +.mode_conflict = lynx_ls_mode_conflict,
> +.mode_apply = lynx_ls_mode_apply,
> +.mode_init = lynx_ls_mode_init,
> +};
> +
> +The ``mode_`` functions will generally be common to all SoCs in a series 
> (e.g.
> +all Layerscape SoCs or all T-series SoCs).
> +
> +In addition, you will need to add a device node as documented in
> +``Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml``. This lets the
> +driver know which lanes are available to configure.
> +
> +Supporting Protocols
> +
> +
> +Each protocol is a combination of values which must be programmed into the 
> lane
> +registers. To add a new protocol, first add it to :c:type:`enum lynx_protocol
> +`. Add a new entry to `lynx_proto_params`, and populate the
> +appropriate fields. Modify `lynx_lookup_proto` to map the :c:type:`enum
> +phy_mode ` to :c:type:`enum lynx_protocol `. Update
> +the ``mode_conflict``, ``mode_apply``, and ``mode_init`` helpers are updated 
> to
> +support your protocol.
> +

These lynx_ keywords should be in double backticks to be consistent
(rendered as inline code).

Also, don't forget to add conjunctions:

"... Then modify ``lynx_lookup_proto`` ... Finally, update the ...
helpers ..."

> +You may need to modify :c:func:`lynx_set_mode` in order to support your
> +protocol. This can happen when you have added members to :c:type:`struct
> +lynx_proto_params `. It can also happen if you have 
> specific
> +clocking requirements, or protocol-specific registers to program.
> +
> +Internal API Reference
> +--
> +
> +.. kernel-doc:: drivers/phy/freescale/phy-fsl-lynx-10g.c

Otherwise LGTM, thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: linux-next tree panic on ppc64le

[Bagas Sanjaya]

On 2/22/23 07:55, Murphy Zhou wrote:
> Hi,
> 
> [   59.558339] [ cut here ]
> [   59.558361] kernel BUG at arch/powerpc/kernel/syscall.c:34!
> [   59.558373] Oops: Exception in kernel mode, sig: 5 [#1]
> [   59.558384] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
> [   59.558397] Modules linked in: rfkill i2c_dev sunrpc ast
> i2c_algo_bit drm_shmem_helper drm_kms_helper ext4 syscopyarea
> sysfillrect sysimgblt ofpart ses powernv_flash enclosure
> scsi_transport_sas ipmi_powernv at24 mbcache jbd2 ipmi_devintf
> regmap_i2c opal_prd ipmi_msghandler mtd ibmpowernv drm fuse
> drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi
> crc64_rocksoft_generic crc64_rocksoft crc64 sg i40e aacraid vmx_crypto
> [   59.558494] CPU: 29 PID: 6366 Comm: kexec Not tainted 6.2.0-next-20230221 
> #1
> [   59.558508] Hardware name: CSE-829U POWER9 0x4e1202
> opal:skiboot-v6.0.7 PowerNV
> [   59.558521] NIP:  c0031e4c LR: c000d520 CTR: 
> c000d3c0
> [   59.558534] REGS: c00097247b70 TRAP: 0700   Not tainted
> (6.2.0-next-20230221)
> [   59.558548] MSR:  90029033   CR:
> 84424840  XER: 
> [   59.558570] CFAR: c000d51c IRQMASK: 3
> [   59.558570] GPR00: c000d520 c00097247e10
> c14b1400 c00097247e80
> [   59.558570] GPR04: 84424840 
>  
> [   59.558570] GPR08:  9280b033
> 0001 
> [   59.558570] GPR12:  c007fffcb280
>  
> [   59.558570] GPR16:  
>  
> [   59.558570] GPR20:  
>  
> [   59.558570] GPR24:  
>  
> [   59.558570] GPR28:  84424840
> c00097247e80 c00097247e10
> [   59.558689] NIP [c0031e4c] system_call_exception+0x5c/0x340
> [   59.558705] LR [c000d520] system_call_common+0x160/0x2c4
> [   59.558719] Call Trace:
> [   59.558725] [c00097247e10] [c0031f18]
> system_call_exception+0x128/0x340 (unreliable)
> [   59.558743] [c00097247e50] [c000d520]
> system_call_common+0x160/0x2c4
> [   59.558759] --- interrupt: c00 at plpar_hcall+0x38/0x60
> [   59.558770] NIP:  c00f58dc LR: c011277c CTR: 
> 
> [   59.558783] REGS: c00097247e80 TRAP: 0c00   Not tainted
> (6.2.0-next-20230221)
> [   59.558796] MSR:  9280b033
>   CR: 84424840  XER: 
> [   59.558821] IRQMASK: 0
> [   59.558821] GPR00: 84424840 c000972479e0
> c14b1400 041c
> [   59.558821] GPR04: 97ff4000 0200
> c00097247930 c007fe233ef8
> [   59.558821] GPR08:  
>  
> [   59.558821] GPR12:  c007fffcb280
>  
> [   59.558821] GPR16:  
>  
> [   59.558821] GPR20:  
>  
> [   59.558821] GPR24: 0004 c000ba704000
> 00c6 c00814d2
> [   59.558821] GPR28: 0417b200 
> c000af848800 c00097ff4000
> [   59.558935] NIP [c00f58dc] plpar_hcall+0x38/0x60
> [   59.558946] LR [c011277c] _plpks_get_config+0x7c/0x270
> [   59.558958] --- interrupt: c00
> [   59.558966] [c000972479e0] [c011275c]
> _plpks_get_config+0x5c/0x270 (unreliable)
> [   59.558982] Code: 7c9d2378 6000 6000 3920 0b09
> 6000 e93e0108 692a0002 794affe2 0b0a 692a4000 794a97e2
> <0b0a> e95e0138 794a07e0 0b0a
> [   59.559018] ---[ end trace  ]---
> [   60.564314] pstore: backend (nvram) writing error (-1)
> [   60.564336]
> [   61.564343] Kernel panic - not syncing: Fatal exception

Panic on what linux-next tag? Can you test powerpc/next tree?

-- 
An old man doll... just what I always wanted! - Clara

Re: linux-next tree panic on ppc64le

[Bagas Sanjaya]

On 2/22/23 16:13, Murphy Zhou wrote:
> next-20230221
> 
> I'll try powerpc/next.
> 

OK, but next time when you reply, don't top-post; reply inline
with appropriate context instead.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new trust source

[Bagas Sanjaya]

; + * our own custom format that uses a hardware-bound key to secure the sealing
> + * key stored in the key blob.
> + *
> + * Whenever a new trusted key using DCP is generated, we generate a random 
> 128-bit
> + * blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to
> + * encrypt the trusted key payload using AES-128-GCM.
> + *
> + * The BEK itself is encrypted using the hardware-bound key using the DCP's 
> AES
> + * encryption engine with AES-128-ECB. The encrypted BEK, generated nonce,
> + * BEK-encrypted payload and authentication tag make up the blob format 
> together
> + * with a version number, payload length and authentication tag.
> + */
> +
>  /**
>   * struct dcp_blob_fmt - DCP BLOB format.
>   *

The doc LGTM, thanks!

Reviewed-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

[PATCH] KVM: powerpc: remove extraneous asterisk from rm_host_ipi_action comment

[Bagas Sanjaya]

kernel test robot reported kernel-doc warning for rm_host_ipi_action():

arch/powerpc/kvm/book3s_hv_rm_xics.c:887: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst

Since the function is static, remove the extraneous (second) asterisk at
the head of function comment.

Link: https://lore.kernel.org/linux-doc/202204252334.cd2isiii-...@intel.com/
Reported-by: kernel test robot 
Cc: Suresh Warrier 
Cc: Paul Mackerras 
Cc: Anders Roxell 
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Segher Boessenkool 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Nicholas Piggin 
Cc: Fabiano Rosas 
Cc: Paolo Bonzini 
Cc: Alexey Kardashevskiy 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: k...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Bagas Sanjaya 
---
 arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c 
b/arch/powerpc/kvm/book3s_hv_rm_xics.c
index 587c33fc45640f..6e16bd751c8423 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
@@ -883,7 +883,7 @@ long kvmppc_deliver_irq_passthru(struct kvm_vcpu *vcpu,
 
 /*  --- Non-real mode XICS-related built-in routines ---  */
 
-/**
+/*
  * Host Operations poked by RM KVM
  */
 static void rm_host_ipi_action(int action, void *data)

base-commit: d615b5416f8a1afeb82d13b238f8152c572d59c0
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] KVM: powerpc: remove extraneous asterisk from rm_host_ipi_action comment

[Bagas Sanjaya]

On 4/26/22 14:47, Bagas Sanjaya wrote:
> Link: https://lore.kernel.org/linux-doc/202204252334.cd2isiii-...@intel.com/
> Reported-by: kernel test robot 
> Cc: Suresh Warrier 
> Cc: Paul Mackerras 
> Cc: Anders Roxell 
> Cc: Greg Kroah-Hartman 
> Cc: Arnd Bergmann 
> Cc: Segher Boessenkool 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Nicholas Piggin 
> Cc: Fabiano Rosas 
> Cc: Paolo Bonzini 
> Cc: Alexey Kardashevskiy 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: k...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Bagas Sanjaya 

Oops, I forgot Fixes: 0c2a66062470cd ("KVM: PPC: Book3S HV: Host side kick VCPU 
when poked by real-mode KVM")
tag.

-- 
An old man doll... just what I always wanted! - Clara

ppc64_defconfig Werror: no previous prototype on arch/powerpc/kernel/ftrace.c

[Bagas Sanjaya]

Greetings,

I did ppc64_defconfig build (gcc 11.2.0) on current master at commit
46cf2c613f4b10 ("Merge tag 'pinctrl-v5.18-2'
of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl"),
and it errored out early like this:

  CC  arch/powerpc/kernel/trace/ftrace.o
arch/powerpc/kernel/trace/ftrace.c:978:7: error: no previous prototype for 
‘arch_ftrace_match_adjust’ [-Werror=missing-prototypes]
  978 | char *arch_ftrace_match_adjust(char *str, const char *search)
  |   ^~~~
  CC  init/init_task.o
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:288: arch/powerpc/kernel/trace/ftrace.o] 
Error 1
make[2]: *** [scripts/Makefile.build:550: arch/powerpc/kernel/trace] Error 2
make[1]: *** [scripts/Makefile.build:550: arch/powerpc/kernel] Error 2
make: *** [Makefile:1834: arch/powerpc] Error 2

The code in question is introduced by commit 7132e2d669bd42 ("ftrace:
Match dot symbols when searching functions on ppc64").

Reported-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara

[PATCH RESEND] KVM: powerpc: remove extraneous asterisk from rm_host_ipi_action comment

[Bagas Sanjaya]

kernel test robot reported kernel-doc warning for rm_host_ipi_action():

>> arch/powerpc/kvm/book3s_hv_rm_xics.c:887: warning: This comment starts with 
>> '/**', but isn't a kernel-doc comment. Refer 
>> Documentation/doc-guide/kernel-doc.rst
* Host Operations poked by RM KVM

Since the function is static, remove the extraneous (second) asterisk at
the head of function comment.

Fixes: 0c2a66062470cd ("KVM: PPC: Book3S HV: Host side kick VCPU when poked by 
real-mode KVM")
Link: https://lore.kernel.org/linux-doc/202204252334.cd2isiii-...@intel.com/
Reported-by: kernel test robot 
Cc: Suresh Warrier 
Cc: Paul Mackerras 
Cc: Anders Roxell 
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Nicholas Piggin 
Cc: Fabiano Rosas 
Cc: Paolo Bonzini 
Cc: Alexey Kardashevskiy 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: k...@vger.kernel.org
Cc: sta...@vger.kernel.org # v5.15, v5.17
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Bagas Sanjaya 
---
 arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c 
b/arch/powerpc/kvm/book3s_hv_rm_xics.c
index 587c33fc45640f..6e16bd751c8423 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
@@ -883,7 +883,7 @@ long kvmppc_deliver_irq_passthru(struct kvm_vcpu *vcpu,
 
 /*  --- Non-real mode XICS-related built-in routines ---  */
 
-/**
+/*
  * Host Operations poked by RM KVM
  */
 static void rm_host_ipi_action(int action, void *data)

base-commit: a7391ad3572431a354c927cf8896e86e50d7d0bf
-- 
An old man doll... just what I always wanted! - Clara

dangling pointer to '__str' error on ppc64_defconfig, GCC 12.1.0

[Bagas Sanjaya]

nsion of macro 'printk'
  489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
  | ^~
arch/powerpc/kernel/trace/ftrace.c:139:17: note: in expansion of macro 'pr_err'
  139 | pr_err("Not expected bl: opcode is %s\n", 
ppc_inst_as_str(op));
  | ^~
arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_make_call':
./include/linux/printk.h:446:44: error: using a dangling pointer to '__str' 
[-Werror=dangling-pointer=]
  446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
  |^
./include/linux/printk.h:418:17: note: in definition of macro 
'printk_index_wrap'
  418 | _p_func(_fmt, ##__VA_ARGS__);   
\
  | ^~~
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
  489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
  | ^~
arch/powerpc/kernel/trace/ftrace.c:506:17: note: in expansion of macro 'pr_err'
  506 | pr_err("Unexpected call sequence at %p: %s %s\n",
  | ^~
./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here
  156 | char __str[PPC_INST_STR_LEN];   \
  |  ^
./include/linux/printk.h:418:33: note: in expansion of macro 'ppc_inst_as_str'
  418 | _p_func(_fmt, ##__VA_ARGS__);   
\
  | ^~~
./include/linux/printk.h:446:26: note: in expansion of macro 'printk_index_wrap'
  446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
  |      ^
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
  489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
  | ^~
arch/powerpc/kernel/trace/ftrace.c:506:17: note: in expansion of macro 'pr_err'
  506 | pr_err("Unexpected call sequence at %p: %s %s\n",
  | ^~
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:288: arch/powerpc/kernel/trace/ftrace.o] 
Error 1

I also hit this error on current master (commit babf0bb978e3c9
("Merge tag 'xfs-5.19-for-linus' of 
git://git.kernel.org/pub/scm/fs/xfs/xfs-linux")).

Thanks.

Reported-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara

outside array bounds error on ppc64_defconfig, GCC 12.1.0

[Bagas Sanjaya]

Hi,

I'm trying to verify Drop ppc_inst_as_str() patch on [1] by performing
ppc64_defconfig build with powerpc64-unknown-linux-gnu-gcc (GCC 12.1.0).
The patch is applied on top of powerpc tree, next branch.

I got outside array bounds error:

  CC  arch/powerpc/kernel/dbell.o
In function 'do_byte_reverse',
inlined from 'do_vec_store' at arch/powerpc/lib/sstep.c:722:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3509:9:
arch/powerpc/lib/sstep.c:286:25: error: array subscript [3, 4] is outside array 
bounds of 'union [1]' [-Werror=array-bounds]
  286 | up[0] = byterev_8(up[3]);
  | ^~~~
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:708:11: note: at offset [24, 39] into object 'u' of 
size 16
  708 | } u;
  |   ^
In function 'do_byte_reverse',
inlined from 'do_vec_store' at arch/powerpc/lib/sstep.c:722:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3509:9:
arch/powerpc/lib/sstep.c:287:23: error: array subscript [3, 4] is outside array 
bounds of 'union [1]' [-Werror=array-bounds]
  287 | up[3] = tmp;
  | ~~^
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:708:11: note: at offset [24, 39] into object 'u' of 
size 16
  708 | } u;
  |   ^
In function 'do_byte_reverse',
inlined from 'do_vec_store' at arch/powerpc/lib/sstep.c:722:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3509:9:
arch/powerpc/lib/sstep.c:288:23: error: array subscript 2 is outside array 
bounds of 'union [1]' [-Werror=array-bounds]
  288 | tmp = byterev_8(up[2]);
  |   ^~~~
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:708:11: note: at offset 16 into object 'u' of size 16
  708 | } u;
  |   ^
In function 'do_byte_reverse',
inlined from 'do_vec_store' at arch/powerpc/lib/sstep.c:722:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3509:9:
arch/powerpc/lib/sstep.c:289:23: error: array subscript 2 is outside array 
bounds of 'union [1]' [-Werror=array-bounds]
  289 | up[2] = byterev_8(up[1]);
  | ~~^~
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:708:11: note: at offset 16 into object 'u' of size 16
  708 | } u;
  |   ^
In function 'do_byte_reverse',
inlined from 'do_vec_load' at arch/powerpc/lib/sstep.c:691:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3438:9:
arch/powerpc/lib/sstep.c:286:25: error: array subscript [3, 4] is outside array 
bounds of 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds]
  286 | up[0] = byterev_8(up[3]);
  | ^~~~
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
  681 | } u = {};
  |   ^
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
In function 'do_byte_reverse',
inlined from 'do_vec_load' at arch/powerpc/lib/sstep.c:691:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3438:9:
arch/powerpc/lib/sstep.c:287:23: error: array subscript [3, 4] is outside array 
bounds of 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds]
  287 | up[3] = tmp;
  | ~~^
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
  681 | } u = {};
  |   ^
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
arch/powerpc/lib/sstep.c:681:11: note: at offset [24, 39] into object 'u' of 
size 16
In function 'do_byte_reverse',
inlined from 'do_vec_load' at arch/powerpc/lib/sstep.c:691:3,
inlined from 'emulate_loadstore' at arch/powerpc/lib/sstep.c:3438:9:
arch/powerpc/lib/sstep.c:288:23: error: array subscript 2 is outside array 
bounds of 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds]
  288 | tmp = byterev_8(up[2]);
  |   ^~~~
arch/powerpc/lib/sstep.c: In function 'emulate_loadstore':
arch/powerpc/lib/sstep.c:681:11: note: at offset 16 into object 'u' of size 16
  681 | }

Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()

[Bagas Sanjaya]

Hi,

On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> The ppc_inst_as_str() macro tries to make printing variable length,
> aka "prefixed", instructions convenient. It mostly succeeds, but it does
> hide an on-stack buffer, which triggers stack protector.
> 
> More problematically it doesn't compile at all with GCC 12, due to the
> fact that it returns the char buffer declared inside the macro:
> 
>   arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_modify_call':
>   ./include/linux/printk.h:475:44: error: using a dangling pointer to '__str' 
> [-Werror=dangling-pointer=]
> 475 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, 
> ##__VA_ARGS__)
> ...
>   arch/powerpc/kernel/trace/ftrace.c:567:17: note: in expansion of macro 
> 'pr_err'
> 567 | pr_err("Not expected bl: opcode is %s\n", 
> ppc_inst_as_str(op));
> | ^~
>   ./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here
> 156 | char __str[PPC_INST_STR_LEN];   \
> |  ^
> 
> This could be fixed by having the caller declare the buffer, but in some
> places there'd need to be two buffers. In all cases where
> ppc_inst_as_str() is used the output is not really meant for user
> consumption, it's almost always indicative of a kernel bug.
> 
> A simpler solution is to just print the value as an unsigned long. For
> normal instructions the output is identical. For prefixed instructions
> the value is printed as a single 64-bit quantity, whereas previously the
> low half was printed first. But that is good enough for debug output,
> especially as prefixed instructions will be rare in practice.
> 
> Old:
>   c070  6042  ori r2,r2,0
>   c074  0411 e580fb00     .long 0xe580fb000411
> 
> New:
>   c010f90c  6042  ori r2,r2,0
>   c010f910  e580fb000411  .long 0xe580fb000411
> 
> Reported-by: Bagas Sanjaya 
> Reported-by: Petr Mladek 
> Signed-off-by: Michael Ellerman 

The arch/powerpc/kernel/trace/ftrace.c builds successfully, however
there is also other build error for which I have reported at [1].

Thanks.

Tested-by: Bagas Sanjaya 

[1]: https://lore.kernel.org/linuxppc-dev/ypbucprm61rli...@debian.me/

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()

[Bagas Sanjaya]

On 6/1/22 10:03, Bagas Sanjaya wrote:
>>
>> Reported-by: Bagas Sanjaya 
>> Reported-by: Petr Mladek 
>> Signed-off-by: Michael Ellerman 
> 
> The arch/powerpc/kernel/trace/ftrace.c builds successfully, however
> there is also other build error for which I have reported at [1].
> 
> Thanks.
> 
> Tested-by: Bagas Sanjaya 
> 
> [1]: https://lore.kernel.org/linuxppc-dev/ypbucprm61rli...@debian.me/
> 

Oops, I forget to mention: is this patch meant for backporting into
stable tree? I don't see Fixes: tag and Cc: sta...@vger.kernel.org
in the patch.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 5.15 00/28] 5.15.52-rc1 review

[Bagas Sanjaya]

On Thu, Jun 30, 2022 at 03:46:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.52 release.
> There are 28 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 

Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 12.1.0)
and powerpc (ps3_defconfig, GCC 12.1.0).

I get two warnings on powerpc build (vdso related):

  VDSO32L arch/powerpc/kernel/vdso32/vdso32.so.dbg
/lib/gcc/powerpc64-unknown-linux-gnu/12.1.0/../../../../powerpc64-unknown-linux-gnu/bin/ld:
 warning: cannot find entry symbol 
nable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang; not 
setting start address
  VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
/lib/gcc/powerpc64-unknown-linux-gnu/12.1.0/../../../../powerpc64-unknown-linux-gnu/bin/ld:
 warning: cannot find entry symbol 
nable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang; not 
setting start address

Tested-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara

next-20220715 build fail due to 579b9239c1f386 (powerpc, ps3_defconfig, GCC 12.1.0)

[Bagas Sanjaya]

Hi everyone,

I built next-20220715 tree, using powerpc64-unknown-linux-gnu-gcc
(GCC 12.1.0) and ps3_defconfig. The build errored on W=1 build
(-Werror=missing-prototypes):

  CC  arch/powerpc/mm/book3s64/pgtable.o
  CC  arch/powerpc/kernel/process.o
arch/powerpc/mm/book3s64/pgtable.c:478:5: error: no previous prototype for 
'pmd_move_must_withdraw' [-Werror=missing-prototypes]
  478 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
  | ^~
cc1: all warnings being treated as errors

The errored line is introduced by commit 579b9239c1f386 ("powerpc/radix: Fix
kernel crash with mremap()")

Looking at the commit, it seems like GCC didn't see the prototype which had
already been given, or am I missing something?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: next-20220715 build fail due to 579b9239c1f386 (powerpc, ps3_defconfig, GCC 12.1.0)

[Bagas Sanjaya]

On 7/17/22 10:27, Bagas Sanjaya wrote:
> Hi everyone,
> 
> I built next-20220715 tree, using powerpc64-unknown-linux-gnu-gcc
> (GCC 12.1.0) and ps3_defconfig. The build errored on W=1 build
> (-Werror=missing-prototypes):
> 
>   CC  arch/powerpc/mm/book3s64/pgtable.o
>   CC  arch/powerpc/kernel/process.o
> arch/powerpc/mm/book3s64/pgtable.c:478:5: error: no previous prototype for 
> 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
>   478 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
>   | ^~
> cc1: all warnings being treated as errors
> 

Oops, I forget to attach the full build log.

-- 
An old man doll... just what I always wanted! - Clara

powerpc.log.gz
Description: application/gzip

[PATCH 2/3] Documentation: use different label names for each arch's elf_hwcaps.rst

[Bagas Sanjaya]

Sphinx reported duplicate label warning:

WARNING: duplicate label elf_hwcaps_index, other instance in 
Documentation/arm64/elf_hwcaps.rst

The warning is caused by elf_hwcaps_index label name is already used for
arm64 documentation, whileas powerpc use the same name.

Disambiguate the label name for each architecture's documentation. While
at it, also adjust original reference in translated documentation.

Link: 
https://lore.kernel.org/linuxppc-dev/20220727220050.549db...@canb.auug.org.au/
Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs")
Reported-by: Stephen Rothwell 
Signed-off-by: Bagas Sanjaya 
---
 Documentation/arm64/elf_hwcaps.rst| 2 +-
 Documentation/powerpc/elf_hwcaps.rst  | 2 +-
 Documentation/translations/zh_CN/arm64/elf_hwcaps.rst | 2 +-
 Documentation/translations/zh_TW/arm64/elf_hwcaps.rst | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm64/elf_hwcaps.rst 
b/Documentation/arm64/elf_hwcaps.rst
index 3d116fb536c538..63b75080ec4544 100644
--- a/Documentation/arm64/elf_hwcaps.rst
+++ b/Documentation/arm64/elf_hwcaps.rst
@@ -1,4 +1,4 @@
-.. _elf_hwcaps_index:
+.. _elf_hwcaps_arm64:
 
 
 ARM64 ELF hwcaps
diff --git a/Documentation/powerpc/elf_hwcaps.rst 
b/Documentation/powerpc/elf_hwcaps.rst
index bb7438cebf36e8..3366e5b18e6759 100644
--- a/Documentation/powerpc/elf_hwcaps.rst
+++ b/Documentation/powerpc/elf_hwcaps.rst
@@ -1,4 +1,4 @@
-.. _elf_hwcaps_index:
+.. _elf_hwcaps_powerpc:
 
 ==
 POWERPC ELF HWCAPs
diff --git a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst 
b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
index 9aa4637eac979c..39a94ff5383c01 100644
--- a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
+++ b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-zh_CN.rst
 
-:Original: :ref:`Documentation/arm64/elf_hwcaps.rst `
+:Original: :ref:`Documentation/arm64/elf_hwcaps.rst `
 
 Translator: Bailu Lin 
 
diff --git a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst 
b/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst
index 3eb1c623ce31b0..76164d851d0b5e 100644
--- a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst
+++ b/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst
@@ -2,7 +2,7 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/arm64/elf_hwcaps.rst `
+:Original: :ref:`Documentation/arm64/elf_hwcaps.rst `
 
 Translator: Bailu Lin 
 Hu Haowen 
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 0/3] Documentation: powerpc: documentation fixes for Documentation/powerpc/elf_hwcaps.rst

[Bagas Sanjaya]

After merging powerpc tree for linux-next integration testing, Stephen
Rothwell reported htmldocs warnings at [1]. Fix these with self-explanatory
fixes in the shortlog below.

[1]: 
https://lore.kernel.org/linuxppc-dev/20220727220050.549db...@canb.auug.org.au/

Bagas Sanjaya (3):
  Documentation: powerpc: fix indentation warnings
  Documentation: use different label names for each arch's
elf_hwcaps.rst
  Documentation: powerpc: add elf_hwcaps to table of contents

 Documentation/arm64/elf_hwcaps.rst  |  2 +-
 Documentation/powerpc/elf_hwcaps.rst| 17 +++--
 Documentation/powerpc/index.rst |  1 +
 .../translations/zh_CN/arm64/elf_hwcaps.rst |  2 +-
 .../translations/zh_TW/arm64/elf_hwcaps.rst |  2 +-
 5 files changed, 11 insertions(+), 13 deletions(-)


base-commit: d6b551b8f90cc92c7d3c09cf38c748efe305ecb4
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 3/3] Documentation: powerpc: add elf_hwcaps to table of contents

[Bagas Sanjaya]

elf_hwcaps documentation is missing from table of contents at index.rst,
hence triggers Sphinx warning:

Documentation/powerpc/elf_hwcaps.rst: WARNING: document isn't included in any 
toctree

Add the documentation to the index to fix the warning.

Link: 
https://lore.kernel.org/linuxppc-dev/20220727220050.549db...@canb.auug.org.au/
Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs")
Reported-by: Stephen Rothwell 
Signed-off-by: Bagas Sanjaya 
---
 Documentation/powerpc/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index 0f7d3c495693e0..85e80e30160bb6 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -17,6 +17,7 @@ powerpc
 dawr-power9
 dscr
 eeh-pci-error-recovery
+elf_hwcaps
 elfnote
 firmware-assisted-dump
 hvcs
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 1/3] Documentation: powerpc: fix indentation warnings

[Bagas Sanjaya]

Sphinx reported unexpected indentation warnings:

Documentation/powerpc/elf_hwcaps.rst:82: WARNING: Unexpected indentation.
Documentation/powerpc/elf_hwcaps.rst:100: WARNING: Unexpected indentation.
Documentation/powerpc/elf_hwcaps.rst:117: WARNING: Unexpected indentation.
Documentation/powerpc/elf_hwcaps.rst:122: WARNING: Unexpected indentation.
Documentation/powerpc/elf_hwcaps.rst:144: WARNING: Unexpected indentation.

Fix these warnings by unindenting commit references and using literal code
block for instructions list for PPC_FEATURE_ICACHE_SNOOP.

Link: 
https://lore.kernel.org/linuxppc-dev/20220727220050.549db...@canb.auug.org.au/
Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs")
Reported-by: Stephen Rothwell 
Signed-off-by: Bagas Sanjaya 
---
 Documentation/powerpc/elf_hwcaps.rst | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/Documentation/powerpc/elf_hwcaps.rst 
b/Documentation/powerpc/elf_hwcaps.rst
index 96d4fc4a3f91fe..bb7438cebf36e8 100644
--- a/Documentation/powerpc/elf_hwcaps.rst
+++ b/Documentation/powerpc/elf_hwcaps.rst
@@ -78,8 +78,7 @@ PPC_FEATURE_64
 
 PPC_FEATURE_601_INSTR
 The processor is PowerPC 601.
-Unused in the kernel since:
-  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
 
 PPC_FEATURE_HAS_ALTIVEC
 Vector (aka Altivec, VMX) facility is available.
@@ -96,8 +95,7 @@ PPC_FEATURE_HAS_4xxMAC
 PPC_FEATURE_UNIFIED_CACHE
 The processor has a unified L1 cache for instructions and data, as
 found in NXP e200.
-Unused in the kernel since:
-  39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)")
+Unused in the kernel since 39c8bf2b3cc1 ("powerpc: Retire e200 core 
(mpc555x processor)")
 
 PPC_FEATURE_HAS_SPE
 Signal Processing Engine facility is available.
@@ -113,13 +111,11 @@ PPC_FEATURE_NO_TB
 This is a 601 specific HWCAP, so if it is known that the processor
 running is not a 601, via other HWCAPs or other means, it is not
 required to test this bit before using the timebase.
-Unused in the kernel since:
-  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
 
 PPC_FEATURE_POWER4
 The processor is POWER4 or PPC970/FX/MP.
-POWER4 support dropped from the kernel since:
-  471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
+POWER4 support dropped from the kernel since 471d7ff8b51b ("powerpc/64s: 
Remove POWER4 support")
 
 PPC_FEATURE_POWER5
 The processor is POWER5.
@@ -140,7 +136,8 @@ PPC_FEATURE_ICACHE_SNOOP
 The processor icache is coherent with the dcache, and instruction storage
 can be made consistent with data storage for the purpose of executing
 instructions with the sequence (as described in, e.g., POWER9 Processor
-User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)):
+User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi))::
+
 sync
 icbi (to any address)
 isync
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 0/9] Extend automarkup support for ABI symbols

[Bagas Sanjaya]

On Tue, Feb 11, 2025 at 07:22:54AM +0100, Mauro Carvalho Chehab wrote:
> Now that ABI creates a python dictionary, use automarkup to create cross
> references for ABI symbols as well. 

I get three new warnings:

WARNING: /sys/devices/system/cpu/cpuX/topology/physical_package_id is defined 2 
times: 
/home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:27;
 
/home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70
WARNING: /sys/devices/system/cpu/cpuX/topology/ppin is defined 2 times: 
/home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:89;
 
/home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70
WARNING: Documentation/ABI/testing/sysfs-class-cxl not found

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH v3 1/6] powerpc: Document APIv2 KVM hcall spec for Hostwide counters

[Bagas Sanjaya]

On Thu, Jan 23, 2025 at 05:37:43PM +0530, Vaibhav Jain wrote:
> diff --git a/Documentation/arch/powerpc/kvm-nested.rst 
> b/Documentation/arch/powerpc/kvm-nested.rst
> index 5defd13cc6c1..574592505604 100644
> --- a/Documentation/arch/powerpc/kvm-nested.rst
> +++ b/Documentation/arch/powerpc/kvm-nested.rst
> @@ -208,13 +208,9 @@ associated values for each ID in the GSB::
>flags:
>   Bit 0: getGuestWideState: Request state of the Guest instead
> of an individual VCPU.
> - Bit 1: takeOwnershipOfVcpuState Indicate the L1 is taking
> -   over ownership of the VCPU state and that the L0 can free
> -   the storage holding the state. The VCPU state will need to
> -   be returned to the Hypervisor via H_GUEST_SET_STATE prior
> -   to H_GUEST_RUN_VCPU being called for this VCPU. The data
> -   returned in the dataBuffer is in a Hypervisor internal
> -   format.
> + Bit 1: getHostWideState: Request stats of the Host. This causes
> +   the guestId and vcpuId parameters to be ignored and attempting
> +   to get the VCPU/Guest state will cause an error.
>   Bits 2-63: Reserved
>guestId: ID obtained from H_GUEST_CREATE
>vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
> @@ -406,9 +402,10 @@ the partition like the timebase offset and partition 
> scoped page
>  table information.
>  
>  ++---+++--+
> -|   ID   | Size  | RW | Thread | Details  |
> -|| Bytes || Guest  |  |
> -||   || Scope  |  |
> +|   ID   | Size  | RW |(H)ost  | Details  |
> +|| Bytes ||(G)uest |  |
> +||   ||(T)hread|  |
> +||   ||Scope   |  |
>  ++===+++==+
>  | 0x |   | RW |   TG   | NOP element  |
>  ++---+++--+
> @@ -434,6 +431,29 @@ table information.
>  ||   |||- 0x8 Table size. |
>  ++---+++--+
>  | 0x0007-|   ||| Reserved |
> +| 0x07FF |   |||  |
> +++---+++--+
> +| 0x0800 | 0x08  | R  |   H| Current usage in bytes of the|
> +||   ||| L0's Guest Management Space  |
> +||   ||| for an L1-Lpar.  |
> +++---+++--+
> +| 0x0801 | 0x08  | R  |   H| Max bytes available in the   |
> +||   ||| L0's Guest Management Space for  |
> +||   ||| an L1-Lpar   |
> +++---+++--+
> +| 0x0802 | 0x08  | R  |   H| Current usage in bytes of the|
> +||   ||| L0's Guest Page Table Management |
> +||   ||| Space for an L1-Lpar |
> +++---+++--+
> +| 0x0803 | 0x08  | R  |   H| Max bytes available in the L0's  |
> +||   ||| Guest Page Table Management  |
> +||   ||| Space for an L1-Lpar |
> +++---+++--+
> +| 0x0804 | 0x08  | R  |   H| Cumulative Reclaimed bytes from  |
> +||   ||| L0 Guest's Page Table Management |
> +||   ||| Space due to overcommit  |
> +++---+++--+
> +| 0x0805-|   ||| Reserved |
>  | 0x0BFF |   |||      |
>  ++---+++--+
>  | 0x0C00 | 0x10  | RW |   T|Run vCPU Input Buffer:|

The doc LGTM, thanks!

Reviewed-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH] Documentation: ioctl-number: Extend "Include File" column width

[Bagas Sanjaya]

On Wed, Apr 30, 2025 at 06:38:27PM +0530, Venkat Rao Bagalkote wrote:
> 
> Note: There is other patch [1] 
> 
> which has a different approach to fix the reported issue.

Then let the maintainers decide...

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH] Documentation: Fix description format for powerpc RTAS ioctls

[Bagas Sanjaya]

On Tue, Apr 29, 2025 at 07:28:47PM -0700, Haren Myneni wrote:
> Fix the description format for the following build warnings:
> 
> "Documentation/userspace-api/ioctl/ioctl-number.rst:369:
> ERROR: Malformed table. Text in column margin in table line 301.
> 
> 0xB2  03-05 arch/powerpc/include/uapi/asm/papr-indices.h
> powerpc/pseries indices API
> <mailto:linuxppc-dev>
> 0xB2  06-07 arch/powerpc/include/uapi/asm/papr-platform-dump.h
> powerpc/pseries Platform Dump API
> <mailto:linuxppc-dev>
> 0xB2  08  arch/powerpc/include/uapi/asm/papr-physical-attestation.h
> powerpc/pseries Physical Attestation API
> <mailto:linuxppc-dev>"
> 

Hi,

FYI, I've also submitted the fix earlier at [1] (but different approach).
ppc maintainers, would you like taking this patch instead or mine?

[1]: 
https://lore.kernel.org/linuxppc-dev/20250429130524.33587-2-bagasdo...@gmail.com/

> Reported-by: Stephen Rothwell 
> Signed-off-by: Haren Myneni 
> Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for 
> papr-indices ioctls")
> Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character 
> driver for dump retrieval")
> Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for 
> physical-attestation RTAS")
> Closes: 
> https://lore.kernel.org/linux-next/20250429181707.78489...@canb.auug.org.au/
> ---
>  Documentation/userspace-api/ioctl/ioctl-number.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 017a23aeadc3..fee5c4731501 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -366,11 +366,11 @@ Code  Seq#Include File  
>  Comments
>   
> <mailto:linuxppc-dev>
>  0xB2  01-02  arch/powerpc/include/uapi/asm/papr-sysparm.h
> powerpc/pseries system parameter API
>   
> <mailto:linuxppc-dev>
> -0xB2  03-05 arch/powerpc/include/uapi/asm/papr-indices.h 
> powerpc/pseries indices API
> +0xB2  03-05  arch/powerpc/include/uapi/asm/papr-indices.h
> powerpc/pseries indices API
>   
> <mailto:linuxppc-dev>
> -0xB2  06-07 arch/powerpc/include/uapi/asm/papr-platform-dump.h   
> powerpc/pseries Platform Dump API
> +0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h  
> powerpc/pseries Platform Dump API
>   
> <mailto:linuxppc-dev>
> -0xB2  08  arch/powerpc/include/uapi/asm/papr-physical-attestation.h  
> powerpc/pseries Physical Attestation API
> +0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h
> powerpc/pseries Physical Attestation API
>       
> <mailto:linuxppc-dev>
>  0xB3  00 linux/mmc/ioctl.h
>  0xB4  00-0F  linux/gpio.h
> <mailto:linux-g...@vger.kernel.org>

In any case,

Reviewed-by: Bagas Sanjaya 

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

Re: [PATCH] Documentation: Fix description format for powerpc RTAS ioctls

[Bagas Sanjaya]

On Fri, May 02, 2025 at 09:42:37AM +0530, Madhavan Srinivasan wrote:
> 
> 
> On 4/30/25 2:38 PM, Bagas Sanjaya wrote:
> > On Tue, Apr 29, 2025 at 07:28:47PM -0700, Haren Myneni wrote:
> >> Fix the description format for the following build warnings:
> >>
> >> "Documentation/userspace-api/ioctl/ioctl-number.rst:369:
> >> ERROR: Malformed table. Text in column margin in table line 301.
> >>
> >> 0xB2  03-05 arch/powerpc/include/uapi/asm/papr-indices.h
> >> powerpc/pseries indices API
> >> <mailto:linuxppc-dev>
> >> 0xB2  06-07 arch/powerpc/include/uapi/asm/papr-platform-dump.h
> >> powerpc/pseries Platform Dump API
> >> <mailto:linuxppc-dev>
> >> 0xB2  08  arch/powerpc/include/uapi/asm/papr-physical-attestation.h
> >> powerpc/pseries Physical Attestation API
> >> <mailto:linuxppc-dev>"
> >>
> > 
> > Hi,
> > 
> > FYI, I've also submitted the fix earlier at [1] (but different approach).
> > ppc maintainers, would you like taking this patch instead or mine?
> 
> Looked your patch (thanks for the link) and it is more of generic clean up. 
> I would prefer to take Haren patch now since it fixes the specific failure
> case. But would encourage you to send it as generic cleanup patch.

Do you mean submitting the cleanup patch (essentially the same
resulting table as my patch would) on top of Haren's patch?

Confused...

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

[PATCH] Documentation: ioctl-number: Extend "Include File" column width

[Bagas Sanjaya]

Stephen Rothwell reports htmldocs warning when merging powerpc tree for
linux-next:

Documentation/userspace-api/ioctl/ioctl-number.rst:369: ERROR: Malformed table.
Text in column margin in table line 301.

  =  === 

Code  Seq#Include File   Comments
  (hex)
  =  === 

.
.
.
0xB2  03-05 arch/powerpc/include/uapi/asm/papr-indices.h 
powerpc/pseries indices API
 
<mailto:linuxppc-dev>
0xB2  06-07 arch/powerpc/include/uapi/asm/papr-platform-dump.h   
powerpc/pseries Platform Dump API
 
<mailto:linuxppc-dev>
0xB2  08  arch/powerpc/include/uapi/asm/papr-physical-attestation.h  
powerpc/pseries Physical Attestation API
 
<mailto:linuxppc-dev>
.
.
.
  =  === 
 [docutils]

That's because arch/powerpc/include/uapi/asm/papr-physical-attestation.h
now occupies the widest "Include File" column entry in ioctl number
table. In addition, the other papr-*.h entries in the same column aren't
sufficiently padded to align to the rest of column. As such, the table
is skipped in resulting htmldocs output.

Fix the warning by extending "Include File" column so that the
widest entry can fit, and by aligning the other papr-*.h entries. While
at it, also fix mailto: links to linuxppc-dev mailing list.

Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for 
papr-indices ioctls")
Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver 
for dump retrieval")
Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for 
physical-attestation RTAS")
Reported-by: Stephen Rothwell 
Closes: 
https://lore.kernel.org/linux-next/20250429181707.78489...@canb.auug.org.au/
Signed-off-by: Bagas Sanjaya 
---
 .../userspace-api/ioctl/ioctl-number.rst  | 512 +-
 1 file changed, 256 insertions(+), 256 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 017a23aeadc329..b725186670a1d8 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -66,343 +66,343 @@ This table lists ioctls visible from user land for 
Linux/x86.  It contains
 most drivers up to 2.6.31, but I know I am missing some.  There has been
 no attempt to list non-X86 architectures or ioctls from drivers/staging/.
 
-  =  === 

-Code  Seq#Include File   Comments
+  =  =  

+Code  Seq#Include File  
Comments
   (hex)
-  =  === 

-0x00  00-1F  linux/fs.h  conflict!
-0x00  00-1F  scsi/scsi_ioctl.h   conflict!
-0x00  00-1F  linux/fb.h  conflict!
-0x00  00-1F  linux/wavefront.h   conflict!
+  =  =  

+0x00  00-1F  linux/fs.h 
conflict!
+0x00  00-1F  scsi/scsi_ioctl.h  
conflict!
+0x00  00-1F  linux/fb.h 
conflict!
+0x00  00-1F  linux/wavefront.h  
conflict!
 0x02  alllinux/fd.h
 0x03  alllinux/hdreg.h
-0x04  D2-DC  linux/umsdos_fs.h   Dead 
since 2.6.11, but don't reuse these.
+0x04  D2-DC  linux/umsdos_fs.h  Dead 
since 2.6.11, but don't reuse these.
 0x06  alllinux/lp.h
 0x07  9F-D0  linux/vmw_vmci_defs.h, uapi/linux/vm_sockets.h
 0x09  alllinux/raid/md_u.h
 0x10  00-0F  drivers/char/s390/vmcp.h
 0x10  10-1F  arch/s390/include/uapi/sclp_ctl.h
 0x10  20-2F  arch/s390/include/uapi/asm/hypfs.h
-0x12  alllinux

Re: [PATCH] cxl: Fix cross-reference in documentation and add deprecation warning

[Bagas Sanjaya]

On Wed, Feb 19, 2025 at 05:48:07PM +1100, Andrew Donnellan wrote:
> commit 5731d41af924 ("cxl: Deprecate driver") labelled the cxl driver as
> deprecated and moved the ABI documentation to the obsolete/ subdirectory,
> but didn't update cxl.rst, causing a warning once ff7ff6eb4f809 ("docs:
> media: Allow creating cross-references for RC ABI") was merged.
> 
> Fix the cross-reference, and also add a deprecation warning.

Acked-by: Bagas Sanjaya 

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

[PATCH 2/3] Documentation: ioctl-number: Extend "Include File" column width

[Bagas Sanjaya]

Extend width of "Include File" column to fit full path to
papr-physical-attestation.h in later commit.

Signed-off-by: Bagas Sanjaya 
---
 .../userspace-api/ioctl/ioctl-number.rst  | 512 +-
 1 file changed, 256 insertions(+), 256 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index b613235ca18767..3864c8416627e0 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -66,343 +66,343 @@ This table lists ioctls visible from user land for 
Linux/x86.  It contains
 most drivers up to 2.6.31, but I know I am missing some.  There has been
 no attempt to list non-X86 architectures or ioctls from drivers/staging/.
 
-  =  === 

-Code  Seq#Include File   Comments
+  =  = 

+Code  Seq#Include File Comments
   (hex)
-  =  === 

-0x00  00-1F  linux/fs.h  conflict!
-0x00  00-1F  scsi/scsi_ioctl.h   conflict!
-0x00  00-1F  linux/fb.h  conflict!
-0x00  00-1F  linux/wavefront.h   conflict!
+  =  = 

+0x00  00-1F  linux/fs.h
conflict!
+0x00  00-1F  scsi/scsi_ioctl.h 
conflict!
+0x00  00-1F  linux/fb.h
conflict!
+0x00  00-1F  linux/wavefront.h 
conflict!
 0x02  alllinux/fd.h
 0x03  alllinux/hdreg.h
-0x04  D2-DC  linux/umsdos_fs.h   Dead 
since 2.6.11, but don't reuse these.
+0x04  D2-DC  linux/umsdos_fs.h Dead 
since 2.6.11, but don't reuse these.
 0x06  alllinux/lp.h
 0x07  9F-D0  linux/vmw_vmci_defs.h, uapi/linux/vm_sockets.h
 0x09  alllinux/raid/md_u.h
 0x10  00-0F  drivers/char/s390/vmcp.h
 0x10  10-1F  arch/s390/include/uapi/sclp_ctl.h
 0x10  20-2F  arch/s390/include/uapi/asm/hypfs.h
-0x12  alllinux/fs.h  BLK* 
ioctls
+0x12  alllinux/fs.hBLK* 
ioctls
  linux/blkpg.h
  linux/blkzoned.h
  linux/blk-crypto.h
-0x15  alllinux/fs.h  FS_IOC_* 
ioctls
-0x1b  all
InfiniBand Subsystem
- 
<http://infiniband.sourceforge.net/>
+0x15  alllinux/fs.h
FS_IOC_* ioctls
+0x1b  all  
InfiniBand Subsystem
+   
<http://infiniband.sourceforge.net/>
 0x20  alldrivers/cdrom/cm206.h
 0x22  allscsi/sg.h
-0x3E  00-0F  linux/counter.h 
<mailto:linux-...@vger.kernel.org>
+0x3E  00-0F  linux/counter.h   
<mailto:linux-...@vger.kernel.org>
 '!'   00-1F  uapi/linux/seccomp.h
-'#'   00-3F  IEEE 1394 
Subsystem
- Block for 
the entire subsystem
+'#'   00-3FIEEE 
1394 Subsystem
+   Block 
for the entire subsystem
 '$'   00-0F  linux/perf_counter.h, linux/perf_event.h
-'%'   00-0F  include/uapi/linux/stm.hSystem 
Trace Module subsystem
- 
<mailto:alexander.shish...@linux.intel.com>
+'%'   00-0F  include/uapi/linux/stm.h  System 
Trace Module subsystem
+   
<mailto:alexander.shish...@linux.intel.com>
 '&'   00-07  drivers/firewire/nosy-user.h
-'*'   00-1F  uapi/linux/user_events.hUser 
Events Subs

[PATCH 1/3] Documentation: ioctl-number: Fix linuxppc-dev mailto link

[Bagas Sanjaya]

Spell out full Linux PPC mailing list address like other subsystem
mailing lists listed in the table.

Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for 
papr-indices ioctls")
Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver 
for dump retrieval")
Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for 
physical-attestation RTAS")
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index fee5c473150177..b613235ca18767 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -363,15 +363,15 @@ Code  Seq#Include File
   Comments
 0xB1  00-1F  PPPoX
  
<mailto:mostr...@styx.uwaterloo.ca>
 0xB2  00 arch/powerpc/include/uapi/asm/papr-vpd.h
powerpc/pseries VPD API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  01-02  arch/powerpc/include/uapi/asm/papr-sysparm.h
powerpc/pseries system parameter API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  03-05  arch/powerpc/include/uapi/asm/papr-indices.h
powerpc/pseries indices API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h  
powerpc/pseries Platform Dump API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h
powerpc/pseries Physical Attestation API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h
<mailto:linux-g...@vger.kernel.org>
 0xB5  00-0F  uapi/linux/rpmsg.h  
<mailto:linux-remotep...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 0/3] ioctl numbers list cleanup

[Bagas Sanjaya]

Hi Haren, Hi Maddy,

Here is the cleanup series following up from 03c9d1a5a30d93 ("Documentation:
Fix description format for powerpc RTAS ioctls"). The end result should be the
same as my previous fixup patch [1].

Enjoy!

[1]: 
https://lore.kernel.org/linuxppc-dev/20250429130524.33587-2-bagasdo...@gmail.com/

Bagas Sanjaya (3):
  Documentation: ioctl-number: Fix linuxppc-dev mailto link
  Documentation: ioctl-number: Extend "Include File" column width
  Documentation: ioctl-number: Correct full path to
papr-physical-attestation.h

 .../userspace-api/ioctl/ioctl-number.rst  | 512 +-
 1 file changed, 256 insertions(+), 256 deletions(-)


base-commit: 03c9d1a5a30d93bff31b4eb0a52f030b4c7f73ea
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 3/3] Documentation: ioctl-number: Correct full path to papr-physical-attestation.h

[Bagas Sanjaya]

Commit 03c9d1a5a30d93 ("Documentation: Fix description format for
powerpc RTAS ioctls") fixes Sphinx warning by chopping arch/ path
component of papr-physical-attestation.h to fit existing "Include File"
column. Now that the column has been widened just enough for that
header file, add back its arch/ path component.

Fixes: 03c9d1a5a30d ("Documentation: Fix description format for powerpc RTAS 
ioctls")
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 3864c8416627e0..855139f3bc0e48 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -370,7 +370,7 @@ Code  Seq#Include File  
   Comments

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h
powerpc/pseries Platform Dump API

<mailto:linuxppc-dev@lists.ozlabs.org>
-0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h  
powerpc/pseries Physical Attestation API
+0xB2  08 arch/powerpc/include/uapi/asm/papr-physical-attestation.h 
powerpc/pseries Physical Attestation API

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h  
<mailto:linux-g...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH RESEND 1/3] Documentation: ioctl-number: Fix linuxppc-dev mailto link

[Bagas Sanjaya]

On Mon, Jul 07, 2025 at 11:23:30PM -0700, Haren Myneni wrote:
> On Tue, 2025-07-08 at 07:43 +0700, Bagas Sanjaya wrote:
> > Spell out full Linux PPC mailing list address like other subsystem
> > mailing lists listed in the table.
> > 
> > 
> Please also add:
>   Fixes: 514f6ff4369a ("powerpc/pseries: Add papr-vpd character driver
> for VPD retrieval")
>   Fixes: 905b9e48786e ("powerpc/pseries/papr-sysparm: Expose character
> device to user space")

OK, thanks! I will add these in v2.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

[PATCH v2 0/3] ioctl numbers list cleanup for papr-physical-attestation.h

[Bagas Sanjaya]

Hi,

This is the cleanup series following up from 03c9d1a5a30d93 ("Documentation:
Fix description format for powerpc RTAS ioctls"). It is based on docs-next
tree. The end result should be the same as my previous fixup patch [1].

Enjoy!

Changes since v1 (RESEND) [2]:

  * Add Fixes: and Reviewed-by: trailers (Haren)
  * Expand tabs for uapi/misc/amd-apml.h to match other entries

Jon: Would you like to apply this series on docs-next or should powerpc
folks handle it?

[1]: 
https://lore.kernel.org/linuxppc-dev/20250429130524.33587-2-bagasdo...@gmail.com/
[2]: https://lore.kernel.org/lkml/20250708004334.15861-1-bagasdo...@gmail.com/

Bagas Sanjaya (3):
  Documentation: ioctl-number: Fix linuxppc-dev mailto link
  Documentation: ioctl-number: Extend "Include File" column width
  Documentation: ioctl-number: Correct full path to
papr-physical-attestation.h

 .../userspace-api/ioctl/ioctl-number.rst  | 516 +-
 1 file changed, 258 insertions(+), 258 deletions(-)


base-commit: f55b3ca3cf1d1652c4b3481b671940461331d69f
-- 
An old man doll... just what I always wanted! - Clara

[PATCH v2 3/3] Documentation: ioctl-number: Correct full path to papr-physical-attestation.h

[Bagas Sanjaya]

Commit 03c9d1a5a30d93 ("Documentation: Fix description format for
powerpc RTAS ioctls") fixes Sphinx warning by chopping arch/ path
component of papr-physical-attestation.h to fit existing "Include File"
column. Now that the column has been widened just enough for that
header file, add back its arch/ path component.

Fixes: 03c9d1a5a30d ("Documentation: Fix description format for powerpc RTAS 
ioctls")
Reviewed-by: Haren Myneni 
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a7f729eb0c3694..24c7f480e31057 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -369,7 +369,7 @@ Code  Seq#Include File  
   Comments

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h
powerpc/pseries Platform Dump API

<mailto:linuxppc-dev@lists.ozlabs.org>
-0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h  
powerpc/pseries Physical Attestation API
+0xB2  08 arch/powerpc/include/uapi/asm/papr-physical-attestation.h 
powerpc/pseries Physical Attestation API

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h  
<mailto:linux-g...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara

[PATCH v2 2/3] Documentation: ioctl-number: Extend "Include File" column width

[Bagas Sanjaya]

Extend width of "Include File" column to fit full path to
papr-physical-attestation.h in later commit.

Reviewed-by: Haren Myneni 
Signed-off-by: Bagas Sanjaya 
---
 .../userspace-api/ioctl/ioctl-number.rst  | 516 +-
 1 file changed, 258 insertions(+), 258 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a4782e566392c7..a7f729eb0c3694 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -65,345 +65,345 @@ Following this convention is good because:
 This table lists ioctls visible from userland, excluding ones from
 drivers/staging/.
 
-  =  === 

-Code  Seq#Include File   Comments
+  =  = 

+Code  Seq#Include File Comments
   (hex)
-  =  === 

-0x00  00-1F  linux/fs.h  conflict!
-0x00  00-1F  scsi/scsi_ioctl.h   conflict!
-0x00  00-1F  linux/fb.h  conflict!
-0x00  00-1F  linux/wavefront.h   conflict!
+  =  = 

+0x00  00-1F  linux/fs.h
conflict!
+0x00  00-1F  scsi/scsi_ioctl.h 
conflict!
+0x00  00-1F  linux/fb.h
conflict!
+0x00  00-1F  linux/wavefront.h 
conflict!
 0x02  alllinux/fd.h
 0x03  alllinux/hdreg.h
-0x04  D2-DC  linux/umsdos_fs.h   Dead 
since 2.6.11, but don't reuse these.
+0x04  D2-DC  linux/umsdos_fs.h Dead 
since 2.6.11, but don't reuse these.
 0x06  alllinux/lp.h
 0x07  9F-D0  linux/vmw_vmci_defs.h, uapi/linux/vm_sockets.h
 0x09  alllinux/raid/md_u.h
 0x10  00-0F  drivers/char/s390/vmcp.h
 0x10  10-1F  arch/s390/include/uapi/sclp_ctl.h
 0x10  20-2F  arch/s390/include/uapi/asm/hypfs.h
-0x12  alllinux/fs.h  BLK* 
ioctls
+0x12  alllinux/fs.hBLK* 
ioctls
  linux/blkpg.h
  linux/blkzoned.h
  linux/blk-crypto.h
-0x15  alllinux/fs.h  FS_IOC_* 
ioctls
-0x1b  all
InfiniBand Subsystem
- 
<http://infiniband.sourceforge.net/>
+0x15  alllinux/fs.h
FS_IOC_* ioctls
+0x1b  all  
InfiniBand Subsystem
+   
<http://infiniband.sourceforge.net/>
 0x20  alldrivers/cdrom/cm206.h
 0x22  allscsi/sg.h
-0x3E  00-0F  linux/counter.h 
<mailto:linux-...@vger.kernel.org>
+0x3E  00-0F  linux/counter.h   
<mailto:linux-...@vger.kernel.org>
 '!'   00-1F  uapi/linux/seccomp.h
-'#'   00-3F  IEEE 1394 
Subsystem
- Block for 
the entire subsystem
+'#'   00-3FIEEE 
1394 Subsystem
+   Block 
for the entire subsystem
 '$'   00-0F  linux/perf_counter.h, linux/perf_event.h
-'%'   00-0F  include/uapi/linux/stm.hSystem 
Trace Module subsystem
- 
<mailto:alexander.shish...@linux.intel.com>
+'%'   00-0F  include/uapi/linux/stm.h  System 
Trace Module subsystem
+   
<mailto:alexander.shish...@linux.intel.com>
 '&'   00-07  drivers/firewire/nosy-user.h
-'*'   00-1F  uapi/linux/user_events.hUser 
Events Subsystem
- 

[PATCH v2 1/3] Documentation: ioctl-number: Fix linuxppc-dev mailto link

[Bagas Sanjaya]

Spell out full Linux PPC mailing list address like other subsystem
mailing lists listed in the table.

Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for 
papr-indices ioctls")
Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver 
for dump retrieval")
Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for 
physical-attestation RTAS")
Fixes: 514f6ff4369a ("powerpc/pseries: Add papr-vpd character driver for VPD 
retrieval")
Fixes: 905b9e48786e ("powerpc/pseries/papr-sysparm: Expose character device to 
user space")
Reviewed-by: Haren Myneni 
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index bc91756bde733b..a4782e566392c7 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -362,15 +362,15 @@ Code  Seq#Include File
   Comments
 0xB1  00-1F  PPPoX
  
<mailto:mostr...@styx.uwaterloo.ca>
 0xB2  00 arch/powerpc/include/uapi/asm/papr-vpd.h
powerpc/pseries VPD API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  01-02  arch/powerpc/include/uapi/asm/papr-sysparm.h
powerpc/pseries system parameter API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  03-05  arch/powerpc/include/uapi/asm/papr-indices.h
powerpc/pseries indices API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h  
powerpc/pseries Platform Dump API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h
powerpc/pseries Physical Attestation API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h
<mailto:linux-g...@vger.kernel.org>
 0xB5  00-0F  uapi/linux/rpmsg.h  
<mailto:linux-remotep...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara

[PATCH RESEND 2/3] Documentation: ioctl-number: Extend "Include File" column width

[Bagas Sanjaya]

Extend width of "Include File" column to fit full path to
papr-physical-attestation.h in later commit.

Signed-off-by: Bagas Sanjaya 
---
 .../userspace-api/ioctl/ioctl-number.rst  | 516 +-
 1 file changed, 258 insertions(+), 258 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a4782e566392c7..b45f5d857a00b6 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -65,345 +65,345 @@ Following this convention is good because:
 This table lists ioctls visible from userland, excluding ones from
 drivers/staging/.
 
-  =  === 

-Code  Seq#Include File   Comments
+  =  = 

+Code  Seq#Include File Comments
   (hex)
-  =  === 

-0x00  00-1F  linux/fs.h  conflict!
-0x00  00-1F  scsi/scsi_ioctl.h   conflict!
-0x00  00-1F  linux/fb.h  conflict!
-0x00  00-1F  linux/wavefront.h   conflict!
+  =  = 

+0x00  00-1F  linux/fs.h
conflict!
+0x00  00-1F  scsi/scsi_ioctl.h 
conflict!
+0x00  00-1F  linux/fb.h
conflict!
+0x00  00-1F  linux/wavefront.h 
conflict!
 0x02  alllinux/fd.h
 0x03  alllinux/hdreg.h
-0x04  D2-DC  linux/umsdos_fs.h   Dead 
since 2.6.11, but don't reuse these.
+0x04  D2-DC  linux/umsdos_fs.h Dead 
since 2.6.11, but don't reuse these.
 0x06  alllinux/lp.h
 0x07  9F-D0  linux/vmw_vmci_defs.h, uapi/linux/vm_sockets.h
 0x09  alllinux/raid/md_u.h
 0x10  00-0F  drivers/char/s390/vmcp.h
 0x10  10-1F  arch/s390/include/uapi/sclp_ctl.h
 0x10  20-2F  arch/s390/include/uapi/asm/hypfs.h
-0x12  alllinux/fs.h  BLK* 
ioctls
+0x12  alllinux/fs.hBLK* 
ioctls
  linux/blkpg.h
  linux/blkzoned.h
  linux/blk-crypto.h
-0x15  alllinux/fs.h  FS_IOC_* 
ioctls
-0x1b  all
InfiniBand Subsystem
- 
<http://infiniband.sourceforge.net/>
+0x15  alllinux/fs.h
FS_IOC_* ioctls
+0x1b  all  
InfiniBand Subsystem
+   
<http://infiniband.sourceforge.net/>
 0x20  alldrivers/cdrom/cm206.h
 0x22  allscsi/sg.h
-0x3E  00-0F  linux/counter.h 
<mailto:linux-...@vger.kernel.org>
+0x3E  00-0F  linux/counter.h   
<mailto:linux-...@vger.kernel.org>
 '!'   00-1F  uapi/linux/seccomp.h
-'#'   00-3F  IEEE 1394 
Subsystem
- Block for 
the entire subsystem
+'#'   00-3FIEEE 
1394 Subsystem
+   Block 
for the entire subsystem
 '$'   00-0F  linux/perf_counter.h, linux/perf_event.h
-'%'   00-0F  include/uapi/linux/stm.hSystem 
Trace Module subsystem
- 
<mailto:alexander.shish...@linux.intel.com>
+'%'   00-0F  include/uapi/linux/stm.h  System 
Trace Module subsystem
+   
<mailto:alexander.shish...@linux.intel.com>
 '&'   00-07  drivers/firewire/nosy-user.h
-'*'   00-1F  uapi/linux/user_events.hUser 
Events Subsystem
- 

[PATCH RESEND 3/3] Documentation: ioctl-number: Correct full path to papr-physical-attestation.h

[Bagas Sanjaya]

Commit 03c9d1a5a30d93 ("Documentation: Fix description format for
powerpc RTAS ioctls") fixes Sphinx warning by chopping arch/ path
component of papr-physical-attestation.h to fit existing "Include File"
column. Now that the column has been widened just enough for that
header file, add back its arch/ path component.

Fixes: 03c9d1a5a30d ("Documentation: Fix description format for powerpc RTAS 
ioctls")
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index b45f5d857a00b6..5aa09865b3aa0f 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -369,7 +369,7 @@ Code  Seq#Include File  
   Comments

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h
powerpc/pseries Platform Dump API

<mailto:linuxppc-dev@lists.ozlabs.org>
-0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h  
powerpc/pseries Physical Attestation API
+0xB2  08 arch/powerpc/include/uapi/asm/papr-physical-attestation.h 
powerpc/pseries Physical Attestation API

<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h  
<mailto:linux-g...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara

[PATCH RESEND 0/3] ioctl numbers list cleanup for papr-physical-attestation.h

[Bagas Sanjaya]

Hi,

Sorry if my original series [1] didn't get reviewed at all (and merged), so I'm
resending it here.

This is the cleanup series following up from 03c9d1a5a30d93 ("Documentation:
Fix description format for powerpc RTAS ioctls"), now based on docs-next tree.
The end result should be the same as my previous fixup patch [2].

Enjoy!

[1]: 
https://lore.kernel.org/linux-doc/20250507061302.25219-2-bagasdo...@gmail.com/
[2]: 
https://lore.kernel.org/linuxppc-dev/20250429130524.33587-2-bagasdo...@gmail.com/

Bagas Sanjaya (3):
  Documentation: ioctl-number: Fix linuxppc-dev mailto link
  Documentation: ioctl-number: Extend "Include File" column width
  Documentation: ioctl-number: Correct full path to
papr-physical-attestation.h

 .../userspace-api/ioctl/ioctl-number.rst  | 516 +-
 1 file changed, 258 insertions(+), 258 deletions(-)


base-commit: 38d573a624a54ccde1384ead8af0780fe4005c2b
-- 
An old man doll... just what I always wanted! - Clara

[PATCH RESEND 1/3] Documentation: ioctl-number: Fix linuxppc-dev mailto link

[Bagas Sanjaya]

Spell out full Linux PPC mailing list address like other subsystem
mailing lists listed in the table.

Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for 
papr-indices ioctls")
Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver 
for dump retrieval")
Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for 
physical-attestation RTAS")
Signed-off-by: Bagas Sanjaya 
---
 Documentation/userspace-api/ioctl/ioctl-number.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index bc91756bde733b..a4782e566392c7 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -362,15 +362,15 @@ Code  Seq#Include File
   Comments
 0xB1  00-1F  PPPoX
  
<mailto:mostr...@styx.uwaterloo.ca>
 0xB2  00 arch/powerpc/include/uapi/asm/papr-vpd.h
powerpc/pseries VPD API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  01-02  arch/powerpc/include/uapi/asm/papr-sysparm.h
powerpc/pseries system parameter API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  03-05  arch/powerpc/include/uapi/asm/papr-indices.h
powerpc/pseries indices API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  06-07  arch/powerpc/include/uapi/asm/papr-platform-dump.h  
powerpc/pseries Platform Dump API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB2  08 powerpc/include/uapi/asm/papr-physical-attestation.h
powerpc/pseries Physical Attestation API
- 
<mailto:linuxppc-dev>
+ 
<mailto:linuxppc-dev@lists.ozlabs.org>
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h
<mailto:linux-g...@vger.kernel.org>
 0xB5  00-0F  uapi/linux/rpmsg.h  
<mailto:linux-remotep...@vger.kernel.org>
-- 
An old man doll... just what I always wanted! - Clara