From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Frank Li <Frank.li@nxp.com>
Cc: linux-renesas-soc@vger.kernel.org,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH] i3c: don't fail if GETHDRCAP is unsupported
Date: Wed, 25 Jun 2025 18:41:37 +0200 [thread overview]
Message-ID: <aFwmwduUm8KuJlny@shikoro> (raw)
In-Reply-To: <aFwUx65gdpv6H6rU@lizhi-Precision-Tower-5810>
> > If a target has the HDR_CAP bit set in BCR, the core wants to get
> > additional information using the CCC 'GETHDRCAP'. Not all controllers
> > support this CCC, though.
>
> Do you know which target device support HDR? I3C master API don't HDR yet.
The problem is bigger but I didn't want to tackle all of it right now.
'I3C_BCR_HDR_CAP' is still spec v1.0 and has been renamed to 'advanced
capabilities' in v1.1 onwards. That means the CCC was also modified to
get the advanced caps (while it is backwards compatible if you only read
the first byte I have been told, didn't check). So, if you get the ST
pressure sensor LPS22DF, it will not have HDR, but it will have the
'advanced cap' bit set.
Because my controller neither supports old GETHDRCAP nor new GETCAPS
CCC, it will bail out and not instantiate the device. Which is wrong,
because we can deal with it good enough without the extended
capabilities.
Maybe I should update the commit message a bit?
> This is not fatal and can be safely skipped, as the information is not
> necessary if HDR is unsupported by the controller anyway.
It is fatal because the target device is not instantiated while it
could be. I tested it.
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2025-06-25 20:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 7:34 [PATCH] i3c: don't fail if GETHDRCAP is unsupported Wolfram Sang
2025-06-25 15:24 ` Frank Li
2025-06-25 16:41 ` Wolfram Sang [this message]
2025-06-26 2:46 ` Joshua Yeong
2025-07-03 6:41 ` Wolfram Sang
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=aFwmwduUm8KuJlny@shikoro \
--to=wsa+renesas@sang-engineering.com \
--cc=Frank.li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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