* Re: [BUG] powerpc: test_progs -t for_each faults kernel
From: Jiri Olsa @ 2022-01-03 14:36 UTC (permalink / raw)
To: Naveen N. Rao
Cc: haliu, Daniel Borkmann, linuxppc-dev, Alexei Starovoitov,
Yauheni Kaliuta, Jiri Olsa, Yonghong Song, bpf, Andrii Nakryiko
In-Reply-To: <1641188093.6jujx0dvg7.naveen@linux.ibm.com>
On Mon, Jan 03, 2022 at 11:07:02AM +0530, Naveen N. Rao wrote:
> Hi Jiri,
>
> Jiri Olsa wrote:
> > hi,
> > when running 'test_progs -t for_each' on powerpc we are getting
> > the fault below
>
> This looks to be the same issue reported by Yauheni:
> http://lkml.kernel.org/r/xunylf0o872l.fsf@redhat.com
>
> Can you please check if the patch I posted there fixes it for you?
great, yes, that fixes it for me
thanks,
jirka
^ permalink raw reply
* [Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
From: bugzilla-daemon @ 2022-01-03 15:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215443-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215443
Alex Deucher (alexdeucher@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alexdeucher@gmail.com
--- Comment #2 from Alex Deucher (alexdeucher@gmail.com) ---
does appending amdgpu.runpm=0 on the kernel command line help?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
From: bugzilla-daemon @ 2022-01-03 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215443-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215443
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Alex Deucher from comment #2)
> does appending amdgpu.runpm=0 on the kernel command line help?
I doubt it as amdgpu is not even built (# CONFIG_DRM_AMDGPU is not set, see
attached .config).
The card in question is a Radeon HD 6670 using the radeon drm module. Sorry I
forgot to mention that!
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* ppc64el kernel bug?
From: Kip Warner @ 2022-01-04 2:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K.V, Tulio Magno Quites Machado Filho
[-- Attachment #1: Type: text/plain, Size: 11770 bytes --]
Dear List,
I was directed to this list by a colleague of mine at IBM (cc'd).
After recently spending all day debugging late into the evening, I
think I've found a problem. I noticed some really weird behaviour with
one of my application's database i/o threads exiting without any
exceptions being thrown and without anything in my code apparently
telling it to exit. This happened only on ppc64el.
I checked the postgresql log and this is what I see after my
application's connection thread bails:
2021-12-25 06:52:52.836 UTC [144517] LOG: server process (PID 144937) was terminated by signal 11: Segmentation fault
2021-12-25 06:52:52.836 UTC [144517] DETAIL: Failed process was running: SELECT * FROM mytable;
2021-12-25 06:52:52.836 UTC [144517] LOG: terminating any other active server processes
2021-12-25 06:52:52.836 UTC [144941] WARNING: terminating connection because of crash of another server process
2021-12-25 06:52:52.836 UTC [144941] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-12-25 06:52:52.836 UTC [144941] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-12-25 06:52:52.836 UTC [144940] WARNING: terminating connection because of crash of another server process
2021-12-25 06:52:52.836 UTC [144940] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-12-25 06:52:52.836 UTC [144940] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-12-25 06:52:52.836 UTC [144938] WARNING: terminating connection because of crash of another server process
2021-12-25 06:52:52.836 UTC [144938] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-12-25 06:52:52.836 UTC [144938] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-12-25 06:52:52.836 UTC [144939] WARNING: terminating connection because of crash of another server process
2021-12-25 06:52:52.836 UTC [144939] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-12-25 06:52:52.836 UTC [144939] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-12-25 06:52:52.836 UTC [144833] WARNING: terminating connection because of crash of another server process
2021-12-25 06:52:52.836 UTC [144833] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-12-25 06:52:52.836 UTC [144833] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-12-25 06:52:52.838 UTC [144517] LOG: all server processes terminated; reinitializing
2021-12-25 06:52:52.842 UTC [144942] LOG: database system was interrupted; last known up at 2021-12-25 06:46:54 UTC
2021-12-25 06:52:52.842 UTC [144942] LOG: database system was not properly shut down; automatic recovery in progress
2021-12-25 06:52:52.843 UTC [144942] LOG: redo starts at 0/192A690
2021-12-25 06:52:52.843 UTC [144942] LOG: invalid record length at 0/19378B8: wanted 24, got 0
2021-12-25 06:52:52.843 UTC [144942] LOG: redo done at 0/1937430
2021-12-25 06:52:52.850 UTC [144517] LOG: database system is ready to accept connections
That looks like PostgreSQL itself crashed. So I started trying to find
a core dump, but couldn't find it. I checked the kernel log and this is
where it gets interesting:
Dec 25 06:52:52 romulus-server kernel: [28835.277591] BUG: Unable to handle kernel data access on write at 0x132b47d38499fd58
Dec 25 06:52:52 romulus-server kernel: [28835.277624] Faulting instruction address: 0xc0000000004d0434
Dec 25 06:52:52 romulus-server kernel: [28835.277636] Oops: Kernel access of bad area, sig: 11 [#150]
Dec 25 06:52:52 romulus-server kernel: [28835.277656] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Dec 25 06:52:52 romulus-server kernel: [28835.277669] Modules linked in: veth nft_masq zfs(PO) zunicode(PO) zzstd(O) zlua(O) zcommon(PO) znvpair(PO) zavl(PO) icp(PO) spl(O) vhost_vsock vmw_vsock_virtio_transport_common vhost vhost_iotlb vsock xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter xt_tcpudp nft_compat bridge stp llc nf_tables nfnetlink binfmt_misc dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua joydev input_leds ipmi_powernv mac_hid ipmi_devintf ipmi_msghandler ofpart cmdlinepart at24 powernv_flash mtd uio_pdrv_genirq opal_prd uio ibmpowernv vmx_crypto sch_fq_codel jc42 ip_tables x_tables autofs4 xfs btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_generic usbhid hid raid6_pq libcrc32c raid1 raid0 multipath linear nouveau ses enclosure scsi_transport_sas ast drm_vram_helper i2c_algo_bit drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm crct10dif_vpmsum
Dec 25 06:52:52 romulus-server kernel: [28835.277776] crc32c_vpmsum xhci_pci tg3 aacraid xhci_pci_renesas drm_panel_orientation_quirks
Dec 25 06:52:52 romulus-server kernel: [28835.277918] CPU: 26 PID: 144937 Comm: postgres Tainted: P D O 5.11.0-41-generic #45-Ubuntu
Dec 25 06:52:52 romulus-server kernel: [28835.277943] NIP: c0000000004d0434 LR: c0000000004d032c CTR: c0000000010a90e0
Dec 25 06:52:52 romulus-server kernel: [28835.277975] REGS: c000000056b9f6b0 TRAP: 0380 Tainted: P D O (5.11.0-41-generic)
Dec 25 06:52:52 romulus-server kernel: [28835.278008] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 88002281 XER: 0000008c
Dec 25 06:52:52 romulus-server kernel: [28835.278050] CFAR: c0000000004d041c IRQMASK: 0
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR00: c0000000004d032c c000000056b9f950 c000000002409a00 0000000000000000
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR04: 0000000000400cc0 0000000000000097 ffffffffffffffff c000000ffda9d0d0
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR08: 0000000ffbd90000 132b47d38499fce8 0000000000000070 d4ff277338704e25
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR12: 0000000000002000 c000000ffffd2c00 0000000000000000 c000000116c512d0
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR16: 0000000000000154 c000000116c51570 c000000056b9fc88 0000000000000154
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR24: c000000000ecccc0 0000000000000001 c0000000024588fc c000000000ec9954
Dec 25 06:52:52 romulus-server kernel: [28835.278050] GPR28: ffffffffffffffff c00000001d597e40 0000000000400cc0 c000000003018880
Dec 25 06:52:52 romulus-server kernel: [28835.278213] NIP [c0000000004d0434] kmem_cache_alloc_node+0x1d4/0x490
Dec 25 06:52:52 romulus-server kernel: [28835.278237] LR [c0000000004d032c] kmem_cache_alloc_node+0xcc/0x490
Dec 25 06:52:52 romulus-server kernel: [28835.278268] Call Trace:
Dec 25 06:52:52 romulus-server kernel: [28835.278283] [c000000056b9f950] [c0000000004d032c] kmem_cache_alloc_node+0xcc/0x490 (unreliable)
Dec 25 06:52:52 romulus-server kernel: [28835.278328] [c000000056b9f9c0] [c000000000ec9954] __alloc_skb+0x74/0x2d0
Dec 25 06:52:52 romulus-server kernel: [28835.278369] [c000000056b9fa20] [c000000000ecccc0] alloc_skb_with_frags+0x70/0x2e0
Dec 25 06:52:52 romulus-server kernel: [28835.278403] [c000000056b9faa0] [c000000000ec0f38] sock_alloc_send_pskb+0x1d8/0x200
Dec 25 06:52:52 romulus-server kernel: [28835.278436] [c000000056b9fb10] [c0000000010a93a8] unix_stream_sendmsg+0x2c8/0x710
Dec 25 06:52:52 romulus-server kernel: [28835.278471] [c000000056b9fc10] [c000000000eb64e0] sock_sendmsg+0x80/0xb0
Dec 25 06:52:52 romulus-server kernel: [28835.278494] [c000000056b9fc40] [c000000000ebab88] __sys_sendto+0xf8/0x1a0
Dec 25 06:52:52 romulus-server kernel: [28835.278526] [c000000056b9fd90] [c000000000ebaca0] sys_send+0x30/0x40
Dec 25 06:52:52 romulus-server kernel: [28835.278558] [c000000056b9fdb0] [c000000000036ffc] system_call_exception+0x10c/0x230
Dec 25 06:52:52 romulus-server kernel: [28835.278601] [c000000056b9fe10] [c00000000000d374] system_call_vectored_common+0xf4/0x26c
Dec 25 06:52:52 romulus-server kernel: [28835.278634] --- interrupt: 3000 at 0x7ec638a194f4
Dec 25 06:52:52 romulus-server kernel: [28835.278654] NIP: 00007ec638a194f4 LR: 0000000000000000 CTR: 0000000000000000
Dec 25 06:52:52 romulus-server kernel: [28835.278685] REGS: c000000056b9fe80 TRAP: 3000 Tainted: P D O (5.11.0-41-generic)
Dec 25 06:52:52 romulus-server kernel: [28835.278719] MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48008281 XER: 00000000
Dec 25 06:52:52 romulus-server kernel: [28835.278766] IRQMASK: 0
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR00: 000000000000014e 00007fffe99c1800 00007ec638a47f00 0000000000000009
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR04: 00000043809d1148 0000000000000154 0000000000000000 0000000000001ae8
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR08: 0000004362347d00 0000000000000000 0000000000000000 0000000000000000
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR12: 0000000000000000 00007ec6348e0890 0000000000000000 ffffffffffffffff
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR16: 0000000000000000 000000436233f7a0 0000000000000001 0000000000000000
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR20: 00007fffe99c18ac 0000004362344f48 0000000000000004 00007fffe99c18b0
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR24: 0000000006000001 0000000000000000 0000000000000154 00000043809d1148
Dec 25 06:52:52 romulus-server kernel: [28835.278766] GPR28: 0000000000000000 00007ec6348d9938 00000043809ceb00 000000000000000b
Dec 25 06:52:52 romulus-server kernel: [28835.278992] NIP [00007ec638a194f4] 0x7ec638a194f4
Dec 25 06:52:52 romulus-server kernel: [28835.279020] LR [0000000000000000] 0x0
Dec 25 06:52:52 romulus-server kernel: [28835.279038] --- interrupt: 3000
Dec 25 06:52:52 romulus-server kernel: [28835.279054] Instruction dump:
Dec 25 06:52:52 romulus-server kernel: [28835.279072] f9210020 41820098 2e1cffff 3b200001 2c2a0000 41820088 41920010 894a0007
Dec 25 06:52:52 romulus-server kernel: [28835.279110] 7c1c5000 40820078 815f0028 e97f00b8 <7ce9502a> 7c095214 886d0988 9b2d0988
Dec 25 06:52:52 romulus-server kernel: [28835.279141] ---[ end trace fe7ee98d0b7beb6a ]---
Dec 25 06:52:52 romulus-server kernel: [28835.855026]
I'm only experiencing this on ppc64el, but not amd64 or risc64. The
closest thing I could find to it was this:
https://github.com/dynup/kpatch/issues/1228
I'm using kernel 5.11.0-41-generic and g++ 11.1.0.
Any thoughts?
--
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [5.16.0-rc7] net-next build broken on powerpc
From: Jakub Kicinski @ 2022-01-04 3:33 UTC (permalink / raw)
To: Abdul Haleem; +Cc: sachinp, netdev, saeedm, linuxppc-dev, linux-kernel
In-Reply-To: <7c03768d-d948-c935-a7ab-b1f963ac7eed@linux.vnet.ibm.com>
On Mon, 3 Jan 2022 19:10:01 +0530 Abdul Haleem wrote:
> Greeting's
>
> Today's netdev/net-next kernel 5.16.0-rc7 failed to build on my powerpc box with below error
>
> CC [M] drivers/net/ethernet/mellanox/mlx5/core/en_main.o
> In file included from ./arch/powerpc/include/generated/asm/rwonce.h:1,
> from ./include/linux/compiler.h:266,
> from ./arch/powerpc/include/asm/cmpxchg.h:6,
> from ./arch/powerpc/include/asm/atomic.h:11,
> from ./include/linux/atomic.h:7,
> from ./include/linux/refcount.h:95,
> from ./include/net/act_api.h:9,
> from ./include/net/tc_act/tc_gact.h:5,
> from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:33:
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c: In function ‘mlx5e_alloc_rq’:
> ./include/linux/rcupdate.h:412:36: error: dereferencing pointer to incomplete type ‘struct bpf_prog’
> #define RCU_INITIALIZER(v) (typeof(*(v)) __force __rcu *)(v)
> ^~~~
> ./include/asm-generic/rwonce.h:55:33: note: in definition of macro ‘__WRITE_ONCE’
> *(volatile typeof(x) *)&(x) = (val); \
> ^~~
> ./include/linux/rcupdate.h:854:3: note: in expansion of macro ‘WRITE_ONCE’
> WRITE_ONCE(p, RCU_INITIALIZER(v)); \
> ^~~~~~~~~~
> ./include/linux/rcupdate.h:854:17: note: in expansion of macro ‘RCU_INITIALIZER’
> WRITE_ONCE(p, RCU_INITIALIZER(v)); \
> ^~~~~~~~~~~~~~~
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c:569:2: note: in expansion of macro ‘RCU_INIT_POINTER’
> RCU_INIT_POINTER(rq->xdp_prog, params->xdp_prog);
> ^~~~~~~~~~~~~~~~
> make[5]: *** [scripts/Makefile.build:287: drivers/net/ethernet/mellanox/mlx5/core/en_main.o] Error 1
>
I can repro a powerpc build failure with ice, but I don't see anything
wrong in mlx5 in an allmodconfig. The config you attached is invalid:
.config:709:warning: symbol value 'm' invalid for HOTPLUG_PCI_SHPC
.config:892:warning: symbol value 'm' invalid for NF_CT_PROTO_GRE
.config:919:warning: symbol value 'm' invalid for NF_NAT_REDIRECT
.config:922:warning: symbol value 'm' invalid for NF_TABLES_INET
.config:1099:warning: symbol value 'm' invalid for NF_TABLES_IPV4
.config:1104:warning: symbol value 'm' invalid for NF_TABLES_ARP
.config:1146:warning: symbol value 'm' invalid for NF_TABLES_IPV6
.config:1537:warning: symbol value 'm' invalid for NET_DEVLINK
.config:2721:warning: symbol value 'm' invalid for ISDN_CAPI
.config:3066:warning: symbol value 'm' invalid for HW_RANDOM_TPM
.config:3589:warning: symbol value 'm' invalid for LIRC
.config:5356:warning: symbol value 'm' invalid for FS_ENCRYPTION
I'll send a fix based on your error messages, it does look like
en_main.c should include filter.h.
^ permalink raw reply
* Re: [PATCH 2/3] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
From: Alexey Kardashevskiy @ 2022-01-04 9:01 UTC (permalink / raw)
To: Fabiano Rosas, Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <87zgomq7nn.fsf@linux.ibm.com>
On 28/12/2021 04:28, Fabiano Rosas wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> Excerpts from Fabiano Rosas's message of December 24, 2021 7:15 am:
>>> The MMIO emulation code for vector instructions is duplicated between
>>> VSX and VMX. When emulating VMX we should check the VMX copy size
>>> instead of the VSX one.
>>>
>>> Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
>>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>>
>> Good catch. AFAIKS handle_vmx_store needs the same treatment? If you
>> agree then
>
> Half the bug now, half the bug next year... haha I'll send a v2.
>
> aside:
> All this duplication is kind of annoying. I'm looking into what it would
> take to have quadword instruction emulation here as well (Alexey caught
> a bug with syskaller) and the code would be really similar. I see that
> x86 has a more generic implementation that maybe we could take advantage
> of. See "f78146b0f923 (KVM: Fix page-crossing MMIO)"
Uff. My head exploded with vsx/vmx/vec :)
But this seems to have fixed "lvx" (which is vmx, right?).
Tested with: https://github.com/aik/linux/commits/my_kvm_tests
--
Alexey
^ permalink raw reply
* [PATCH 0/3] ASoC: imx-card: several improvement and fixes
From: Shengjiu Wang @ 2022-01-04 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
Several improvement and fixes for AK codecs supported on i.MX platfroms
Shengjiu Wang (3):
ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
ASoC: imx-card: Fix mclk calculation issue for akcodec
ASoC: imx-card: improve the sound quality for low rate
sound/soc/fsl/imx-card.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/3] ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
From: Shengjiu Wang @ 2022-01-04 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1641292835-19085-1-git-send-email-shengjiu.wang@nxp.com>
The SAI on i.MX8MQ don't support one2one ratio for mclk:bclk, so
the mclk frequency exceeds the supported range of codec for
the case that sample rate is larger than 705kHZ and format is
S32_LE. Update the supported width for such case.
Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-card.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
index e758c4f1b0bc..e0f3aa6d9501 100644
--- a/sound/soc/fsl/imx-card.c
+++ b/sound/soc/fsl/imx-card.c
@@ -553,8 +553,23 @@ static int imx_card_parse_of(struct imx_card_data *data)
link_data->cpu_sysclk_id = FSL_SAI_CLK_MAST1;
/* sai may support mclk/bclk = 1 */
- if (of_find_property(np, "fsl,mclk-equal-bclk", NULL))
+ if (of_find_property(np, "fsl,mclk-equal-bclk", NULL)) {
link_data->one2one_ratio = true;
+ } else {
+ int i;
+
+ /*
+ * i.MX8MQ don't support one2one ratio, then
+ * with ak4497 only 16bit case is supported.
+ */
+ for (i = 0; i < ARRAY_SIZE(ak4497_fs_mul); i++) {
+ if (ak4497_fs_mul[i].rmin == 705600 &&
+ ak4497_fs_mul[i].rmax == 768000) {
+ ak4497_fs_mul[i].wmin = 32;
+ ak4497_fs_mul[i].wmax = 32;
+ }
+ }
+ }
}
link->cpus->of_node = args.np;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] ASoC: imx-card: Fix mclk calculation issue for akcodec
From: Shengjiu Wang @ 2022-01-04 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1641292835-19085-1-git-send-email-shengjiu.wang@nxp.com>
Transfer the refined slots and slot_width to akcodec_get_mclk_rate()
for mclk calculation, otherwise the mclk frequency does not match
with the slots and slot_width for S16_LE format, because the default
slot_width is 32.
Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-card.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
index e0f3aa6d9501..f9196fb7e833 100644
--- a/sound/soc/fsl/imx-card.c
+++ b/sound/soc/fsl/imx-card.c
@@ -247,13 +247,14 @@ static bool codec_is_akcodec(unsigned int type)
}
static unsigned long akcodec_get_mclk_rate(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
+ struct snd_pcm_hw_params *params,
+ int slots, int slot_width)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct imx_card_data *data = snd_soc_card_get_drvdata(rtd->card);
const struct imx_card_plat_data *plat_data = data->plat_data;
struct dai_link_data *link_data = &data->link_data[rtd->num];
- unsigned int width = link_data->slots * link_data->slot_width;
+ unsigned int width = slots * slot_width;
unsigned int rate = params_rate(params);
int i;
@@ -349,7 +350,7 @@ static int imx_aif_hw_params(struct snd_pcm_substream *substream,
/* Set MCLK freq */
if (codec_is_akcodec(plat_data->type))
- mclk_freq = akcodec_get_mclk_rate(substream, params);
+ mclk_freq = akcodec_get_mclk_rate(substream, params, slots, slot_width);
else
mclk_freq = params_rate(params) * slots * slot_width;
/* Use the maximum freq from DSD512 (512*44100 = 22579200) */
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] ASoC: imx-card: improve the sound quality for low rate
From: Shengjiu Wang @ 2022-01-04 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1641292835-19085-1-git-send-email-shengjiu.wang@nxp.com>
According to RM, on auto mode:
For codec AK4458 and AK4497, the lowest ratio of MLCK/FS is 256
if sample rate is 8kHz-48kHz,
For codec AK5558, the lowest ratio of MLCK/FS is 512 if sample
rate is 8kHz-48kHz.
With these setting the sound quality for 8kHz-48kHz can be improved.
Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-card.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
index f9196fb7e833..6f8efd838fcc 100644
--- a/sound/soc/fsl/imx-card.c
+++ b/sound/soc/fsl/imx-card.c
@@ -120,7 +120,7 @@ struct imx_card_data {
static struct imx_akcodec_fs_mul ak4458_fs_mul[] = {
/* Normal, < 32kHz */
- { .rmin = 8000, .rmax = 24000, .wmin = 1024, .wmax = 1024, },
+ { .rmin = 8000, .rmax = 24000, .wmin = 256, .wmax = 1024, },
/* Normal, 32kHz */
{ .rmin = 32000, .rmax = 32000, .wmin = 256, .wmax = 1024, },
/* Normal */
@@ -151,8 +151,8 @@ static struct imx_akcodec_fs_mul ak4497_fs_mul[] = {
* Table 7 - mapping multiplier and speed mode
* Tables 8 & 9 - mapping speed mode and LRCK fs
*/
- { .rmin = 8000, .rmax = 32000, .wmin = 1024, .wmax = 1024, }, /* Normal, <= 32kHz */
- { .rmin = 44100, .rmax = 48000, .wmin = 512, .wmax = 512, }, /* Normal */
+ { .rmin = 8000, .rmax = 32000, .wmin = 256, .wmax = 1024, }, /* Normal, <= 32kHz */
+ { .rmin = 44100, .rmax = 48000, .wmin = 256, .wmax = 512, }, /* Normal */
{ .rmin = 88200, .rmax = 96000, .wmin = 256, .wmax = 256, }, /* Double */
{ .rmin = 176400, .rmax = 192000, .wmin = 128, .wmax = 128, }, /* Quad */
{ .rmin = 352800, .rmax = 384000, .wmin = 128, .wmax = 128, }, /* Oct */
@@ -164,7 +164,7 @@ static struct imx_akcodec_fs_mul ak4497_fs_mul[] = {
* (Table 4 from datasheet)
*/
static struct imx_akcodec_fs_mul ak5558_fs_mul[] = {
- { .rmin = 8000, .rmax = 32000, .wmin = 1024, .wmax = 1024, },
+ { .rmin = 8000, .rmax = 32000, .wmin = 512, .wmax = 1024, },
{ .rmin = 44100, .rmax = 48000, .wmin = 512, .wmax = 512, },
{ .rmin = 88200, .rmax = 96000, .wmin = 256, .wmax = 256, },
{ .rmin = 176400, .rmax = 192000, .wmin = 128, .wmax = 128, },
--
2.17.1
^ permalink raw reply related
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: John Paul Adrian Glaubitz @ 2022-01-04 13:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <87k0hs8iyq.fsf@mpe.ellerman.id.au>
Hi Michael!
Sorry for the long time without any responses. Shall we continue debugging this?
We're currently running 5.15.x on the host system and the guests and the testsuite
for gcc-9 still reproducibly kills the KVM host.
Adrian
On 11/1/21 07:53, Michael Ellerman wrote:
> Sure, will give that a try.
>
> I was able to crash my machine over the weekend, building openjdk, but I
> haven't been able to reproduce it for ~24 hours now (I didn't change
> anything).
>
>
> Can you try running your guests with no SMT threads?
>
> I think one of your guests was using:
>
> -smp 32,sockets=1,dies=1,cores=8,threads=4
>
> Can you change that to:
>
> -smp 8,sockets=1,dies=1,cores=8,threads=1
>
>
> And something similar for the other guest(s).
>
> If the system is stable with those settings that would be useful
> information, and would also mean you could use the system without it
> crashing semi regularly.
>
> cheers
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH] powerpc/cacheinfo: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-04 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: Parth Shah, Gautham R. Shenoy, Greg Kroah-Hartman, Paul Mackerras,
linuxppc-dev
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the powerpc cacheinfo sysfs code to use default_groups
field which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute groups to kobj_type") so that we can soon
get rid of the obsolete default_attrs field.
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Cc: Parth Shah <parth@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/cacheinfo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index cf1be75b7833..00b0992be3e7 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -710,7 +710,7 @@ static struct kobj_attribute cache_shared_cpu_list_attr =
__ATTR(shared_cpu_list, 0444, shared_cpu_list_show, NULL);
/* Attributes which should always be created -- the kobject/sysfs core
- * does this automatically via kobj_type->default_attrs. This is the
+ * does this automatically via kobj_type->default_groups. This is the
* minimum data required to uniquely identify a cache.
*/
static struct attribute *cache_index_default_attrs[] = {
@@ -720,6 +720,7 @@ static struct attribute *cache_index_default_attrs[] = {
&cache_shared_cpu_list_attr.attr,
NULL,
};
+ATTRIBUTE_GROUPS(cache_index_default);
/* Attributes which should be created if the cache device node has the
* right properties -- see cacheinfo_create_index_opt_attrs
@@ -738,7 +739,7 @@ static const struct sysfs_ops cache_index_ops = {
static struct kobj_type cache_index_type = {
.release = cache_index_release,
.sysfs_ops = &cache_index_ops,
- .default_attrs = cache_index_default_attrs,
+ .default_groups = cache_index_default_groups,
};
static void cacheinfo_create_index_opt_attrs(struct cache_index_dir *dir)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_mqs: fix MODULE_ALIAS
From: Mark Brown @ 2022-01-04 16:02 UTC (permalink / raw)
To: Takashi Iwai, Liam Girdwood, Nicolin Chen, Shengjiu Wang,
Jaroslav Kysela, Fabio Estevam, Alyssa Ross, Xiubo Li
Cc: moderated list:FREESCALE SOC SOUND DRIVERS,
open list:FREESCALE SOC SOUND DRIVERS, open list
In-Reply-To: <20220104132218.1690103-1-hi@alyssa.is>
On Tue, 4 Jan 2022 13:22:16 +0000, Alyssa Ross wrote:
> modprobe can't handle spaces in aliases.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_mqs: fix MODULE_ALIAS
commit: 9f3d45318dd9e739ed62e4218839a7a824d3cced
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v6 03/14] mm: Add len and flags parameters to arch_get_mmap_end()
From: Catalin Marinas @ 2022-01-04 16:09 UTC (permalink / raw)
To: Christophe Leroy
Cc: alex@ghiti.fr, Steve Capper, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, will@kernel.org, Paul Mackerras,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <f1014efff7d26279d8c687d759af9f709cd50453.1639736449.git.christophe.leroy@csgroup.eu>
On Fri, Dec 17, 2021 at 10:27:23AM +0000, Christophe Leroy wrote:
> Powerpc needs flags and len to make decision on arch_get_mmap_end().
>
> So add them as parameters to arch_get_mmap_end().
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> arch/arm64/include/asm/processor.h | 4 ++--
> mm/mmap.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 6f41b65f9962..88c696350ace 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -91,8 +91,8 @@
> #endif /* CONFIG_COMPAT */
>
> #ifndef CONFIG_ARM64_FORCE_52BIT
> -#define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
> - DEFAULT_MAP_WINDOW)
> +#define arch_get_mmap_end(addr, len, flags) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
> + DEFAULT_MAP_WINDOW)
Nitpick, move the "((addr > ...." on the following line. Either way,
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] powerpc/opal: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-04 16:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, Vasant Hegde, Paul Mackerras, Joel Stanley,
linuxppc-dev
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the powerpc opal dump and elog sysfs code to use
default_groups field which has been the preferred way since aa30f47cf666
("kobject: Add support for default attribute groups to kobj_type") so
that we can soon get rid of the obsolete default_attrs field.
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/powernv/opal-dump.c | 3 ++-
arch/powerpc/platforms/powernv/opal-elog.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index 717d1d30ade5..410ed5b9de29 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -208,11 +208,12 @@ static struct attribute *dump_default_attrs[] = {
&ack_attribute.attr,
NULL,
};
+ATTRIBUTE_GROUPS(dump_default);
static struct kobj_type dump_ktype = {
.sysfs_ops = &dump_sysfs_ops,
.release = &dump_release,
- .default_attrs = dump_default_attrs,
+ .default_groups = dump_default_groups,
};
static int64_t dump_read_info(uint32_t *dump_id, uint32_t *dump_size, uint32_t *dump_type)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 5821b0fa8614..554fdd7f88b8 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -144,11 +144,12 @@ static struct attribute *elog_default_attrs[] = {
&ack_attribute.attr,
NULL,
};
+ATTRIBUTE_GROUPS(elog_default);
static struct kobj_type elog_ktype = {
.sysfs_ops = &elog_sysfs_ops,
.release = &elog_release,
- .default_attrs = elog_default_attrs,
+ .default_groups = elog_default_groups,
};
/* Maximum size of a single log on FSP is 16KB */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 04/14] mm, hugetlbfs: Allow for "high" userspace addresses
From: Catalin Marinas @ 2022-01-04 16:21 UTC (permalink / raw)
To: Christophe Leroy
Cc: alex@ghiti.fr, Steve Capper, Will Deacon,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, will@kernel.org,
Paul Mackerras, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <db238c1ca2d46e33c57328f8d450f2563e92f8c2.1639736449.git.christophe.leroy@csgroup.eu>
On Fri, Dec 17, 2021 at 10:27:28AM +0000, Christophe Leroy wrote:
> This is a complement of f6795053dac8 ("mm: mmap: Allow for "high"
> userspace addresses") for hugetlb.
>
> This patch adds support for "high" userspace addresses that are
> optionally supported on the system and have to be requested via a hint
> mechanism ("high" addr parameter to mmap).
>
> Architectures such as powerpc and x86 achieve this by making changes to
> their architectural versions of hugetlb_get_unmapped_area() function.
> However, arm64 uses the generic version of that function.
>
> So take into account arch_get_mmap_base() and arch_get_mmap_end() in
> hugetlb_get_unmapped_area(). To allow that, move those two macros
> out of mm/mmap.c into include/linux/sched/mm.h
>
> If these macros are not defined in architectural code then they default
> to (TASK_SIZE) and (base) so should not introduce any behavioural
> changes to architectures that do not define them.
>
> For the time being, only ARM64 is affected by this change.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> fs/hugetlbfs/inode.c | 9 +++++----
> include/linux/sched/mm.h | 8 ++++++++
> mm/mmap.c | 8 --------
> 3 files changed, 13 insertions(+), 12 deletions(-)
This would be an ABI change but I'm fine with it. Basically with this
patch, getting hugetblfs addresses above 48-bit require explicit hint
passed to mmap().
I wonder whether we should add a fixes tag (or at least the cc stable):
Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses")
Cc: <stable@vger.kernel.org> # 5.0.x
I think the original commit should have changed
hugetlb_get_unmapped_area() to have the same behaviour as
arch_get_unmapped_area(). Steve, any thoughts?
FWIW,
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
From: Mark Brown @ 2022-01-04 18:06 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, perex,
nicoleotsuka, festevam, linux-kernel
In-Reply-To: <1641292835-19085-2-git-send-email-shengjiu.wang@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
On Tue, Jan 04, 2022 at 06:40:33PM +0800, Shengjiu Wang wrote:
> /* sai may support mclk/bclk = 1 */
> - if (of_find_property(np, "fsl,mclk-equal-bclk", NULL))
> + if (of_find_property(np, "fsl,mclk-equal-bclk", NULL)) {
> link_data->one2one_ratio = true;
> + } else {
> + int i;
> +
> + /*
> + * i.MX8MQ don't support one2one ratio, then
> + * with ak4497 only 16bit case is supported.
> + */
> + for (i = 0; i < ARRAY_SIZE(ak4497_fs_mul); i++) {
Shouldn't this be keyed off checking that we are actually running with
an ak4497?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/13] livepatch: Fix build failure on 32 bits processors
From: Joe Lawrence @ 2022-01-04 19:35 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Jiri Kosina, linux-kernel@vger.kernel.org,
Steven Rostedt, Ingo Molnar, Josh Poimboeuf,
live-patching@vger.kernel.org, Naveen N . Rao, Miroslav Benes,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5288e11b018a762ea3351cc8fb2d4f15093a4457.1640017960.git.christophe.leroy@csgroup.eu>
On Mon, Dec 20, 2021 at 04:38:02PM +0000, Christophe Leroy wrote:
> Trying to build livepatch on powerpc/32 results in:
>
> kernel/livepatch/core.c: In function 'klp_resolve_symbols':
> kernel/livepatch/core.c:221:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 221 | sym = (Elf64_Sym *)sechdrs[symndx].sh_addr + ELF_R_SYM(relas[i].r_info);
> | ^
> kernel/livepatch/core.c:221:21: error: assignment to 'Elf32_Sym *' {aka 'struct elf32_sym *'} from incompatible pointer type 'Elf64_Sym *' {aka 'struct elf64_sym *'} [-Werror=incompatible-pointer-types]
> 221 | sym = (Elf64_Sym *)sechdrs[symndx].sh_addr + ELF_R_SYM(relas[i].r_info);
> | ^
> kernel/livepatch/core.c: In function 'klp_apply_section_relocs':
> kernel/livepatch/core.c:312:35: error: passing argument 1 of 'klp_resolve_symbols' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 312 | ret = klp_resolve_symbols(sechdrs, strtab, symndx, sec, sec_objname);
> | ^~~~~~~
> | |
> | Elf32_Shdr * {aka struct elf32_shdr *}
> kernel/livepatch/core.c:193:44: note: expected 'Elf64_Shdr *' {aka 'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka 'struct elf32_shdr *'}
> 193 | static int klp_resolve_symbols(Elf64_Shdr *sechdrs, const char *strtab,
> | ~~~~~~~~~~~~^~~~~~~
>
> Fix it by using the right types instead of forcing 64 bits types.
>
> Fixes: 7c8e2bdd5f0d ("livepatch: Apply vmlinux-specific KLP relocations early")
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Acked-by: Petr Mladek <pmladek@suse.com>
> ---
> kernel/livepatch/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 335d988bd811..c0789383807b 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -190,7 +190,7 @@ static int klp_find_object_symbol(const char *objname, const char *name,
> return -EINVAL;
> }
>
> -static int klp_resolve_symbols(Elf64_Shdr *sechdrs, const char *strtab,
> +static int klp_resolve_symbols(Elf_Shdr *sechdrs, const char *strtab,
> unsigned int symndx, Elf_Shdr *relasec,
> const char *sec_objname)
> {
> @@ -218,7 +218,7 @@ static int klp_resolve_symbols(Elf64_Shdr *sechdrs, const char *strtab,
> relas = (Elf_Rela *) relasec->sh_addr;
> /* For each rela in this klp relocation section */
> for (i = 0; i < relasec->sh_size / sizeof(Elf_Rela); i++) {
> - sym = (Elf64_Sym *)sechdrs[symndx].sh_addr + ELF_R_SYM(relas[i].r_info);
> + sym = (Elf_Sym *)sechdrs[symndx].sh_addr + ELF_R_SYM(relas[i].r_info);
> if (sym->st_shndx != SHN_LIVEPATCH) {
> pr_err("symbol %s is not marked as a livepatch symbol\n",
> strtab + sym->st_name);
> --
> 2.33.1
>
Thanks for finding and fixing, lgtm.
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
-- Joe
^ permalink raw reply
* Re: [PATCH v2 03/13] powerpc/module_32: Fix livepatching for RO modules
From: Joe Lawrence @ 2022-01-04 19:44 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Jiri Kosina, linux-kernel@vger.kernel.org,
Steven Rostedt, Ingo Molnar, Josh Poimboeuf,
live-patching@vger.kernel.org, Naveen N . Rao, Miroslav Benes,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <d5697157cb7dba3927e19aa17c915a83bc550bb2.1640017960.git.christophe.leroy@csgroup.eu>
On Mon, Dec 20, 2021 at 04:38:09PM +0000, Christophe Leroy wrote:
> Livepatching a loaded module involves applying relocations through
> apply_relocate_add(), which attempts to write to read-only memory when
> CONFIG_STRICT_MODULE_RWX=y.
>
> R_PPC_ADDR16_LO, R_PPC_ADDR16_HI, R_PPC_ADDR16_HA and R_PPC_REL24 are
> the types generated by the kpatch-build userspace tool or klp-convert
> kernel tree observed applying a relocation to a post-init module.
>
> Use patch_instruction() to patch those relocations.
>
> Commit 8734b41b3efe ("powerpc/module_64: Fix livepatching for
> RO modules") did similar change in module_64.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Russell Currey <ruscur@russell.cc>
> ---
> arch/powerpc/kernel/module_32.c | 44 ++++++++++++++++++++++-----------
> 1 file changed, 30 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
> index a491ad481d85..a0432ef46967 100644
> --- a/arch/powerpc/kernel/module_32.c
> +++ b/arch/powerpc/kernel/module_32.c
> @@ -18,6 +18,7 @@
> #include <linux/bug.h>
> #include <linux/sort.h>
> #include <asm/setup.h>
> +#include <asm/code-patching.h>
>
> /* Count how many different relocations (different symbol, different
> addend) */
> @@ -174,15 +175,25 @@ static uint32_t do_plt_call(void *location,
> entry++;
> }
>
> - entry->jump[0] = PPC_RAW_LIS(_R12, PPC_HA(val));
> - entry->jump[1] = PPC_RAW_ADDI(_R12, _R12, PPC_LO(val));
> - entry->jump[2] = PPC_RAW_MTCTR(_R12);
> - entry->jump[3] = PPC_RAW_BCTR();
> + if (patch_instruction(&entry->jump[0], ppc_inst(PPC_RAW_LIS(_R12, PPC_HA(val)))))
> + return 0;
> + if (patch_instruction(&entry->jump[1], ppc_inst(PPC_RAW_ADDI(_R12, _R12, PPC_LO(val)))))
> + return 0;
> + if (patch_instruction(&entry->jump[2], ppc_inst(PPC_RAW_MTCTR(_R12))))
> + return 0;
> + if (patch_instruction(&entry->jump[3], ppc_inst(PPC_RAW_BCTR())))
> + return 0;
>
> pr_debug("Initialized plt for 0x%x at %p\n", val, entry);
> return (uint32_t)entry;
> }
>
> +static int patch_location_16(uint32_t *loc, u16 value)
> +{
> + loc = PTR_ALIGN_DOWN(loc, sizeof(u32));
> + return patch_instruction(loc, ppc_inst((*loc & 0xffff0000) | value));
> +}
> +
> int apply_relocate_add(Elf32_Shdr *sechdrs,
> const char *strtab,
> unsigned int symindex,
> @@ -216,37 +227,42 @@ int apply_relocate_add(Elf32_Shdr *sechdrs,
>
> case R_PPC_ADDR16_LO:
> /* Low half of the symbol */
> - *(uint16_t *)location = value;
> + if (patch_location_16(location, PPC_LO(value)))
> + return -EFAULT;
> break;
>
> case R_PPC_ADDR16_HI:
> /* Higher half of the symbol */
> - *(uint16_t *)location = (value >> 16);
> + if (patch_location_16(location, PPC_HI(value)))
> + return -EFAULT;
> break;
>
> case R_PPC_ADDR16_HA:
> - /* Sign-adjusted lower 16 bits: PPC ELF ABI says:
> - (((x >> 16) + ((x & 0x8000) ? 1 : 0))) & 0xFFFF.
> - This is the same, only sane.
> - */
> - *(uint16_t *)location = (value + 0x8000) >> 16;
> + if (patch_location_16(location, PPC_HA(value)))
> + return -EFAULT;
> break;
>
> case R_PPC_REL24:
> if ((int)(value - (uint32_t)location) < -0x02000000
> - || (int)(value - (uint32_t)location) >= 0x02000000)
> + || (int)(value - (uint32_t)location) >= 0x02000000) {
> value = do_plt_call(location, value,
> sechdrs, module);
> + if (!value)
> + return -EFAULT;
> + }
>
> /* Only replace bits 2 through 26 */
> pr_debug("REL24 value = %08X. location = %08X\n",
> value, (uint32_t)location);
> pr_debug("Location before: %08X.\n",
> *(uint32_t *)location);
> - *(uint32_t *)location
> - = (*(uint32_t *)location & ~0x03fffffc)
> + value = (*(uint32_t *)location & ~0x03fffffc)
> | ((value - (uint32_t)location)
> & 0x03fffffc);
> +
> + if (patch_instruction(location, ppc_inst(value)))
> + return -EFAULT;
> +
> pr_debug("Location after: %08X.\n",
> *(uint32_t *)location);
> pr_debug("ie. jump to %08X+%08X = %08X\n",
> --
> 2.33.1
>
IIRC, offlist we hacked up klp-convert to create the klp-relocations for
a 32-bit target and then you hit the selftest late relocation crash, so
I assume that part is happy after this fix. :) Thanks again for the
testing.
For the livepatching implications,
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
-- Joe
^ permalink raw reply
* Re: [PATCH] powerpc/cacheinfo: use default_groups in kobj_type
From: Tyrel Datwyler @ 2022-01-04 19:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Parth Shah, Paul Mackerras, linuxppc-dev, Gautham R. Shenoy
In-Reply-To: <20220104155450.1291277-1-gregkh@linuxfoundation.org>
On 1/4/22 7:54 AM, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the powerpc cacheinfo sysfs code to use default_groups
> field which has been the preferred way since aa30f47cf666 ("kobject: Add
> support for default attribute groups to kobj_type") so that we can soon
> get rid of the obsolete default_attrs field.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> Cc: Parth Shah <parth@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
^ permalink raw reply
* [PATCH] ASoC: fsl_mqs: fix MODULE_ALIAS
From: Alyssa Ross @ 2022-01-04 13:22 UTC (permalink / raw)
To: Nicolin Chen, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai
Cc: Alyssa Ross, open list:FREESCALE SOC SOUND DRIVERS,
moderated list:FREESCALE SOC SOUND DRIVERS, open list
modprobe can't handle spaces in aliases.
Fixes: 9e28f6532c61 ("ASoC: fsl_mqs: Add MQS component driver")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
---
sound/soc/fsl/fsl_mqs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_mqs.c b/sound/soc/fsl/fsl_mqs.c
index 27b4536dce44..ceaecbe3a25e 100644
--- a/sound/soc/fsl/fsl_mqs.c
+++ b/sound/soc/fsl/fsl_mqs.c
@@ -337,4 +337,4 @@ module_platform_driver(fsl_mqs_driver);
MODULE_AUTHOR("Shengjiu Wang <Shengjiu.Wang@nxp.com>");
MODULE_DESCRIPTION("MQS codec driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform: fsl-mqs");
+MODULE_ALIAS("platform:fsl-mqs");
base-commit: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
--
2.33.0
^ permalink raw reply related
* Re: [PATCH] fs: btrfs: Disable BTRFS on platforms having 256K pages
From: Qu Wenruo @ 2022-01-04 23:32 UTC (permalink / raw)
To: Christophe Leroy, Chris Mason, Josef Bacik, David Sterba
Cc: linux-hexagon, linuxppc-dev, linux-kernel, linux-btrfs
In-Reply-To: <a16c31f3caf448dda5d9315e056585b6fafc22c5.1623302442.git.christophe.leroy@csgroup.eu>
Hi Christophe,
I'm recently enhancing the subpage support for btrfs, and my current
branch should solve the problem for btrfs to support larger page sizes.
But unfortunately my current test environment can only provide page size
with 64K or 4K, no 16K or 128K/256K support.
Mind to test my new branch on 128K page size systems?
(256K page size support is still lacking though, which will be addressed
in the future)
https://github.com/adam900710/linux/tree/metadata_subpage_switch
Thanks,
Qu
On 2021/6/10 13:23, Christophe Leroy wrote:
> With a config having PAGE_SIZE set to 256K, BTRFS build fails
> with the following message
>
> include/linux/compiler_types.h:326:38: error: call to '__compiletime_assert_791' declared with attribute error: BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0
>
> BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with
> 256K pages at the time being.
>
> There are two platforms that can select 256K pages:
> - hexagon
> - powerpc
>
> Disable BTRFS when 256K page size is selected.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> fs/btrfs/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 68b95ad82126..520a0f6a7d9e 100644
> --- a/fs/btrfs/Kconfig
> +++ b/fs/btrfs/Kconfig
> @@ -18,6 +18,8 @@ config BTRFS_FS
> select RAID6_PQ
> select XOR_BLOCKS
> select SRCU
> + depends on !PPC_256K_PAGES # powerpc
> + depends on !PAGE_SIZE_256KB # hexagon
>
> help
> Btrfs is a general purpose copy-on-write filesystem with extents,
^ permalink raw reply
* [5.16.0-rc5][ppc][net] kernel oops when hotplug remove of vNIC interface
From: Abdul Haleem @ 2022-01-05 8:26 UTC (permalink / raw)
To: linux-kernel
Cc: dumazet, netdev, alexandr.lobakin, brian King,
kuba@kernel.org >> Jakub Kicinski, linuxppc-dev
Greeting's
Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
Powerpc LPAR
Perform below dlpar commands in a loop from linux OS
drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
drmgr -a -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
after 7th iteration, the kernel panics with below messages
console messages:
[102056] ibmvnic 30000003 env3: Sending CRQ: 801e000864000000
0060000000000000
<intr> ibmvnic 30000003 env3: Handling CRQ: 809e000800000000
0000000000000000
[102056] ibmvnic 30000003 env3: Disabling tx_scrq[0] irq
[102056] ibmvnic 30000003 env3: Disabling tx_scrq[1] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[0] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[1] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[2] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[3] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[4] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[5] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: bridge stp llc ib_core rpadlpar_io rpaphp nfnetlink
tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag
bonding rfkill ibmvnic sunrpc pseries_rng xts vmx_crypto gf128mul
sch_fq_codel binfmt_misc ip_tables ext4 mbcache jbd2 dm_service_time
sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth dm_multipath dm_mirror
dm_region_hash dm_log dm_mod fuse
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted
5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted
(5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
GPR04: c000000c7d1a7e00 fffffffffffffff6 0000000000000027 c000000c7d1a7e08
GPR08: 0000000000000023 0000000000000000 0000000000000010 c0080000029bdd10
GPR12: c000000000a3c820 c000000c7fca6680 0000000000000000 c000000133016bf8
GPR16: 00000000000003fe 0000000000001000 0000000000000002 0000000000000008
GPR20: c000000133016eb0 0000000000000000 0000000000000000 0000000000000003
GPR24: c000000133016000 c000000133017168 0000000020000000 c000000133016a00
GPR28: 0000000000000006 c000000133016a00 0000000000000001 c000000133016000
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---
radix-mmu: Page sizes from device-tree:
the fault instruction points to
[root@ltcden11-lp1 boot]# gdb -batch
vmlinuz-5.16.0-rc5-autotest-g6441998e2e37 -ex 'list *(0xc000000000a3c840)'
0xc000000000a3c840 is in napi_enable (net/core/dev.c:6966).
6961 void napi_enable(struct napi_struct *n)
6962 {
6963 unsigned long val, new;
6964
6965 do {
6966 val = READ_ONCE(n->state);
6967 BUG_ON(!test_bit(NAPI_STATE_SCHED, &val));
6968
6969 new = val & ~(NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC);
6970 if (n->dev->threaded && n->thread)
--
Regard's
Abdul Haleem
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
From: S.J. Wang @ 2022-01-05 9:02 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, linuxppc-dev@lists.ozlabs.org,
tiwai@suse.com, perex@perex.cz, nicoleotsuka@gmail.com,
festevam@gmail.com, linux-kernel@vger.kernel.org
Hi
>
> > /* sai may support mclk/bclk = 1 */
> > - if (of_find_property(np, "fsl,mclk-equal-bclk", NULL))
> > + if (of_find_property(np, "fsl,mclk-equal-bclk", NULL))
> {
> > link_data->one2one_ratio = true;
> > + } else {
> > + int i;
> > +
> > + /*
> > + * i.MX8MQ don't support one2one ratio,
> then
> > + * with ak4497 only 16bit case is supported.
> > + */
> > + for (i = 0; i < ARRAY_SIZE(ak4497_fs_mul); i++)
> {
>
> Shouldn't this be keyed off checking that we are actually running with an
> ak4497?
No need. Here just update the ak4497_fs_mul table, before it is used the
codec type is checked.
Best regards
Wang Shengjiu
^ permalink raw reply
* [PATCH] ASoC: fsl_asrc: refine the check of available clock divider
From: Shengjiu Wang @ 2022-01-05 11:08 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, alsa-devel,
lgirdwood, perex, tiwai
Cc: linuxppc-dev, linux-kernel
According to RM, the clock divider range is from 1 to 8, clock
prescaling ratio may be any power of 2 from 1 to 128.
So the supported divider is not all the value between
1 and 1024, just limited value in that range.
Create table for the supported divder and add function to
check the clock divider is available by comparing with
the table.
Fixes: d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio mode")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc.c | 69 +++++++++++++++++++++++++++++++++-------
1 file changed, 58 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 24b41881a68f..d7d1536a4f37 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -19,6 +19,7 @@
#include "fsl_asrc.h"
#define IDEAL_RATIO_DECIMAL_DEPTH 26
+#define DIVIDER_NUM 64
#define pair_err(fmt, ...) \
dev_err(&asrc->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__)
@@ -101,6 +102,55 @@ static unsigned char clk_map_imx8qxp[2][ASRC_CLK_MAP_LEN] = {
},
};
+/*
+ * According to RM, the divider range is 1 ~ 8,
+ * prescaler is power of 2 from 1 ~ 128.
+ */
+static int asrc_clk_divider[DIVIDER_NUM] = {
+ 1, 2, 4, 8, 16, 32, 64, 128, /* divider = 1 */
+ 2, 4, 8, 16, 32, 64, 128, 256, /* divider = 2 */
+ 3, 6, 12, 24, 48, 96, 192, 384, /* divider = 3 */
+ 4, 8, 16, 32, 64, 128, 256, 512, /* divider = 4 */
+ 5, 10, 20, 40, 80, 160, 320, 640, /* divider = 5 */
+ 6, 12, 24, 48, 96, 192, 384, 768, /* divider = 6 */
+ 7, 14, 28, 56, 112, 224, 448, 896, /* divider = 7 */
+ 8, 16, 32, 64, 128, 256, 512, 1024, /* divider = 8 */
+};
+
+/*
+ * Check if the divider is available for internal ratio mode
+ */
+static bool fsl_asrc_divider_avail(int clk_rate, int rate, int *div)
+{
+ u32 rem, i;
+ u64 n;
+
+ if (div)
+ *div = 0;
+
+ if (clk_rate == 0 || rate == 0)
+ return false;
+
+ n = clk_rate;
+ rem = do_div(n, rate);
+
+ if (div)
+ *div = n;
+
+ if (rem != 0)
+ return false;
+
+ for (i = 0; i < DIVIDER_NUM; i++) {
+ if (n == asrc_clk_divider[i])
+ break;
+ }
+
+ if (i == DIVIDER_NUM)
+ return false;
+
+ return true;
+}
+
/**
* fsl_asrc_sel_proc - Select the pre-processing and post-processing options
* @inrate: input sample rate
@@ -330,12 +380,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
enum asrc_word_width input_word_width;
enum asrc_word_width output_word_width;
u32 inrate, outrate, indiv, outdiv;
- u32 clk_index[2], div[2], rem[2];
+ u32 clk_index[2], div[2];
u64 clk_rate;
int in, out, channels;
int pre_proc, post_proc;
struct clk *clk;
- bool ideal;
+ bool ideal, div_avail;
if (!config) {
pair_err("invalid pair config\n");
@@ -415,8 +465,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
clk = asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]];
clk_rate = clk_get_rate(clk);
- rem[IN] = do_div(clk_rate, inrate);
- div[IN] = (u32)clk_rate;
+ div_avail = fsl_asrc_divider_avail(clk_rate, inrate, &div[IN]);
/*
* The divider range is [1, 1024], defined by the hardware. For non-
@@ -425,7 +474,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
* only result in different converting speeds. So remainder does not
* matter, as long as we keep the divider within its valid range.
*/
- if (div[IN] == 0 || (!ideal && (div[IN] > 1024 || rem[IN] != 0))) {
+ if (div[IN] == 0 || (!ideal && !div_avail)) {
pair_err("failed to support input sample rate %dHz by asrck_%x\n",
inrate, clk_index[ideal ? OUT : IN]);
return -EINVAL;
@@ -436,13 +485,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
clk = asrc_priv->asrck_clk[clk_index[OUT]];
clk_rate = clk_get_rate(clk);
if (ideal && use_ideal_rate)
- rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE);
+ div_avail = fsl_asrc_divider_avail(clk_rate, IDEAL_RATIO_RATE, &div[OUT]);
else
- rem[OUT] = do_div(clk_rate, outrate);
- div[OUT] = clk_rate;
+ div_avail = fsl_asrc_divider_avail(clk_rate, outrate, &div[OUT]);
/* Output divider has the same limitation as the input one */
- if (div[OUT] == 0 || (!ideal && (div[OUT] > 1024 || rem[OUT] != 0))) {
+ if (div[OUT] == 0 || (!ideal && !div_avail)) {
pair_err("failed to support output sample rate %dHz by asrck_%x\n",
outrate, clk_index[OUT]);
return -EINVAL;
@@ -621,8 +669,7 @@ static void fsl_asrc_select_clk(struct fsl_asrc_priv *asrc_priv,
clk_index = asrc_priv->clk_map[j][i];
clk_rate = clk_get_rate(asrc_priv->asrck_clk[clk_index]);
/* Only match a perfect clock source with no remainder */
- if (clk_rate != 0 && (clk_rate / rate[j]) <= 1024 &&
- (clk_rate % rate[j]) == 0)
+ if (fsl_asrc_divider_avail(clk_rate, rate[j], NULL))
break;
}
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox