Thanks Rob !
On 2/12/2025 3:09 AM, Rob Herring wrote:
On Mon, Feb 10, 2025 at 09:42:03PM +0530, Mukesh Kumar Savaliya wrote:
Thanks Krzysztof !
On 2/9/2025 5:15 PM, Krzysztof Kozlowski wrote:
On 06/02/2025 14:43, Mukesh Kumar Savaliya wrote:
Hi Krzysztof, Thanks !
On 2/5/2025 8:12 PM, Krzysztof Kozlowski wrote:
On 05/02/2025 15:31, Mukesh Kumar Savaliya wrote:
Add device tree bindings for the Qualcomm I3C master controller. This
includes the necessary documentation and properties required to describe
the hardware in the device tree.
A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.
Sure
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Use modern terminology, which means:
s/master/whatever else or even nothing/
See other recent bindings and discussions.
Sure
Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@xxxxxxxxxxx>
---
.../bindings/i3c/qcom,i3c-master.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/qcom,i3c-master.yaml
diff --git a/Documentation/devicetree/bindings/i3c/qcom,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/qcom,i3c-master.yaml
new file mode 100644
index 000000000000..ad63ea779fd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/qcom,i3c-master.yaml
Filename matching compatible.
Changed compatible to "qcom,i3c-master"
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/qcom,i3c-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm I3C master controller
+
+maintainers:
+ - Mukesh Kumar Savaliya <quic_msavaliy@xxxxxxxxxxx>
+
+allOf:
+ - $ref: i3c.yaml#
+
+properties:
+ compatible:
+ const: qcom,geni-i3c
No SoC? So to be sure: you claim all future SoCs will be using exactly
the same interface. No new compatibles, no new properties will be added.
I think i should remove const. kept it for now as no other compatible to
be added as of now.
let me remove const.
No, it does not matter. Keep const.
Sure. I reviewed other files and seems i should write as below. Please help
confirm.
compatible:
items:
- enum:
- qcom,sm8550-i3c-master
- const: qcom,i3c-master
No, that's even worse. I doubt there is some universal, never changing
QCom I3C master.
Agree, it may change. So can i go with "qcom, i3c-master" now instead of
going SOC specific name ? The current i2c and spi qcom drivers are also
using "qcom, geno-proto".
Since other i3c drivers using "vendor, i3c-master", i followed same.
Should i use "qcom, geni-i3c" or "qcom, i3c-master". Accordingly i can
make next patch.
SoC name is not required, as this compatible is generic to all the SOCs.
That's the statement you make. I accept it. I will bookmark this thread
and use it whenever you try to add any future property here (to be
clear: you agree you will not add new properties to fulfill *FUTURE* SoC
differences).
Sorry, i am not saying there won't be any other compatible but i was saying
base driver will use "qcom,i3c-master".
After checking other files i realized there can be const compatible but
other SOC specific can be added as enum. Hope above given way is fine.
AIUI, "geni" is some firmware based multi-protocol serial i/o controller
and we already have other "geni" bindings. So really, it's probably more
coupled to firmware versions than SoC versions. If we haven't had
problems with per SoC quirks with the other geni bindings, then I think
using the same "geni" here is fine. But we won't be happy if we start
seeing per SoC quirk properties.
Yes, was trying to follow same like geni based i2c, spi.
SOC specific can come, but that would be kind of variant which may
depend on QUP GENI HW version or FW version.
Rob
