* Re: [PATCH v2] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Steven Price @ 2023-04-19 10:17 UTC (permalink / raw)
To: Dan Carpenter, Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Eric Auger, linux-arm-kernel,
kvmarm, kernel-janitors
In-Reply-To: <4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain>
On 19/04/2023 11:16, Dan Carpenter wrote:
> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> between 0-32768 but if it is more than sizeof(long) this will corrupt
> memory.
>
> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Steven Price <steven.price@arm.com>
Thanks,
Steve
> ---
> v2: The original patch was okay but checking for != sizeof(val) is
> stricter and more Obviously Correct[tm]. Return -ENOENT instead of
> -EINVAL in case future ioctls are added which take a different size.
>
> arch/arm64/kvm/hypercalls.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 2e16fc7b31bf..7fb4df0456de 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -544,6 +544,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> u64 val;
> int wa_level;
>
> + if (KVM_REG_SIZE(reg->id) != sizeof(val))
> + return -ENOENT;
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Dan Carpenter @ 2023-04-19 10:16 UTC (permalink / raw)
To: Steven Price
Cc: Andre Przywara, Oliver Upton, James Morse, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Eric Auger,
linux-arm-kernel, kvmarm, kernel-janitors
In-Reply-To: <e85395c3-e0f8-f1a0-3115-c1f26f4aca99@arm.com>
On Wed, Apr 19, 2023 at 11:00:37AM +0100, Steven Price wrote:
> On 19/04/2023 10:48, Dan Carpenter wrote:
> > On Wed, Apr 19, 2023 at 09:48:41AM +0100, Steven Price wrote:
> >> On 19/04/2023 09:06, Dan Carpenter wrote:
> >>> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> >>> between 0-32768 but if it is more than sizeof(long) this will corrupt
> >>> memory.
> >>>
> >>> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> >>> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> >>
> >> Reviewed-by: Steven Price <steven.price@arm.com>
> >>
> >> Although there might be something to be said for rejecting anything
> >> where KVM_REG_SIZE(reg->id) != sizeof(u64), as for smaller sizes the top
> >> bits of val would be undefined which would require the code to mask the
> >> top bits out to be safe. Given that all registers are currently u64 (and
> >> I don't expect that to change), perhaps the below would be clearer?
> >>
> >> if (KVM_REG_SIZE(reg->id) != sizeof(val))
> >> return -EINVAL;
> >> if (copy_from_user(&val, uaddr, sizeof(val)))
> >> return -EFAULT;
> >
> > I was thinking that zero might be a valid size?
>
> Well any value of reg->id which doesn't match in the switch statement
> will cause a -ENOENT return currently, so a zero size would fail that
> way as it stands. So I don't think any size other than u64 is valid in
> the current code.
>
> There is obviously a question of return value - perhaps returning
> -ENOENT would be more appropriate if the size doesn't match (as a later
> kernel could decide to implement registers of different sizes)?
Okay. I've sent a v2. Probably either -EINVAL or -ENOENT is fine, but
-ENOENT is more helpful so let's return that.
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Dan Carpenter @ 2023-04-19 10:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Eric Auger, Steven Price,
linux-arm-kernel, kvmarm, kernel-janitors
The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
between 0-32768 but if it is more than sizeof(long) this will corrupt
memory.
Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
v2: The original patch was okay but checking for != sizeof(val) is
stricter and more Obviously Correct[tm]. Return -ENOENT instead of
-EINVAL in case future ioctls are added which take a different size.
arch/arm64/kvm/hypercalls.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 2e16fc7b31bf..7fb4df0456de 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -544,6 +544,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
u64 val;
int wa_level;
+ if (KVM_REG_SIZE(reg->id) != sizeof(val))
+ return -ENOENT;
if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
return -EFAULT;
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC v2 PATCH 00/17] variable-order, large folios for anonymous memory
From: Ryan Roberts @ 2023-04-19 10:12 UTC (permalink / raw)
To: David Hildenbrand, Andrew Morton, Matthew Wilcox (Oracle),
Yu Zhao, Yin, Fengwei
Cc: linux-mm, linux-arm-kernel
In-Reply-To: <568b5b73-f0e9-c385-f628-93e45825fb7b@redhat.com>
Hi David,
On 17/04/2023 15:05, David Hildenbrand wrote:
> [...]
>
>>> Just a note (that you maybe already know) that we have to be a bit careful in
>>> the wp_copy path with replacing sub-pages that are marked exclusive.
>>
>> Ahh, no I wasn't aware of this - thanks for taking the time to explain it. I
>> think I have a bug.
>>
>> (I'm guessing the GUP fast path assumes that if it sees an exclusive page then
>> that page can't go away? And if I then wp_copy it, I'm breaking the assumption?
>> But surely user space can munmap it at any time and the consequences are
>> similar? It's probably clear that I don't know much about the GUP implementation
>> details...)
>
> If GUP finds a read-only PTE pointing at an exclusive subpage, it assumes that
> this page cannot randomly be replaced by core MM due to COW. See
> gup_must_unshare(). So it can go ahead and pin the page. As long as user space
> doesn't do something stupid with the mapping (MADV_DONTNEED, munmap()) the
> pinned page must correspond to the mapped page.
>
> If GUP finds a writeable PTE, it assumes that this page cannot randomly be
> replaced by core MM due to COW -- because writable implies exclusive. See, for
> example the VM_BUG_ON_PAGE() in follow_page_pte(). So, similarly, GUP can simply
> go ahead and pin the page.
>
> GUP-fast runs lockless, not even taking the PT locks. It syncs against
> concurrent fork() using a special seqlock, and essentially unpins whatever it
> temporarily pinned when it detects that fork() was running concurrently. But it
> might result in some pages temporarily being flagged as "maybe pinned".
>
> In other cases (!fork()), GUP-fast synchronizes against concurrent sharing (KSM)
> or unmapping (migration, swapout) that implies clearing of the PG_anon_flag of
> the subpage by first unmapping the PTE and conditionally remapping it. See
> mm/ksm.c:write_protect_page() as an example for the sharing side (especially: if
> page_try_share_anon_rmap() fails because the page may be pinned).
>
> Long story short: replacing a r-o "maybe shared" (!exclusive) PTE is easy.
> Replacing an exclusive PTE (including writable PTEs) requires some work to sync
> with GUP-fast and goes rather in the "maybe just don't bother" terriroty.
I'm looking to fix this problem in my code, but am struggling to see how the
current code is safe. I'm thinking about the following scenario:
- A page is CoW mapped into processes A and B.
- The page takes a fault in process A, and do_wp_page() determines that it is
"maybe-shared" and therefore must copy. So drops the PTL and calls
wp_page_copy().
- Process B exits.
- Another thread in process A faults on the page. This time dw_wp_page()
determines that the page is exclusive (due to the ref count), and reuses it,
marking it exclusive along the way.
- wp_page_copy() from the original thread in process A retakes the PTL and
copies the _now exclusive_ page.
Having typed it up, I guess this can't happen, because wp_page_copy() will only
do the copy if the PTE hasn't changed and it will have changed because it is now
writable? So this is safe?
To make things more convoluted, what happens if the second thread does an
mprotect() to make the page RO after its write fault was handled? I think
mprotect() will serialize on the mmap write lock so this is safe too?
Sorry if this is a bit rambly, just trying to make sure I've understood
everything correctly.
Thanks,
Ryan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: dts: ti: k3-j784s4: Add Main CPSW2G node
From: Jayesh Choudhary @ 2023-04-19 10:02 UTC (permalink / raw)
To: Krzysztof Kozlowski, nm, vigneshr, afd
Cc: s-vadapalli, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, a-bhatia1
In-Reply-To: <e83733cf-b396-1ec7-4247-49d0f94e8517@linaro.org>
On 19/04/23 13:20, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:17, Jayesh Choudhary wrote:
>> From: Siddharth Vadapalli <s-vadapalli@ti.com>
>>
>> J784S4 SoC has a Main CPSW2G instance of the CPSW Ethernet Switch.
>>
>> Add the device-tree nodes for the Main CPSW2G instance and enable it.
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 48 +++++++++++++++
>> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 68 ++++++++++++++++++++++
>> 2 files changed, 116 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> index f33815953e77..aef6f53ae8ac 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> @@ -105,6 +105,30 @@ vdd_sd_dv: regulator-TLV71033 {
>> };
>>
>> &main_pmx0 {
>> + main_cpsw2g_pins_default: main-cpsw2g-pins-default {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x0b8, PIN_INPUT, 6) /* (AC34) MCASP1_ACLKX.RGMII1_RD0 */
>> + J784S4_IOPAD(0x0a0, PIN_INPUT, 6) /* (AD34) MCASP0_AXR12.RGMII1_RD1 */
>> + J784S4_IOPAD(0x0a4, PIN_INPUT, 6) /* (AJ36) MCASP0_AXR13.RGMII1_RD2 */
>> + J784S4_IOPAD(0x0a8, PIN_INPUT, 6) /* (AF34) MCASP0_AXR14.RGMII1_RD3 */
>> + J784S4_IOPAD(0x0b0, PIN_INPUT, 6) /* (AL33) MCASP1_AXR3.RGMII1_RXC */
>> + J784S4_IOPAD(0x0ac, PIN_INPUT, 6) /* (AE34) MCASP0_AXR15.RGMII1_RX_CTL */
>> + J784S4_IOPAD(0x08c, PIN_INPUT, 6) /* (AE35) MCASP0_AXR7.RGMII1_TD0 */
>> + J784S4_IOPAD(0x090, PIN_INPUT, 6) /* (AC35) MCASP0_AXR8.RGMII1_TD1 */
>> + J784S4_IOPAD(0x094, PIN_INPUT, 6) /* (AG35) MCASP0_AXR9.RGMII1_TD2 */
>> + J784S4_IOPAD(0x098, PIN_INPUT, 6) /* (AH36) MCASP0_AXR10.RGMII1_TD3 */
>> + J784S4_IOPAD(0x0b4, PIN_INPUT, 6) /* (AL34) MCASP1_AXR4.RGMII1_TXC */
>> + J784S4_IOPAD(0x09c, PIN_INPUT, 6) /* (AF35) MCASP0_AXR11.RGMII1_TX_CTL */
>> + >;
>> + };
>> +
>> + main_cpsw2g_mdio_pins_default: main-cpsw2g-mdio-pins-default {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x0c0, PIN_INPUT, 6) /* (AD38) MCASP1_AXR0.MDIO0_MDC */
>> + J784S4_IOPAD(0x0bc, PIN_INPUT, 6) /* (AD33) MCASP1_AFSX.MDIO0_MDIO */
>> + >;
>> + };
>> +
>> main_uart8_pins_default: main-uart8-pins-default {
>> pinctrl-single,pins = <
>> J784S4_IOPAD(0x040, PIN_INPUT, 14) /* (AF37) MCASP0_AXR0.UART8_CTSn */
>> @@ -253,3 +277,27 @@ &mcu_cpsw_port1 {
>> phy-mode = "rgmii-rxid";
>> phy-handle = <&mcu_phy0>;
>> };
>> +
>> +&main_cpsw1 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_cpsw2g_pins_default>;
>> +};
>> +
>> +&main_cpsw1_mdio {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_cpsw2g_mdio_pins_default>;
>> +
>> + main_phy0: ethernet-phy@0 {
>> + reg = <0>;
>> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>> + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>> + ti,min-output-impedance;
>> + };
>> +};
>> +
>> +&main_cpsw1_port1 {
>> + status = "okay";
>> + phy-mode = "rgmii-rxid";
>> + phy-handle = <&main_phy0>;
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> index 5fb7edf4f5a0..8bd8aebebe1c 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -36,6 +36,12 @@ scm_conf: syscon@100000 {
>> #size-cells = <1>;
>> ranges = <0x00 0x00 0x00100000 0x1c000>;
>>
>> + cpsw1_phy_gmii_sel: phy@4034 {
>> + compatible = "ti,am654-phy-gmii-sel";
>> + reg = <0x4034 0x4>;
>> + #phy-cells = <1>;
>> + };
>> +
>> serdes_ln_ctrl: mux-controller-4080 {
>> compatible = "mmio-mux";
>> #mux-control-cells = <1>;
>> @@ -777,6 +783,68 @@ cpts@310d0000 {
>> };
>> };
>>
>> + main_cpsw1: ethernet@c200000 {
>> + compatible = "ti,j721e-cpsw-nuss";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>
> Fix order of your properties. reg/reg-names/ranges follow comaptible.
Noted. Will fix.
>
>> + reg = <0x00 0xc200000 0x00 0x200000>;
>> + reg-names = "cpsw_nuss";
>> + ranges = <0x00 0x00 0x00 0xc200000 0x00 0x200000>;
>> + dma-coherent;
>> + clocks = <&k3_clks 62 0>;
>> + clock-names = "fck";
>> + power-domains = <&k3_pds 62 TI_SCI_PD_EXCLUSIVE>;
>> +
>> + dmas = <&main_udmap 0xc640>,
>> + <&main_udmap 0xc641>,
>> + <&main_udmap 0xc642>,
>> + <&main_udmap 0xc643>,
>> + <&main_udmap 0xc644>,
>> + <&main_udmap 0xc645>,
>> + <&main_udmap 0xc646>,
>> + <&main_udmap 0xc647>,
>> + <&main_udmap 0x4640>;
>> + dma-names = "tx0", "tx1", "tx2", "tx3",
>> + "tx4", "tx5", "tx6", "tx7",
>> + "rx";
>> +
>> + status = "disabled";
>> +
>> + ethernet-ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + main_cpsw1_port1: port@1 {
>> + reg = <1>;
>> + label = "port1";
>> + phys = <&cpsw1_phy_gmii_sel 1>;
>> + ti,mac-only;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + main_cpsw1_mdio: mdio@f00 {
>> + compatible = "ti,cpsw-mdio", "ti,davinci_mdio";
>> + reg = <0x00 0xf00 0x00 0x100>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = <&k3_clks 62 0>;
>> + clock-names = "fck";
>> + bus_freq = <1000000>;
>> + };
>> +
>> + cpts@3d000 {
>
> Are you sure dtbs_check does not print any warnings?
>
One more warning for clock order in serdes_wiz nodes. Will be fixed
after I swap 'ext_ref_clk' and 'core_ref1_clk' in clock and names.
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: kernel: smp: ignore disabled cpu node
From: Sudeep Holla @ 2023-04-19 10:02 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: catalin.marinas, will, peterz, jpoimboe, rafael.j.wysocki,
vschneid, ben-linux, Pierre.Gondois, linux-arm-kernel,
linux-kernel, Peng Fan
In-Reply-To: <20230419094039.3140521-1-peng.fan@oss.nxp.com>
On Wed, Apr 19, 2023 at 05:40:39PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> If the cpu node is set disabled in device tree, we should ignore the
> node. i.MX8MP has some variants, which have one or two or four A53 cores.
> The current imx8mp device tree use the full feature SoC. With such
> device tree to bring the variant with one or two A53 cores will cause
> issue.
>
> The firmware will update the status property, and kernel will check the
> property before bring up the core.
>
IIRC it has been discussed in the past[1][2], has anything changed now ?
--
Regards,
Sudeep
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174324.html
[2] https://yhbt.net/lore/all/1524697712-20208-1-git-send-email-rokhanna@nvidia.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Steven Price @ 2023-04-19 10:00 UTC (permalink / raw)
To: Dan Carpenter
Cc: Andre Przywara, Oliver Upton, James Morse, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Eric Auger,
linux-arm-kernel, kvmarm, kernel-janitors
In-Reply-To: <46ace8c7-c3b1-4e2d-8af0-3f0ab1bd55f5@kili.mountain>
On 19/04/2023 10:48, Dan Carpenter wrote:
> On Wed, Apr 19, 2023 at 09:48:41AM +0100, Steven Price wrote:
>> On 19/04/2023 09:06, Dan Carpenter wrote:
>>> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
>>> between 0-32768 but if it is more than sizeof(long) this will corrupt
>>> memory.
>>>
>>> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
>>> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
>>
>> Reviewed-by: Steven Price <steven.price@arm.com>
>>
>> Although there might be something to be said for rejecting anything
>> where KVM_REG_SIZE(reg->id) != sizeof(u64), as for smaller sizes the top
>> bits of val would be undefined which would require the code to mask the
>> top bits out to be safe. Given that all registers are currently u64 (and
>> I don't expect that to change), perhaps the below would be clearer?
>>
>> if (KVM_REG_SIZE(reg->id) != sizeof(val))
>> return -EINVAL;
>> if (copy_from_user(&val, uaddr, sizeof(val)))
>> return -EFAULT;
>
> I was thinking that zero might be a valid size?
Well any value of reg->id which doesn't match in the switch statement
will cause a -ENOENT return currently, so a zero size would fail that
way as it stands. So I don't think any size other than u64 is valid in
the current code.
There is obviously a question of return value - perhaps returning
-ENOENT would be more appropriate if the size doesn't match (as a later
kernel could decide to implement registers of different sizes)?
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] firmware: arm_ffa: Fix FFA device names for logical partitions
From: Sudeep Holla @ 2023-04-19 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Lucian Paul-Trifu, Marc Bonnici, Jens Wiklander
In-Reply-To: <20230419-ffa_fixes_6-4-v1-0-1881ee6699f1@arm.com>
Each physical partition can provide multiple services each with UUID.
Each such service can be presented as logical partition with a unique
combination of VM ID and UUID. The number of distinct UUID in a system
will be less than or equal to the number of logical partitions.
However, currently it fails to register more than one logical partition
or service within a physical partition as the device name contains only
VM ID while both VM ID and UUID are maintained in the partition information.
The kernel complains with the below message:
| sysfs: cannot create duplicate filename '/devices/arm-ffa-8001'
| CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8
| Hardware name: FVP Base RevC (DT)
| Call trace:
| dump_backtrace+0xf8/0x118
| show_stack+0x18/0x24
| dump_stack_lvl+0x50/0x68
| dump_stack+0x18/0x24
| sysfs_create_dir_ns+0xe0/0x13c
| kobject_add_internal+0x220/0x3d4
| kobject_add+0x94/0x100
| device_add+0x144/0x5d8
| device_register+0x20/0x30
| ffa_device_register+0x88/0xd8
| ffa_setup_partitions+0x108/0x1b8
| ffa_init+0x2ec/0x3a4
| do_one_initcall+0xcc/0x240
| do_initcall_level+0x8c/0xac
| do_initcalls+0x54/0x94
| do_basic_setup+0x1c/0x28
| kernel_init_freeable+0x100/0x16c
| kernel_init+0x20/0x1a0
| ret_from_fork+0x10/0x20
| kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to
| register things with the same name in the same directory.
| arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17
| ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001
By virtue of being random enough to avoid collisions when generated in a
distributed system, there is no way to compress UUID keys to the number
of bits required to identify each. We can eliminate '-' in the name but
it is not worth eliminating 4 bytes and add unnecessary logic for doing
that. Also v1.0 doesn't provide the UUID of the partitions which makes
it hard to use the same for the device name.
So to keep it simple, let us just append the index to the list of the
partitions obtained in response to FFA_PARTITION_INFO_GET to "arm-ffa" to
make up a unique device name.
Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Reported-by: Lucian Paul-Trifu <lucian.paul-trifu@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 4aced2e5b772..39b912bbd7db 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -678,7 +678,7 @@ static void ffa_setup_partitions(void)
* provides UUID here for each partition as part of the
* discovery API and the same is passed.
*/
- ffa_dev = ffa_device_register(&uuid, tpbuf->id, &ffa_drv_ops);
+ ffa_dev = ffa_device_register(&uuid, idx, &ffa_drv_ops);
if (!ffa_dev) {
pr_err("%s: failed to register partition ID 0x%x\n",
__func__, tpbuf->id);
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] firmware: arm_ffa: Some fixes for v6.4
From: Sudeep Holla @ 2023-04-19 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Lucian Paul-Trifu, Marc Bonnici, Jens Wiklander
This series has assorted set of 3 fixes to the issues reported recently.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Sudeep Holla (3):
firmware: arm_ffa: Check if ffa_driver remove is present before executing
firmware: arm_ffa: Fix usage of partition info get count flag
firmware: arm_ffa: Fix FFA device names for logical partitions
drivers/firmware/arm_ffa/bus.c | 3 ++-
drivers/firmware/arm_ffa/driver.c | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
---
base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026
change-id: 20230419-ffa_fixes_6-4-cf2aadf75d05
Best regards,
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] firmware: arm_ffa: Check if ffa_driver remove is present before executing
From: Sudeep Holla @ 2023-04-19 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Lucian Paul-Trifu, Marc Bonnici, Jens Wiklander
In-Reply-To: <20230419-ffa_fixes_6-4-v1-0-1881ee6699f1@arm.com>
Currently ffa_drv->remove() is called unconditionally from
ffa_device_remove(). Since the driver registration doesn't check for it
and allows it to be registered without .remove callback, we need to check
for the presence of it before executing it from ffa_device_remove() to
above a NULL pointer dereference like the one below:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
| ESR = 0x0000000086000004
| EC = 0x21: IABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
| CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6
| Hardware name: FVP Base RevC (DT)
| pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c)
| pc : 0x0
| lr : ffa_device_remove+0x20/0x2c
| Call trace:
| 0x0
| device_release_driver_internal+0x16c/0x260
| driver_detach+0x90/0xd0
| bus_remove_driver+0xdc/0x11c
| driver_unregister+0x30/0x54
| ffa_driver_unregister+0x14/0x20
| cleanup_module+0x18/0xeec
| __arm64_sys_delete_module+0x234/0x378
| invoke_syscall+0x40/0x108
| el0_svc_common+0xb4/0xf0
| do_el0_svc+0x30/0xa4
| el0_svc+0x2c/0x7c
| el0t_64_sync_handler+0x84/0xf0
| el0t_64_sync+0x190/0x194
Fixes: 244f5d597e1e ("firmware: arm_ffa: Add missing remove callback to ffa_bus_type")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_ffa/bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/bus.c b/drivers/firmware/arm_ffa/bus.c
index f29d77ecf72d..36bd5423c2f0 100644
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -53,7 +53,8 @@ static void ffa_device_remove(struct device *dev)
{
struct ffa_driver *ffa_drv = to_ffa_driver(dev->driver);
- ffa_drv->remove(to_ffa_dev(dev));
+ if (ffa_drv->remove)
+ ffa_drv->remove(to_ffa_dev(dev));
}
static int ffa_device_uevent(const struct device *dev, struct kobj_uevent_env *env)
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] firmware: arm_ffa: Fix usage of partition info get count flag
From: Sudeep Holla @ 2023-04-19 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Lucian Paul-Trifu, Marc Bonnici, Jens Wiklander
In-Reply-To: <20230419-ffa_fixes_6-4-v1-0-1881ee6699f1@arm.com>
Commit bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
adds support to discovery the UUIDs of the partitions or just fetch the
partition count using the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag.
However the commit doesn't handle the fact that the older version doesn't
understand the flag and must be MBZ which results in firmware returning
invalid parameter error. That results in the failure of the driver probe
which is in correct.
Limit the usage of the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag for the
versions above v1.0(i.e v1.1 and onwards) which fixes the issue.
Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
Reported-by: Jens Wiklander <jens.wiklander@linaro.org>
Reported-by: Marc Bonnici <marc.bonnici@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_ffa/driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index fa85c64d3ded..4aced2e5b772 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -193,7 +193,8 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
int idx, count, flags = 0, sz, buf_sz;
ffa_value_t partition_info;
- if (!buffer || !num_partitions) /* Just get the count for now */
+ if (drv_info->version > FFA_VERSION_1_0 &&
+ (!buffer || !num_partitions)) /* Just get the count for now */
flags = PARTITION_INFO_GET_RETURN_COUNT_ONLY;
mutex_lock(&drv_info->rx_lock);
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: defconfig: Enable PRUSS as module
From: MD Danish Anwar @ 2023-04-19 9:50 UTC (permalink / raw)
To: rafal, Mark Brown, nfraprado, Thierry Reding, Krzysztof Kozlowski,
Geert Uytterhoeven, Arnd Bergmann, Bjorn Andersson, Will Deacon,
Catalin Marinas, nm
Cc: linux-kernel, linux-arm-kernel, linux-omap, vigneshr, danishanwar
Enables PRUSS as kernel module for TI SoCs.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index a24609e14d50..2a362a902526 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1277,6 +1277,7 @@ CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_ARCH_TEGRA_194_SOC=y
CONFIG_ARCH_TEGRA_234_SOC=y
CONFIG_TI_SCI_PM_DOMAINS=y
+CONFIG_TI_PRUSS=m
CONFIG_ARM_IMX_BUS_DEVFREQ=y
CONFIG_ARM_IMX8M_DDRC_DEVFREQ=m
CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: kernel: smp: ignore disabled cpu node
From: Peng Fan (OSS) @ 2023-04-19 9:40 UTC (permalink / raw)
To: catalin.marinas, will, peterz, jpoimboe, rafael.j.wysocki,
vschneid, ben-linux, Pierre.Gondois
Cc: linux-arm-kernel, linux-kernel, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
If the cpu node is set disabled in device tree, we should ignore the
node. i.MX8MP has some variants, which have one or two or four A53 cores.
The current imx8mp device tree use the full feature SoC. With such
device tree to bring the variant with one or two A53 cores will cause
issue.
The firmware will update the status property, and kernel will check the
property before bring up the core.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/kernel/smp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d00d4cbb31b1..aa1d678adf4a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -631,6 +631,9 @@ static void __init of_parse_and_init_cpus(void)
for_each_of_cpu_node(dn) {
u64 hwid = of_get_cpu_hwid(dn, 0);
+ if (!of_device_is_available(dn))
+ goto next;
+
if (hwid & ~MPIDR_HWID_BITMASK)
goto next;
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Dan Carpenter @ 2023-04-19 9:48 UTC (permalink / raw)
To: Steven Price
Cc: Andre Przywara, Oliver Upton, James Morse, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Eric Auger,
linux-arm-kernel, kvmarm, kernel-janitors
In-Reply-To: <d6e45332-0b91-2400-0549-068ea72a4482@arm.com>
On Wed, Apr 19, 2023 at 09:48:41AM +0100, Steven Price wrote:
> On 19/04/2023 09:06, Dan Carpenter wrote:
> > The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> > between 0-32768 but if it is more than sizeof(long) this will corrupt
> > memory.
> >
> > Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
>
> Reviewed-by: Steven Price <steven.price@arm.com>
>
> Although there might be something to be said for rejecting anything
> where KVM_REG_SIZE(reg->id) != sizeof(u64), as for smaller sizes the top
> bits of val would be undefined which would require the code to mask the
> top bits out to be safe. Given that all registers are currently u64 (and
> I don't expect that to change), perhaps the below would be clearer?
>
> if (KVM_REG_SIZE(reg->id) != sizeof(val))
> return -EINVAL;
> if (copy_from_user(&val, uaddr, sizeof(val)))
> return -EFAULT;
I was thinking that zero might be a valid size?
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] spi: s3c64xx: support interrupt based pio mode
From: Jaewon Kim @ 2023-04-19 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <88e74f8f-feee-159a-3048-736a5ffc13cd@linaro.org>
On 23. 4. 19. 17:21, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> Interrupt based pio mode is supported to reduce CPU load.
>> If transfer size is larger than 32 byte, it is processed using interrupt.
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 82 ++++++++++++++++++++++++++++++++-------
>> 1 file changed, 67 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index cf3060b2639b..ce1afb9a4ed4 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -58,6 +58,8 @@
>> #define S3C64XX_SPI_MODE_BUS_TSZ_HALFWORD (1<<17)
>> #define S3C64XX_SPI_MODE_BUS_TSZ_WORD (2<<17)
>> #define S3C64XX_SPI_MODE_BUS_TSZ_MASK (3<<17)
>> +#define S3C64XX_SPI_MODE_RX_RDY_LVL GENMASK(16, 11)
>> +#define S3C64XX_SPI_MODE_RX_RDY_LVL_SHIFT 11
>> #define S3C64XX_SPI_MODE_SELF_LOOPBACK (1<<3)
>> #define S3C64XX_SPI_MODE_RXDMA_ON (1<<2)
>> #define S3C64XX_SPI_MODE_TXDMA_ON (1<<1)
>> @@ -114,6 +116,8 @@
>>
>> #define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
>>
>> +#define S3C64XX_SPI_POLLING_SIZE 32
>> +
>> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
>> #define is_polling(x) (x->cntrlr_info->polling)
>>
>> @@ -552,10 +556,11 @@ static int s3c64xx_wait_for_dma(struct s3c64xx_spi_driver_data *sdd,
>> }
>>
>> static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>> - struct spi_transfer *xfer)
>> + struct spi_transfer *xfer, int use_irq)
>> {
>> void __iomem *regs = sdd->regs;
>> unsigned long val;
>> + unsigned long time;
>> u32 status;
>> int loops;
>> u32 cpy_len;
>> @@ -563,17 +568,24 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>> int ms;
>> u32 tx_time;
>>
>> - /* sleep during signal transfer time */
>> - status = readl(regs + S3C64XX_SPI_STATUS);
>> - if (RX_FIFO_LVL(status, sdd) < xfer->len) {
>> - tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
>> - usleep_range(tx_time / 2, tx_time);
>> - }
> You just added this code. Adding and immediately removing it, suggests
> this should be one patch.
>
This code has been moved, not removed.
+ if (use_irq) {
+ val = msecs_to_jiffies(ms);
+ time =
wait_for_completion_timeout(&sdd->xfer_completion, val);
+ if (!time)
+ return -EIO;
+ } else {
+ /* sleep during signal transfer time */
+ status = readl(regs + S3C64XX_SPI_STATUS);
+ if (RX_FIFO_LVL(status, sdd) < xfer->len) {
+ tx_time = (xfer->len * 8 * 1000 * 1000) /
sdd->cur_speed;
+ usleep_range(tx_time / 2, tx_time);
+ }
+ }
+
> Best regards,
> Krzysztof
>
>
Thanks
Jaewon Kim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/5] arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux
From: Jayesh Choudhary @ 2023-04-19 9:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, nm, vigneshr, afd
Cc: s-vadapalli, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, a-bhatia1
In-Reply-To: <eb2540e6-6768-aa38-ec3e-d0f9bb75d797@linaro.org>
Hi Krzysztof,
On 19/04/23 13:19, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:17, Jayesh Choudhary wrote:
>> From: Siddharth Vadapalli <s-vadapalli@ti.com>
>>
>> The system controller node manages the CTRL_MMR0 region.
>> Add serdes_ln_ctrl node which is used for controlling the SERDES lane mux.
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> [j-choudhary@ti.com: Minor cleanup to fix dtc warnings]
>> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> index e9169eb358c1..5fb7edf4f5a0 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -5,6 +5,9 @@
>> * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
>> */
>>
>> +#include <dt-bindings/mux/mux.h>
>> +#include <dt-bindings/mux/ti-serdes.h>
>> +
>> &cbass_main {
>> msmc_ram: sram@70000000 {
>> compatible = "mmio-sram";
>> @@ -26,6 +29,25 @@ l3cache-sram@200000 {
>> };
>> };
>>
>> + scm_conf: syscon@100000 {
>> + compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
>> + reg = <0x00 0x00100000 0x00 0x1c000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x00 0x00 0x00100000 0x1c000>;
>> +
>> + serdes_ln_ctrl: mux-controller-4080 {
>
> Does not look like you tested the DTS against bindings. Please run `make
> dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst
> for instructions).
>
Ohkay. The base seems to be from k3-j7200-main.dtsi which has the node
name as mux-controller@4080 without reg property. After comments in v2,
I used '-' instead of adding reg property to this node. Will change the
node name again and add the reg property to fix the warning that I see
now with dtbs_check.
Thanks!!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] spi: s3c64xx: add sleep during transfer
From: Jaewon Kim @ 2023-04-19 9:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <b91c6cfb-4fd2-1189-72fd-92b40d1b4743@linaro.org>
On 23. 4. 19. 17:19, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> In polling mode, the status register is constantly read to check transfer
>> completion. It cause excessive CPU usage.
>> So, it calculates the SPI transfer time and made it sleep.
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index 886722fb40ea..cf3060b2639b 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -561,6 +561,14 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>> u32 cpy_len;
>> u8 *buf;
>> int ms;
>> + u32 tx_time;
>> +
>> + /* sleep during signal transfer time */
>> + status = readl(regs + S3C64XX_SPI_STATUS);
>> + if (RX_FIFO_LVL(status, sdd) < xfer->len) {
>> + tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
>> + usleep_range(tx_time / 2, tx_time);
>> + }
> Did you actually check the delays introduced by it? Is it worth?
Yes, I already test it.
Throughput was the same, CPU utilization decreased to 30~40% from 100%.
Tested board is ExynosAutov9 SADK.
>
>>
>> /* millisecs to xfer 'len' bytes @ 'cur_speed' */
>> ms = xfer->len * 8 * 1000 / sdd->cur_speed;
> You have now some code duplication so this could be combined.
>
> Best regards,
> Krzysztof
>
>
Thanks
Jaewon Kim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [patch 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Thomas Gleixner @ 2023-04-19 9:38 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-kernel, x86, David Woodhouse, Andrew Cooper, Brian Gerst,
Arjan van de Veen, Paolo Bonzini, Paul McKenney, Tom Lendacky,
Sean Christopherson, Oleksandr Natalenko, Guilherme G. Piccoli,
Piotr Gorski, David Woodhouse, Usama Arif, Jürgen Groß,
Boris Ostrovsky, xen-devel, Russell King, Arnd Bergmann,
linux-arm-kernel, Catalin Marinas, Will Deacon, Guo Ren,
linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <8592a301-9933-1cad-bd61-8d97e7c7493b@molgen.mpg.de>
Paul!
On Tue, Apr 18 2023 at 22:10, Paul Menzel wrote:
> Am 18.04.23 um 10:40 schrieb Thomas Gleixner:
>> Can you please provide the output of cpuid?
>
> Of course. Here the top, and the whole output is attached.
Thanks for the data. Can you please apply the debug patch below and
provide the dmesg output? Just the line which is added by the patch is
enough. You can boot with cpuhp.parallel=off so you don't have wait for
10 seconds.
Thanks,
tglx
---
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -814,6 +814,7 @@ static int wakeup_secondary_cpu_via_init
unsigned long send_status = 0, accept_status = 0;
int maxlvt, num_starts, j;
+ pr_info("Kicking AP alive: %d\n", phys_apicid);
preempt_disable();
maxlvt = lapic_get_maxlvt();
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: ti: k3-j721e: Add ESM support
From: Neha Malcom Francis @ 2023-04-19 9:25 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel
Cc: n-francis, nm, vigneshr, u-kumar1
In-Reply-To: <20230419092559.673869-1-n-francis@ti.com>
Add address entry mapping ESM on J721E.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
index b912143b6a11..52bcde601eb8 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
@@ -131,6 +131,7 @@ cbass_main: bus@100000 {
#size-cells = <2>;
ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
<0x00 0x00600000 0x00 0x00600000 0x00 0x00031100>, /* GPIO */
+ <0x00 0x00700000 0x00 0x00700000 0x00 0x00001000>, /* ESM */
<0x00 0x00900000 0x00 0x00900000 0x00 0x00012000>, /* serdes */
<0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* timesync router */
<0x00 0x06000000 0x00 0x06000000 0x00 0x00400000>, /* USBSS0 */
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices
From: Neha Malcom Francis @ 2023-04-19 9:25 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel
Cc: n-francis, nm, vigneshr, u-kumar1
In-Reply-To: <20230419092559.673869-1-n-francis@ti.com>
Document the binding for TI K3 ESM (Error Signaling Module) block.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
.../bindings/hwmon/ti,j721e-esm.yaml | 55 +++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
new file mode 100644
index 000000000000..7b23ac7cb3ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,j721e-esm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM
+
+maintainers:
+ - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+ The ESM (Error Signaling Module) is an IP block on TI K3 devices
+ that allows handling of safety events somewhat similar to what interrupt
+ controller would do. The safety signals have their separate paths within
+ the SoC, and they are handled by the ESM, which routes them to the proper
+ destination, which can be system reset, interrupt controller, etc. In the
+ simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+ compatible:
+ const: ti,j721e-esm
+
+ reg:
+ items:
+ - description: the ESM register set
+
+ ti,esm-pins:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ integer array of ESM interrupt pins to route to external event pin
+ which can be used to reset the SoC.
+ minItems: 1
+ maxItems: 255
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ti,esm-pins
+
+examples:
+ - |
+ cbass_main {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ esm@700000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x700000 0x0 0x1000>;
+ ti,esm-pins = <344>, <345>;
+ };
+ };
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: ti: k3-j7200: Add ESM support
From: Neha Malcom Francis @ 2023-04-19 9:25 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel
Cc: n-francis, nm, vigneshr, u-kumar1
In-Reply-To: <20230419092559.673869-1-n-francis@ti.com>
Add address entry mapping ESM on J7200.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 ++++++
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index ef352e32f19d..89f816f5e53d 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -1010,4 +1010,10 @@ main_r5fss0_core1: r5f@5d00000 {
ti,loczrama = <1>;
};
};
+
+ main_esm: esm@700000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x700000 0x0 0x1000>;
+ ti,esm-pins = <656>, <657>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200.dtsi b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
index bbe380c72a7e..4998eb4fbe75 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
@@ -128,6 +128,7 @@ cbass_main: bus@100000 {
#size-cells = <2>;
ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
<0x00 0x00600000 0x00 0x00600000 0x00 0x00031100>, /* GPIO */
+ <0x00 0x00700000 0x00 0x00700000 0x00 0x00001000>, /* ESM */
<0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* timesync router */
<0x00 0x01000000 0x00 0x01000000 0x00 0x0d000000>, /* Most peripherals */
<0x00 0x30000000 0x00 0x30000000 0x00 0x0c400000>, /* MAIN NAVSS */
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/3] Add support for ESM
From: Neha Malcom Francis @ 2023-04-19 9:25 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel
Cc: n-francis, nm, vigneshr, u-kumar1
ESM (Error Signaling Module) is a fundamental IP responsible for
handling safety events. The driver currently present in U-Boot is
responsible for configuring ESM. This patch series adds dt-binding and
nodes for J721E and J7200. This goes towards end goal of having DTB sync
with that of U-Boot as well as ensuring completeness of hardware
description in devicetree.
Changes in v2:
- misc/esm-k3.yaml -> hwmon/ti,j721e-esm.yaml
- formatting changes in dt-binding
- modified example in dt-binding
Neha Malcom Francis (3):
dt-bindings: misc: esm: Add ESM support for TI K3 devices
arm64: dts: ti: k3-j721e: Add ESM support
arm64: dts: ti: k3-j7200: Add ESM support
.../bindings/hwmon/ti,j721e-esm.yaml | 55 +++++++++++++++++++
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 ++
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 +
4 files changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] riscv: Allow userspace to directly access perf counters
From: Alexandre Ghiti @ 2023-04-19 9:21 UTC (permalink / raw)
To: Atish Patra
Cc: Ian Rogers, David Laight, Jonathan Corbet, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Anup Patel, Will Deacon, Rob Herring,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, paranlee
In-Reply-To: <CAOnJCULJfSN79MzAwhCrbVzG1rYyrPB3OraFmoZFBxuRCwq01w@mail.gmail.com>
Hi Ian,
On Tue, Apr 18, 2023 at 10:30 PM Atish Patra <atishp@atishpatra.org> wrote:
>
> On Tue, Apr 18, 2023 at 11:46 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Tue, Apr 18, 2023 at 9:43 AM Atish Patra <atishp@atishpatra.org> wrote:
> > >
> > > On Fri, Apr 14, 2023 at 2:40 AM David Laight <David.Laight@aculab.com> wrote:
> > > >
> > > > From: Atish Patra
> > > > > Sent: 13 April 2023 20:18
> > > > >
> > > > > On Thu, Apr 13, 2023 at 9:47 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > > > > >
> > > > > > riscv used to allow direct access to cycle/time/instret counters,
> > > > > > bypassing the perf framework, this patchset intends to allow the user to
> > > > > > mmap any counter when accessed through perf. But we can't break the
> > > > > > existing behaviour so we introduce a sysctl perf_user_access like arm64
> > > > > > does, which defaults to the legacy mode described above.
> > > > > >
> > > > >
> > > > > It would be good provide additional direction for user space packages:
> > > > >
> > > > > The legacy behavior is supported for now in order to avoid breaking
> > > > > existing software.
> > > > > However, reading counters directly without perf interaction may
> > > > > provide incorrect values which
> > > > > the userspace software must avoid. We are hoping that the user space
> > > > > packages which
> > > > > read the cycle/instret directly, will move to the proper interface
> > > > > eventually if they actually need it.
> > > > > Most of the users are supposed to read "time" instead of "cycle" if
> > > > > they intend to read timestamps.
> > > >
> > > > If you are trying to measure the performance of short code
> > > > fragments then you need pretty much raw access directly to
> > > > the cycle/clock count register.
> > > >
> > > > I've done this on x86 to compare the actual cycle times
> > > > of different implementations of the IP checksum loop
> > > > (and compare them to the theoretical limit).
> > > > The perf framework just added far too much latency,
> > > > only directly reading the cpu registers gave anything
> > > > like reliable (and consistent) answers.
> > > >
> > >
> > > This series allows direct access to the counters once configured
> > > through the perf.
> > > Earlier the cycle/instret counters are directly exposed to the
> > > userspace without kernel/perf frameworking knowing
> > > when/which user space application is reading it. That has security implications.
> > >
> > > With this series applied, the user space application just needs to
> > > configure the event (cycle/instret) through perf syscall.
> > > Once configured, the userspace application can find out the counter
> > > information from the mmap & directly
> > > read the counter. There is no latency while reading the counters.
> > >
> > > This mechanism allows stop/clear the counters when the requesting task
> > > is not running. It also takes care of context switching
> > > which may result in invalid values as you mentioned below. This is
> > > nothing new and all other arch (x86, ARM64) allow user space
> > > counter read through the same mechanism.
> > >
> > > Here is the relevant upstream discussion:
> > > https://lore.kernel.org/lkml/Y7wLa7I2hlz3rKw%2F@hirez.programming.kicks-ass.net/T/
> > >
> > > ARM64:
> > > https://docs.kernel.org/arm64/perf.html?highlight=perf_user_access#perf-userspace-pmu-hardware-counter-access
> > >
> > > example usage in x86:
> > > https://github.com/andikleen/pmu-tools/blob/master/jevents/rdpmc.c
> >
> > The canonical implementation of this should be:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/mmap.c#n400
>
> Thanks for sharing the libperf implementation.
>
> > which is updated in these patches but the tests are not:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/tests/mmap-basic.c#n287
> > Which appears to be an oversight. The tests display some differences
>
> Yes. It's an oversight. We should make sure that perf mmap tests pass
> for RISC-V as well.
Yes, that's an oversight, I had a local test adapted from this one but
forgot to update it afterwards, I'll do that in the next version.
Thanks for your quick feedbacks and sorry for being late,
Alex
>
>
> > between x86 and aarch64 that have assumed userspace hardware counter
> > access, and everything else that it is assumed don't.
> >
> > Thanks,
> > Ian
> >
> > > > Clearly process switches (especially cpu migrations) cause
> > > > problems, but they are obviously invalid values and can
> > > > be ignored.
> > > >
> > > > So while a lot of uses may be 'happy' with the values the
> > > > perf framework gives, sometimes you do need to directly
> > > > read the relevant registers.
> > > >
> > > > David
> > > >
> > > > -
> > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > > Registration No: 1397386 (Wales)
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
>
>
>
> --
> Regards,
> Atish
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Make vcpu flag updates non-preemptible
From: Will Deacon @ 2023-04-19 8:58 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, James Morse, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Catalin Marinas, Quentin Perret,
Mostafa Saleh, stable
In-Reply-To: <20230418125737.2327972-1-maz@kernel.org>
On Tue, Apr 18, 2023 at 01:57:37PM +0100, Marc Zyngier wrote:
> Per-vcpu flags are updated using a non-atomic RMW operation.
> Which means it is possible to get preempted between the read and
> write operations.
>
> Another interesting thing to note is that preemption also updates
> flags, as we have some flag manipulation in both the load and put
> operations.
>
> It is thus possible to lose information communicated by either
> load or put, as the preempted flag update will overwrite the flags
> when the thread is resumed. This is specially critical if either
> load or put has stored information which depends on the physical
> CPU the vcpu runs on.
>
> This results in really elusive bugs, and kudos must be given to
> Mostafa for the long hours of debugging, and finally spotting
> the problem.
>
> Fix it by disabling preemption during the RMW operation, which
> ensures that the state stays consistent. Also upgrade vcpu_get_flag
> path to use READ_ONCE() to make sure the field is always atomically
> accessed.
>
> Fixes: e87abb73e594 ("KVM: arm64: Add helpers to manipulate vcpu flags among a set")
> Reported-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Cc: stable@vger.kernel.org
> ---
>
> Notes:
> v2: add READ_ONCE() on the read path, expand commit message
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
From: Mike Rapoport @ 2023-04-19 8:56 UTC (permalink / raw)
To: Kefeng Wang
Cc: Andrew Morton, Arnd Bergmann, Catalin Marinas, Christophe Leroy,
David S. Miller, Dinh Nguyen, Geert Uytterhoeven, Guo Ren,
John Paul Adrian Glaubitz, Kirill A. Shutemov, Max Filippov,
Michael Ellerman, Rich Felker, Russell King, Will Deacon,
Yoshinori Sato, Zi Yan, linux-arm-kernel, linux-csky, linux-ia64,
linux-kernel, linux-m68k, linux-mm, linux-sh, linux-xtensa,
linuxppc-dev, sparclinux
In-Reply-To: <02dd2437-32fa-31aa-4ff3-b33a058f2363@huawei.com>
On Sat, Mar 25, 2023 at 02:38:15PM +0800, Kefeng Wang wrote:
>
>
> On 2023/3/25 14:08, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)" <rppt@kernel.org>
> >
> > It is enough to keep default values for base and huge pages without
> > letting users to override ARCH_FORCE_MAX_ORDER.
> >
> > Drop the prompt to make the option unvisible in *config.
> >
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Reviewed-by: Zi Yan <ziy@nvidia.com>
> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > ---
> > arch/ia64/Kconfig | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> > index 0d2f41fa56ee..b61437cae162 100644
> > --- a/arch/ia64/Kconfig
> > +++ b/arch/ia64/Kconfig
> > @@ -202,8 +202,7 @@ config IA64_CYCLONE
> > If you're unsure, answer N.
> > config ARCH_FORCE_MAX_ORDER
> > - int "MAX_ORDER (10 - 16)" if !HUGETLB_PAGE
> > - range 10 16 if !HUGETLB_PAGE
> > + int
> > default "16" if HUGETLB_PAGE
> > default "10"
>
> It seems that we could drop the following part?
ia64 can have 64k pages, so with MAX_ORDER==16 we'd need at least 32 bits
for section size
> diff --git a/arch/ia64/include/asm/sparsemem.h
> b/arch/ia64/include/asm/sparsemem.h
> index a58f8b466d96..18187551b183 100644
> --- a/arch/ia64/include/asm/sparsemem.h
> +++ b/arch/ia64/include/asm/sparsemem.h
> @@ -11,11 +11,6 @@
>
> #define SECTION_SIZE_BITS (30)
> #define MAX_PHYSMEM_BITS (50)
> -#ifdef CONFIG_ARCH_FORCE_MAX_ORDER
> -#if (CONFIG_ARCH_FORCE_MAX_ORDER + PAGE_SHIFT > SECTION_SIZE_BITS)
> -#undef SECTION_SIZE_BITS
> -#define SECTION_SIZE_BITS (CONFIG_ARCH_FORCE_MAX_ORDER + PAGE_SHIFT)
> -#endif
> #endif
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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