Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] KVM: arm64: Ensure CPU PMU probes before pKVM host de-privilege
From: Will Deacon @ 2023-04-20 12:33 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: kvmarm, Will Deacon, Oliver Upton, Fuad Tabba, Marc Zyngier

Although pKVM supports CPU PMU emulation for non-protected guests since
722625c6f4c5 ("KVM: arm64: Reenable pmu in Protected Mode"), this relies
on the PMU driver probing before the host has de-privileged so that the
'kvm_arm_pmu_available' static key can still be enabled by patching the
hypervisor text.

As it happens, both of these events hang off device_initcall() but the
PMU consistently won the race until 7755cec63ade ("arm64: perf: Move
PMUv3 driver to drivers/perf"). Since then, the host will fail to boot
when pKVM is enabled:

  | hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available
  | kvm [1]: nVHE hyp BUG at: [<ffff8000090366e0>] __kvm_nvhe_handle_host_mem_abort+0x270/0x284!
  | kvm [1]: Cannot dump pKVM nVHE stacktrace: !CONFIG_PROTECTED_NVHE_STACKTRACE
  | kvm [1]: Hyp Offset: 0xfffea41fbdf70000
  | Kernel panic - not syncing: HYP panic:
  | PS:a00003c9 PC:0000dbe04b0c66e0 ESR:00000000f2000800
  | FAR:fffffbfffddfcf00 HPFAR:00000000010b0bf0 PAR:0000000000000000
  | VCPU:0000000000000000
  | CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7-00083-g0bce6746d154 #1
  | Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  | Call trace:
  |  dump_backtrace+0xec/0x108
  |  show_stack+0x18/0x2c
  |  dump_stack_lvl+0x50/0x68
  |  dump_stack+0x18/0x24
  |  panic+0x13c/0x33c
  |  nvhe_hyp_panic_handler+0x10c/0x190
  |  aarch64_insn_patch_text_nosync+0x64/0xc8
  |  arch_jump_label_transform+0x4c/0x5c
  |  __jump_label_update+0x84/0xfc
  |  jump_label_update+0x100/0x134
  |  static_key_enable_cpuslocked+0x68/0xac
  |  static_key_enable+0x20/0x34
  |  kvm_host_pmu_init+0x88/0xa4
  |  armpmu_register+0xf0/0xf4
  |  arm_pmu_acpi_probe+0x2ec/0x368
  |  armv8_pmu_driver_init+0x38/0x44
  |  do_one_initcall+0xcc/0x240

Fix the race properly by deferring the de-privilege step to
device_initcall_sync(). This will also be needed in future when probing
IOMMU devices and allows us to separate the pKVM de-privilege logic from
the core hypervisor initialisation path.

Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Fixes: 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf")
Signed-off-by: Will Deacon <will@kernel.org>
---

Marc, Oliver -- in practice, this issue only crops with the patches
moving the CPU PMU driver out into drivers/perf/ and so the arm64
for-next/core branch is broken. Please can I queue this in the arm64
tree for 6.4 with your Ack? Thanks.

 arch/arm64/kvm/arm.c  | 45 -----------------------------------------
 arch/arm64/kvm/pkvm.c | 47 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 45 deletions(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 3bd732eaf087..890f730bc3ab 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -16,7 +16,6 @@
 #include <linux/fs.h>
 #include <linux/mman.h>
 #include <linux/sched.h>
-#include <linux/kmemleak.h>
 #include <linux/kvm.h>
 #include <linux/kvm_irqfd.h>
 #include <linux/irqbypass.h>
@@ -46,7 +45,6 @@
 #include <kvm/arm_psci.h>
 
 static enum kvm_mode kvm_mode = KVM_MODE_DEFAULT;
-DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
 
 DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
 
@@ -2105,41 +2103,6 @@ static int __init init_hyp_mode(void)
 	return err;
 }
 
-static void __init _kvm_host_prot_finalize(void *arg)
-{
-	int *err = arg;
-
-	if (WARN_ON(kvm_call_hyp_nvhe(__pkvm_prot_finalize)))
-		WRITE_ONCE(*err, -EINVAL);
-}
-
-static int __init pkvm_drop_host_privileges(void)
-{
-	int ret = 0;
-
-	/*
-	 * Flip the static key upfront as that may no longer be possible
-	 * once the host stage 2 is installed.
-	 */
-	static_branch_enable(&kvm_protected_mode_initialized);
-	on_each_cpu(_kvm_host_prot_finalize, &ret, 1);
-	return ret;
-}
-
-static int __init finalize_hyp_mode(void)
-{
-	if (!is_protected_kvm_enabled())
-		return 0;
-
-	/*
-	 * Exclude HYP sections from kmemleak so that they don't get peeked
-	 * at, which would end badly once inaccessible.
-	 */
-	kmemleak_free_part(__hyp_bss_start, __hyp_bss_end - __hyp_bss_start);
-	kmemleak_free_part_phys(hyp_mem_base, hyp_mem_size);
-	return pkvm_drop_host_privileges();
-}
-
 struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr)
 {
 	struct kvm_vcpu *vcpu;
@@ -2257,14 +2220,6 @@ static __init int kvm_arm_init(void)
 	if (err)
 		goto out_hyp;
 
-	if (!in_hyp_mode) {
-		err = finalize_hyp_mode();
-		if (err) {
-			kvm_err("Failed to finalize Hyp protection\n");
-			goto out_subs;
-		}
-	}
-
 	if (is_protected_kvm_enabled()) {
 		kvm_info("Protected nVHE mode initialized successfully\n");
 	} else if (in_hyp_mode) {
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index cf56958b1492..6e9ece1ebbe7 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -4,6 +4,8 @@
  * Author: Quentin Perret <qperret@google.com>
  */
 
+#include <linux/init.h>
+#include <linux/kmemleak.h>
 #include <linux/kvm_host.h>
 #include <linux/memblock.h>
 #include <linux/mutex.h>
@@ -13,6 +15,8 @@
 
 #include "hyp_constants.h"
 
+DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
 static struct memblock_region *hyp_memory = kvm_nvhe_sym(hyp_memory);
 static unsigned int *hyp_memblock_nr_ptr = &kvm_nvhe_sym(hyp_memblock_nr);
 
@@ -213,3 +217,46 @@ int pkvm_init_host_vm(struct kvm *host_kvm)
 	mutex_init(&host_kvm->lock);
 	return 0;
 }
+
+static void __init _kvm_host_prot_finalize(void *arg)
+{
+	int *err = arg;
+
+	if (WARN_ON(kvm_call_hyp_nvhe(__pkvm_prot_finalize)))
+		WRITE_ONCE(*err, -EINVAL);
+}
+
+static int __init pkvm_drop_host_privileges(void)
+{
+	int ret = 0;
+
+	/*
+	 * Flip the static key upfront as that may no longer be possible
+	 * once the host stage 2 is installed.
+	 */
+	static_branch_enable(&kvm_protected_mode_initialized);
+	on_each_cpu(_kvm_host_prot_finalize, &ret, 1);
+	return ret;
+}
+
+static int __init finalize_pkvm(void)
+{
+	int ret;
+
+	if (!is_protected_kvm_enabled())
+		return 0;
+
+	/*
+	 * Exclude HYP sections from kmemleak so that they don't get peeked
+	 * at, which would end badly once inaccessible.
+	 */
+	kmemleak_free_part(__hyp_bss_start, __hyp_bss_end - __hyp_bss_start);
+	kmemleak_free_part_phys(hyp_mem_base, hyp_mem_size);
+
+	ret = pkvm_drop_host_privileges();
+	if (ret)
+		pr_err("Failed to finalize Hyp protection: %d\n", ret);
+
+	return ret;
+}
+device_initcall_sync(finalize_pkvm);
-- 
2.40.0.634.g4ca3ef3211-goog


_______________________________________________
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] perf cs-etm: Add support for coresight trace for any range of CPUs
From: James Clark @ 2023-04-20 12:30 UTC (permalink / raw)
  To: Ganapatrao Kulkarni
  Cc: mathieu.poirier, acme, darren, scott, scclevenger, linux-kernel,
	coresight, linux-arm-kernel, mike.leach, suzuki.poulose
In-Reply-To: <84eb3363-2ef8-d3f1-4613-805959dbf334@os.amperecomputing.com>



