From: Leo Yan <leo.yan@arm.com>
To: Jie Gan <jie.gan@oss.qualcomm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@arm.com>,
James Clark <james.clark@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coresight: platform: check the availability of the endpoint before parse
Date: Fri, 20 Mar 2026 09:23:37 +0000 [thread overview]
Message-ID: <20260320092337.GP8048@e132581.arm.com> (raw)
In-Reply-To: <519ca61b-049e-4e2f-a9fc-9b4621574470@oss.qualcomm.com>
Hi Jie,
On Fri, Mar 20, 2026 at 04:44:54PM +0800, Jie Gan wrote:
[...]
> It's about the coresight_find_device_by_fwnode() returns NULL, resulting in
> -EPROBE_DEFER. So the probe process will re-start after several seconds, but
> always failed because we have a "disabled" device node in DT(we can see this
> device in DT, but it never becomes available). It's ok if the device only
> has one remote device, but has issue with more than one remote devices.
>
> Consider below situation:
>
> device0
> | |
> device1 device2(status = "disabled")
>
> The probe of device0 succeeds only when device1 and device2 are available at
> probe time. But I think it's ok to probe the device0 only with device1
> available.
Thanks a lot for details. We might need to report warning or error if
all remote endpoints fail (e.g., device1/device2 both are disabled),
this is a rare case so would be low priority.
For this patch:
Reviewed-by: Leo Yan <leo.yan@arm.com>
prev parent reply other threads:[~2026-03-20 9:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 7:31 [PATCH] coresight: platform: check the availability of the endpoint before parse Jie Gan
2026-03-20 8:25 ` Leo Yan
2026-03-20 8:44 ` Jie Gan
2026-03-20 9:23 ` Leo Yan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260320092337.GP8048@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=james.clark@linaro.org \
--cc=jie.gan@oss.qualcomm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.leach@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tingwei.zhang@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox