* 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
* Re: [PATCH] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Eric Auger @ 2023-04-19 8:52 UTC (permalink / raw)
To: Dan Carpenter, Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Steven Price, linux-arm-kernel,
kvmarm, kernel-janitors
In-Reply-To: <ab7b9caf-5c90-4616-8517-b38637293639@kili.mountain>
Hi Dan,
On 4/19/23 10: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: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> 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..4f5767fcaca5 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 -EINVAL;
> 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] staging: vchiq_arm: Make vchiq_platform_init() static
From: Simon Horman @ 2023-04-19 8:51 UTC (permalink / raw)
To: Stefan Wahren
Cc: Broadcom internal kernel review list, Nathan Chancellor,
Nick Desaulniers, Tom Rix, Greg Kroah-Hartman, linux-rpi-kernel,
linux-arm-kernel, linux-staging, llvm, Florian Fainelli
In-Reply-To: <e1fed875-059d-bf98-f9da-09c51f362be8@i2se.com>
On Wed, Apr 19, 2023 at 08:37:58AM +0200, Stefan Wahren wrote:
> Hi Simon,
>
> Am 18.04.23 um 13:23 schrieb Simon Horman:
> > vchiq_platform_init() is only used in this file so it can be static.
> >
> > clang-16 with W=1 reports:
> >
> > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:465:5: error: no previous prototype for function 'vchiq_platform_init' [-Werror,-Wmissing-prototypes]
> > int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state *state)
> > ^
> > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:465:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
> >
> > Signed-off-by: Simon Horman <horms@kernel.org>
>
> this is not the first attempt to fix this [1]. But maybe this has been fixed
> in the meantime.
>
> [1] - https://lore.kernel.org/linux-staging/20221022043548.1671644-1-scottjcrouch@gmail.com/#t
Thanks,
I see in that thread that Greg notes that "this breaks the build in a very
horrible and strange way" [2].
I'm a bit surprised as I didn't observe such a thing.
But I also don't dispute it - clearly my testing was inadequate.
I'll try and dig a bit deeper into this one.
Perhaps starting with the report from the kernel test robot [3]
[2] https://lore.kernel.org/linux-staging/Y1Okpjbi2kKU2GFz@kroah.com/
[3] https://lore.kernel.org/linux-staging/202210230127.p1Dp295m-lkp@intel.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 8:48 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: <ab7b9caf-5c90-4616-8517-b38637293639@kili.mountain>
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;
Steve
> ---
> 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..4f5767fcaca5 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 -EINVAL;
> 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
* [PATCH V2] spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS
From: Dhruva Gole @ 2023-04-19 8:48 UTC (permalink / raw)
To: Mark Brown
Cc: Dhruva Gole, Vaishnav Achath, Vignesh, Apurva Nandan,
linux-arm-kernel, linux-spi, linux-kernel
Using this macro makes the code more readable.
It also inits the members of dev_pm_ops in the following manner
without us explicitly needing to:
.suspend = cqspi_suspend, \
.resume = cqspi_resume, \
.freeze = cqspi_suspend, \
.thaw = cqspi_resume, \
.poweroff = cqspi_suspend, \
.restore = cqspi_resume
Signed-off-by: Dhruva Gole <d-gole@ti.com>
---
Address comments from previously posted patch:
https://patchwork.kernel.org/project/spi-devel-general/patch/20230417091027.966146-2-d-gole@ti.com/
drivers/spi/spi-cadence-quadspi.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 79ab7e309644..922026bb9380 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1829,12 +1829,7 @@ static int cqspi_resume(struct device *dev)
return 0;
}
-static const struct dev_pm_ops cqspi__dev_pm_ops = {
- .suspend = cqspi_suspend,
- .resume = cqspi_resume,
-};
-
-#define CQSPI_DEV_PM_OPS (&cqspi__dev_pm_ops)
+static DEFINE_SIMPLE_DEV_PM_OPS(cqspi_dev_pm_ops, cqspi_suspend, cqspi_resume);
#else
#define CQSPI_DEV_PM_OPS NULL
#endif
@@ -1912,7 +1907,7 @@ static struct platform_driver cqspi_platform_driver = {
.remove_new = cqspi_remove,
.driver = {
.name = CQSPI_NAME,
- .pm = CQSPI_DEV_PM_OPS,
+ .pm = &cqspi_dev_pm_ops,
.of_match_table = cqspi_dt_ids,
},
};
--
2.25.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: SMP enablement on Cortex-R52 (using PSCI ?)
From: Sudeep Holla @ 2023-04-19 8:47 UTC (permalink / raw)
To: Ayan Kumar Halder
Cc: mark.rutland, lpieralisi, Sudeep Holla, linux-arm-kernel,
linux-kernel, Vladimir Murzin, Stefano Stabellini
In-Reply-To: <1cb7d428-c047-1485-e39d-465806f6ef0b@amd.com>
Hi Ayan,
On Fri, Apr 14, 2023 at 12:24:38PM +0100, Ayan Kumar Halder wrote:
> Hi PSCI developers,
>
> We have a SoC where there are 4 Cortex-R52 which is distributed in two
> clusters. So we have 2 Cortex-R52 in one cluster and 2 Cortex-R52 in another
> cluster.
>
> We wish to enable SMP on the 2 R52 within a cluster with Xen hypervisor (EL2
> software) running on them.
>
> We are trying to explore if we can use PSCI for booting the secondary cores.
>
> Refer Cortex-R52 TRM
> (https://developer.arm.com/documentation/100026/0101/?lang=en ), it
> specifies the following :-
>
> Page 24 - Section 1.4.1
>
> "Support for Exception levels, EL0, EL1, and EL2."
>
> Page 30 - Section 2.1.6
>
> "The Cortex-R52 processor does not implement TrustZone® technology. It does
> not support the ability to distinguish between secure and non-secure
> physical memories."
>
> Thus, there is no EL3 and secure world in Cortex-R52. It implements
> AArch32-V8R architecture.
>
KVM hypervisor use PSCI to bring up secondaries in the VMs. So I am sure we
must be able to use the interface on Cortex-R52 without EL3.
>
> Refer PSCI design document,
> https://developer.arm.com/documentation/den0022/e/?lang=en
>
> Page 18 -
> "The PSCI specification focuses on the interface between Security states for
> power management. It provides a method for issuing power management
> requests. To deal with the requests, the PPF must include a PSCI
> implementation. A PSCI implementation might require communication between
> the PPF and a Trusted OS or SP."
>
> Page 17 - Privileged Platform Firmware (PPF)
>
> "For Armv7 systems, or Armv8 systems using AArch32 at EL3, PPF executes in
> EL3."
>
> From the above two statements, I infer that PSCI requires a PPF (running at
> EL3) and a Trusted OS (running at secure EL2). If this is correct, then R52
> cannot support PSCI. Please correct me if I am mistaken.
>
> I wish to know how do we wake up the secondary core if PSCI is not
> supported.
>
I will check with the authors if EL3 is a must for PSCI implementation, but
IMO it must not be though every aspects described in the spec may not apply
when used across EL2/EL1 boundaries especially when EL3 is not implemented
in the hardware.
--
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
* Re: [PATCH 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices
From: Neha Malcom Francis @ 2023-04-19 8:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, u-boot, robh+dt, krzysztof.kozlowski+dt,
devicetree, linux-kernel, linux-arm-kernel, Guenter Roeck
Cc: nm, vigneshr, u-kumar1
In-Reply-To: <eb6bfe2e-1e44-bfb5-01b9-bbf53eba6501@linaro.org>
Hi Krzysztof
On 18/04/23 21:40, Krzysztof Kozlowski wrote:
> On 17/04/2023 10:56, Neha Malcom Francis wrote:
>> Hi Krzysztof
>>
>> On 14/04/23 17:10, Krzysztof Kozlowski wrote:
>>> On 14/04/2023 12:52, Neha Malcom Francis wrote:
>>>> Document the binding for TI K3 ESM (Error Signaling Module) block.
>>>>
>>>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>>>> ---
>>>> .../devicetree/bindings/misc/esm-k3.yaml | 54 +++++++++++++++++++
>>>> 1 file changed, 54 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/misc/esm-k3.yaml b/Documentation/devicetree/bindings/misc/esm-k3.yaml
>>>> new file mode 100644
>>>> index 000000000000..5e637add3b0e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/misc/esm-k3.yaml
>>>
>>> Filename matching compatible. Missing vendor prefix and device name.
>>>
>>>> @@ -0,0 +1,54 @@
>>>> +# 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/misc/esm-k3.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Texas Instruments K3 ESM Binding
>>>
>>> Drop: Binding
>>>
>>>> +
>>>> +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 handld by the ESM, which routes them to the proper
>>>
>>> typo: handled
>>>
>>>> + destination, which can be system reset, interrupt controller, etc. In the
>>>> + simplest configuration the signals are just routed to reset the SoC.
>>>
>>> There is no proper bindings directory for ESM? Misc is discouraged.
>>>
>>
>> There is no other directory I see fit for a block like ESM; it could
>> either remain in misc/ or maybe create a directory error/ for all error
>> signaling and correction mechanisms? I see misc/xlnx,sd-fec.txt that
>> could also go in error/
>>
>> What do you think is fit?
>
> I don't know. Maybe it is something like hwmon? Or maybe along with
> xlnx,sd-fec, tmr-inject and tmr-manager should be moved to some "fault"
> directory for all fault-management-and-handling hardware?
>
I think hwmon would be a fit for now. Maybe we can move to a common
fault directory in a future patch if there is enough bindings.
> Best regards,
> Krzysztof
>
--
Thanking You
Neha Malcom Francis
_______________________________________________
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: Oliver Upton @ 2023-04-19 8:41 UTC (permalink / raw)
To: linux-arm-kernel, kvm, kvmarm, Marc Zyngier
Cc: Oliver Upton, Mostafa Saleh, Suzuki K Poulose, stable,
James Morse, Catalin Marinas, Zenghui Yu, Will Deacon,
Quentin Perret
In-Reply-To: <20230418125737.2327972-1-maz@kernel.org>
On Tue, 18 Apr 2023 13:57:37 +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.
>
> [...]
Applied to kvmarm/fixes, thanks!
[1/1] KVM: arm64: Make vcpu flag updates non-preemptible
https://git.kernel.org/kvmarm/kvmarm/c/35dcb3ac663a
--
Best,
Oliver
_______________________________________________
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 1/4] spi: s3c64xx: changed to PIO mode if there is no DMA
From: Krzysztof Kozlowski @ 2023-04-19 8:36 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <e29c3c88-e487-75da-662b-6720a1ef1dc6@samsung.com>
On 19/04/2023 10:31, Jaewon Kim wrote:
>
> On 23. 4. 19. 17:03, Krzysztof Kozlowski wrote:
>> On 19/04/2023 08:06, Jaewon Kim wrote:
>>> Polling mode supported with qurik if there was no DMA in the SOC.
>> typo: quirk
>> You missed verb in your first part of sentence. I don't understand it.
>
> Sorry, I change this sentence like below.
>
> Polling mode supported as a quirk for SOCs without DMA.
I would say still verb is missing as supported in past tense does not
make sense.
See:
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95
>
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 v2 1/4] spi: s3c64xx: changed to PIO mode if there is no DMA
From: Jaewon Kim @ 2023-04-19 8:31 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: <41ebe41f-d773-7cc3-dcad-8574c858645e@linaro.org>
On 23. 4. 19. 17:03, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> Polling mode supported with qurik if there was no DMA in the SOC.
> typo: quirk
> You missed verb in your first part of sentence. I don't understand it.
Sorry, I change this sentence like below.
Polling mode supported as a quirk for SOCs without DMA.
>
>> However, there are cased where we cannot or do not want to use DMA.
>> To support this case, if DMA is not set, it is switched to polling mode.
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 8 ++++++--
>> include/linux/platform_data/spi-s3c64xx.h | 1 +
>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index 71d324ec9a70..273aa02322d9 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -19,7 +19,6 @@
>> #include <linux/platform_data/spi-s3c64xx.h>
>>
>> #define MAX_SPI_PORTS 12
>> -#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
>> #define S3C64XX_SPI_QUIRK_CS_AUTO (1 << 1)
>> #define AUTOSUSPEND_TIMEOUT 2000
>>
>> @@ -116,7 +115,7 @@
>> #define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
>>
>> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
>> -#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
>> +#define is_polling(x) (x->cntrlr_info->polling)
>>
>> #define RXBUSY (1<<2)
>> #define TXBUSY (1<<3)
>> @@ -1067,6 +1066,11 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
>> sci->num_cs = temp;
>> }
>>
>> + if (!of_find_property(dev->of_node, "dmas", NULL)) {
>> + dev_warn(dev, "cannot find DMA, changed to PIO mode\n");
> You said it is desired option, so should not be a warning. I would make
> it debug at most.
>
Okay, I will change dev_warn() to dev_dbg().
>> + sci->polling = 1;
>
>
> 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 v2 0/4] Improves polling mode of s3c64xx driver
From: Jaewon Kim @ 2023-04-19 8:29 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: <c49881dc-f283-6981-3e03-02fb02b5ce54@linaro.org>
On 23. 4. 19. 16:59, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> 1.
>> s3cx64xx driver was supporting polling mode using quirk for SOC without DMA.
>> However, in order to use PIO mode as an optional rather than a quirk, when DMA
>> is not described, spi operates with pio mode rather than probe fail.
>>
>> 2.
>> Fixed the problem of high CPU usage in PIO mode.
>>
>> 3.
>> If the transfer data size is larger than 32-bit, IRQ base PIO mode used.
>>
> What changed in the patches? You need to provide changelog.
Oh, I missed changes while copy/pasting.
I will add changes v2 from v3 together.
Changes in V2.
- DeviceTree property not used to change PIO mod.
- Add cpu_releax() in polling loop
- Add lower limit in IRQ mode
>
> 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 v2 4/4] spi: s3c64xx: support interrupt based pio mode
From: Krzysztof Kozlowski @ 2023-04-19 8:21 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419060639.38853-5-jaewon02.kim@samsung.com>
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.
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 v2 3/4] spi: s3c64xx: add sleep during transfer
From: Krzysztof Kozlowski @ 2023-04-19 8:19 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419060639.38853-4-jaewon02.kim@samsung.com>
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?
>
> /* 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] firmware: arm_scmi: Remove unnecessary (void*) conversions
From: yunchuan @ 2023-04-19 8:19 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi; +Cc: linux-arm-kernel, linux-kernel, yunchuan
Pointer variables of void * type do not require type cast.
Signed-off-by: yunchuan <yunchuan@nfschina.com>
---
drivers/firmware/arm_scmi/virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/virtio.c b/drivers/firmware/arm_scmi/virtio.c
index d68c01cb7aa0..f0863b9c0e5d 100644
--- a/drivers/firmware/arm_scmi/virtio.c
+++ b/drivers/firmware/arm_scmi/virtio.c
@@ -392,7 +392,7 @@ static bool virtio_chan_available(struct device_node *of_node, int idx)
if (WARN_ON_ONCE(!scmi_vdev))
return false;
- channels = (struct scmi_vio_channel *)scmi_vdev->priv;
+ channels = scmi_vdev->priv;
switch (idx) {
case VIRTIO_SCMI_VQ_TX:
--
2.30.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: [PATCH v2 2/4] spi: s3c64xx: add cpu_relax in polling loop
From: Krzysztof Kozlowski @ 2023-04-19 8:14 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419060639.38853-3-jaewon02.kim@samsung.com>
On 19/04/2023 08:06, Jaewon Kim wrote:
> Adds cpu_relax() to prevent long busy-wait.
How cpu_relax prevents long waiting?
> There is busy-wait loop to check data transfer completion in polling mode.
>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> ---
> drivers/spi/spi-s3c64xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 273aa02322d9..886722fb40ea 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -568,6 +568,7 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>
> val = msecs_to_loops(ms);
> do {
> + cpu_relax();
Shouldn't this be just readl_poll_timeout()? Or the syntax would be too
complicated?
> status = readl(regs + S3C64XX_SPI_STATUS);
> } while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
>
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
* [linux-next:master] BUILD REGRESSION 67d5d9f013d6c3829383c08162939cabff14fccc
From: kernel test robot @ 2023-04-19 8:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, linux-mediatek, linux-arm-kernel, intel-gfx, amd-gfx,
Linux Memory Management List
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 67d5d9f013d6c3829383c08162939cabff14fccc Add linux-next specific files for 20230418
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304102354.Q4VOXGTE-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "__floatundidf" [drivers/phy/mediatek/phy-mtk-hdmi-drv.ko] undefined!
ERROR: modpost: "__gedf2" [drivers/phy/mediatek/phy-mtk-hdmi-drv.ko] undefined!
ERROR: modpost: "__ltdf2" [drivers/phy/mediatek/phy-mtk-hdmi-drv.ko] undefined!
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line:
drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized]
ld.lld: error: .btf.vmlinux.bin.o: unknown file type
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm64-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm64-randconfig-r012-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- i386-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- ia64-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- loongarch-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- loongarch-defconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- mips-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- mips-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- powerpc-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- riscv-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- riscv-randconfig-r033-20230417
| |-- ERROR:__floatundidf-drivers-phy-mediatek-phy-mtk-hdmi-drv.ko-undefined
| |-- ERROR:__gedf2-drivers-phy-mediatek-phy-mtk-hdmi-drv.ko-undefined
| `-- ERROR:__ltdf2-drivers-phy-mediatek-phy-mtk-hdmi-drv.ko-undefined
|-- s390-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- sparc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
`-- x86_64-allyesconfig
|-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
`-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
clang_recent_errors
|-- arm64-randconfig-r004-20230418
| `-- ld.lld:error:.btf.vmlinux.bin.o:unknown-file-type
|-- powerpc-randconfig-r032-20230416
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
`-- x86_64-randconfig-a011-20230417
|-- drivers-gpu-drm-i915-gt-uc-guc_capture_fwif.h:warning:wrong-kernel-doc-identifier-on-line:
|-- drivers-gpu-drm-i915-i915_pmu.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- drivers-gpu-drm-i915-i915_request.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
`-- drivers-gpu-drm-i915-i915_vma.h:warning:expecting-prototype-for-i915_vma_offset().-Prototype-was-for-i915_vma_size()-instead
elapsed time: 726m
configs tested: 151
configs skipped: 15
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r013-20230416 gcc
arc randconfig-r025-20230417 gcc
arc randconfig-r043-20230416 gcc
arc randconfig-r043-20230417 gcc
arc randconfig-r043-20230418 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r005-20230416 clang
arm defconfig gcc
arm randconfig-r011-20230416 clang
arm randconfig-r021-20230416 clang
arm randconfig-r025-20230416 clang
arm randconfig-r034-20230417 clang
arm randconfig-r034-20230418 gcc
arm randconfig-r035-20230418 gcc
arm randconfig-r046-20230416 clang
arm randconfig-r046-20230417 gcc
arm randconfig-r046-20230418 clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r004-20230418 clang
arm64 randconfig-r006-20230417 gcc
arm64 randconfig-r012-20230416 gcc
arm64 randconfig-r026-20230416 gcc
csky defconfig gcc
csky randconfig-r016-20230417 gcc
csky randconfig-r023-20230416 gcc
csky randconfig-r035-20230417 gcc
hexagon randconfig-r001-20230417 clang
hexagon randconfig-r041-20230416 clang
hexagon randconfig-r041-20230417 clang
hexagon randconfig-r041-20230418 clang
hexagon randconfig-r045-20230416 clang
hexagon randconfig-r045-20230417 clang
hexagon randconfig-r045-20230418 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001 gcc
i386 randconfig-a002 clang
i386 randconfig-a003 gcc
i386 randconfig-a004 clang
i386 randconfig-a005 gcc
i386 randconfig-a006 clang
i386 randconfig-a011-20230417 clang
i386 randconfig-a012-20230417 clang
i386 randconfig-a013-20230417 clang
i386 randconfig-a014-20230417 clang
i386 randconfig-a015-20230417 clang
i386 randconfig-a016-20230417 clang
i386 randconfig-r023-20230417 clang
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r001-20230417 gcc
ia64 buildonly-randconfig-r005-20230418 gcc
ia64 defconfig gcc
ia64 randconfig-r004-20230416 gcc
ia64 randconfig-r005-20230416 gcc
ia64 randconfig-r006-20230416 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r006-20230416 gcc
m68k defconfig gcc
m68k randconfig-r005-20230418 gcc
m68k randconfig-r006-20230418 gcc
m68k randconfig-r014-20230417 gcc
m68k randconfig-r031-20230417 gcc
m68k randconfig-r033-20230418 gcc
m68k randconfig-r035-20230416 gcc
m68k randconfig-r036-20230417 gcc
microblaze buildonly-randconfig-r004-20230418 gcc
microblaze buildonly-randconfig-r006-20230418 gcc
microblaze randconfig-r003-20230416 gcc
microblaze randconfig-r021-20230417 gcc
microblaze randconfig-r024-20230416 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips randconfig-r002-20230418 gcc
mips randconfig-r004-20230417 clang
nios2 buildonly-randconfig-r001-20230416 gcc
nios2 defconfig gcc
nios2 randconfig-r005-20230417 gcc
nios2 randconfig-r022-20230417 gcc
openrisc randconfig-r031-20230418 gcc
parisc buildonly-randconfig-r003-20230416 gcc
parisc defconfig gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r003-20230417 clang
powerpc buildonly-randconfig-r004-20230417 clang
powerpc randconfig-r016-20230416 gcc
powerpc randconfig-r032-20230416 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r001-20230418 gcc
riscv defconfig gcc
riscv randconfig-r002-20230417 gcc
riscv randconfig-r015-20230416 gcc
riscv randconfig-r033-20230417 gcc
riscv randconfig-r034-20230416 clang
riscv randconfig-r042-20230416 gcc
riscv randconfig-r042-20230417 clang
riscv randconfig-r042-20230418 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r004-20230416 gcc
s390 defconfig gcc
s390 randconfig-r012-20230417 clang
s390 randconfig-r015-20230417 clang
s390 randconfig-r044-20230416 gcc
s390 randconfig-r044-20230417 clang
s390 randconfig-r044-20230418 gcc
sh allmodconfig gcc
sh buildonly-randconfig-r002-20230416 gcc
sh buildonly-randconfig-r005-20230417 gcc
sh randconfig-r001-20230418 gcc
sh randconfig-r003-20230417 gcc
sh randconfig-r031-20230416 gcc
sh randconfig-r036-20230416 gcc
sparc defconfig gcc
sparc randconfig-r032-20230417 gcc
sparc randconfig-r036-20230418 gcc
sparc64 buildonly-randconfig-r002-20230417 gcc
sparc64 buildonly-randconfig-r003-20230418 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230417 gcc
x86_64 randconfig-a002-20230417 gcc
x86_64 randconfig-a003-20230417 gcc
x86_64 randconfig-a004-20230417 gcc
x86_64 randconfig-a005-20230417 gcc
x86_64 randconfig-a006-20230417 gcc
x86_64 randconfig-a011-20230417 clang
x86_64 randconfig-a012-20230417 clang
x86_64 randconfig-a013-20230417 clang
x86_64 randconfig-a014-20230417 clang
x86_64 randconfig-a015-20230417 clang
x86_64 randconfig-a016-20230417 clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r001-20230416 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
_______________________________________________
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 linux-next v3 4/4] clocksource/drivers/timer-mediatek: Make timer-mediatek become loadable module
From: AngeloGioacchino Del Regno @ 2023-04-19 8:10 UTC (permalink / raw)
To: walter.chang, Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230419074910.10809-5-walter.chang@mediatek.com>
Il 19/04/23 09:49, walter.chang@mediatek.com ha scritto:
> From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
>
> Make the timer-mediatek driver which can register
> an always-on timer as tick_broadcast_device on
> MediaTek SoCs become loadable module in GKI.
>
> Tested-by: Walter Chang <walter.chang@mediatek.com>
> Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
I think I typoed your email when sending the example patch for the
conversion to platform_device. Check [1], it may be better to just
iterate through that? (please ignore the pure_initcall() part, that's
a mistake, it's never gonna happen as it automatically becomes a
module_init() call).
It depends on what maintainers think about that clocksource.h addition,
the patch got zero comments, so if you're interested in that perhaps we
can explicitly ask what would be the best option between yours and mine;
that addition is done only to avoid the big ifdef party that this patch
proposes and makes things a bit shorter if this timer modularization
goes on with more drivers, but I don't have strong opinions anyway.
In the meanwhile, just to eventually speed up integrating this, or the
other patch - I'll still give you a review of this one.
[1]:
https://patchwork.kernel.org/project/linux-mediatek/patch/20230309132119.175650-1-angelogioacchino.delregno@collabora.com/
> ---
> drivers/clocksource/Kconfig | 2 +-
> drivers/clocksource/timer-mediatek.c | 39 ++++++++++++++++++++++++++++
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 526382dc7482..a7413ad7b6ad 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -472,7 +472,7 @@ config SYS_SUPPORTS_SH_CMT
> bool
>
> config MTK_TIMER
> - bool "Mediatek timer driver" if COMPILE_TEST
> + tristate "Mediatek timer driver"
While at it, you could also fix the text, Mediatek -> MediaTek
> depends on HAS_IOMEM
> select TIMER_OF
> select CLKSRC_MMIO
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 7bcb4a3f26fb..3448848682c0 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -13,6 +13,9 @@
> #include <linux/clocksource.h>
> #include <linux/interrupt.h>
> #include <linux/irqreturn.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> #include <linux/sched_clock.h>
> #include <linux/slab.h>
> #include "timer-of.h"
> @@ -337,5 +340,41 @@ static int __init mtk_gpt_init(struct device_node *node)
>
> return 0;
> }
> +
> +#ifdef MODULE
#ifndef MODULE
... two lines...
#else
... a bunch of lines ...
#endif
looks more readable. I'd go with that.
> +static int mtk_timer_probe(struct platform_device *pdev)
> +{
> + int (*timer_init)(struct device_node *node);
> + struct device_node *np = pdev->dev.of_node;
> +
> + timer_init = of_device_get_match_data(&pdev->dev);
> + return timer_init(np);
> +}
> +
> +static const struct of_device_id mtk_timer_match_table[] = {
> + {
> + .compatible = "mediatek,mt6577-timer",
> + .data = mtk_gpt_init,
Fits in one line!
> + },
> + {
> + .compatible = "mediatek,mt6765-timer",
> + .data = mtk_syst_init,
ditto.
> + },
> + {}
Always end with { /* sentinel */ }
> +};
> +
> +static struct platform_driver mtk_timer_driver = {
> + .probe = mtk_timer_probe,
> + .driver = {
> + .name = "mtk-timer",
"mediatek-timer" looks nicer :-)
> + .of_match_table = mtk_timer_match_table,
> + },
> +};
> +module_platform_driver(mtk_timer_driver);
> +
> +MODULE_DESCRIPTION("MediaTek Module Timer driver");
"MediaTek Timer driver" is enough, "Module" gets misleading if this gets compiled
as built in platform driver (instead of built in timer_of).
> +MODULE_LICENSE("GPL v2");
> +#else
> TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
> TIMER_OF_DECLARE(mtk_mt6765, "mediatek,mt6765-timer", mtk_syst_init);
> +#endif
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Dan Carpenter @ 2023-04-19 8:06 UTC (permalink / raw)
To: Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Steven Price, Eric Auger,
Andre Przywara, 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>
---
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..4f5767fcaca5 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 -EINVAL;
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 PATCH v1 0/4] HiSilicon Performance Monitor Control Unit
From: Jie Zhan @ 2023-04-19 8:01 UTC (permalink / raw)
To: Jonathan Cameron
Cc: will, mark.rutland, mathieu.poirier, suzuki.poulose, mike.leach,
leo.yan, john.g.garry, james.clark, peterz, mingo, acme, corbet,
zhangshaokun, shenyang39, hejunhao3, yangyicong, prime.zeng,
suntao25, jiazhao4, linuxarm, linux-doc, linux-kernel,
linux-arm-kernel, linux-perf-users, Rob Herring
In-Reply-To: <20230317131131.00005817@Huawei.com>
On 17/03/2023 21:11, Jonathan Cameron wrote:
> On Mon, 27 Feb 2023 16:49:46 +0800
> Jie Zhan <zhanjie9@hisilicon.com> wrote:
>
>> Please can anyone have a look at this PMCU patchset and provide some
>> comments?
>>
>> It is much related to the ARM PMU.
>>
>> We are looking forward to the feedback.
>>
>> Any relevant comments/questions, with respect to software or hardware
>> design, use cases, coding, are welcome.
>>
>> Kind regards,
>>
>> Jie
>>
>>
>> On 06/02/2023 14:51, Jie Zhan wrote:
>>> HiSilicon Performance Monitor Control Unit (PMCU) is a device that offloads
>>> PMU accesses from CPUs, handling the configuration, event switching, and
>>> counter reading of core PMUs on Kunpeng SoC. It facilitates fine-grained
>>> and multi-PMU-event CPU profiling, in which scenario the current 'perf'
>>> scheme may lose events or drop sampling frequency. With PMCU, users can
>>> reliably obtain the data of up to 240 PMU events with the sample interval
>>> of events down to 1ms, while the software overhead of accessing PMUs, as
>>> well as its impact on target workloads, is reduced.
>>>
>>> This patchset contains the documentation, driver, and user perf tool
>>> support to enable using PMCU with the 'perf_event' framework.
>>>
>>> Here are two key questions requested for comments:
>>>
>>> - How do we make it compatible with arm_pmu drivers?
>>>
>>> Hardware-wise, PMCU uses the existing core PMUs, so PMUs can be accessed
>>> from CPU and PMCU simultaneously. The current hardware can't guarantee
>>> mutual exclusive accesses. Hence, scheduling arm_pmu and PMCU events at
>>> the same time may mess up the operation of PMUs, delivering incorrect
>>> data for both events, e.g. unexpected events or sample periods.
>>> Software-wise, we probably need to prevent the two types of events from
>>> running at the same time, but currently there isn't a clear solution.
Hi Jonathan,
Sorry for a late reply on this, but I have thought a bit more on this
issue recently.
> I've been thinking about this a bit and don't have a good answer yet.
>
> So some thoughts that might get some discussion going (some are here
> mostly to be shot down ;)
>
> 1. I suspect adding a hook into the specific pmu driver to reserve a counter is going
> to be controversial for this usecase. But maybe there is a more generic
> way... There are lock up detectors that use PMU counters and ensure the counters
> aren't also used for other purposes and that leads me to wonder if you can use
> https://elixir.bootlin.com/linux/latest/source/kernel/events/core.c#L12700
> perf_event_create_kernel_counter()
> to do the same as opening a counter from userspace but then not use it.
> I have no idea if this will work though or if enabling the event would be necessary
> to prevent it being used elsewhere.
KVM is actually doing a similar thing. KVM inserts a call in
armpmu_register() to save
a reference to struct arm_pmu, so as to get some information of arm_pmu,
e.g. its pmu
type. With the pmu type, it can issue arm_pmu events through
perf_event_create_kernel_counter().
Now we can make a general interface of this (supposed to be read-only),
enabling other
kernel code to get the data of arm_pmu, not just for kvm.
In addition, PMCU needs to occupy certain counters, while the arm_pmu
driver currently
gets the first free counter it finds in the counter bitmap (see
armv8pmu_get_event_idx()).
Thus, we may have to add a mechanism to optionally specify a counter
index that an event
wants to use. Adding a config field and adapting
armv8pmu_get_event_idx() should work.
A more tricky work would be preventing the "occupying" events from being
scheduled out.
I don't think this is a friendly action, and the perf_event framework
doesn't seem to
support so (even if we add the "pinned" attribute, the event would also
be switched out
when there comes another "pinned" event). However, any "occupying"
events being scheduled
out should cause PMCU to stop, and I think this would undermine the
advantage of PMCU.
> 2. It might be possible to reuse any of the infrastructure that exists
> for userspace PMU counter access or maybe Rob Herring (+CC) has a suggestion based on
> his work on that feature.
>
> 3. It's not nice, but maybe could enforce this constraint just in userspace?
> We'd have to make sure that both drivers didn't do anything beyond not working
> correctly if the other driver is messing with the hardware.
I actually think this is fine? So far, we haven't identified or found
any problem from
running PMCU and ARM_PMU simultaneously beyond getting wrong readings.
PMCU is designed
for system administrative use only. PMCU can also use a subset of PMU
counters with higher
indices, and the reset of counters with lower indices can still be
exposed to EL0 or EL1.
Thus, this approach should also work, providing that: a) EL0 or EL1 can
only access a subset
of counters with the lower indices, and b) system administrative
programs don't use ARM_PMU
and PMCU at the same time, or don't do anything harmful when getting
abnormal PMU readings.
>
> 4. We can't do the nasty trick of providing a second driver that binds to the
> PMU hardware to prevent it being used because I think the main arm PMU
> driver has suppress_bind_attrs = true. Maybe we can make remove work?
> (original patch for this in 2018 added that line because of a crash on remove
> - not sure anyone looked at fixing the crash).
We still prefer to keep at least part of ARM PMU counters in service
while running PMCU
in some scenarios. Unbinding the ARM PMU driver would go against that.
Thanks!
Jie Zhan
>>> - Currently we reply on a sysfs file for users to input event numbers. Is
>>> there a better way to pass many events?
>>>
>>> The perf framework only allows three 64-bit config fields for custom PMU
>>> configs. Obviously, this can't satisfy our need for passing many events
>>> at a time. As an event number is 16-bit wide, the config fields can only
>>> take up to 12 events at a time, or up to 192 events even if we do a
>>> bitmap of events (and there are more than 192 available event numbers).
>>> Hence, the current design takes an array of event numbers from a sysfs
>>> file before starting profiling. However, this may go against the common
>>> way to schedule perf events through perf commands.
>>>
>>> Jie Zhan (4):
>>> docs: perf: Add documentation for HiSilicon PMCU
>>> drivers/perf: hisi: Add driver support for HiSilicon PMCU
>>> perf tool: Add HiSilicon PMCU data recording support
>>> perf tool: Add HiSilicon PMCU data decoding support
>>>
>>> Documentation/admin-guide/perf/hisi-pmcu.rst | 183 +++
>>> Documentation/admin-guide/perf/index.rst | 1 +
>>> drivers/perf/hisilicon/Kconfig | 15 +
>>> drivers/perf/hisilicon/Makefile | 1 +
>>> drivers/perf/hisilicon/hisi_pmcu.c | 1096 ++++++++++++++++++
>>> tools/perf/arch/arm/util/auxtrace.c | 61 +
>>> tools/perf/arch/arm64/util/Build | 2 +-
>>> tools/perf/arch/arm64/util/hisi-pmcu.c | 145 +++
>>> tools/perf/util/Build | 1 +
>>> tools/perf/util/auxtrace.c | 4 +
>>> tools/perf/util/auxtrace.h | 1 +
>>> tools/perf/util/hisi-pmcu.c | 305 +++++
>>> tools/perf/util/hisi-pmcu.h | 19 +
>>> 13 files changed, 1833 insertions(+), 1 deletion(-)
>>> create mode 100644 Documentation/admin-guide/perf/hisi-pmcu.rst
>>> create mode 100644 drivers/perf/hisilicon/hisi_pmcu.c
>>> create mode 100644 tools/perf/arch/arm64/util/hisi-pmcu.c
>>> create mode 100644 tools/perf/util/hisi-pmcu.c
>>> create mode 100644 tools/perf/util/hisi-pmcu.h
>>>
>>>
>>> base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
_______________________________________________
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 1/4] spi: s3c64xx: changed to PIO mode if there is no DMA
From: Krzysztof Kozlowski @ 2023-04-19 8:03 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419060639.38853-2-jaewon02.kim@samsung.com>
On 19/04/2023 08:06, Jaewon Kim wrote:
> Polling mode supported with qurik if there was no DMA in the SOC.
typo: quirk
You missed verb in your first part of sentence. I don't understand it.
> However, there are cased where we cannot or do not want to use DMA.
> To support this case, if DMA is not set, it is switched to polling mode.
>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> ---
> drivers/spi/spi-s3c64xx.c | 8 ++++++--
> include/linux/platform_data/spi-s3c64xx.h | 1 +
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 71d324ec9a70..273aa02322d9 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -19,7 +19,6 @@
> #include <linux/platform_data/spi-s3c64xx.h>
>
> #define MAX_SPI_PORTS 12
> -#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
> #define S3C64XX_SPI_QUIRK_CS_AUTO (1 << 1)
> #define AUTOSUSPEND_TIMEOUT 2000
>
> @@ -116,7 +115,7 @@
> #define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
>
> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
> -#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
> +#define is_polling(x) (x->cntrlr_info->polling)
>
> #define RXBUSY (1<<2)
> #define TXBUSY (1<<3)
> @@ -1067,6 +1066,11 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
> sci->num_cs = temp;
> }
>
> + if (!of_find_property(dev->of_node, "dmas", NULL)) {
> + dev_warn(dev, "cannot find DMA, changed to PIO mode\n");
You said it is desired option, so should not be a warning. I would make
it debug at most.
> + sci->polling = 1;
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 v2 0/4] Improves polling mode of s3c64xx driver
From: Krzysztof Kozlowski @ 2023-04-19 7:59 UTC (permalink / raw)
To: Jaewon Kim, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419060639.38853-1-jaewon02.kim@samsung.com>
On 19/04/2023 08:06, Jaewon Kim wrote:
> 1.
> s3cx64xx driver was supporting polling mode using quirk for SOC without DMA.
> However, in order to use PIO mode as an optional rather than a quirk, when DMA
> is not described, spi operates with pio mode rather than probe fail.
>
> 2.
> Fixed the problem of high CPU usage in PIO mode.
>
> 3.
> If the transfer data size is larger than 32-bit, IRQ base PIO mode used.
>
What changed in the patches? You need to provide changelog.
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
* [PATCH] arm64: delete dead code in this_cpu_set_vectors()
From: Dan Carpenter @ 2023-04-19 7:58 UTC (permalink / raw)
To: James Morse
Cc: Will Deacon, Kristina Martsenko, Mark Rutland, Mark Brown,
Ard Biesheuvel, Liu Song, D Scott Phillips, James Morse,
linux-arm-kernel, linux-kernel, kernel-janitors
The "slot" variable is an enum, and in this context it is an unsigned
int. So the type means it can never be negative and also we never pass
invalid data to this function. If something did pass invalid data then
this check would be insufficient protection.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
arch/arm64/kernel/proton-pack.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
index fca9cc6f5581..05f40c4e18fd 100644
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -966,9 +966,6 @@ static void this_cpu_set_vectors(enum arm64_bp_harden_el1_vectors slot)
{
const char *v = arm64_get_bp_hardening_vector(slot);
- if (slot < 0)
- return;
-
__this_cpu_write(this_cpu_vector, v);
/*
--
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: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
From: David Hildenbrand @ 2023-04-19 7:54 UTC (permalink / raw)
To: Vishal Moola
Cc: Andrew Morton, Matthew Wilcox, linux-mm, linux-arch,
linux-arm-kernel, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, sparclinux, linux-um, xen-devel, kvm
In-Reply-To: <CAOzc2pwpRhNoFbdzdzuvrqbZdf2OsrTvBGs40QCZJjA5fS_q1A@mail.gmail.com>
On 18.04.23 23:33, Vishal Moola wrote:
> On Tue, Apr 18, 2023 at 8:45 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 17.04.23 22:50, Vishal Moola (Oracle) wrote:
>>> s390 uses page->index to keep track of page tables for the guest address
>>> space. In an attempt to consolidate the usage of page fields in s390,
>>> replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap.
>>>
>>> This will help with the splitting of struct ptdesc from struct page, as
>>> well as allow s390 to use _pt_frag_refcount for fragmented page table
>>> tracking.
>>>
>>> Since page->_pt_s390_gaddr aliases with mapping, ensure its set to NULL
>>> before freeing the pages as well.
>>>
>>> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
>>> ---
>>
>> [...]
>>
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index 3fc9e680f174..2616d64c0e8c 100644
>>> --- a/include/linux/mm_types.h
>>> +++ b/include/linux/mm_types.h
>>> @@ -144,7 +144,7 @@ struct page {
>>> struct { /* Page table pages */
>>> unsigned long _pt_pad_1; /* compound_head */
>>> pgtable_t pmd_huge_pte; /* protected by page->ptl */
>>> - unsigned long _pt_pad_2; /* mapping */
>>> + unsigned long _pt_s390_gaddr; /* mapping */
>>> union {
>>> struct mm_struct *pt_mm; /* x86 pgds only */
>>> atomic_t pt_frag_refcount; /* powerpc */
>>
>> The confusing part is, that these gmap page tables are not ordinary
>> process page tables that we would ordinarily place into this section
>> here. That's why they are also not allocated/freed using the typical
>> page table constructor/destructor ...
>
> I initially thought the same, so I was quite confused when I saw
> __gmap_segment_gaddr was using pmd_pgtable_page().
>
> Although they are not ordinary process page tables, since we
> eventually want to move them out of struct page, I think shifting them
> to be in ptdescs, being a memory descriptor for page tables, makes
> the most sense.
Seeing utilities like tlb_remove_page_ptdesc() that don't really apply
to such page tables, I wonder if we should much rather treat such
shadow/auxiliary/... page tables (just like other architectures like
x86, arm, ... employ as well) as a distinct type.
And have ptdesc be the common type for all process page tables.
>
> Another option is to leave pmd_pgtable_page() as is just for this case.
> Or we can revert commit 7e25de77bc5ea which uses the function here
> then figure out where these gmap pages table pages will go later.
I'm always confused when reading gmap code, so let me have another look :)
The confusing part is that s390x shares the lowest level page tables
(PTE tables) between the process and gmap ("guest mapping", similar to
EPT on x86-64). It maps these process PTE tables (covering 1 MiB) into
gmap-specific PMD tables.
pmd_pgtable_page() should indeed always give us a gmap-specific
PMD-table. In fact, something allocated via gmap_alloc_table().
Decoupling both concepts sounds like a good idea.
--
Thanks,
David / dhildenb
_______________________________________________
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 4/5] arm64: dts: ti: k3-j784s4-main: Add DSS and DP-bridge node
From: Krzysztof Kozlowski @ 2023-04-19 7:51 UTC (permalink / raw)
To: Jayesh Choudhary, nm, vigneshr, afd
Cc: s-vadapalli, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, a-bhatia1
In-Reply-To: <20230419061710.290068-5-j-choudhary@ti.com>
On 19/04/2023 08:17, Jayesh Choudhary wrote:
> From: Rahul T R <r-ravikumar@ti.com>
>
> Add DSS and DP-bridge node for J784S4 SoC. DSS IP in J784S4 is
> same as DSS IP in J721E, so same compatible is being used.
> The DP is Cadence MHDP8546.
>
> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
> [j-choudhary@ti.com: move all k3-j784s4-main.dtsi changes together]
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 77 ++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 51aa476dedba..739741e93bc1 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -1373,4 +1373,81 @@ main_spi7: spi@2170000 {
> clocks = <&k3_clks 383 1>;
> status = "disabled";
> };
> +
> + mhdp: dp-bridge@a000000 {
> + compatible = "ti,j721e-mhdp8546";
> +
> + reg = <0x0 0xa000000 0x0 0x30a00>,
> + <0x0 0x4f40000 0x0 0x20>;
> + reg-names = "mhdptx", "j721e-intg";
> +
> + clocks = <&k3_clks 217 11>;
> +
> + interrupt-parent = <&gic500>;
> + interrupts = <GIC_SPI 614 IRQ_TYPE_LEVEL_HIGH>;
> +
> + power-domains = <&k3_pds 217 TI_SCI_PD_EXCLUSIVE>;
> +
> + status = "disabled";
> +
> + dp0_ports: ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + dss: dss@4a00000 {
> + compatible = "ti,j721e-dss";
> + reg =
> + <0x00 0x04a00000 0x00 0x10000>,
Fix indent/stray line break.
> + <0x00 0x04a10000 0x00 0x10000>,
> + <0x00 0x04b00000 0x00 0x10000>,
> + <0x00 0x04b10000 0x00 0x10000>,
> +
> + <0x00 0x04a20000 0x00 0x10000>,
> + <0x00 0x04a30000 0x00 0x10000>,
> + <0x00 0x04a50000 0x00 0x10000>,
> + <0x00 0x04a60000 0x00 0x10000>,
> +
> + <0x00 0x04a70000 0x00 0x10000>,
> + <0x00 0x04a90000 0x00 0x10000>,
> + <0x00 0x04ab0000 0x00 0x10000>,
> + <0x00 0x04ad0000 0x00 0x10000>,
> +
> + <0x00 0x04a80000 0x00 0x10000>,
> + <0x00 0x04aa0000 0x00 0x10000>,
> + <0x00 0x04ac0000 0x00 0x10000>,
> + <0x00 0x04ae0000 0x00 0x10000>,
> + <0x00 0x04af0000 0x00 0x10000>;
> +
> + reg-names = "common_m", "common_s0",
> + "common_s1", "common_s2",
> + "vidl1", "vidl2","vid1","vid2",
> + "ovr1", "ovr2", "ovr3", "ovr4",
> + "vp1", "vp2", "vp3", "vp4",
> + "wb";
> +
> + clocks = <&k3_clks 218 0>,
Broken indentation.
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 v3 2/5] arm64: dts: ti: k3-j784s4: Add Main CPSW2G node
From: Krzysztof Kozlowski @ 2023-04-19 7:50 UTC (permalink / raw)
To: Jayesh Choudhary, nm, vigneshr, afd
Cc: s-vadapalli, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, a-bhatia1
In-Reply-To: <20230419061710.290068-3-j-choudhary@ti.com>
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.
> + 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?
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
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