On 20/04/2023 12:47, Ganapatrao Kulkarni wrote:
> 
> Hi James,
> 
> On 20-04-2023 03:13 pm, James Clark wrote:
>>
>>
>> On 19/04/2023 18:21, Ganapatrao Kulkarni wrote:
>>> The current implementation supports coresight trace for a range of
>>> CPUs, if the first CPU is CPU0.
>>>
>>> Adding changes to enable coresight trace for any range of CPUs by
>>> decoding the first CPU also from the header.
>>> Later, first CPU id is used instead of CPU0 across the decoder
>>> functions.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
>>> ---
>>>   .../perf/util/cs-etm-decoder/cs-etm-decoder.c |  4 +-
>>>   .../perf/util/cs-etm-decoder/cs-etm-decoder.h |  3 +-
>>>   tools/perf/util/cs-etm.c                      | 62 ++++++++++++-------
>>>   3 files changed, 42 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>>> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>>> index 82a27ab90c8b..41ab299b643b 100644
>>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>>> @@ -724,7 +724,7 @@ cs_etm_decoder__create_etm_decoder(struct
>>> cs_etm_decoder_params *d_params,
>>>   }
>>>     struct cs_etm_decoder *
>>> -cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params
>>> *d_params,
>>> +cs_etm_decoder__new(int first_decoder, int decoders, struct
>>> cs_etm_decoder_params *d_params,
>>>               struct cs_etm_trace_params t_params[])
>>>   {
>>>       struct cs_etm_decoder *decoder;
>>> @@ -769,7 +769,7 @@ cs_etm_decoder__new(int decoders, struct
>>> cs_etm_decoder_params *d_params,
>>>       /* init raw frame logging if required */
>>>       cs_etm_decoder__init_raw_frame_logging(d_params, decoder);
>>>   -    for (i = 0; i < decoders; i++) {
>>> +    for (i = first_decoder; i < decoders; i++) {
>>>           ret = cs_etm_decoder__create_etm_decoder(d_params,
>>>                                &t_params[i],
>>>                                decoder);
>>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>>> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>>> index 92a855fbe5b8..b06193fc75b4 100644
>>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>>> @@ -90,7 +90,8 @@ int cs_etm_decoder__process_data_block(struct
>>> cs_etm_decoder *decoder,
>>>                          size_t len, size_t *consumed);
>>>     struct cs_etm_decoder *
>>> -cs_etm_decoder__new(int num_cpu,
>>> +cs_etm_decoder__new(int first_decoder,
>>> +            int decoders,
>>>               struct cs_etm_decoder_params *d_params,
>>>               struct cs_etm_trace_params t_params[]);
>>>   diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>>> index 94e2d02009eb..2619513ae088 100644
>>> --- a/tools/perf/util/cs-etm.c
>>> +++ b/tools/perf/util/cs-etm.c
>>> @@ -55,6 +55,8 @@ struct cs_etm_auxtrace {
>>>       u8 has_virtual_ts; /* Virtual/Kernel timestamps in the trace. */
>>>         int num_cpu;
>>> +    int first_cpu;
>>> +    int last_cpu;
>>>       u64 latest_kernel_timestamp;
>>>       u32 auxtrace_type;
>>>       u64 branches_sample_type;
>>> @@ -638,14 +640,13 @@ static void cs_etm__set_trace_param_ete(struct
>>> cs_etm_trace_params *t_params,
>>>   }
>>>     static int cs_etm__init_trace_params(struct cs_etm_trace_params
>>> *t_params,
>>> -                     struct cs_etm_auxtrace *etm,
>>> -                     int decoders)
>>> +                     struct cs_etm_auxtrace *etm)
>>>   {
>>>       int i;
>>>       u32 etmidr;
>>>       u64 architecture;
>>>   -    for (i = 0; i < decoders; i++) {
>>> +    for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>>           architecture = etm->metadata[i][CS_ETM_MAGIC];
>>>             switch (architecture) {
>>> @@ -817,7 +818,7 @@ static void cs_etm__free(struct perf_session
>>> *session)
>>>       /* Then the RB tree itself */
>>>       intlist__delete(traceid_list);
>>>   -    for (i = 0; i < aux->num_cpu; i++)
>>> +    for (i = aux->first_cpu; i < aux->last_cpu; i++)
>>>           zfree(&aux->metadata[i]);
>>>         thread__zput(aux->unknown_thread);
>>> @@ -921,7 +922,8 @@ static struct cs_etm_queue
>>> *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>>        * Each queue can only contain data from one CPU when
>>> unformatted, so only one decoder is
>>>        * needed.
>>>        */
>>> -    int decoders = formatted ? etm->num_cpu : 1;
>>> +    int first_decoder = formatted ? etm->first_cpu : 0;
>>> +    int decoders = first_decoder + (formatted ? etm->num_cpu : 1);
>>>         etmq = zalloc(sizeof(*etmq));
>>>       if (!etmq)
>>> @@ -937,7 +939,7 @@ static struct cs_etm_queue
>>> *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>>       if (!t_params)
>>>           goto out_free;
>>>   -    if (cs_etm__init_trace_params(t_params, etm, decoders))
>>> +    if (cs_etm__init_trace_params(t_params, etm))
>>>           goto out_free;
>>>         /* Set decoder parameters to decode trace packets */
>>> @@ -947,8 +949,7 @@ static struct cs_etm_queue
>>> *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>>                       formatted))
>>>           goto out_free;
>>>   -    etmq->decoder = cs_etm_decoder__new(decoders, &d_params,
>>> -                        t_params);
>>> +    etmq->decoder = cs_etm_decoder__new(first_decoder, decoders,
>>> &d_params, t_params);
>>>         if (!etmq->decoder)
>>>           goto out_free;
>>> @@ -2959,11 +2960,11 @@ static int cs_etm__queue_aux_records(struct
>>> perf_session *session)
>>>    * Loop through the ETMs and complain if we find at least one where
>>> ts_source != 1 (virtual
>>>    * timestamps).
>>>    */
>>> -static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
>>> +static bool cs_etm__has_virtual_ts(u64 **metadata, struct
>>> cs_etm_auxtrace *etm)
>>>   {
>>>       int j;
>>>   -    for (j = 0; j < num_cpu; j++) {
>>> +    for (j = etm->first_cpu; j < etm->last_cpu; j++) {
>>>           switch (metadata[j][CS_ETM_MAGIC]) {
>>>           case __perf_cs_etmv4_magic:
>>>               if (HAS_PARAM(j, ETMV4, TS_SOURCE) ||
>>> metadata[j][CS_ETMV4_TS_SOURCE] != 1)
>>> @@ -2982,13 +2983,14 @@ static bool cs_etm__has_virtual_ts(u64
>>> **metadata, int num_cpu)
>>>   }
>>>     /* map trace ids to correct metadata block, from information in
>>> metadata */
>>> -static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
>>> +static int cs_etm__map_trace_ids_metadata(struct cs_etm_auxtrace *etm)
>>>   {
>>>       u64 cs_etm_magic;
>>> +    u64 **metadata = etm->metadata;
>>>       u8 trace_chan_id;
>>>       int i, err;
>>>   -    for (i = 0; i < num_cpu; i++) {
>>> +    for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>>           cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>>>           switch (cs_etm_magic) {
>>>           case __perf_cs_etmv3_magic:
>>> @@ -3015,12 +3017,13 @@ static int cs_etm__map_trace_ids_metadata(int
>>> num_cpu, u64 **metadata)
>>>    * If we found AUX_HW_ID packets, then set any metadata marked as
>>> unused to the
>>>    * unused value to reduce the number of unneeded decoders created.
>>>    */
>>> -static int cs_etm__clear_unused_trace_ids_metadata(int num_cpu, u64
>>> **metadata)
>>> +static int cs_etm__clear_unused_trace_ids_metadata(struct
>>> cs_etm_auxtrace *etm)
>>>   {
>>>       u64 cs_etm_magic;
>>> +    u64 **metadata = etm->metadata;
>>>       int i;
>>>   -    for (i = 0; i < num_cpu; i++) {
>>> +    for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>>           cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>>>           switch (cs_etm_magic) {
>>>           case __perf_cs_etmv3_magic:
>>> @@ -3049,7 +3052,7 @@ int cs_etm__process_auxtrace_info_full(union
>>> perf_event *event,
>>>       int event_header_size = sizeof(struct perf_event_header);
>>>       int total_size = auxtrace_info->header.size;
>>>       int priv_size = 0;
>>> -    int num_cpu;
>>> +    int num_cpu, first_cpu = 0, last_cpu;
>>>       int err = 0;
>>>       int aux_hw_id_found;
>>>       int i, j;
>>> @@ -3068,22 +3071,31 @@ int cs_etm__process_auxtrace_info_full(union
>>> perf_event *event,
>>>       /* First the global part */
>>>       ptr = (u64 *) auxtrace_info->priv;
>>>       num_cpu = ptr[CS_PMU_TYPE_CPUS] & 0xffffffff;
>>> -    metadata = zalloc(sizeof(*metadata) * num_cpu);
>>> +
>>> +    /* Start parsing after the common part of the header */
>>> +    i = CS_HEADER_VERSION_MAX;
>>> +
>>> +    /*Get CPU id of first event */
>>> +    first_cpu = ptr[i + CS_ETM_CPU];
>>> +    last_cpu = first_cpu + num_cpu;
>>> +
>>> +    if (first_cpu > cpu__max_cpu().cpu ||
>>> +            last_cpu > cpu__max_cpu().cpu)
>>> +        return -EINVAL;
>>> +
>>> +    metadata = zalloc(sizeof(*metadata) * last_cpu);
>>
>> Hi Ganapatrao,
>>
>> I think I see what the problem is, but I'm wondering if a better fix
>> would be to further decouple the CPU ID from the index in the array.
>>
>> With your change it's not clear what happens with sparse recordings, for
>> example 'perf record -e cs_etm// -C 1,3,5'. And it seems like there is
> 
> This patch fixes for any range of CPUs.
> Record with sparse list of CPUs will not work with current code still.
> 

Is there a major issue that means sparse can't be done? I'm thinking it
would be best to fix both issues with one change while we understand
this part rather than a half fix that might have do be completely
re-understood and re-done later anyway. Unless there is some big blocker
but I can't see it?

>> some wastage in the zalloc here for example if only CPU 256 is traced
>> then we'd still make 256 decoders but 255 of them would be unused?
>>
>> I tried to test sparse recordings, but your change doesn't apply to the
>> latest coresight/next branch. I did notice that 'perf report -D' doesn't
>> work with them on coresight/next (it just quits), but I couldn't see if
>> that's fixed with your change.
> 
> My patch is rebased on 6.3-RC7 codebase with Mike's 3 perf patches
> related to dynamic id [1] support(queued for 6.4).
> 
> "perf report -D" works for me.

I was referring to sparse CPU lists, which I think you mentioned above
doesn't work even with this patch.

> 
> [1] https://www.spinics.net/lists/linux-perf-users/msg27452.html
> 

It should be based on the next branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git

>>
>> Would a better fix not be to keep the metadata loops from 0-N and
>> instead save the CPU ID in cs_etm_decoder_params or the decoder. That
>> way it would support both sparse and not starting from 0 cases? I think
> 
> Yep, I though this initially, it got complicated due to for more
> for-loops. I will try again and post V2.
> 

I can't imagine it would need any extra for loops off the top of my
head. Just saving the CPU ID in a few structs and using it wherever it's
needed instead of the loop index. I imagine most of the loops would
actually stay the same rather than be changed like you have in V1.

>> the code would be better if it's worded like "i < recorded_cpus" rather
>> than "i < cpu" to make it clear that i isn't actually the CPU ID it's
>> just an index.
> 
> Yes, makes sense to call it "recorded_cpus".
> 
>>
>> Also a new test for this scenario would probably be a good idea.
>>
>> Thanks
>> James
>>
> Thanks,
> Ganapat

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 2/3] ARM: dts: Add nvmem node for BCM2711 bootloader public key
From: Ivan T. Ivanov @ 2023-04-20 12:29 UTC (permalink / raw)
  To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
	linux-rpi-kernel, linux-arm-kernel, devicetree, Tim Gover,
	Ivan T . Ivanov
In-Reply-To: <20230420122924.37997-1-iivanov@suse.de>

From: Tim Gover <tim.gover@raspberrypi.com>

Make a copy of the bootloader secure-boot public key available to the OS
via an nvmem node. The placement information is populated by the
Raspberry Pi firmware[1] if a public key is present in the BCM2711
bootloader EEPROM.

[1] https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes

Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
[iivanov] Added link to documentation.
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 arch/arm/boot/dts/bcm2711-rpi.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi.dtsi b/arch/arm/boot/dts/bcm2711-rpi.dtsi
index 98817a6675b9..e30fbe84f9c3 100644
--- a/arch/arm/boot/dts/bcm2711-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2711-rpi.dtsi
@@ -15,6 +15,7 @@ aliases {
 		ethernet0 = &genet;
 		pcie0 = &pcie0;
 		blconfig = &blconfig;
+		blpubkey = &blpubkey;
 	};
 };
 
@@ -67,6 +68,19 @@ blconfig: nvram@0 {
 		no-map;
 		status = "disabled";
 	};
+
+	/*
+	 * RPi4 will copy the binary public key blob (if present) from the bootloader
+	 * into memory for use by the OS.
+	 */
+	blpubkey: nvram@1 {
+		compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x0 0x0 0x0>;
+		no-map;
+		status = "disabled";
+	};
 };
 
 &v3d {
-- 
2.35.3


_______________________________________________
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 v3 0/3] Add nvmem node for BCM2711 bootloader public key
From: Ivan T. Ivanov @ 2023-04-20 12:29 UTC (permalink / raw)
  To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
	linux-rpi-kernel, linux-arm-kernel, devicetree, Ivan T. Ivanov

While debugging kernel stack trace from bug report[1], on openSUSE
Tumbleweed, which uses vendor devicetree, I have found that rmem driver
lack support for multiple rmem devices.

Following patches add new devicetree node, its documentation and
support for it in rmem driver.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1206846

--
[    9.831285] sysfs: cannot create duplicate filename '/bus/nvmem/devices/rmem0'
[    9.831304] CPU: 3 PID: 467 Comm: (udev-worker) Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed a4aeb3a90c0f23041a8a7944b12739b07585f009
[    9.831326] Hardware name: raspberrypi rpi/rpi, BIOS 2023.01 01/01/2023
[    9.831335] Call trace:
[    9.831343]  dump_backtrace+0xe4/0x140
[    9.831366]  show_stack+0x20/0x30
[    9.831379]  dump_stack_lvl+0x64/0x80
[    9.831398]  dump_stack+0x18/0x34
[    9.831410]  sysfs_warn_dup+0x6c/0x90
[    9.831424]  sysfs_do_create_link_sd+0xf8/0x100
[    9.831437]  sysfs_create_link+0x28/0x50
[    9.831449]  bus_add_device+0x70/0x190
[    9.831468]  device_add+0x3e8/0x84c
[    9.831481]  nvmem_register+0x85c/0x9f0
[    9.831500]  devm_nvmem_register+0x24/0x70
[    9.831517]  rmem_probe+0xa0/0xf4 [nvmem_rmem 649243b01e5e28ee94e4dd53bd13b6ececa836f8]
[    9.831555]  platform_probe+0x70/0xd0
[    9.831566]  really_probe+0xc8/0x3e4
[    9.831582]  __driver_probe_device+0x84/0x190
[    9.831598]  driver_probe_device+0x44/0x11c
[    9.831613]  __driver_attach+0xf8/0x200
[    9.831629]  bus_for_each_dev+0x78/0xd0
[    9.831643]  driver_attach+0x2c/0x40
[    9.831657]  bus_add_driver+0x188/0x250
[    9.831672]  driver_register+0x80/0x13c
[    9.831688]  __platform_driver_register+0x30/0x40
[    9.831699]  rmem_driver_init+0x28/0x1000 [nvmem_rmem 649243b01e5e28ee94e4dd53bd13b6ececa836f8]
[    9.831727]  do_one_initcall+0x48/0x2bc
[    9.831740]  do_init_module+0x50/0x1f0
[    9.831753]  load_module+0x1e54/0x2250
[    9.831763]  __do_sys_init_module+0x2ac/0x2f0
[    9.831774]  __arm64_sys_init_module+0x24/0x30
[    9.831785]  invoke_syscall+0x78/0x100
[    9.831803]  el0_svc_common.constprop.0+0x15c/0x180
[    9.831820]  do_el0_svc+0x40/0xb0
[    9.831836]  el0_svc+0x34/0x134
[    9.831850]  el0t_64_sync_handler+0x114/0x120
[    9.831865]  el0t_64_sync+0x1a4/0x1a8
[    9.831956] rmem: probe of 3ef62ce0.nvram failed with error -17

--
Changes since v2
https://lore.kernel.org/all/20230413085206.149730-1-iivanov@suse.de/

 - Add devicetree bindings documentation patch

--
Changes since v1
https://lore.kernel.org/all/20230411135035.106725-1-iivanov@suse.de/

I dig into Raspberry Github repository and found original patches
from Tim and Phil which add new region and fix rmem driver.

 - Use NVMEM_DEVID_AUTO instead making region name unique from
   the driver itself.
 - Add devicetree node for BCM2711 bootloader public key.
--

Ivan T. Ivanov (1):
  dt-bindings: nvmem: rmem: Add raspberrypi,bootloader-public-key

Phil Elwell (1):
  nvmem: rmem: Use NVMEM_DEVID_AUTO

Tim Gover (1):
  ARM: dts: Add nvmem node for BCM2711 bootloader public key

 Documentation/devicetree/bindings/nvmem/rmem.yaml |  1 +
 arch/arm/boot/dts/bcm2711-rpi.dtsi                | 14 ++++++++++++++
 drivers/nvmem/rmem.c                              |  1 +
 3 files changed, 16 insertions(+)

-- 
2.35.3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 1/3] dt-bindings: nvmem: rmem: Add raspberrypi,bootloader-public-key
From: Ivan T. Ivanov @ 2023-04-20 12:29 UTC (permalink / raw)
  To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
	linux-rpi-kernel, linux-arm-kernel, devicetree, Ivan T. Ivanov
In-Reply-To: <20230420122924.37997-1-iivanov@suse.de>

On RPi4 the bootloader[1] will copy the binary public key blob
(if present) into memory location specified by this node, for
use by the OS.

[1] https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 Documentation/devicetree/bindings/nvmem/rmem.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml
index a4a755dcfc43..566eff3d1061 100644
--- a/Documentation/devicetree/bindings/nvmem/rmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml
@@ -17,6 +17,7 @@ properties:
     items:
       - enum:
           - raspberrypi,bootloader-config
+          - raspberrypi,bootloader-public-key
       - const: nvmem-rmem
 
   reg:
-- 
2.35.3


_______________________________________________
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 v3 3/3] nvmem: rmem: Use NVMEM_DEVID_AUTO
From: Ivan T. Ivanov @ 2023-04-20 12:29 UTC (permalink / raw)
  To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
	linux-rpi-kernel, linux-arm-kernel, devicetree, Phil Elwell,
	Ivan T . Ivanov
In-Reply-To: <20230420122924.37997-1-iivanov@suse.de>

From: Phil Elwell <phil@raspberrypi.com>

It is reasonable to declare multiple nvmem blocks. Unless a unique 'id'
is passed in for each block there may be name clashes.

Avoid this by using the magic token NVMEM_DEVID_AUTO.

Fixes: 5a3fa75a4d9cb ("nvmem: Add driver to expose reserved memory as nvmem")

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 drivers/nvmem/rmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/rmem.c b/drivers/nvmem/rmem.c
index 80cb187f1481..752d0bf4445e 100644
--- a/drivers/nvmem/rmem.c
+++ b/drivers/nvmem/rmem.c
@@ -71,6 +71,7 @@ static int rmem_probe(struct platform_device *pdev)
 	config.dev = dev;
 	config.priv = priv;
 	config.name = "rmem";
+	config.id = NVMEM_DEVID_AUTO;
 	config.size = mem->size;
 	config.reg_read = rmem_read;
 
-- 
2.35.3


_______________________________________________
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: next: arm: drivers/net/phy/phy_device.o: in function `phy_probe': drivers/net/phy/phy_device.c:3053: undefined reference to
From: Arnd Bergmann @ 2023-04-20 12:21 UTC (permalink / raw)
  To: Naresh Kamboju, Netdev, linux-next, Linux ARM, lkft-triage, llvm
  Cc: Russell King, David S . Miller, Ard Biesheuvel, Anders Roxell,
	Eric Dumazet, Paolo Abeni, Jakub Kicinski
In-Reply-To: <CA+G9fYuMEEzTUyF-pCVuZYd+BU53_8MRyXoOmbYEo1O1v=9teg@mail.gmail.com>

On Thu, Apr 20, 2023, at 12:51, Naresh Kamboju wrote:
> [ Please ignore this email if it is already reported ]
>
> Following build failures noticed on Linux next-20230419.
>
> Regressions found on arm:
>  - build/clang-16-omap2plus_defconfig
>  - build/clang-16-davinci_all_defconfig
>  - build/gcc-8-davinci_all_defconfig
>  - build/clang-nightly-omap2plus_defconfig
>  - build/gcc-12-omap2plus_defconfig
>  - build/gcc-12-davinci_all_defconfig
>  - build/clang-nightly-davinci_all_defconfig
>  - build/gcc-8-omap2plus_defconfig
>
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> Build log:
> ------------
>
>  arm-linux-gnueabihf-ld: drivers/net/phy/phy_device.o: in function `phy_probe':
> drivers/net/phy/phy_device.c:3053: undefined reference to
> `devm_led_classdev_register_ext'

I sent this patch now:

https://lore.kernel.org/all/20230420084624.3005701-1-arnd@kernel.org/

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH 1/2] arm64: amlogic: add new ARCH_AMLIPC for IPC SoC
From: Neil Armstrong @ 2023-04-20 12:18 UTC (permalink / raw)
  To: Kelvin Zhang, Dmitry Rokosov
  Cc: =Xianwei Zhao, linux-arm-kernel, linux-kernel, linux-amlogic,
	devicetree, Catalin Marinas, Will Deacon, Kevin Hilman,
	Rob Herring, Krzysztof Kozlowski
In-Reply-To: <1c7322c9-8d2d-1cd1-95dc-dd9ec861981f@amlogic.com>

Hi Kelvin,

On 20/04/2023 10:43, Kelvin Zhang wrote:
> On 2023/4/20 01:00, Dmitry Rokosov wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Wed, Apr 19, 2023 at 06:25:07PM +0200, Neil Armstrong wrote:
>>> On 19/04/2023 18:04, Dmitry Rokosov wrote:
>>>> On Wed, Apr 19, 2023 at 03:43:12PM +0200, Neil Armstrong wrote:
>>>>> On 19/04/2023 15:14, Dmitry Rokosov wrote:
>>>>>> On Wed, Apr 19, 2023 at 03:38:33PM +0800, =Xianwei Zhao wrote:
>>>>>>> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>>>>>
>>>>>>> The C series SoCs are designed for smart IP camera
>>>>>>> applications, which does not belong to Meson series.
>>>>>>> So, Add ARCH_AMLIPC for the new series.
>>>>>>>
>>>>>>> There are now multiple amlogic SoC seies supported, so group them under
>>>>>>> their own menu. we can easily add new platforms there in the future.
>>>>>>> Introduce ARCH_AMLOGIC to cover all Amlogic SoC series.
>>>>>>>
>>>>>>> No functional changes introduced.
>>>>>>>
>>>>>>> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>>>>> ---
>>>>>>>     arch/arm64/Kconfig.platforms | 12 ++++++++++++
>>>>>>>     arch/arm64/configs/defconfig |  2 ++
>>>>>>>     2 files changed, 14 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>>>> index 89a0b13b058d..bfbc817eef8f 100644
>>>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>>>> @@ -162,12 +162,24 @@ config ARCH_MEDIATEK
>>>>>>>          This enables support for MediaTek MT27xx, MT65xx, MT76xx
>>>>>>>          & MT81xx ARMv8 SoCs
>>>>>>> +menuconfig ARCH_AMLOGIC
>>>>>>> +     bool "NXP SoC support"
>>>>>> NXP? Did you mean "Amlogic"?
>>>>>>
>>>>>>> +
>>>>>>> +if ARCH_AMLOGIC
>>>>>>> +
>>>>>>>     config ARCH_MESON
>>>>>>>        bool "Amlogic Platforms"
>>>>>>>        help
>>>>>>>          This enables support for the arm64 based Amlogic SoCs
>>>>>>>          such as the s905, S905X/D, S912, A113X/D or S905X/D2
>>>>>>> +config ARCH_AMLIPC
>>>>>> Do we really need a different ARCH for Amlogic IPC?
>>>>>> I can imagine that it's not the Meson architecture at all.
>>>>>> But maybe a better solution is just to rename ARCH_MESON to ARCH_AMLOGIC?
>>>>> It should be changed treewide, and is it worth it ?
>>>> As far as I understand, the A1 and S4 families are not fully compatible
>>>> with the Meson architecture, and we haven't provided additional ARCH_*
>>>> for them.
>>> The GXBB, GXL/GXM, G12A, G12B & SM1 are also not fully compatible,
>>> but they lie under the "MESON" umbrella which covers SoC since the
>>> Meson6 architecture. It's a facility to include/exclude Amlogic
>>> drivers/DT, nothing else.
> GXBB, GXL/GXM, G12A, G12B , SM1 and S4 belong to media box.
> So, "MESON" represents the media box series.
> Up to now, "MESON" works well for all existing chips except A1 and AXG.
>>> If you compare it to BCM or NXP, it's different situation, the
>>> different ARCH_* actually targets totally different SoCs from
>>> completely different Business Units or from companies acquisitions.
> Firstly, the new C series is totally different from previous MESON series.
>  From the perspective of application, the new C series is designed for smart IP camera applications,
> while MESON series is designed for hybrid OTT/ IP Set Top Box  and high-end media box applications.
>  From the perspective of architecture, the new C series integrates the sensor interface, image signal processing unit, Dewarp, video encoder, neural networking processing unit,
> which MESON series does not and will never have.
> Secondly, there are C1 and C2 besides C3.
> Moreover, more other series are on the way, such as T series.
> If we always stick to "MESON", people will get more and more confused.
> Therefore, I think it is the right time to add ARCH_AMLIPC.

Thanks for sharing such details, we are all happy to see Amlogic's
commitment to upstream of these SoC families.

But as I explained, this ARCH_MESON doesn't define the SoC type
but badly defines the Amlogic SoCs support.

>>> We should have named it ARCH_AMLOGIC since the beginning, but we
>>> can't change history.
> Shouldn't we deserve a chance to make it right?

Yes, so the right thing to do is to move to ARCH_AMLOGIC

>>>> In my opinion, it's a good time to split the Meson architecture into
>>>> proper subsets, or rename it treewide (maybe only config option
>>>> ARCH_MESON => ARCH_AMLOGIC).
>>> MESON is only a codename to differentiate from other SoC vendors
>>> because Amlogic used it as a codename for a long time.
>>> Compare this to Allwinner's "sunxi" or Qualcomm's "msm".
>>>
>>> This config has no functional mean, it's only a config namespace.
>>>
>>> Renaming it would need renaming it in all subsystems Kconfig/Makefiles
>>> and will certainly break builds with custom kernel configs
>>> in various publicly used builds like Armbian, meta-meson, LibreELEC,
>>> Debian, Suse, ...
> Let's get back to ARCH_AMLIPC.
> We just need to add ARCH_AMLIPC in the necessary subsystems Kconfig/Makefile.
> This change will keep the existing MESON related code,  and will neither involve renaming nor break any builds.

The goal of mainline Linux is to build as much as possible and
be modular at runtime, the only supported configuration is arch/arm64/configs/defconfig
and adding a new config to differentiate an Application type
doesn't make sense.

>>> So it's pointless to change, and even add a different one since
>>> it's not a family differentiator since the Kernel is modular
>>> and works around DT to determine which drivers to probe.
> Proper names play an important role in understanding the code, right?

Yes, but stable config names also play an important role for the
users for mainline, and there's a big number of users relying
on the stable naming for all SoCs starting from Meson6.

So if you really want to get rid of the ARCH_MESON, migrating to
ARCH_AMLOGIC is the right thing to do, but it involves doing
a treewide migration and there's no easy way to do this and make
sure the users still manages to build for other Amlogic platforms.

So as the Amlogic ARM/ARM64 SoC support maintainer I must make sure
breakage don't happens, and so far I don't see how achieve that.

Now, you can post a RFC so we can discuss on something.

Neil

>>> Neil
>>>
>> Thank you for the detailed explanation; it makes sense!
>> Actually, I disagree with creating a separate ARCH without first reworking
>> all of its subsets - that's why I started this discussion.
>> Now, I see that you share my perspective and believe that C3
>> should be added to the ARCH_MESON subset, so I have no objections.
>>
>> [...]
>>
>> -- 
>> Thank you,
>> Dmitry
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] spi: bcm63xx: remove PM_SLEEP based conditional compilation
From: Dhruva Gole @ 2023-04-20 12:16 UTC (permalink / raw)
  To: Mark Brown
  Cc: Dhruva Gole, Vaishnav Achath, Vignesh, Apurva Nandan,
	linux-arm-kernel, linux-spi, linux-kernel, Grant Likely,
	Tanguy Bouzeloc

Get rid of conditional compilation based on CONFIG_PM_SLEEP because
it may introduce build issues with certain configs where it maybe disabled
This is because if above config is not enabled the suspend-resume
functions are never part of the code but the bcm63xx_spi_pm_ops struct
still inits them to non-existent suspend-resume functions.

Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver")

Signed-off-by: Dhruva Gole <d-gole@ti.com>
---
 drivers/spi/spi-bcm63xx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
index 96633a0051b1..99395932074c 100644
--- a/drivers/spi/spi-bcm63xx.c
+++ b/drivers/spi/spi-bcm63xx.c
@@ -617,7 +617,6 @@ static void bcm63xx_spi_remove(struct platform_device *pdev)
 	clk_disable_unprepare(bs->clk);
 }
 
-#ifdef CONFIG_PM_SLEEP
 static int bcm63xx_spi_suspend(struct device *dev)
 {
 	struct spi_master *master = dev_get_drvdata(dev);
@@ -644,7 +643,6 @@ static int bcm63xx_spi_resume(struct device *dev)
 
 	return 0;
 }
-#endif
 
 static const struct dev_pm_ops bcm63xx_spi_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(bcm63xx_spi_suspend, bcm63xx_spi_resume)
-- 
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: [PATCH] drm/mediatek: fix uninitialized symbol
From: AngeloGioacchino Del Regno @ 2023-04-20 12:01 UTC (permalink / raw)
  To: Nancy.Lin, Chun-Kuang Hu, Philipp Zabel, Matthias Brugger
  Cc: David Airlie, Daniel Vetter, dri-devel, linux-mediatek,
	linux-kernel, linux-arm-kernel, clang-built-linux,
	Project_Global_Chrome_Upstream_Group, singo.chang
In-Reply-To: <20230420105115.26838-1-nancy.lin@mediatek.com>

Il 20/04/23 12:51, Nancy.Lin ha scritto:
> fix Smatch static checker warning
>    - uninitialized symbol comp_pdev in mtk_ddp_comp_init.
> 
> Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>

I agree with this commit, but please add a Fixes tag.

Thanks,
Angelo

_______________________________________________
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 13/13] dma: arm64: Add CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC and enable it for arm64
From: Petr Tesařík @ 2023-04-20 11:51 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Isaac Manjarres, Catalin Marinas, Robin Murphy, Linus Torvalds,
	Arnd Bergmann, Greg Kroah-Hartman, Will Deacon, Marc Zyngier,
	Andrew Morton, Herbert Xu, Ard Biesheuvel, Saravana Kannan,
	Alasdair Kergon, Daniel Vetter, Joerg Roedel, Mark Brown,
	Mike Snitzer, Rafael J. Wysocki, linux-mm, iommu,
	linux-arm-kernel, Christoph Hellwig
In-Reply-To: <629d62ce-b993-35fe-05ff-ee0befc0c73d@csgraf.de>

Hi Alex!

Nice to meet you again...

On Thu, 1 Dec 2022 00:32:07 +0100
Alexander Graf <agraf@csgraf.de> wrote:

> Hi Isaac,
> 
> On 30.11.22 19:48, Isaac Manjarres wrote:
> > On Tue, Nov 08, 2022 at 11:03:31AM +0100, Christoph Hellwig wrote:  
> >> On Tue, Nov 08, 2022 at 09:52:15AM +0000, Catalin Marinas wrote:  
> >>> Since it's hard to guess the optimal swiotlb buffer for such platforms,
> >>> I think a follow-up step would be to use the DMA coherent pool for
> >>> bouncing if no swiotlb buffer is available. At least the pool can grow
> >>> dynamically. Yet another option would be to increase the swiotlb buffer
> >>> at run-time but it has an overhead for is_swiotlb_buffer().  
> >> Alex said he wanted to look into growing the swiotlb buffer on demand
> >> for other reason, so adding him to Cc to check if there has been any
> >> progress on that.  
> > Hi Alex,
> >
> > Did you get a chance to look into this? If so, have you been able to
> > make progress on being able to grow the SWIOTLB buffer on demand?  
> 
> 
> I've been slightly under water and haven't been able to look at this yet 
> :). It's on my list, but will probably be a while until I get to it. 
> Would you be interested in having a first try?

All right, I have just found this thread now after having sent my own
patch series to make SWIOTLB dynamic. I hope you don't mind. I didn't
want to "steal" the project from you.

Petr T

_______________________________________________
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/7] arm64: dts: ti: k3-am65: Cleanups and minor additions
From: Kamlesh Gurudasani @ 2023-04-20 11:50 UTC (permalink / raw)
  To: Nishanth Menon, Krzysztof Kozlowski, Rob Herring,
	Vignesh Raghavendra
  Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
	Nishanth Menon, Jan Kiszka
In-Reply-To: <20230419225913.663448-1-nm@ti.com>

Nishanth Menon <nm@ti.com> writes:

> Hi,
>
> This is a result of looking to cleanup u-boot and realizing there are
> pieces missing in kernel that need to be pushed out.
>
> So, minor cleanups and adding a few missing pieces.
>
> Bootlog: https://gist.github.com/nmenon/f4dc43aef616dfcb3d38701cc074ff6d
>
> Nishanth Menon (7):
>   arm64: dts: ti: k3-am654-base-board: Add missing pinmux wkup_uart,
>     mcu_uart and mcu_i2c
>   arm64: dts: ti: k3-am654-base-board: Rename regulator node name
>   arm64: dts: ti: k3-am654-base-board: Add VTT GPIO regulator for DDR
>   arm64: dts: ti: k3-am654-base-board: Add missing PMIC
>   arm64: dts: ti: k3-am654-base-board: Add board detect eeprom
>   arm64: dts: ti: k3-am654-base-board: Add aliases
>   arm64: dts: ti: k3-am65: Drop aliases
>
>  arch/arm64/boot/dts/ti/k3-am65.dtsi           | 17 ----
>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 93 ++++++++++++++++++-
>  2 files changed, 88 insertions(+), 22 deletions(-)
>
> -- 
> 2.40.0
All patches look good to me.

Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.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] arm64: abort SDEI handlers during crash
From: Mihai Carabas @ 2023-04-20 11:50 UTC (permalink / raw)
  To: scott; +Cc: catalin.marinas, james.morse, linux-arm-kernel, will
In-Reply-To: <86sffdnp3s.fsf@scott-ph-mail.amperecomputing.com>

Tested-by: Mihai Carabas <mihai.carabas@oracle.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] perf cs-etm: Add support for coresight trace for any range of CPUs
From: Ganapatrao Kulkarni @ 2023-04-20 11:47 UTC (permalink / raw)
  To: James Clark
  Cc: mathieu.poirier, acme, darren, scott, scclevenger, linux-kernel,
	coresight, linux-arm-kernel, mike.leach, suzuki.poulose
In-Reply-To: <d758c5e2-aa32-d829-35ee-a685bdb56f75@arm.com>


Hi James,

On 20-04-2023 03:13 pm, James Clark wrote:
> 
> 
> On 19/04/2023 18:21, Ganapatrao Kulkarni wrote:
>> The current implementation supports coresight trace for a range of
>> CPUs, if the first CPU is CPU0.
>>
>> Adding changes to enable coresight trace for any range of CPUs by
>> decoding the first CPU also from the header.
>> Later, first CPU id is used instead of CPU0 across the decoder functions.
>>
>> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
>> ---
>>   .../perf/util/cs-etm-decoder/cs-etm-decoder.c |  4 +-
>>   .../perf/util/cs-etm-decoder/cs-etm-decoder.h |  3 +-
>>   tools/perf/util/cs-etm.c                      | 62 ++++++++++++-------
>>   3 files changed, 42 insertions(+), 27 deletions(-)
>>
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> index 82a27ab90c8b..41ab299b643b 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> @@ -724,7 +724,7 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>>   }
>>   
>>   struct cs_etm_decoder *
>> -cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
>> +cs_etm_decoder__new(int first_decoder, int decoders, struct cs_etm_decoder_params *d_params,
>>   		    struct cs_etm_trace_params t_params[])
>>   {
>>   	struct cs_etm_decoder *decoder;
>> @@ -769,7 +769,7 @@ cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
>>   	/* init raw frame logging if required */
>>   	cs_etm_decoder__init_raw_frame_logging(d_params, decoder);
>>   
>> -	for (i = 0; i < decoders; i++) {
>> +	for (i = first_decoder; i < decoders; i++) {
>>   		ret = cs_etm_decoder__create_etm_decoder(d_params,
>>   							 &t_params[i],
>>   							 decoder);
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> index 92a855fbe5b8..b06193fc75b4 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> @@ -90,7 +90,8 @@ int cs_etm_decoder__process_data_block(struct cs_etm_decoder *decoder,
>>   				       size_t len, size_t *consumed);
>>   
>>   struct cs_etm_decoder *
>> -cs_etm_decoder__new(int num_cpu,
>> +cs_etm_decoder__new(int first_decoder,
>> +		    int decoders,
>>   		    struct cs_etm_decoder_params *d_params,
>>   		    struct cs_etm_trace_params t_params[]);
>>   
>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> index 94e2d02009eb..2619513ae088 100644
>> --- a/tools/perf/util/cs-etm.c
>> +++ b/tools/perf/util/cs-etm.c
>> @@ -55,6 +55,8 @@ struct cs_etm_auxtrace {
>>   	u8 has_virtual_ts; /* Virtual/Kernel timestamps in the trace. */
>>   
>>   	int num_cpu;
>> +	int first_cpu;
>> +	int last_cpu;
>>   	u64 latest_kernel_timestamp;
>>   	u32 auxtrace_type;
>>   	u64 branches_sample_type;
>> @@ -638,14 +640,13 @@ static void cs_etm__set_trace_param_ete(struct cs_etm_trace_params *t_params,
>>   }
>>   
>>   static int cs_etm__init_trace_params(struct cs_etm_trace_params *t_params,
>> -				     struct cs_etm_auxtrace *etm,
>> -				     int decoders)
>> +				     struct cs_etm_auxtrace *etm)
>>   {
>>   	int i;
>>   	u32 etmidr;
>>   	u64 architecture;
>>   
>> -	for (i = 0; i < decoders; i++) {
>> +	for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>   		architecture = etm->metadata[i][CS_ETM_MAGIC];
>>   
>>   		switch (architecture) {
>> @@ -817,7 +818,7 @@ static void cs_etm__free(struct perf_session *session)
>>   	/* Then the RB tree itself */
>>   	intlist__delete(traceid_list);
>>   
>> -	for (i = 0; i < aux->num_cpu; i++)
>> +	for (i = aux->first_cpu; i < aux->last_cpu; i++)
>>   		zfree(&aux->metadata[i]);
>>   
>>   	thread__zput(aux->unknown_thread);
>> @@ -921,7 +922,8 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>   	 * Each queue can only contain data from one CPU when unformatted, so only one decoder is
>>   	 * needed.
>>   	 */
>> -	int decoders = formatted ? etm->num_cpu : 1;
>> +	int first_decoder = formatted ? etm->first_cpu : 0;
>> +	int decoders = first_decoder + (formatted ? etm->num_cpu : 1);
>>   
>>   	etmq = zalloc(sizeof(*etmq));
>>   	if (!etmq)
>> @@ -937,7 +939,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>   	if (!t_params)
>>   		goto out_free;
>>   
>> -	if (cs_etm__init_trace_params(t_params, etm, decoders))
>> +	if (cs_etm__init_trace_params(t_params, etm))
>>   		goto out_free;
>>   
>>   	/* Set decoder parameters to decode trace packets */
>> @@ -947,8 +949,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>>   					formatted))
>>   		goto out_free;
>>   
>> -	etmq->decoder = cs_etm_decoder__new(decoders, &d_params,
>> -					    t_params);
>> +	etmq->decoder = cs_etm_decoder__new(first_decoder, decoders, &d_params, t_params);
>>   
>>   	if (!etmq->decoder)
>>   		goto out_free;
>> @@ -2959,11 +2960,11 @@ static int cs_etm__queue_aux_records(struct perf_session *session)
>>    * Loop through the ETMs and complain if we find at least one where ts_source != 1 (virtual
>>    * timestamps).
>>    */
>> -static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
>> +static bool cs_etm__has_virtual_ts(u64 **metadata, struct cs_etm_auxtrace *etm)
>>   {
>>   	int j;
>>   
>> -	for (j = 0; j < num_cpu; j++) {
>> +	for (j = etm->first_cpu; j < etm->last_cpu; j++) {
>>   		switch (metadata[j][CS_ETM_MAGIC]) {
>>   		case __perf_cs_etmv4_magic:
>>   			if (HAS_PARAM(j, ETMV4, TS_SOURCE) || metadata[j][CS_ETMV4_TS_SOURCE] != 1)
>> @@ -2982,13 +2983,14 @@ static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
>>   }
>>   
>>   /* map trace ids to correct metadata block, from information in metadata */
>> -static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
>> +static int cs_etm__map_trace_ids_metadata(struct cs_etm_auxtrace *etm)
>>   {
>>   	u64 cs_etm_magic;
>> +	u64 **metadata = etm->metadata;
>>   	u8 trace_chan_id;
>>   	int i, err;
>>   
>> -	for (i = 0; i < num_cpu; i++) {
>> +	for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>   		cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>>   		switch (cs_etm_magic) {
>>   		case __perf_cs_etmv3_magic:
>> @@ -3015,12 +3017,13 @@ static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
>>    * If we found AUX_HW_ID packets, then set any metadata marked as unused to the
>>    * unused value to reduce the number of unneeded decoders created.
>>    */
>> -static int cs_etm__clear_unused_trace_ids_metadata(int num_cpu, u64 **metadata)
>> +static int cs_etm__clear_unused_trace_ids_metadata(struct cs_etm_auxtrace *etm)
>>   {
>>   	u64 cs_etm_magic;
>> +	u64 **metadata = etm->metadata;
>>   	int i;
>>   
>> -	for (i = 0; i < num_cpu; i++) {
>> +	for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>>   		cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>>   		switch (cs_etm_magic) {
>>   		case __perf_cs_etmv3_magic:
>> @@ -3049,7 +3052,7 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
>>   	int event_header_size = sizeof(struct perf_event_header);
>>   	int total_size = auxtrace_info->header.size;
>>   	int priv_size = 0;
>> -	int num_cpu;
>> +	int num_cpu, first_cpu = 0, last_cpu;
>>   	int err = 0;
>>   	int aux_hw_id_found;
>>   	int i, j;
>> @@ -3068,22 +3071,31 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
>>   	/* First the global part */
>>   	ptr = (u64 *) auxtrace_info->priv;
>>   	num_cpu = ptr[CS_PMU_TYPE_CPUS] & 0xffffffff;
>> -	metadata = zalloc(sizeof(*metadata) * num_cpu);
>> +
>> +	/* Start parsing after the common part of the header */
>> +	i = CS_HEADER_VERSION_MAX;
>> +
>> +	/*Get CPU id of first event */
>> +	first_cpu = ptr[i + CS_ETM_CPU];
>> +	last_cpu = first_cpu + num_cpu;
>> +
>> +	if (first_cpu > cpu__max_cpu().cpu ||
>> +			last_cpu > cpu__max_cpu().cpu)
>> +		return -EINVAL;
>> +
>> +	metadata = zalloc(sizeof(*metadata) * last_cpu);
> 
> Hi Ganapatrao,
> 
> I think I see what the problem is, but I'm wondering if a better fix
> would be to further decouple the CPU ID from the index in the array.
> 
> With your change it's not clear what happens with sparse recordings, for
> example 'perf record -e cs_etm// -C 1,3,5'. And it seems like there is

This patch fixes for any range of CPUs.
Record with sparse list of CPUs will not work with current code still.

> some wastage in the zalloc here for example if only CPU 256 is traced
> then we'd still make 256 decoders but 255 of them would be unused?
> 
> I tried to test sparse recordings, but your change doesn't apply to the
> latest coresight/next branch. I did notice that 'perf report -D' doesn't
> work with them on coresight/next (it just quits), but I couldn't see if
> that's fixed with your change.

My patch is rebased on 6.3-RC7 codebase with Mike's 3 perf patches 
related to dynamic id [1] support(queued for 6.4).

"perf report -D" works for me.

[1] https://www.spinics.net/lists/linux-perf-users/msg27452.html

> 
> Would a better fix not be to keep the metadata loops from 0-N and
> instead save the CPU ID in cs_etm_decoder_params or the decoder. That
> way it would support both sparse and not starting from 0 cases? I think

Yep, I though this initially, it got complicated due to for more 
for-loops. I will try again and post V2.

> the code would be better if it's worded like "i < recorded_cpus" rather
> than "i < cpu" to make it clear that i isn't actually the CPU ID it's
> just an index.

Yes, makes sense to call it "recorded_cpus".

> 
> Also a new test for this scenario would probably be a good idea.
> 
> Thanks
> James
> 
Thanks,
Ganapat

_______________________________________________
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] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue
From: Ivan T. Ivanov @ 2023-04-20 11:29 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Brown, Mark Rutland, Shawn Guo, Dong Aisheng, Frank Li,
	Jason Liu, linux-arm-kernel, linux-imx, Ivan T. Ivanov

According to NXP errata document[1] i.MX8QuadMax SoC suffers from
serious cache coherence issue. It was also mentioned in initial
support[2] for imx8qm mek machine.

I chose to use an ALTERNATIVE() framework, instead downstream solution[3],
for this issue with the hope to reduce effect of this fix on unaffected
platforms.

Unfortunately I was unable to find a way to identify SoC ID using
registers. Boot CPU MIDR_EL1 is equal to 0x410fd034, AIDR_EL1 is
equal to 0. So I fallback to using devicetree compatible strings for this.
And because we can not guarantee that VMs on top of KVM will get
correct devicetree KVM is disabled.

Also make sure that SMMU "Broadcast TLB Maintenance" is not used even
SMMU device build in this SoC supports it.

I know this fix is a suboptimal solution for affected machines, but I
haven't been able to come up with a less intrusive fix.  And I hope once
TLB caches are invalidated any immediate attempt to invalidate them again
will be close to NOP operation (flush_tlb_kernel_range())

I have run few simple benchmarks and perf tests on affected and unaffected
machines and I was not able see any obvious issues. iMX8QM "performance"
was nearly doubled with 2 A72 bringed online.

Following is excerpt from NXP IMX8_1N94W "Mask Set Errata" document
Rev. 5, 3/2023. Just in case it gets lost somehow.

--
"ERR050104: Arm/A53: Cache coherency issue"

Description

Some maintenance operations exchanged between the A53 and A72
core clusters, involving some Translation Look-aside Buffer
Invalidate (TLBI) and Instruction Cache (IC) instructions can
be corrupted. The upper bits, above bit-35, of ARADDR and ACADDR
buses within in Arm A53 sub-system have been incorrectly connected.
Therefore ARADDR and ACADDR address bits above bit-35 should not
be used.

Workaround

The following software instructions are required to be downgraded
to TLBI VMALLE1IS:  TLBI ASIDE1, TLBI ASIDE1IS, TLBI VAAE1,
TLBI VAAE1IS, TLBI VAALE1, TLBI VAALE1IS, TLBI VAE1, TLBI VAE1IS,
TLBI VALE1, TLBI VALE1IS

The following software instructions are required to be downgraded
to TLBI VMALLS12E1IS: TLBI IPAS2E1IS, TLBI IPAS2LE1IS

The following software instructions are required to be downgraded
to TLBI ALLE2IS: TLBI VAE2IS, TLBI VALE2IS.

The following software instructions are required to be downgraded
to TLBI ALLE3IS: TLBI VAE3IS, TLBI VALE3IS.

The following software instructions are required to be downgraded
to TLBI VMALLE1IS when the Force Broadcast (FB) bit [9] of the
Hypervisor Configuration Register (HCR_EL2) is set:
TLBI ASIDE1, TLBI VAAE1, TLBI VAALE1, TLBI VAE1, TLBI VALE1

The following software instruction is required to be downgraded
to IC IALLUIS: IC IVAU, Xt

Specifically for the IC IVAU, Xt downgrade, setting SCTLR_EL1.UCI
to 0 will disable EL0 access to this instruction. Any attempt to
execute from EL0 will generate an EL1 trap, where the downgrade to
IC ALLUIS can be implemented.
--

[1] https://www.nxp.com/docs/en/errata/IMX8_1N94W.pdf
[2] commit 307fd14d4b14c ("arm64: dts: imx: add imx8qm mek support")
[3] https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/include/asm/tlbflush.h#L19

Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---

Changes since v1:
https://lore.kernel.org/linux-arm-kernel/20230412125506.21634-1-iivanov@suse.de/

 - Disable KVM on affected SoC add a note in commit message why this is done.
 - Updated Kconfig help message and made option enabled by default, like
   the rest of the workarounds.
 - Removed unnecessary DSB ISH + ISB instructions from the ALTERNATIVES.
 - Reworked handling of user-space IC IVAU.
 - Adjusted position of workaround definition in cpucaps file
 - Make sure that "Broadcast TLB Maintenance" is not used even if SMMU device
   build in this SoC supports it. And note it in commit message.

 Documentation/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                     | 12 ++++++++++++
 arch/arm64/include/asm/tlbflush.h      |  6 +++++-
 arch/arm64/kernel/cpu_errata.c         | 18 ++++++++++++++++++
 arch/arm64/kernel/traps.c              |  5 +++++
 arch/arm64/kvm/arm.c                   |  5 +++++
 arch/arm64/tools/cpucaps               |  1 +
 drivers/iommu/arm/arm-smmu/arm-smmu.c  |  4 ++++
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |  1 +
 9 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
index ec5f889d7681..fce231797184 100644
--- a/Documentation/arm64/silicon-errata.rst
+++ b/Documentation/arm64/silicon-errata.rst
@@ -175,6 +175,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Freescale/NXP  | LS2080A/LS1043A | A-008585        | FSL_ERRATUM_A008585         |
 +----------------+-----------------+-----------------+-----------------------------+
+| Freescale/NXP  | i.MX 8QuadMax   | ERR050104       | NXP_IMX8QM_ERRATUM_ERR050104|
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | Hisilicon      | Hip0{5,6,7}     | #161010101      | HISILICON_ERRATUM_161010101 |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1023e896d46b..a5fe6ffb8150 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1159,6 +1159,18 @@ config SOCIONEXT_SYNQUACER_PREITS
 
 	  If unsure, say Y.
 
+config NXP_IMX8QM_ERRATUM_ERR050104
+	bool "NXP iMX8QM ERR050104: broken cache/tlb invalidation"
+	default y
+	help
+	  On iMX8QM, addresses above bit 35 are not broadcast correctly for
+	  TLBI or IC operations, making TLBI and IC unreliable.
+
+	  Work around this erratum by using TLBI *ALL*IS and IC IALLUIS
+	  operations. EL0 use of IC IVAU is trapped and upgraded to IC IALLUIS.
+
+	  If unsure, say Y.
+
 endmenu # "ARM errata workarounds via the alternatives framework"
 
 choice
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 412a3b9a3c25..e3bad2298ea5 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -37,7 +37,11 @@
 			    : : )
 
 #define __TLBI_1(op, arg) asm (ARM64_ASM_PREAMBLE			       \
-			       "tlbi " #op ", %0\n"			       \
+		   ALTERNATIVE("tlbi " #op ", %0\n",			       \
+			       "tlbi vmalle1is\n",			       \
+			       ARM64_WORKAROUND_NXP_ERR050104)		       \
+			    : : "r" (arg));				       \
+			  asm (ARM64_ASM_PREAMBLE			       \
 		   ALTERNATIVE("nop\n			nop",		       \
 			       "dsb ish\n		tlbi " #op ", %0",     \
 			       ARM64_WORKAROUND_REPEAT_TLBI,		       \
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 307faa2b4395..b0647b64dbb8 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -8,6 +8,7 @@
 #include <linux/arm-smccc.h>
 #include <linux/types.h>
 #include <linux/cpu.h>
+#include <linux/of.h>
 #include <asm/cpu.h>
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
@@ -55,6 +56,14 @@ is_kryo_midr(const struct arm64_cpu_capabilities *entry, int scope)
 	return model == entry->midr_range.model;
 }
 
+static bool __maybe_unused
+is_imx8qm_soc(const struct arm64_cpu_capabilities *entry, int scope)
+{
+	WARN_ON(preemptible());
+
+	return of_machine_is_compatible("fsl,imx8qm");
+}
+
 static bool
 has_mismatched_cache_type(const struct arm64_cpu_capabilities *entry,
 			  int scope)
@@ -729,6 +738,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		MIDR_FIXED(MIDR_CPU_VAR_REV(1,1), BIT(25)),
 		.cpu_enable = cpu_clear_bf16_from_user_emulation,
 	},
+#endif
+#ifdef CONFIG_NXP_IMX8QM_ERRATUM_ERR050104
+	{
+		.desc = "NXP erratum ERR050104",
+		.capability = ARM64_WORKAROUND_NXP_ERR050104,
+		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
+		.matches = is_imx8qm_soc,
+		.cpu_enable = cpu_enable_cache_maint_trap,
+	},
 #endif
 	{
 	}
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 4a79ba100799..265b6334291b 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -556,6 +556,11 @@ static void user_cache_maint_handler(unsigned long esr, struct pt_regs *regs)
 		__user_cache_maint("dc civac", address, ret);
 		break;
 	case ESR_ELx_SYS64_ISS_CRM_IC_IVAU:	/* IC IVAU */
+		if (cpus_have_final_cap(ARM64_WORKAROUND_NXP_ERR050104)) {
+			asm volatile("ic ialluis");
+			ret = 0;
+			break;
+		}
 		__user_cache_maint("ic ivau", address, ret);
 		break;
 	default:
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 4b2e16e696a8..5066332302d2 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2239,6 +2239,11 @@ static __init int kvm_arm_init(void)
 		return -ENODEV;
 	}
 
+	if (cpus_have_final_cap(ARM64_WORKAROUND_NXP_ERR050104)) {
+		kvm_info("KVM is not supported on this system\n");
+		return -ENODEV;
+	}
+
 	err = kvm_sys_reg_table_init();
 	if (err) {
 		kvm_info("Error initializing system register tables");
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 37b1340e9646..c1de9235f922 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -87,6 +87,7 @@ WORKAROUND_CAVIUM_TX2_219_TVM
 WORKAROUND_CLEAN_CACHE
 WORKAROUND_DEVICE_LOAD_ACQUIRE
 WORKAROUND_NVIDIA_CARMEL_CNP
+WORKAROUND_NXP_ERR050104
 WORKAROUND_QCOM_FALKOR_E1003
 WORKAROUND_REPEAT_TLBI
 WORKAROUND_SPECULATIVE_AT
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 2ff7a72cf377..29bbb16bae6e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1680,6 +1680,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 	/* ID0 */
 	id = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_ID0);
 
+	/* Do not use Broadcast TLB Maintenance on affected platforms */
+	if (cpus_have_final_cap(ARM64_WORKAROUND_NXP_ERR050104))
+		id &= ~ARM_SMMU_ID0_BTM;
+
 	/* Restrict available stages based on module parameter */
 	if (force_stage == 1)
 		id &= ~(ARM_SMMU_ID0_S2TS | ARM_SMMU_ID0_NTS);
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..1589acfdbed9 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -52,6 +52,7 @@
 #define ARM_SMMU_ID0_PTFS_NO_AARCH32S	BIT(24)
 #define ARM_SMMU_ID0_NUMIRPT		GENMASK(23, 16)
 #define ARM_SMMU_ID0_CTTW		BIT(14)
+#define ARM_SMMU_ID0_BTM		BIT(13)
 #define ARM_SMMU_ID0_NUMSIDB		GENMASK(12, 9)
 #define ARM_SMMU_ID0_EXIDS		BIT(8)
 #define ARM_SMMU_ID0_NUMSMRG		GENMASK(7, 0)
-- 
2.35.3


_______________________________________________
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 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Thomas Gleixner @ 2023-04-20 11:17 UTC (permalink / raw)
  To: Andrew Cooper, Paul Menzel
  Cc: linux-kernel, x86, David Woodhouse, 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: <26d385da-2ede-5d73-2959-84c8f7d89e03@citrix.com>

On Thu, Apr 20 2023 at 10:23, Andrew Cooper wrote:
> On 20/04/2023 9:32 am, Thomas Gleixner wrote:
>> I'm pondering to simply deny parallel mode if x2APIC is not there.
>
> I'm not sure if that will help much.

Spoilsport.

> Just because x2APIC is there doesn't mean it's in use.  There are
> several generations of Intel system which have x2APIC but also use the
> opt-out bit in ACPI tables.  There are some machines which have
> mismatched APIC-ness settings in the BIOS->OS handover.
>
> There's very little you can do on the BSP alone to know for certain that
> the APs come out of wait-for-SIPI already in x2APIC mode.

Yeah. Reading the APIC that early is going to be entertaining too :)

> One way is the ÆPIC Leak "locked into x2APIC mode" giant security
> bodge. 

Bah.

> If the system really does have a CPU with an APIC ID above 0xfe, then
> chances are good that the APs come out consistently...

Anything else would be really magic :)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH AUTOSEL 6.1 09/15] net: wwan: t7xx: do not compile with -Werror
From: Sasha Levin @ 2023-04-20 11:02 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Jiri Slaby (SUSE), Chandrashekar Devegowda, Intel Corporation,
	Chiranjeevi Rapolu, Liu Haijun, M Chetan Kumar, Ricardo Martinez,
	Loic Poulain, Sergey Ryazanov, Johannes Berg, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, Sasha Levin,
	matthias.bgg, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230420110231.505992-1-sashal@kernel.org>

From: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>

[ Upstream commit 362f0b6678ad1377c322a7dd237ea6785efc7342 ]

When playing with various compilers or their versions, some choke on
the t7xx code. For example (with gcc 13):
 In file included from ./arch/s390/include/generated/asm/rwonce.h:1,
                  from ../include/linux/compiler.h:247,
                  from ../include/linux/build_bug.h:5,
                  from ../include/linux/bits.h:22,
                  from ../drivers/net/wwan/t7xx/t7xx_state_monitor.c:17:
 In function 'preempt_count',
     inlined from 't7xx_fsm_append_event' at ../drivers/net/wwan/t7xx/t7xx_state_monitor.c:439:43:
 ../include/asm-generic/rwonce.h:44:26: error: array subscript 0 is outside array bounds of 'const volatile int[0]' [-Werror=array-bounds=]

There is no reason for any code in the kernel to be built with -Werror
by default. Note that we have generic CONFIG_WERROR. So if anyone wants
-Werror, they can enable that.

Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/all/20230330232717.1f8bf5ea@kernel.org/
Cc: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Cc: Intel Corporation <linuxwwan@intel.com>
Cc: Chiranjeevi Rapolu <chiranjeevi.rapolu@linux.intel.com>
Cc: Liu Haijun <haijun.liu@mediatek.com>
Cc: M Chetan Kumar <m.chetan.kumar@linux.intel.com>
Cc: Ricardo Martinez <ricardo.martinez@linux.intel.com>
Cc: Loic Poulain <loic.poulain@linaro.org>
Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wwan/t7xx/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wwan/t7xx/Makefile b/drivers/net/wwan/t7xx/Makefile
index dc6a7d682c159..5e6398b527e72 100644
--- a/drivers/net/wwan/t7xx/Makefile
+++ b/drivers/net/wwan/t7xx/Makefile
@@ -1,7 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-ccflags-y += -Werror
-
 obj-${CONFIG_MTK_T7XX} := mtk_t7xx.o
 mtk_t7xx-y:=	t7xx_pci.o \
 		t7xx_pcie_mac.o \
-- 
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

* [PATCH AUTOSEL 6.2 10/17] net: wwan: t7xx: do not compile with -Werror
From: Sasha Levin @ 2023-04-20 11:01 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Jiri Slaby (SUSE), Chandrashekar Devegowda, Intel Corporation,
	Chiranjeevi Rapolu, Liu Haijun, M Chetan Kumar, Ricardo Martinez,
	Loic Poulain, Sergey Ryazanov, Johannes Berg, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, Sasha Levin,
	matthias.bgg, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230420110148.505779-1-sashal@kernel.org>

From: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>

[ Upstream commit 362f0b6678ad1377c322a7dd237ea6785efc7342 ]

When playing with various compilers or their versions, some choke on
the t7xx code. For example (with gcc 13):
 In file included from ./arch/s390/include/generated/asm/rwonce.h:1,
                  from ../include/linux/compiler.h:247,
                  from ../include/linux/build_bug.h:5,
                  from ../include/linux/bits.h:22,
                  from ../drivers/net/wwan/t7xx/t7xx_state_monitor.c:17:
 In function 'preempt_count',
     inlined from 't7xx_fsm_append_event' at ../drivers/net/wwan/t7xx/t7xx_state_monitor.c:439:43:
 ../include/asm-generic/rwonce.h:44:26: error: array subscript 0 is outside array bounds of 'const volatile int[0]' [-Werror=array-bounds=]

There is no reason for any code in the kernel to be built with -Werror
by default. Note that we have generic CONFIG_WERROR. So if anyone wants
-Werror, they can enable that.

Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/all/20230330232717.1f8bf5ea@kernel.org/
Cc: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Cc: Intel Corporation <linuxwwan@intel.com>
Cc: Chiranjeevi Rapolu <chiranjeevi.rapolu@linux.intel.com>
Cc: Liu Haijun <haijun.liu@mediatek.com>
Cc: M Chetan Kumar <m.chetan.kumar@linux.intel.com>
Cc: Ricardo Martinez <ricardo.martinez@linux.intel.com>
Cc: Loic Poulain <loic.poulain@linaro.org>
Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wwan/t7xx/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wwan/t7xx/Makefile b/drivers/net/wwan/t7xx/Makefile
index 268ff9e87e5b3..2652cd00504e6 100644
--- a/drivers/net/wwan/t7xx/Makefile
+++ b/drivers/net/wwan/t7xx/Makefile
@@ -1,7 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-ccflags-y += -Werror
-
 obj-${CONFIG_MTK_T7XX} := mtk_t7xx.o
 mtk_t7xx-y:=	t7xx_pci.o \
 		t7xx_pcie_mac.o \
-- 
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

* [PATCH AUTOSEL 6.2 11/17] wifi: mt76: mt7921: Fix use-after-free in fw features query.
From: Sasha Levin @ 2023-04-20 11:01 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Ben Greear, Lorenzo Bianconi, Felix Fietkau, Kalle Valo,
	Sasha Levin, ryder.lee, davem, edumazet, kuba, pabeni,
	matthias.bgg, deren.wu, sean.wang, mingyen.hsieh, yn.chen,
	linux-wireless, netdev, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230420110148.505779-1-sashal@kernel.org>

From: Ben Greear <greearb@candelatech.com>

[ Upstream commit 2ceb76f734e37833824b7fab6af17c999eb48d2b ]

Stop referencing 'features' memory after release_firmware is called.

Fixes this crash:

RIP: 0010:mt7921_check_offload_capability+0x17d
mt7921_pci_probe+0xca/0x4b0
...

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/51fd8f76494348aa9ecbf0abc471ebe47a983dfd.1679502607.git.lorenzo@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/mt7921/init.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
index d4b681d7e1d22..f2c6ec4d8e2ee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
@@ -162,12 +162,12 @@ mt7921_mac_init_band(struct mt7921_dev *dev, u8 band)
 
 u8 mt7921_check_offload_capability(struct device *dev, const char *fw_wm)
 {
-	struct mt7921_fw_features *features = NULL;
 	const struct mt76_connac2_fw_trailer *hdr;
 	struct mt7921_realease_info *rel_info;
 	const struct firmware *fw;
 	int ret, i, offset = 0;
 	const u8 *data, *end;
+	u8 offload_caps = 0;
 
 	ret = request_firmware(&fw, fw_wm, dev);
 	if (ret)
@@ -199,7 +199,10 @@ u8 mt7921_check_offload_capability(struct device *dev, const char *fw_wm)
 		data += sizeof(*rel_info);
 
 		if (rel_info->tag == MT7921_FW_TAG_FEATURE) {
+			struct mt7921_fw_features *features;
+
 			features = (struct mt7921_fw_features *)data;
+			offload_caps = features->data;
 			break;
 		}
 
@@ -209,7 +212,7 @@ u8 mt7921_check_offload_capability(struct device *dev, const char *fw_wm)
 out:
 	release_firmware(fw);
 
-	return features ? features->data : 0;
+	return offload_caps;
 }
 EXPORT_SYMBOL_GPL(mt7921_check_offload_capability);
 
-- 
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] counter: stm32-timer-cnt: Reset TIM_TISEL and TIM_SMCR to their default value
From: Lee Jones @ 2023-04-20 11:01 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Maxime Coquelin, Alexandre Torgue, William Breathitt Gray,
	Fabrice Gasnier, Olivier Moysan, Thierry Reding, linux-stm32,
	linux-arm-kernel, linux-kernel, kernel, linux-iio
In-Reply-To: <20230412153709.3557323-1-u.kleine-koenig@pengutronix.de>

On Wed, 12 Apr 2023, Uwe Kleine-König wrote:

> The driver assumes that the input selection register (TIM_TISEL) is at
> its reset default value. Usually this is the case, but the bootloader
> might have modified it. Also reset the SMCR register while at it.
> 
> This bases on the effectively same patch submitted by Olivier Moysan for
> pwm-stm32.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
> 
> note that the patch by Olivier Moysan[1] for pwm-stm32 is expected to
> appear in Thierry's tree soon. It added the definition of TIM_TISEL in
> the same way, so the two patches should merge just fine. Alternatively
> you can commit it to a tree that already has the pwm change (and then
> drop the change to include/linux/mfd/stm32-timers.h from this one).
> 
> Best regards
> Uwe
> 
> [1] https://lore.kernel.org/linux-pwm/20221213102707.1096345-1-olivier.moysan@foss.st.com
> 
>  drivers/counter/stm32-timer-cnt.c | 4 ++++

>  include/linux/mfd/stm32-timers.h  | 1 +

Acked-by: Lee Jones <lee@kernel.org>

>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
> index 9bf20a5d6bda..d001d77f17ac 100644
> --- a/drivers/counter/stm32-timer-cnt.c
> +++ b/drivers/counter/stm32-timer-cnt.c
> @@ -342,6 +342,10 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, priv);
>  
> +	/* Reset input selector to its default input and disable slave mode */
> +	regmap_write(priv->regmap, TIM_TISEL, 0x0);
> +	regmap_write(priv->regmap, TIM_SMCR, 0x0);
> +
>  	/* Register Counter device */
>  	ret = devm_counter_add(dev, counter);
>  	if (ret < 0)
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> index 5f5c43fd69dd..1b94325febb3 100644
> --- a/include/linux/mfd/stm32-timers.h
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -31,6 +31,7 @@
>  #define TIM_BDTR	0x44	/* Break and Dead-Time Reg */
>  #define TIM_DCR		0x48	/* DMA control register    */
>  #define TIM_DMAR	0x4C	/* DMA register for transfer */
> +#define TIM_TISEL	0x68	/* Input Selection         */
>  
>  #define TIM_CR1_CEN	BIT(0)	/* Counter Enable	   */
>  #define TIM_CR1_DIR	BIT(4)  /* Counter Direction	   */
> 
> base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
> -- 
> 2.39.2
> 

-- 
Lee Jones [李琼斯]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* next: arm: drivers/net/phy/phy_device.o: in function `phy_probe': drivers/net/phy/phy_device.c:3053: undefined reference to
From: Naresh Kamboju @ 2023-04-20 10:51 UTC (permalink / raw)
  To: Netdev, Linux-Next Mailing List, Linux ARM, lkft-triage, llvm
  Cc: Russell King - ARM Linux, David S. Miller, Arnd Bergmann,
	Ard Biesheuvel, Anders Roxell, Eric Dumazet, Paolo Abeni,
	Jakub Kicinski

[ Please ignore this email if it is already reported ]

Following build failures noticed on Linux next-20230419.

Regressions found on arm:
 - build/clang-16-omap2plus_defconfig
 - build/clang-16-davinci_all_defconfig
 - build/gcc-8-davinci_all_defconfig
 - build/clang-nightly-omap2plus_defconfig
 - build/gcc-12-omap2plus_defconfig
 - build/gcc-12-davinci_all_defconfig
 - build/clang-nightly-davinci_all_defconfig
 - build/gcc-8-omap2plus_defconfig


Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

Build log:
------------

 arm-linux-gnueabihf-ld: drivers/net/phy/phy_device.o: in function `phy_probe':
drivers/net/phy/phy_device.c:3053: undefined reference to
`devm_led_classdev_register_ext'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.o: in
function `davinci_emac_of_get_pdata':
drivers/net/ethernet/ti/davinci_emac.c:1770: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.c:1772:
undefined reference to `of_phy_register_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.o: in
function `davinci_emac_probe':
drivers/net/ethernet/ti/davinci_emac.c:1990: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.c:1990:
undefined reference to `of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.c:1991:
undefined reference to `of_phy_deregister_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.o: in
function `emac_dev_open':
drivers/net/ethernet/ti/davinci_emac.c:1497: undefined reference to
`of_phy_connect'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.o: in
function `davinci_emac_remove':
drivers/net/ethernet/ti/davinci_emac.c:2022: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_emac.c:2023:
undefined reference to `of_phy_deregister_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_mdio.o: in
function `davinci_mdio_probe':
include/linux/of_mdio.h:23: undefined reference to `__of_mdiobus_register'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/davinci_mdio.o: in
function `davinci_mdio_probe':
include/linux/phy.h:458: undefined reference to `devm_mdiobus_alloc_size'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw.o: in function
`cpsw_remove_dt':
drivers/net/ethernet/ti/cpsw.c:1410: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw.c:1411: undefined
reference to `of_phy_deregister_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw.o: in function
`cpsw_probe':
drivers/net/ethernet/ti/cpsw.c:1318: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw.c:1322: undefined
reference to `of_phy_register_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw.o: in function
`cpsw_slave_open':
drivers/net/ethernet/ti/cpsw.c:614: undefined reference to `of_phy_connect'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.o: in
function `cpsw_remove':
drivers/net/ethernet/ti/cpsw_new.c:1354: undefined reference to
`of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.c:1355:
undefined reference to `of_phy_deregister_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.o: in
function `cpsw_probe':
drivers/net/ethernet/ti/cpsw_new.c:1290: undefined reference to
`of_phy_register_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.c:1289:
undefined reference to `of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.c:1354:
undefined reference to `of_phy_is_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.c:1355:
undefined reference to `of_phy_deregister_fixed_link'
arm-linux-gnueabihf-ld: drivers/net/ethernet/ti/cpsw_new.o: in
function `cpsw_ndo_open':
drivers/net/ethernet/ti/cpsw_new.c:768: undefined reference to `of_phy_connect'
make[2]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 1


Details:
-------
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230419/testrun/16368708/suite/build/test/gcc-12-omap2plus_defconfig/log
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230419/testrun/16368708/suite/build/test/gcc-12-omap2plus_defconfig/details/

Steps to reproduce:
---------
#
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.
# Original tuxmake command with fragments listed below.

tuxmake --runtime podman --target-arch arm --toolchain gcc-12
--kconfig omap2plus_defconfig


--
Linaro LKFT
https://lkft.linaro.org

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] drm/mediatek: fix uninitialized symbol
From: Nancy.Lin @ 2023-04-20 10:51 UTC (permalink / raw)
  To: Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
	AngeloGioacchino Del Regno
  Cc: David Airlie, Daniel Vetter, dri-devel, linux-mediatek,
	linux-kernel, linux-arm-kernel, clang-built-linux,
	Project_Global_Chrome_Upstream_Group, singo.chang, Nancy.Lin

fix Smatch static checker warning
  - uninitialized symbol comp_pdev in mtk_ddp_comp_init.

Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index f114da4d36a9..e987ac4481bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -546,7 +546,7 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
 int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
 		      unsigned int comp_id)
 {
-	struct platform_device *comp_pdev;
+	struct platform_device *comp_pdev = NULL;
 	enum mtk_ddp_comp_type type;
 	struct mtk_ddp_comp_dev *priv;
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
@@ -588,6 +588,9 @@ int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
 	    type == MTK_DSI)
 		return 0;
 
+	if (!comp_pdev)
+		return -EPROBE_DEFER;
+
 	priv = devm_kzalloc(comp->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
-- 
2.18.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 V4 3/4] watchdog: xilinx_wwdt: Add Versal window watchdog support
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
  To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
	robh+dt, krzysztof.kozlowski+dt
  Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
	linux-arm-kernel, git, git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-1-srinivas.neeli@amd.com>

Versal watchdog driver uses window watchdog mode. Window watchdog
timer(WWDT) contains closed(first) and open(second) window with
32 bit width. Write to the watchdog timer within predefined window
periods of time. This means a period that is not too soon and a
period that is not too late. The WWDT has to be restarted within
the open window time. If software tries to restart WWDT outside of
the open window time period, it generates a reset.

Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
Changes in V4:
-Maximum timeout value calculated at 100Mhz source clock. This value
 vary depending on the source clock to IP.
-Removed module parameters prefix("x").
-Moved closed window percent check to the probe fucntion and updated
 dependent code.
Changes in V3:
-Removed "xlnx,close_percent" support from dtb.
-Added "xlnx,close_percent" property as module paratmeter.
-Updated code with devm_clk_get_enabled().
Changes in V2:
- Takes "xlnx,close-percent" property from device tree parameter.
- Removed clk_disable() function.
- Removed module parameter permisions and using readomly.
- Added check for close_percent( 0 < close_perecent < 100).
- Updated other minor comments.
---
 drivers/watchdog/Kconfig       |  18 +++
 drivers/watchdog/Makefile      |   1 +
 drivers/watchdog/xilinx_wwdt.c | 201 +++++++++++++++++++++++++++++++++
 3 files changed, 220 insertions(+)
 create mode 100644 drivers/watchdog/xilinx_wwdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f0872970daf9..ec4b522ae29e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -304,6 +304,24 @@ config XILINX_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called of_xilinx_wdt.
 
+config XILINX_WINDOW_WATCHDOG
+	tristate "Xilinx window watchdog timer"
+	depends on HAS_IOMEM
+	depends on ARM64
+	select WATCHDOG_CORE
+	help
+	  Window watchdog driver for the versal_wwdt IP core.
+	  Window watchdog timer(WWDT) contains closed(first) and
+	  open(second) window with 32 bit width. Write to the watchdog
+	  timer within predefined window periods of time. This means
+	  a period that is not too soon and a period that is not too
+	  late. The WWDT has to be restarted within the open window time.
+	  If software tries to restart WWDT outside of the open window
+	  time period, it generates a reset.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called xilinx_wwdt.
+
 config ZIIRAVE_WATCHDOG
 	tristate "Zodiac RAVE Watchdog Timer"
 	depends on I2C
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 9cbf6580f16c..6cb5f1dfb492 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -157,6 +157,7 @@ obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
 
 # MicroBlaze Architecture
 obj-$(CONFIG_XILINX_WATCHDOG) += of_xilinx_wdt.o
+obj-$(CONFIG_XILINX_WINDOW_WATCHDOG) += xilinx_wwdt.o
 
 # MIPS Architecture
 obj-$(CONFIG_ATH79_WDT) += ath79_wdt.o
diff --git a/drivers/watchdog/xilinx_wwdt.c b/drivers/watchdog/xilinx_wwdt.c
new file mode 100644
index 000000000000..2585038d5575
--- /dev/null
+++ b/drivers/watchdog/xilinx_wwdt.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Window watchdog device driver for Xilinx Versal WWDT
+ *
+ * Copyright (C) 2022 - 2023, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/watchdog.h>
+
+/* Max timeout is calculated at 100MHz source clock */
+#define XWWDT_DEFAULT_TIMEOUT	42
+#define XWWDT_MIN_TIMEOUT	1
+
+/* Register offsets for the WWDT device */
+#define XWWDT_MWR_OFFSET	0x00
+#define XWWDT_ESR_OFFSET	0x04
+#define XWWDT_FCR_OFFSET	0x08
+#define XWWDT_FWR_OFFSET	0x0c
+#define XWWDT_SWR_OFFSET	0x10
+
+/* Master Write Control Register Masks */
+#define XWWDT_MWR_MASK		BIT(0)
+
+/* Enable and Status Register Masks */
+#define XWWDT_ESR_WINT_MASK	BIT(16)
+#define XWWDT_ESR_WSW_MASK	BIT(8)
+#define XWWDT_ESR_WEN_MASK	BIT(0)
+
+#define XWWDT_CLOSE_WINDOW_PERCENT	50
+
+static int wwdt_timeout;
+static int closed_window_percent;
+
+module_param(wwdt_timeout, int, 0);
+MODULE_PARM_DESC(wwdt_timeout,
+		 "Watchdog time in seconds. (default="
+		 __MODULE_STRING(XWWDT_DEFAULT_TIMEOUT) ")");
+module_param(closed_window_percent, int, 0);
+MODULE_PARM_DESC(closed_window_percent,
+		 "Watchdog closed window percentage. (default="
+		 __MODULE_STRING(XWWDT_CLOSE_WINDOW_PERCENT) ")");
+/**
+ * struct xwwdt_device - Watchdog device structure
+ * @base: base io address of WDT device
+ * @spinlock: spinlock for IO register access
+ * @xilinx_wwdt_wdd: watchdog device structure
+ * @freq: source clock frequency of WWDT
+ * @close_percent: Closed window percent
+ */
+struct xwwdt_device {
+	void __iomem *base;
+	spinlock_t spinlock; /* spinlock for register handling */
+	struct watchdog_device xilinx_wwdt_wdd;
+	unsigned long freq;
+	u32 close_percent;
+};
+
+static int xilinx_wwdt_start(struct watchdog_device *wdd)
+{
+	struct xwwdt_device *xdev = watchdog_get_drvdata(wdd);
+	struct watchdog_device *xilinx_wwdt_wdd = &xdev->xilinx_wwdt_wdd;
+	u64 time_out, closed_timeout, open_timeout;
+	u32 control_status_reg;
+
+	/* Calculate timeout count */
+	time_out = xdev->freq * wdd->timeout;
+	closed_timeout = (time_out * xdev->close_percent) / 100;
+	open_timeout = time_out - closed_timeout;
+	wdd->min_hw_heartbeat_ms = xdev->close_percent * 10 * wdd->timeout;
+
+	spin_lock(&xdev->spinlock);
+
+	iowrite32(XWWDT_MWR_MASK, xdev->base + XWWDT_MWR_OFFSET);
+	iowrite32(~(u32)XWWDT_ESR_WEN_MASK, xdev->base + XWWDT_ESR_OFFSET);
+	iowrite32((u32)closed_timeout, xdev->base + XWWDT_FWR_OFFSET);
+	iowrite32((u32)open_timeout, xdev->base + XWWDT_SWR_OFFSET);
+
+	/* Enable the window watchdog timer */
+	control_status_reg = ioread32(xdev->base + XWWDT_ESR_OFFSET);
+	control_status_reg |= XWWDT_ESR_WEN_MASK;
+	iowrite32(control_status_reg, xdev->base + XWWDT_ESR_OFFSET);
+
+	spin_unlock(&xdev->spinlock);
+
+	dev_dbg(xilinx_wwdt_wdd->parent, "Watchdog Started!\n");
+
+	return 0;
+}
+
+static int xilinx_wwdt_keepalive(struct watchdog_device *wdd)
+{
+	struct xwwdt_device *xdev = watchdog_get_drvdata(wdd);
+	u32 control_status_reg;
+
+	spin_lock(&xdev->spinlock);
+
+	/* Enable write access control bit for the window watchdog */
+	iowrite32(XWWDT_MWR_MASK, xdev->base + XWWDT_MWR_OFFSET);
+
+	/* Trigger restart kick to watchdog */
+	control_status_reg = ioread32(xdev->base + XWWDT_ESR_OFFSET);
+	control_status_reg |= XWWDT_ESR_WSW_MASK;
+	iowrite32(control_status_reg, xdev->base + XWWDT_ESR_OFFSET);
+
+	spin_unlock(&xdev->spinlock);
+
+	return 0;
+}
+
+static const struct watchdog_info xilinx_wwdt_ident = {
+	.options = WDIOF_KEEPALIVEPING |
+		WDIOF_SETTIMEOUT,
+	.firmware_version = 1,
+	.identity = "xlnx_window watchdog",
+};
+
+static const struct watchdog_ops xilinx_wwdt_ops = {
+	.owner = THIS_MODULE,
+	.start = xilinx_wwdt_start,
+	.ping = xilinx_wwdt_keepalive,
+};
+
+static int xwwdt_probe(struct platform_device *pdev)
+{
+	struct watchdog_device *xilinx_wwdt_wdd;
+	struct device *dev = &pdev->dev;
+	struct xwwdt_device *xdev;
+	struct clk *clk;
+	int ret;
+
+	xdev = devm_kzalloc(dev, sizeof(*xdev), GFP_KERNEL);
+	if (!xdev)
+		return -ENOMEM;
+
+	xilinx_wwdt_wdd = &xdev->xilinx_wwdt_wdd;
+	xilinx_wwdt_wdd->info = &xilinx_wwdt_ident;
+	xilinx_wwdt_wdd->ops = &xilinx_wwdt_ops;
+	xilinx_wwdt_wdd->parent = dev;
+
+	xdev->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(xdev->base))
+		return PTR_ERR(xdev->base);
+
+	clk = devm_clk_get_enabled(dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	xdev->freq = clk_get_rate(clk);
+	if (!xdev->freq)
+		return -EINVAL;
+
+	xilinx_wwdt_wdd->min_timeout = XWWDT_MIN_TIMEOUT;
+	xilinx_wwdt_wdd->timeout = XWWDT_DEFAULT_TIMEOUT;
+	xilinx_wwdt_wdd->max_hw_heartbeat_ms = 1000 * xilinx_wwdt_wdd->timeout;
+
+	if (closed_window_percent == 0 || closed_window_percent >= 100)
+		xdev->close_percent = XWWDT_CLOSE_WINDOW_PERCENT;
+	else
+		xdev->close_percent = closed_window_percent;
+
+	watchdog_init_timeout(xilinx_wwdt_wdd, wwdt_timeout, &pdev->dev);
+	spin_lock_init(&xdev->spinlock);
+	watchdog_set_drvdata(xilinx_wwdt_wdd, xdev);
+	watchdog_set_nowayout(xilinx_wwdt_wdd, 1);
+
+	ret = devm_watchdog_register_device(dev, xilinx_wwdt_wdd);
+	if (ret)
+		return ret;
+
+	dev_info(dev, "Xilinx window watchdog Timer with timeout %ds\n",
+		 xilinx_wwdt_wdd->timeout);
+
+	return 0;
+}
+
+static const struct of_device_id xwwdt_of_match[] = {
+	{ .compatible = "xlnx,versal-wwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, xwwdt_of_match);
+
+static struct platform_driver xwwdt_driver = {
+	.probe = xwwdt_probe,
+	.driver = {
+		.name = "Xilinx window watchdog",
+		.of_match_table = xwwdt_of_match,
+	},
+};
+
+module_platform_driver(xwwdt_driver);
+
+MODULE_AUTHOR("Neeli Srinivas <srinivas.neeli@amd.com>");
+MODULE_DESCRIPTION("Xilinx window watchdog driver");
+MODULE_LICENSE("GPL");
-- 
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

* [PATCH V4 4/4] MAINTAINERS: Add support for Xilinx versal watchdog
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
  To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
	robh+dt, krzysztof.kozlowski+dt
  Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
	linux-arm-kernel, git, git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-1-srinivas.neeli@amd.com>

Added entry for Xilinx versal watchdog driver.

Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
Changes in V4:
-None
Changes in V3:
-None
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 327901c9f1d1..388305608418 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23148,8 +23148,10 @@ M:	Srinivas Neeli <srinivas.neeli@amd.com>
 R:	Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
 R:	Michal Simek <michal.simek@amd.com>
 S:	Maintained
+F:	Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
 F:	Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
 F:	drivers/watchdog/of_xilinx_wdt.c
+F:	drivers/watchdog/xilinx_wwdt.c
 
 XILINX XDMA DRIVER
 M:	Lizhi Hou <lizhi.hou@amd.com>
-- 
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

* [PATCH V4 2/4] dt-bindings: watchdog: xlnx,versal-wwdt: Add versal watchdog
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
  To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
	robh+dt, krzysztof.kozlowski+dt
  Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
	linux-arm-kernel, git, git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-1-srinivas.neeli@amd.com>

Versal watchdog IP uses window watchdog mode. Window watchdog
timer(WWDT) contains closed(first) and open(second) window with
32 bit width. Write to the watchdog timer within predefined window
periods of time. This means a period that is not too soon and
a period that is not too late.

Add devicetree bindings for versal window watchdog device.

Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
Changes in V4:
- Updated commit subject(removed redundant "bindings").
- Updated commit descriptioni(removed "this patch").
- Updated watchdog.yaml reference to local.
Changes in V3:
- Removed  xlnx,close_percent property.
Changes in V2:
- Added watchdog ref
- Removed timeout-sec property
- Used 4 spaces for example indentation.
---
 .../bindings/watchdog/xlnx,versal-wwdt.yaml   | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml

diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
new file mode 100644
index 000000000000..14b069599740
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/xlnx,versal-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal window watchdog timer controller
+
+maintainers:
+  - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+  Versal watchdog intellectual property uses window watchdog mode.
+  Window watchdog timer(WWDT) contains closed(first) and open(second)
+  window with 32 bit width. Write to the watchdog timer within
+  predefined window periods of time. This means a period that is not
+  too soon and a period that is not too late. The WWDT has to be
+  restarted within the open window time. If software tries to restart
+  WWDT outside of the open window time period, it generates a reset.
+
+allOf:
+  - $ref: watchdog.yaml#
+
+properties:
+  compatible:
+    enum:
+      - xlnx,versal-wwdt
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    watchdog@fd4d0000 {
+        compatible = "xlnx,versal-wwdt";
+        reg = <0xfd4d0000 0x10000>;
+        clocks = <&clock25>;
+        timeout-sec = <30>;
+    };
+...
-- 
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox