i.MX95 System Manager Firmware support vendor extension protocol:
- Battery Backed Module(BBM) Protocol for RTC and BUTTON feature.
- MISC Protocol for misc settings, such as BLK CTRL GPR settings, GPIO
expander settings.
This patchset is to support the two protocols and users that use the
protocols.
Signed-off-by: Peng Fan <[email protected]>
To: Rob Herring <[email protected]>
To: Krzysztof Kozlowski <[email protected]>
To: Conor Dooley <[email protected]>
To: Shawn Guo <[email protected]>
To: Sascha Hauer <[email protected]>
To: Pengutronix Kernel Team <[email protected]>
To: Fabio Estevam <[email protected]>
To: Peng Fan <[email protected]>
To: Sudeep Holla <[email protected]>
To: Cristian Marussi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Changes in v2:
- Sorry for late update since v1.
- Add a new patch 1
- Address imx,scmi.yaml issues
- Address comments for imx-sm-bbm.c and imx-sm-misc.c
- I not add vendor id since related patches not landed in linux-next.
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Peng Fan (6):
dt-bindings: firmware: arm,scmi: set additionalProperties to true
dt-bindings: firmware: add i.MX SCMI Extension protocol
firmware: arm_scmi: add initial support for i.MX BBM protocol
firmware: arm_scmi: add initial support for i.MX MISC protocol
firmware: imx: support BBM module
firmware: imx: add i.MX95 MISC driver
.../devicetree/bindings/firmware/arm,scmi.yaml | 2 +-
.../devicetree/bindings/firmware/imx,scmi.yaml | 80 +++++
drivers/firmware/arm_scmi/Kconfig | 20 ++
drivers/firmware/arm_scmi/Makefile | 2 +
drivers/firmware/arm_scmi/imx-sm-bbm.c | 378 +++++++++++++++++++++
drivers/firmware/arm_scmi/imx-sm-misc.c | 305 +++++++++++++++++
drivers/firmware/imx/Makefile | 2 +
drivers/firmware/imx/sm-bbm.c | 317 +++++++++++++++++
drivers/firmware/imx/sm-misc.c | 92 +++++
include/linux/firmware/imx/sm.h | 33 ++
include/linux/scmi_imx_protocol.h | 62 ++++
11 files changed, 1292 insertions(+), 1 deletion(-)
---
base-commit: 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd
change-id: 20240405-imx95-bbm-misc-v2-b5e9d24adc42
Best regards,
--
Peng Fan <[email protected]>
From: Peng Fan <[email protected]>
Add i.MX SCMI Extension protocols bindings for:
- Battery Backed Secure Module(BBSM)
- MISC settings such as General Purpose Registers settings.
Signed-off-by: Peng Fan <[email protected]>
---
.../devicetree/bindings/firmware/imx,scmi.yaml | 80 ++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
new file mode 100644
index 000000000000..7ee19a661d83
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2024 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/imx,scmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX System Control and Management Interface(SCMI) Vendor Protocols Extension
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+allOf:
+ - $ref: arm,scmi.yaml#
+
+properties:
+ protocol@81:
+ $ref: 'arm,scmi.yaml#/$defs/protocol-node'
+ unevaluatedProperties: false
+ description:
+ The BBM Protocol is for managing Battery Backed Secure Module (BBSM) RTC
+ and the ON/OFF Key
+
+ properties:
+ reg:
+ const: 0x81
+
+ required:
+ - reg
+
+ protocol@84:
+ $ref: 'arm,scmi.yaml#/$defs/protocol-node'
+ unevaluatedProperties: false
+ description:
+ The MISC Protocol is for managing SoC Misc settings, such as GPR settings
+
+ properties:
+ reg:
+ const: 0x84
+
+ wakeup-sources:
+ description:
+ Each entry consists of 2 integers, represents the source and electric signal edge
+ items:
+ items:
+ - description: the wakeup source
+ - description: the wakeup electric signal edge
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
+ shmem = <&scmi_buf0>, <&scmi_buf1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ protocol@81 {
+ reg = <0x81>;
+ };
+
+ protocol@84 {
+ reg = <0x84>;
+ wakeup-sources = <0x8000 1
+ 0x8001 1
+ 0x8002 1
+ 0x8003 1
+ 0x8004 1>;
+ };
+ };
+ };
+...
--
2.37.1
From: Peng Fan <[email protected]>
The BBM module provides RTC and BUTTON feature. To i.MX95, this module
is managed by System Manager. Linux could use i.MX SCMI BBM Extension
protocol to use RTC and BUTTON feature.
This driver is to use SCMI interface to get/set RTC, enable pwrkey.
Signed-off-by: Peng Fan <[email protected]>
---
drivers/firmware/imx/Makefile | 1 +
drivers/firmware/imx/sm-bbm.c | 317 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 318 insertions(+)
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 8f9f04a513a8..fb20e22074e1 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o imx-scu-soc.o
+obj-${CONFIG_IMX_SCMI_BBM_EXT} += sm-bbm.o
diff --git a/drivers/firmware/imx/sm-bbm.c b/drivers/firmware/imx/sm-bbm.c
new file mode 100644
index 000000000000..fcb2ae8490c8
--- /dev/null
+++ b/drivers/firmware/imx/sm-bbm.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2024 NXP.
+ */
+
+#include <linux/input.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+#include <linux/suspend.h>
+
+#define DEBOUNCE_TIME 30
+#define REPEAT_INTERVAL 60
+
+struct scmi_imx_bbm {
+ struct rtc_device *rtc_dev;
+ struct scmi_protocol_handle *ph;
+ const struct scmi_imx_bbm_proto_ops *ops;
+ struct notifier_block nb;
+ int keycode;
+ int keystate; /* 1:pressed */
+ bool suspended;
+ struct delayed_work check_work;
+ struct input_dev *input;
+};
+
+static int scmi_imx_bbm_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+ struct scmi_protocol_handle *ph = bbnsm->ph;
+ u64 val;
+ int ret;
+
+ ret = bbnsm->ops->rtc_time_get(ph, 0, &val);
+ if (ret)
+ dev_err(dev, "%s: %d\n", __func__, ret);
+
+ rtc_time64_to_tm(val, tm);
+
+ return 0;
+}
+
+static int scmi_imx_bbm_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+ struct scmi_protocol_handle *ph = bbnsm->ph;
+ u64 val;
+ int ret;
+
+ val = rtc_tm_to_time64(tm);
+
+ ret = bbnsm->ops->rtc_time_set(ph, 0, val);
+ if (ret)
+ dev_err(dev, "%s: %d\n", __func__, ret);
+
+ return 0;
+}
+
+static int scmi_imx_bbm_alarm_irq_enable(struct device *dev, unsigned int enable)
+{
+ return 0;
+}
+
+static int scmi_imx_bbm_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+ struct scmi_protocol_handle *ph = bbnsm->ph;
+ struct rtc_time *alrm_tm = &alrm->time;
+ u64 val;
+ int ret;
+
+ val = rtc_tm_to_time64(alrm_tm);
+
+ ret = bbnsm->ops->rtc_alarm_set(ph, 0, val);
+ if (ret)
+ dev_err(dev, "%s: %d\n", __func__, ret);
+
+ return 0;
+}
+
+static const struct rtc_class_ops smci_imx_bbm_rtc_ops = {
+ .read_time = scmi_imx_bbm_read_time,
+ .set_time = scmi_imx_bbm_set_time,
+ .set_alarm = scmi_imx_bbm_set_alarm,
+ .alarm_irq_enable = scmi_imx_bbm_alarm_irq_enable,
+};
+
+static void scmi_imx_bbm_pwrkey_check_for_events(struct work_struct *work)
+{
+ struct scmi_imx_bbm *bbnsm = container_of(work, struct scmi_imx_bbm, check_work.work);
+ struct scmi_protocol_handle *ph = bbnsm->ph;
+ struct input_dev *input = bbnsm->input;
+ u32 state = 0;
+ int ret;
+
+ ret = bbnsm->ops->button_get(ph, &state);
+ if (ret) {
+ pr_err("%s: %d\n", __func__, ret);
+ return;
+ }
+
+ pr_debug("%s: state: %d, keystate %d\n", __func__, state, bbnsm->keystate);
+
+ /* only report new event if status changed */
+ if (state ^ bbnsm->keystate) {
+ bbnsm->keystate = state;
+ input_event(input, EV_KEY, bbnsm->keycode, state);
+ input_sync(input);
+ pm_relax(bbnsm->input->dev.parent);
+ pr_debug("EV_KEY: %x\n", bbnsm->keycode);
+ }
+
+ /* repeat check if pressed long */
+ if (state)
+ schedule_delayed_work(&bbnsm->check_work, msecs_to_jiffies(REPEAT_INTERVAL));
+}
+
+static int scmi_imx_bbm_pwrkey_event(struct scmi_imx_bbm *bbnsm)
+{
+ struct input_dev *input = bbnsm->input;
+
+ schedule_delayed_work(&bbnsm->check_work, msecs_to_jiffies(DEBOUNCE_TIME));
+
+ /*
+ * Directly report key event after resume to make no key press
+ * event is missed.
+ */
+ if (bbnsm->suspended) {
+ bbnsm->keystate = 1;
+ input_event(input, EV_KEY, bbnsm->keycode, 1);
+ input_sync(input);
+ }
+
+ return 0;
+}
+
+static void scmi_imx_bbm_pwrkey_act(void *pdata)
+{
+ struct scmi_imx_bbm *bbnsm = pdata;
+
+ cancel_delayed_work_sync(&bbnsm->check_work);
+}
+
+static int scmi_imx_bbm_notifier(struct notifier_block *nb, unsigned long event, void *data)
+{
+ struct scmi_imx_bbm *bbnsm = container_of(nb, struct scmi_imx_bbm, nb);
+ struct scmi_imx_bbm_notif_report *r = data;
+
+ if (r->is_rtc)
+ rtc_update_irq(bbnsm->rtc_dev, 1, RTC_AF | RTC_IRQF);
+ if (r->is_button) {
+ pr_debug("BBM Button Power key pressed\n");
+ scmi_imx_bbm_pwrkey_event(bbnsm);
+ }
+
+ return 0;
+}
+
+static int scmi_imx_bbm_pwrkey_init(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+ struct device *dev = &sdev->dev;
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+ struct input_dev *input;
+ int ret;
+
+ if (device_property_read_u32(dev, "linux,code", &bbnsm->keycode)) {
+ bbnsm->keycode = KEY_POWER;
+ dev_warn(dev, "key code is not specified, using default KEY_POWER\n");
+ }
+
+ INIT_DELAYED_WORK(&bbnsm->check_work, scmi_imx_bbm_pwrkey_check_for_events);
+
+ input = devm_input_allocate_device(dev);
+ if (!input) {
+ dev_err(dev, "failed to allocate the input device for SCMI IMX BBM\n");
+ return -ENOMEM;
+ }
+
+ input->name = dev_name(dev);
+ input->phys = "bbnsm-pwrkey/input0";
+ input->id.bustype = BUS_HOST;
+
+ input_set_capability(input, EV_KEY, bbnsm->keycode);
+
+ ret = devm_add_action_or_reset(dev, scmi_imx_bbm_pwrkey_act, bbnsm);
+ if (ret) {
+ dev_err(dev, "failed to register remove action\n");
+ return ret;
+ }
+
+ bbnsm->input = input;
+
+ ret = handle->notify_ops->devm_event_notifier_register(sdev, SCMI_PROTOCOL_IMX_BBM,
+ SCMI_EVENT_IMX_BBM_BUTTON,
+ NULL, &bbnsm->nb);
+
+ if (ret)
+ dev_err(dev, "Failed to register BBM Button Events %d:", ret);
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(dev, "failed to register input device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int scmi_imx_bbm_rtc_init(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+ struct device *dev = &sdev->dev;
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+ int ret;
+
+ bbnsm->rtc_dev = devm_rtc_allocate_device(dev);
+ if (IS_ERR(bbnsm->rtc_dev))
+ return PTR_ERR(bbnsm->rtc_dev);
+
+ bbnsm->rtc_dev->ops = &smci_imx_bbm_rtc_ops;
+ bbnsm->rtc_dev->range_min = 0;
+ bbnsm->rtc_dev->range_max = U32_MAX;
+
+ ret = devm_rtc_register_device(bbnsm->rtc_dev);
+ if (ret)
+ return ret;
+
+ bbnsm->nb.notifier_call = &scmi_imx_bbm_notifier;
+ return handle->notify_ops->devm_event_notifier_register(sdev, SCMI_PROTOCOL_IMX_BBM,
+ SCMI_EVENT_IMX_BBM_RTC,
+ NULL, &bbnsm->nb);
+}
+
+static int scmi_imx_bbm_probe(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+ struct device *dev = &sdev->dev;
+ struct scmi_protocol_handle *ph;
+ struct scmi_imx_bbm *bbnsm;
+ int ret;
+
+ if (!handle)
+ return -ENODEV;
+
+ bbnsm = devm_kzalloc(dev, sizeof(struct scmi_imx_bbm), GFP_KERNEL);
+ if (!bbnsm)
+ return -ENOMEM;
+
+ bbnsm->ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_IMX_BBM, &ph);
+ if (IS_ERR(bbnsm->ops))
+ return PTR_ERR(bbnsm->ops);
+
+ bbnsm->ph = ph;
+
+ device_init_wakeup(dev, true);
+
+ dev_set_drvdata(dev, bbnsm);
+
+ ret = scmi_imx_bbm_rtc_init(sdev);
+ if (ret) {
+ dev_err(dev, "rtc init failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = scmi_imx_bbm_pwrkey_init(sdev);
+ if (ret) {
+ dev_err(dev, "pwr init failed: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused scmi_imx_bbm_suspend(struct device *dev)
+{
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+
+ bbnsm->suspended = true;
+
+ return 0;
+}
+
+static int __maybe_unused scmi_imx_bbm_resume(struct device *dev)
+{
+ struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
+
+ bbnsm->suspended = false;
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(scmi_imx_bbm_pm_ops, scmi_imx_bbm_suspend, scmi_imx_bbm_resume);
+
+static const struct scmi_device_id scmi_id_table[] = {
+ { SCMI_PROTOCOL_IMX_BBM, "imx-bbm" },
+ { },
+};
+MODULE_DEVICE_TABLE(scmi, scmi_id_table);
+
+static struct scmi_driver scmi_imx_bbm_driver = {
+ .driver = {
+ .pm = &scmi_imx_bbm_pm_ops,
+ },
+ .name = "scmi-imx-bbm",
+ .probe = scmi_imx_bbm_probe,
+ .id_table = scmi_id_table,
+};
+module_scmi_driver(scmi_imx_bbm_driver);
+
+MODULE_AUTHOR("Peng Fan <[email protected]>");
+MODULE_DESCRIPTION("IMX SM BBM driver");
+MODULE_LICENSE("GPL");
--
2.37.1
From: Peng Fan <[email protected]>
The i.MX95 System manager exports SCMI MISC protocol for linux to do
various settings, such as set board gpio expander as wakeup source.
The driver is to add the support.
Signed-off-by: Peng Fan <[email protected]>
---
drivers/firmware/imx/Makefile | 1 +
drivers/firmware/imx/sm-misc.c | 92 +++++++++++++++++++++++++++++++++++++++++
include/linux/firmware/imx/sm.h | 33 +++++++++++++++
3 files changed, 126 insertions(+)
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index fb20e22074e1..cb9c361d9b81 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o imx-scu-soc.o
obj-${CONFIG_IMX_SCMI_BBM_EXT} += sm-bbm.o
+obj-${CONFIG_IMX_SCMI_MISC_EXT} += sm-misc.o
diff --git a/drivers/firmware/imx/sm-misc.c b/drivers/firmware/imx/sm-misc.c
new file mode 100644
index 000000000000..a5609de426f6
--- /dev/null
+++ b/drivers/firmware/imx/sm-misc.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2024 NXP.
+ */
+
+#include <linux/firmware/imx/sm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+
+static const struct scmi_imx_misc_proto_ops *imx_misc_ctrl_ops;
+static struct scmi_protocol_handle *ph;
+struct notifier_block scmi_imx_misc_ctrl_nb;
+
+int scmi_imx_misc_ctrl_set(u32 id, u32 val)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_misc_ctrl_ops->misc_ctrl_set(ph, id, 1, &val);
+};
+EXPORT_SYMBOL(scmi_imx_misc_ctrl_set);
+
+int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_misc_ctrl_ops->misc_ctrl_get(ph, id, num, val);
+}
+EXPORT_SYMBOL(scmi_imx_misc_ctrl_get);
+
+static int scmi_imx_misc_ctrl_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ return 0;
+}
+
+static int scmi_imx_misc_ctrl_probe(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+ struct device_node *np = sdev->dev.of_node;
+ u32 src_id, evt_id, wu_num;
+ int ret, i;
+
+ if (!handle)
+ return -ENODEV;
+
+ imx_misc_ctrl_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_IMX_MISC, &ph);
+ if (IS_ERR(imx_misc_ctrl_ops))
+ return PTR_ERR(imx_misc_ctrl_ops);
+
+ scmi_imx_misc_ctrl_nb.notifier_call = &scmi_imx_misc_ctrl_notifier;
+ wu_num = of_property_count_u32_elems(np, "wakeup-sources");
+ if (wu_num % 2) {
+ dev_err(&sdev->dev, "Invalid wakeup-sources\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < wu_num; i += 2) {
+ WARN_ON(of_property_read_u32_index(np, "wakeup-sources", i, &src_id));
+ WARN_ON(of_property_read_u32_index(np, "wakeup-sources", i + 1, &evt_id));
+ ret = handle->notify_ops->devm_event_notifier_register(sdev, SCMI_PROTOCOL_IMX_MISC,
+ evt_id,
+ &src_id,
+ &scmi_imx_misc_ctrl_nb);
+ if (ret)
+ dev_err(&sdev->dev, "Failed to register scmi misc event: %d\n", src_id);
+ }
+
+ return 0;
+
+}
+
+static const struct scmi_device_id scmi_id_table[] = {
+ { SCMI_PROTOCOL_IMX_MISC, "imx-misc-ctrl" },
+ { },
+};
+MODULE_DEVICE_TABLE(scmi, scmi_id_table);
+
+static struct scmi_driver scmi_imx_misc_ctrl_driver = {
+ .name = "scmi-imx-misc-ctrl",
+ .probe = scmi_imx_misc_ctrl_probe,
+ .id_table = scmi_id_table,
+};
+module_scmi_driver(scmi_imx_misc_ctrl_driver);
+
+MODULE_AUTHOR("Peng Fan <[email protected]>");
+MODULE_DESCRIPTION("IMX SM MISC driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/firmware/imx/sm.h b/include/linux/firmware/imx/sm.h
new file mode 100644
index 000000000000..daad4bdf7d1c
--- /dev/null
+++ b/include/linux/firmware/imx/sm.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2024 NXP
+ */
+
+#ifndef _SCMI_IMX_H
+#define _SCMI_IMX_H
+
+#include <linux/bitfield.h>
+#include <linux/types.h>
+
+#define SCMI_IMX_CTRL_PDM_CLK_SEL 0 /* AON PDM clock sel */
+#define SCMI_IMX_CTRL_MQS1_SETTINGS 1 /* AON MQS settings */
+#define SCMI_IMX_CTRL_SAI1_MCLK 2 /* AON SAI1 MCLK */
+#define SCMI_IMX_CTRL_SAI3_MCLK 3 /* WAKE SAI3 MCLK */
+#define SCMI_IMX_CTRL_SAI4_MCLK 4 /* WAKE SAI4 MCLK */
+#define SCMI_IMX_CTRL_SAI5_MCLK 5 /* WAKE SAI5 MCLK */
+
+#if IS_ENABLED(CONFIG_IMX_SCMI_MISC_EXT)
+int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val);
+int scmi_imx_misc_ctrl_set(u32 id, u32 val);
+#else
+static inline int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_misc_ctrl_set(u32 id, u32 val);
+{
+ return -EOPNOTSUPP;
+}
+#endif
+#endif
--
2.37.1
From: Peng Fan <[email protected]>
When adding vendor extension protocols, there is dt-schema warning:
"
imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not match any
of the regexes: 'pinctrl-[0-9]+'
"
Set additionalProperties to true to address the issue.
Signed-off-by: Peng Fan <[email protected]>
---
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 4591523b51a0..cfc613b65585 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -247,7 +247,7 @@ properties:
reg:
const: 0x18
-additionalProperties: false
+additionalProperties: true
$defs:
protocol-node:
--
2.37.1
On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> When adding vendor extension protocols, there is dt-schema warning:
> "
> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not match any
> of the regexes: 'pinctrl-[0-9]+'
> "
>
> Set additionalProperties to true to address the issue.
I do not see anything addressed here, except making the binding
accepting anything anywhere...
Best regards,
Krzysztof
On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> Add i.MX SCMI Extension protocols bindings for:
> - Battery Backed Secure Module(BBSM)
Which is what?
> - MISC settings such as General Purpose Registers settings.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../devicetree/bindings/firmware/imx,scmi.yaml | 80 ++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> new file mode 100644
> index 000000000000..7ee19a661d83
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2024 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/imx,scmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX System Control and Management Interface(SCMI) Vendor Protocols Extension
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +allOf:
> + - $ref: arm,scmi.yaml#
Sorry, but arm,scmi is a final schema. Is your plan to define some
common part?
> +
> +properties:
> + protocol@81:
> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> + unevaluatedProperties: false
> + description:
> + The BBM Protocol is for managing Battery Backed Secure Module (BBSM) RTC
> + and the ON/OFF Key
> +
> + properties:
> + reg:
> + const: 0x81
> +
> + required:
> + - reg
> +
> + protocol@84:
> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> + unevaluatedProperties: false
> + description:
> + The MISC Protocol is for managing SoC Misc settings, such as GPR settings
Genera register is not a setting... this is a pleonasm. Please be more
specific what is the GPR, MISC protocol etc.
> +
> + properties:
> + reg:
> + const: 0x84
> +
> + wakeup-sources:
> + description:
> + Each entry consists of 2 integers, represents the source and electric signal edge
Can you answer questions from reviewers?
> + items:
> + items:
> + - description: the wakeup source
> + - description: the wakeup electric signal edge
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> + required:
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + firmware {
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
> + shmem = <&scmi_buf0>, <&scmi_buf1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + protocol@81 {
> + reg = <0x81>;
> + };
> +
> + protocol@84 {
> + reg = <0x84>;
> + wakeup-sources = <0x8000 1
> + 0x8001 1
> + 0x8002 1
> + 0x8003 1
> + 0x8004 1>;
Nothing improved... If you are going to ignore reviews, then you will
only get NAKed.
Best regards,
Krzysztof
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > When adding vendor extension protocols, there is dt-schema warning:
> > "
> > imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not match
> > any of the regexes: 'pinctrl-[0-9]+'
> > "
> >
> > Set additionalProperties to true to address the issue.
>
> I do not see anything addressed here, except making the binding accepting
> anything anywhere...
I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
With additionalProperties set to false, I not know how, please suggest.
Thanks,
Peng.
>
> Best regards,
> Krzysztof
> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > Add i.MX SCMI Extension protocols bindings for:
> > - Battery Backed Secure Module(BBSM)
>
> Which is what?
I should say BBM(BBSM + BBNSM), BBM has RTC and ON/OFF
key features, but BBM is managed by SCMI firmware and exported
to agent by BBM protocol. So add bindings for i.MX BBM protocol.
Is this ok?
>
> > - MISC settings such as General Purpose Registers settings.
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > .../devicetree/bindings/firmware/imx,scmi.yaml | 80
> ++++++++++++++++++++++
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > new file mode 100644
> > index 000000000000..7ee19a661d83
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > @@ -0,0 +1,80 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright 2024
> > +NXP %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
> C02%7Cp
> >
> +eng.fan%40nxp.com%7C5d16781d3eca425a342508dc562910b7%7C686ea
> 1d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C638479981570959816%7CUnknown%
> 7CTWFpbGZsb
> >
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D
> >
> +%7C0%7C%7C%7C&sdata=mWNwPvu2eyF18MroVOBHb%2Fjeo%2BIHfV5V
> h%2F9ebdx65MM
> > +%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7C5d16781d3eca425a342508dc562910b7%7C686ea1d3bc2b4c6fa
> 92cd99c5c
> >
> +301635%7C0%7C0%7C638479981570971949%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=v4XnGG00D4I8j5MJvDUVYMRTm7yRrvz0V3fUyc5KAAA%3D&reser
> ved=0
> > +
> > +title: i.MX System Control and Management Interface(SCMI) Vendor
> > +Protocols Extension
> > +
> > +maintainers:
> > + - Peng Fan <[email protected]>
> > +
> > +allOf:
> > + - $ref: arm,scmi.yaml#
>
> Sorry, but arm,scmi is a final schema. Is your plan to define some common
> part?
No. I just wanna add vendor extension per SCMI spec.
0x80-0xFF:
Reserved for vendor or platform-specific extensions to this interface
Each vendor may have different usage saying id 0x81, so I add
i.MX dt-schema file.
>
> > +
> > +properties:
> > + protocol@81:
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > + description:
> > + The BBM Protocol is for managing Battery Backed Secure Module
> (BBSM) RTC
> > + and the ON/OFF Key
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + required:
> > + - reg
> > +
> > + protocol@84:
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > + description:
> > + The MISC Protocol is for managing SoC Misc settings, such as
> > + GPR settings
>
> Genera register is not a setting... this is a pleonasm. Please be more specific
> what is the GPR, MISC protocol etc.
The MISC Protocol is for managing SoC Misc settings, such as SAI MCLK/MQS in
Always On domain BLK CTRL, SAI_CLK_SEL in WAKEUP BLK CTRL, gpio
expanders which is under control of SCMI firmware.
> > +
> > + properties:
> > + reg:
> > + const: 0x84
> > +
> > + wakeup-sources:
> > + description:
> > + Each entry consists of 2 integers, represents the source
> > + and electric signal edge
>
> Can you answer questions from reviewers?
Sorry. Is this ok?
minItems: 1
maxItems: 32
>
> > + items:
> > + items:
> > + - description: the wakeup source
> > + - description: the wakeup electric signal edge
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + required:
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + firmware {
> > + scmi {
> > + compatible = "arm,scmi";
>
> > + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
> > + shmem = <&scmi_buf0>, <&scmi_buf1>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + protocol@81 {
> > + reg = <0x81>;
> > + };
> > +
> > + protocol@84 {
> > + reg = <0x84>;
> > + wakeup-sources = <0x8000 1
> > + 0x8001 1
> > + 0x8002 1
> > + 0x8003 1
> > + 0x8004 1>;
>
> Nothing improved... If you are going to ignore reviews, then you will only get
> NAKed.
Sorry, you mean the examples, or the whole dt-schema?
Thanks,
Peng.
>
> Best regards,
> Krzysztof
> Subject: RE: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> > Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI
> > Extension protocol
> >
> > On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > From: Peng Fan <[email protected]>
> > >
> > > Add i.MX SCMI Extension protocols bindings for:
> > > - Battery Backed Secure Module(BBSM)
> >
> > Which is what?
>
> I should say BBM(BBSM + BBNSM), BBM has RTC and ON/OFF key features,
> but BBM is managed by SCMI firmware and exported to agent by BBM
> protocol. So add bindings for i.MX BBM protocol.
>
> Is this ok?
>
> >
> > > - MISC settings such as General Purpose Registers settings.
> > >
> > > Signed-off-by: Peng Fan <[email protected]>
> > > ---
> > > .../devicetree/bindings/firmware/imx,scmi.yaml | 80
> > ++++++++++++++++++++++
> > > 1 file changed, 80 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > > b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > > new file mode 100644
> > > index 000000000000..7ee19a661d83
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > > @@ -0,0 +1,80 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright
> > > +2024 NXP %YAML 1.2
> > > +---
> > > +$id:
> > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> > > +vi
> > >
> >
> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
> > C02%7Cp
> > >
> >
> +eng.fan%40nxp.com%7C5d16781d3eca425a342508dc562910b7%7C686ea
> > 1d3bc2b4c
> > >
> > +6fa92cd99c5c301635%7C0%7C0%7C638479981570959816%7CUnknown%
> > 7CTWFpbGZsb
> > >
> >
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > 0%3D
> > >
> >
> +%7C0%7C%7C%7C&sdata=mWNwPvu2eyF18MroVOBHb%2Fjeo%2BIHfV5V
> > h%2F9ebdx65MM
> > > +%3D&reserved=0
> > > +$schema:
> > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> > > +vi
> > > +cetree.org%2Fmeta-
> > schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> > >
> >
> +p.com%7C5d16781d3eca425a342508dc562910b7%7C686ea1d3bc2b4c6fa
> > 92cd99c5c
> > >
> >
> +301635%7C0%7C0%7C638479981570971949%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiM
> > >
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> > C%7C%7
> > >
> >
> +C&sdata=v4XnGG00D4I8j5MJvDUVYMRTm7yRrvz0V3fUyc5KAAA%3D&reser
> > ved=0
> > > +
> > > +title: i.MX System Control and Management Interface(SCMI) Vendor
> > > +Protocols Extension
> > > +
> > > +maintainers:
> > > + - Peng Fan <[email protected]>
> > > +
> > > +allOf:
> > > + - $ref: arm,scmi.yaml#
> >
> > Sorry, but arm,scmi is a final schema. Is your plan to define some
> > common part?
>
> No. I just wanna add vendor extension per SCMI spec.
>
> 0x80-0xFF:
> Reserved for vendor or platform-specific extensions to this interface
>
> Each vendor may have different usage saying id 0x81, so I add i.MX dt-
> schema file.
>
> >
> > > +
> > > +properties:
> > > + protocol@81:
> > > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > > + unevaluatedProperties: false
> > > + description:
> > > + The BBM Protocol is for managing Battery Backed Secure Module
> > (BBSM) RTC
> > > + and the ON/OFF Key
> > > +
> > > + properties:
> > > + reg:
> > > + const: 0x81
> > > +
> > > + required:
> > > + - reg
> > > +
> > > + protocol@84:
> > > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > > + unevaluatedProperties: false
> > > + description:
> > > + The MISC Protocol is for managing SoC Misc settings, such as
> > > + GPR settings
> >
> > Genera register is not a setting... this is a pleonasm. Please be more
> > specific what is the GPR, MISC protocol etc.
>
> The MISC Protocol is for managing SoC Misc settings, such as SAI MCLK/MQS
> in Always On domain BLK CTRL, SAI_CLK_SEL in WAKEUP BLK CTRL, gpio
> expanders which is under control of SCMI firmware.
>
> > > +
> > > + properties:
> > > + reg:
> > > + const: 0x84
> > > +
> > > + wakeup-sources:
> > > + description:
> > > + Each entry consists of 2 integers, represents the source
> > > + and electric signal edge
> >
> > Can you answer questions from reviewers?
>
> Sorry. Is this ok?
> minItems: 1
> maxItems: 32
>
> >
> > > + items:
> > > + items:
> > > + - description: the wakeup source
> > > + - description: the wakeup electric signal edge
> > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > > +
> > > + required:
> > > + - reg
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + firmware {
> > > + scmi {
> > > + compatible = "arm,scmi";
> >
> > > + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
> > > + shmem = <&scmi_buf0>, <&scmi_buf1>;
> > > +
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + protocol@81 {
> > > + reg = <0x81>;
> > > + };
> > > +
> > > + protocol@84 {
> > > + reg = <0x84>;
> > > + wakeup-sources = <0x8000 1
> > > + 0x8001 1
> > > + 0x8002 1
> > > + 0x8003 1
> > > + 0x8004 1>;
> >
> > Nothing improved... If you are going to ignore reviews, then you will
> > only get NAKed.
>
> Sorry, you mean the examples, or the whole dt-schema?
Missed Rob's comment, will use
< > for each entry.
Thanks,
Peng.
>
> Thanks,
> Peng.
> >
> > Best regards,
> > Krzysztof
On 07/04/2024 02:37, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>> From: Peng Fan <[email protected]>
>>>
>>> When adding vendor extension protocols, there is dt-schema warning:
>>> "
>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not match
>>> any of the regexes: 'pinctrl-[0-9]+'
>>> "
>>>
>>> Set additionalProperties to true to address the issue.
>>
>> I do not see anything addressed here, except making the binding accepting
>> anything anywhere...
>
> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
> a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>
> With additionalProperties set to false, I not know how, please suggest.
First of all, you cannot affect negatively existing devices (their
bindings) and your patch does exactly that. This should make you thing
what is the correct approach...
Rob gave you the comment about missing compatible - you still did not
address that.
You need common schema referenced in arm,scmi and your device specific
schema, also using it.
Best regards,
Krzysztof
On 07/04/2024 02:51, Peng Fan wrote:
>> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
>> protocol
>>
>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>> From: Peng Fan <[email protected]>
>>>
>>> Add i.MX SCMI Extension protocols bindings for:
>>> - Battery Backed Secure Module(BBSM)
>>
>> Which is what?
>
> I should say BBM(BBSM + BBNSM), BBM has RTC and ON/OFF
> key features, but BBM is managed by SCMI firmware and exported
> to agent by BBM protocol. So add bindings for i.MX BBM protocol.
>
> Is this ok?
No, I still don't know what is BBSM, BBNSM and BBM.
>
>>
>>> - MISC settings such as General Purpose Registers settings.
>>>
>>> Signed-off-by: Peng Fan <[email protected]>
>>> ---
>>> .../devicetree/bindings/firmware/imx,scmi.yaml | 80
>> ++++++++++++++++++++++
>>> 1 file changed, 80 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
>>> b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
>>> new file mode 100644
>>> index 000000000000..7ee19a661d83
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
>>> @@ -0,0 +1,80 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright 2024
>>> +NXP %YAML 1.2
>>> +---
>>> +$id:
>>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
>>>
>> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
>> C02%7Cp
>>>
>> +eng.fan%40nxp.com%7C5d16781d3eca425a342508dc562910b7%7C686ea
>> 1d3bc2b4c
>>>
>> +6fa92cd99c5c301635%7C0%7C0%7C638479981570959816%7CUnknown%
>> 7CTWFpbGZsb
>>>
>> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
>> 0%3D
>>>
>> +%7C0%7C%7C%7C&sdata=mWNwPvu2eyF18MroVOBHb%2Fjeo%2BIHfV5V
>> h%2F9ebdx65MM
>>> +%3D&reserved=0
>>> +$schema:
>>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
>>> +cetree.org%2Fmeta-
>> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
>>>
>> +p.com%7C5d16781d3eca425a342508dc562910b7%7C686ea1d3bc2b4c6fa
>> 92cd99c5c
>>>
>> +301635%7C0%7C0%7C638479981570971949%7CUnknown%7CTWFpbGZs
>> b3d8eyJWIjoiM
>>>
>> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
>> C%7C%7
>>>
>> +C&sdata=v4XnGG00D4I8j5MJvDUVYMRTm7yRrvz0V3fUyc5KAAA%3D&reser
>> ved=0
>>> +
>>> +title: i.MX System Control and Management Interface(SCMI) Vendor
>>> +Protocols Extension
>>> +
>>> +maintainers:
>>> + - Peng Fan <[email protected]>
>>> +
>>> +allOf:
>>> + - $ref: arm,scmi.yaml#
>>
>> Sorry, but arm,scmi is a final schema. Is your plan to define some common
>> part?
>
> No. I just wanna add vendor extension per SCMI spec.
>
> 0x80-0xFF:
> Reserved for vendor or platform-specific extensions to this interface
>
> Each vendor may have different usage saying id 0x81, so I add
> i.MX dt-schema file.
>
>>
>>> +
>>> +properties:
>>> + protocol@81:
>>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
>>> + unevaluatedProperties: false
>>> + description:
>>> + The BBM Protocol is for managing Battery Backed Secure Module
>> (BBSM) RTC
>>> + and the ON/OFF Key
>>> +
>>> + properties:
>>> + reg:
>>> + const: 0x81
>>> +
>>> + required:
>>> + - reg
>>> +
>>> + protocol@84:
>>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
>>> + unevaluatedProperties: false
>>> + description:
>>> + The MISC Protocol is for managing SoC Misc settings, such as
>>> + GPR settings
>>
>> Genera register is not a setting... this is a pleonasm. Please be more specific
>> what is the GPR, MISC protocol etc.
>
> The MISC Protocol is for managing SoC Misc settings, such as SAI MCLK/MQS in
> Always On domain BLK CTRL, SAI_CLK_SEL in WAKEUP BLK CTRL, gpio
> expanders which is under control of SCMI firmware.
So like a bag for everything which you do not want to call something
specific?
No, be specific...
>
>>> +
>>> + properties:
>>> + reg:
>>> + const: 0x84
>>> +
>>> + wakeup-sources:
>>> + description:
>>> + Each entry consists of 2 integers, represents the source
>>> + and electric signal edge
>>
>> Can you answer questions from reviewers?
>
> Sorry. Is this ok?
> minItems: 1
> maxItems: 32
No. Does it answers Rob's question? I see zero correlation to his question.
Do not ignore emails from reviewers but respond to them.
>
>>
>>> + items:
>>> + items:
>>> + - description: the wakeup source
>>> + - description: the wakeup electric signal edge
>>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>>> +
>>> + required:
>>> + - reg
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + firmware {
>>> + scmi {
>>> + compatible = "arm,scmi";
>>
>>> + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
>>> + shmem = <&scmi_buf0>, <&scmi_buf1>;
>>> +
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + protocol@81 {
>>> + reg = <0x81>;
>>> + };
>>> +
>>> + protocol@84 {
>>> + reg = <0x84>;
>>> + wakeup-sources = <0x8000 1
>>> + 0x8001 1
>>> + 0x8002 1
>>> + 0x8003 1
>>> + 0x8004 1>;
>>
>> Nothing improved... If you are going to ignore reviews, then you will only get
>> NAKed.
>
> Sorry, you mean the examples, or the whole dt-schema?
*Read comments and respond to them*. Regardless where they are.
Best regards,
Krzysztof
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 07/04/2024 02:37, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>> From: Peng Fan <[email protected]>
> >>>
> >>> When adding vendor extension protocols, there is dt-schema warning:
> >>> "
> >>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
> >>> match any of the regexes: 'pinctrl-[0-9]+'
> >>> "
> >>>
> >>> Set additionalProperties to true to address the issue.
> >>
> >> I do not see anything addressed here, except making the binding
> >> accepting anything anywhere...
> >
> > I not wanna add vendor protocols in arm,scmi.yaml, so will introduce a
> > new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
> >
> > With additionalProperties set to false, I not know how, please suggest.
>
> First of all, you cannot affect negatively existing devices (their
> bindings) and your patch does exactly that. This should make you thing what
> is the correct approach...
>
> Rob gave you the comment about missing compatible - you still did not
> address that.
I added the compatible in patch 2/6 in the examples "compatible = "arm,scmi";"
>
> You need common schema referenced in arm,scmi and your device specific
> schema, also using it.
ok, let me try to figure it out.
Thanks,
Peng.
>
>
> Best regards,
> Krzysztof
> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> On 07/04/2024 02:51, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI
> >> Extension protocol
> >>
> >> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>> From: Peng Fan <[email protected]>
> >>>
> >>> Add i.MX SCMI Extension protocols bindings for:
> >>> - Battery Backed Secure Module(BBSM)
> >>
> >> Which is what?
> >
> > I should say BBM(BBSM + BBNSM), BBM has RTC and ON/OFF key features,
> > but BBM is managed by SCMI firmware and exported to agent by BBM
> > protocol. So add bindings for i.MX BBM protocol.
> >
> > Is this ok?
>
> No, I still don't know what is BBSM, BBNSM and BBM.
From RM:
The Battery Backup (BB) Domain contains the Battery Backed
Security Module (BBSM) and the Battery Backed Non-Secure
Module (BBNSM).
BBNSM:
The BBNSM is the interface to a non-interruptable power
supply (backup battery) and serves as the non-volatile logic
and storage for the chip. When the chip is powered off, the
BBNSM will maintain PMIC logic while connected to a backup supply.
Main features: RTC, PMIC Control, ONOFF Control
BBSM serves as nonvolatile security logic and storage for ELE
Main features: Monotonic counter, Secure RTC,
Zeroizable Master Key,
Security Violation and Tamper Detection
>
> >
> >>
> >>> - MISC settings such as General Purpose Registers settings.
> >>>
> >>> Signed-off-by: Peng Fan <[email protected]>
> >>> ---
> >>> .../devicetree/bindings/firmware/imx,scmi.yaml | 80
> >> ++++++++++++++++++++++
> >>> 1 file changed, 80 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> new file mode 100644
> >>> index 000000000000..7ee19a661d83
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> @@ -0,0 +1,80 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright
> >>> +2024 NXP %YAML 1.2
> >>> +---
> >>> +$id:
> >>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> >>>
> +vi%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C410d9f1b5b874269dc6
> 908dc5
> >>>
> +6e0b628%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638480
> 77032584
> >>>
> +3394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLC
> >>>
> +JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e4zKRcyHbSCtn
> o6%2B%
> >>> +2BBaz%2FGhvPT0HikAdLmwi4VZxX4o%3D&reserved=0
> >>>
> >>
> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
> >> C02%7Cp
> >>>
> >>
> +eng.fan%40nxp.com%7C5d16781d3eca425a342508dc562910b7%7C686ea
> >> 1d3bc2b4c
> >>>
> >>
> +6fa92cd99c5c301635%7C0%7C0%7C638479981570959816%7CUnknown%
> >> 7CTWFpbGZsb
> >>>
> >>
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> >> 0%3D
> >>>
> >>
> +%7C0%7C%7C%7C&sdata=mWNwPvu2eyF18MroVOBHb%2Fjeo%2BIHfV5V
> >> h%2F9ebdx65MM
> >>> +%3D&reserved=0
> >>> +$schema:
> >>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> >>>
> +vi%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C410d9f1b5b874269dc6
> 908dc5
> >>>
> +6e0b628%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638480
> 77032585
> >>>
> +6477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLC
> >>>
> +JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=y1OBJ%2FPp4
> MljifpmG
> >>> +ZM%2FB6Ab20ivqm2qef7gzEjbNmA%3D&reserved=0
> >>> +cetree.org%2Fmeta-
> >> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >>>
> >>
> +p.com%7C5d16781d3eca425a342508dc562910b7%7C686ea1d3bc2b4c6fa
> >> 92cd99c5c
> >>>
> >>
> +301635%7C0%7C0%7C638479981570971949%7CUnknown%7CTWFpbGZs
> >> b3d8eyJWIjoiM
> >>>
> >>
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >> C%7C%7
> >>>
> >>
> +C&sdata=v4XnGG00D4I8j5MJvDUVYMRTm7yRrvz0V3fUyc5KAAA%3D&reser
> >> ved=0
> >>> +
> >>> +title: i.MX System Control and Management Interface(SCMI) Vendor
> >>> +Protocols Extension
> >>> +
> >>> +maintainers:
> >>> + - Peng Fan <[email protected]>
> >>> +
> >>> +allOf:
> >>> + - $ref: arm,scmi.yaml#
> >>
> >> Sorry, but arm,scmi is a final schema. Is your plan to define some
> >> common part?
> >
> > No. I just wanna add vendor extension per SCMI spec.
> >
> > 0x80-0xFF:
> > Reserved for vendor or platform-specific extensions to this interface
> >
> > Each vendor may have different usage saying id 0x81, so I add i.MX
> > dt-schema file.
> >
> >>
> >>> +
> >>> +properties:
> >>> + protocol@81:
> >>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> >>> + unevaluatedProperties: false
> >>> + description:
> >>> + The BBM Protocol is for managing Battery Backed Secure Module
> >> (BBSM) RTC
> >>> + and the ON/OFF Key
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + const: 0x81
> >>> +
> >>> + required:
> >>> + - reg
> >>> +
> >>> + protocol@84:
> >>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> >>> + unevaluatedProperties: false
> >>> + description:
> >>> + The MISC Protocol is for managing SoC Misc settings, such as
> >>> + GPR settings
> >>
> >> Genera register is not a setting... this is a pleonasm. Please be
> >> more specific what is the GPR, MISC protocol etc.
> >
> > The MISC Protocol is for managing SoC Misc settings, such as SAI
> > MCLK/MQS in Always On domain BLK CTRL, SAI_CLK_SEL in WAKEUP BLK
> > CTRL, gpio expanders which is under control of SCMI firmware.
>
> So like a bag for everything which you do not want to call something specific?
>
> No, be specific...
This is not linux stuff, this is i.MX SCMI firmware design.
Sadly there is no public RM for i.MX95, we could not afford each settings
has a protocol ID, it is too heavy. The name MISC is not developed for linux,
it is firmware owner decided to use it.
>
> >
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + const: 0x84
> >>> +
> >>> + wakeup-sources:
> >>> + description:
> >>> + Each entry consists of 2 integers, represents the source
> >>> + and electric signal edge
> >>
> >> Can you answer questions from reviewers?
> >
> > Sorry. Is this ok?
> > minItems: 1
> > maxItems: 32
>
> No. Does it answers Rob's question? I see zero correlation to his question.
Constraints and edge, right? Edge, I have use electric signal edge, so
what else?
>
> Do not ignore emails from reviewers but respond to them.
>
> >
> >>
> >>> + items:
> >>> + items:
> >>> + - description: the wakeup source
> >>> + - description: the wakeup electric signal edge
> >>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>> +
> >>> + required:
> >>> + - reg
> >>> +
> >>> +additionalProperties: false
> >>> +
> >>> +examples:
> >>> + - |
> >>> + firmware {
> >>> + scmi {
> >>> + compatible = "arm,scmi";
> >>
> >>> + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
> >>> + shmem = <&scmi_buf0>, <&scmi_buf1>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + protocol@81 {
> >>> + reg = <0x81>;
> >>> + };
> >>> +
> >>> + protocol@84 {
> >>> + reg = <0x84>;
> >>> + wakeup-sources = <0x8000 1
> >>> + 0x8001 1
> >>> + 0x8002 1
> >>> + 0x8003 1
> >>> + 0x8004 1>;
> >>
> >> Nothing improved... If you are going to ignore reviews, then you will
> >> only get NAKed.
> >
> > Sorry, you mean the examples, or the whole dt-schema?
>
> *Read comments and respond to them*. Regardless where they are.
Yeah. My bad.
Thanks,
Peng
>
> Best regards,
> Krzysztof
On 07/04/2024 12:04, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 07/04/2024 02:37, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>> From: Peng Fan <[email protected]>
>>>>>
>>>>> When adding vendor extension protocols, there is dt-schema warning:
>>>>> "
>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>> "
>>>>>
>>>>> Set additionalProperties to true to address the issue.
>>>>
>>>> I do not see anything addressed here, except making the binding
>>>> accepting anything anywhere...
>>>
>>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce a
>>> new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>>>
>>> With additionalProperties set to false, I not know how, please suggest.
>>
>> First of all, you cannot affect negatively existing devices (their
>> bindings) and your patch does exactly that. This should make you thing what
>> is the correct approach...
>>
>> Rob gave you the comment about missing compatible - you still did not
>> address that.
>
> I added the compatible in patch 2/6 in the examples "compatible = "arm,scmi";"
So you claim that your vendor extensions are the same or fully
compatible with arm,scmi and you add nothing... Are your
extensions/protocol valid for arm,scmi? If yes, why is this in separate
binding. If no, why you use someone else's compatible?
Maybe your binding is correct, feel free to convince me (and read first
writing bindings).
Best regards,
Krzysztof
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 07/04/2024 12:04, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 07/04/2024 02:37, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>> From: Peng Fan <[email protected]>
> >>>>>
> >>>>> When adding vendor extension protocols, there is dt-schema warning:
> >>>>> "
> >>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
> >>>>> match any of the regexes: 'pinctrl-[0-9]+'
> >>>>> "
> >>>>>
> >>>>> Set additionalProperties to true to address the issue.
> >>>>
> >>>> I do not see anything addressed here, except making the binding
> >>>> accepting anything anywhere...
> >>>
> >>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
> >>> a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
> >>>
> >>> With additionalProperties set to false, I not know how, please suggest.
> >>
> >> First of all, you cannot affect negatively existing devices (their
> >> bindings) and your patch does exactly that. This should make you
> >> thing what is the correct approach...
> >>
> >> Rob gave you the comment about missing compatible - you still did not
> >> address that.
> >
> > I added the compatible in patch 2/6 in the examples "compatible =
> "arm,scmi";"
>
> So you claim that your vendor extensions are the same or fully compatible
> with arm,scmi and you add nothing... Are your extensions/protocol valid for
> arm,scmi?
Yes. They are valid for arm,scmi.
If yes, why is this in separate binding. If no, why you use someone
> else's compatible?
Per SCMI Spec
0x80-0xFF: Reserved for vendor or platform-specific extensions to
this interface
i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
the id for their own protocol.
I use a separate binding here is to avoid add more vendor stuff
in arm,scmi.yaml. Otherwise we will have to add a list as:
if nxp
xxx
else if qcom
xxx
else if xx
yyy.
I could add back i.mx extension to arm,scmi.yaml if people
agree.
Thanks
Peng.
>
> Maybe your binding is correct, feel free to convince me (and read first writing
> bindings).
>
> Best regards,
> Krzysztof
On 08/04/2024 01:50, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 07/04/2024 12:04, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 07/04/2024 02:37, Peng Fan wrote:
>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>> additionalProperties to true
>>>>>>
>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>>>> From: Peng Fan <[email protected]>
>>>>>>>
>>>>>>> When adding vendor extension protocols, there is dt-schema warning:
>>>>>>> "
>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>>>> "
>>>>>>>
>>>>>>> Set additionalProperties to true to address the issue.
>>>>>>
>>>>>> I do not see anything addressed here, except making the binding
>>>>>> accepting anything anywhere...
>>>>>
>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
>>>>> a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>>>>>
>>>>> With additionalProperties set to false, I not know how, please suggest.
>>>>
>>>> First of all, you cannot affect negatively existing devices (their
>>>> bindings) and your patch does exactly that. This should make you
>>>> thing what is the correct approach...
>>>>
>>>> Rob gave you the comment about missing compatible - you still did not
>>>> address that.
>>>
>>> I added the compatible in patch 2/6 in the examples "compatible =
>> "arm,scmi";"
>>
>> So you claim that your vendor extensions are the same or fully compatible
>> with arm,scmi and you add nothing... Are your extensions/protocol valid for
>> arm,scmi?
>
> Yes. They are valid for arm,scmi.
>
> If yes, why is this in separate binding. If no, why you use someone
>> else's compatible?
>
> Per SCMI Spec
> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> this interface
>
> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> the id for their own protocol.
So how are they valid for arm,scmi? I don't understand.
Best regards,
Krzysztof
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 08/04/2024 01:50, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 07/04/2024 12:04, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>> From: Peng Fan <[email protected]>
> >>>>>>>
> >>>>>>> When adding vendor extension protocols, there is dt-schema
> warning:
> >>>>>>> "
> >>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
> >>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>> "
> >>>>>>>
> >>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>
> >>>>>> I do not see anything addressed here, except making the binding
> >>>>>> accepting anything anywhere...
> >>>>>
> >>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> extension.
> >>>>>
> >>>>> With additionalProperties set to false, I not know how, please suggest.
> >>>>
> >>>> First of all, you cannot affect negatively existing devices (their
> >>>> bindings) and your patch does exactly that. This should make you
> >>>> thing what is the correct approach...
> >>>>
> >>>> Rob gave you the comment about missing compatible - you still did
> >>>> not address that.
> >>>
> >>> I added the compatible in patch 2/6 in the examples "compatible =
> >> "arm,scmi";"
> >>
> >> So you claim that your vendor extensions are the same or fully
> >> compatible with arm,scmi and you add nothing... Are your
> >> extensions/protocol valid for arm,scmi?
> >
> > Yes. They are valid for arm,scmi.
> >
> > If yes, why is this in separate binding. If no, why you use someone
> >> else's compatible?
> >
> > Per SCMI Spec
> > 0x80-0xFF: Reserved for vendor or platform-specific extensions to this
> > interface
> >
> > i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> > id for their own protocol.
>
> So how are they valid for arm,scmi? I don't understand.
arm,scmi is a firmware compatible string. The protocol node is a sub-node.
I think the arm,scmi is that saying the firmware following
SCMI spec to implement the protocols.
For vendor reserved ID, firmware also follow the SCMI spec to implement
their own usage, so from firmware level, it is ARM SCMI spec compatible.
firmware {
scmi {
compatible = "arm,scmi";
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sys_power: protocol@12 {
reg = <0x12>;
};
scmi_perf: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
Scmi_bbm: protocol@81 {
reg = <0x81>; ->vendor id
vendor,xyz; ---> vendor properties.
}
Thanks,
Peng.
>
>
>
> Best regards,
> Krzysztof
On 08/04/2024 08:08, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 08/04/2024 01:50, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 07/04/2024 12:04, Peng Fan wrote:
>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>> additionalProperties to true
>>>>>>
>>>>>> On 07/04/2024 02:37, Peng Fan wrote:
>>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>>>> additionalProperties to true
>>>>>>>>
>>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>>>>>> From: Peng Fan <[email protected]>
>>>>>>>>>
>>>>>>>>> When adding vendor extension protocols, there is dt-schema
>> warning:
>>>>>>>>> "
>>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>>>>>> "
>>>>>>>>>
>>>>>>>>> Set additionalProperties to true to address the issue.
>>>>>>>>
>>>>>>>> I do not see anything addressed here, except making the binding
>>>>>>>> accepting anything anywhere...
>>>>>>>
>>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
>>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
>> extension.
>>>>>>>
>>>>>>> With additionalProperties set to false, I not know how, please suggest.
>>>>>>
>>>>>> First of all, you cannot affect negatively existing devices (their
>>>>>> bindings) and your patch does exactly that. This should make you
>>>>>> thing what is the correct approach...
>>>>>>
>>>>>> Rob gave you the comment about missing compatible - you still did
>>>>>> not address that.
>>>>>
>>>>> I added the compatible in patch 2/6 in the examples "compatible =
>>>> "arm,scmi";"
>>>>
>>>> So you claim that your vendor extensions are the same or fully
>>>> compatible with arm,scmi and you add nothing... Are your
>>>> extensions/protocol valid for arm,scmi?
>>>
>>> Yes. They are valid for arm,scmi.
>>>
>>> If yes, why is this in separate binding. If no, why you use someone
>>>> else's compatible?
>>>
>>> Per SCMI Spec
>>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to this
>>> interface
>>>
>>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
>>> id for their own protocol.
>>
>> So how are they valid for arm,scmi? I don't understand.
>
> arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> I think the arm,scmi is that saying the firmware following
> SCMI spec to implement the protocols.
>
> For vendor reserved ID, firmware also follow the SCMI spec to implement
> their own usage, so from firmware level, it is ARM SCMI spec compatible.
That's not the point. It is obvious that your firmware is compatible
with arm,scmi, but what you try to say in this and revised patch is that
every arm,scmi is compatible with your implementation. What you are
saying is that 0x84 is MISC protocol for every firmware, Qualcomm, NXP,
Samsung, TI, Mediatek etc.
I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
Best regards,
Krzysztof
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 08/04/2024 08:08, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 08/04/2024 01:50, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 12:04, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> >>>>>>>> set additionalProperties to true
> >>>>>>>>
> >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>>>> From: Peng Fan <[email protected]>
> >>>>>>>>>
> >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> >> warning:
> >>>>>>>>> "
> >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>>>> "
> >>>>>>>>>
> >>>>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>>>
> >>>>>>>> I do not see anything addressed here, except making the binding
> >>>>>>>> accepting anything anywhere...
> >>>>>>>
> >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> >> extension.
> >>>>>>>
> >>>>>>> With additionalProperties set to false, I not know how, please
> suggest.
> >>>>>>
> >>>>>> First of all, you cannot affect negatively existing devices
> >>>>>> (their
> >>>>>> bindings) and your patch does exactly that. This should make you
> >>>>>> thing what is the correct approach...
> >>>>>>
> >>>>>> Rob gave you the comment about missing compatible - you still did
> >>>>>> not address that.
> >>>>>
> >>>>> I added the compatible in patch 2/6 in the examples "compatible =
> >>>> "arm,scmi";"
> >>>>
> >>>> So you claim that your vendor extensions are the same or fully
> >>>> compatible with arm,scmi and you add nothing... Are your
> >>>> extensions/protocol valid for arm,scmi?
> >>>
> >>> Yes. They are valid for arm,scmi.
> >>>
> >>> If yes, why is this in separate binding. If no, why you use someone
> >>>> else's compatible?
> >>>
> >>> Per SCMI Spec
> >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> >>> this interface
> >>>
> >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> >>> id for their own protocol.
> >>
> >> So how are they valid for arm,scmi? I don't understand.
> >
> > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > I think the arm,scmi is that saying the firmware following SCMI spec
> > to implement the protocols.
> >
> > For vendor reserved ID, firmware also follow the SCMI spec to
> > implement their own usage, so from firmware level, it is ARM SCMI spec
> compatible.
>
> That's not the point. It is obvious that your firmware is compatible with
> arm,scmi, but what you try to say in this and revised patch is that every
> arm,scmi is compatible with your implementation. What you are saying is
> that 0x84 is MISC protocol for every firmware, Qualcomm, NXP, Samsung, TI,
> Mediatek etc.
>
> I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
You are right. I am lost now on how to add vendor ID support, using
arm,scmi.yaml or adding a new imx,scmi.yaml or else.
Please suggest.
Thanks,
Peng
>
> Best regards,
> Krzysztof
Hi Krzysztof,
> Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > On 08/04/2024 08:08, Peng Fan wrote:
> > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >> additionalProperties to true
> > >>
> > >> On 08/04/2024 01:50, Peng Fan wrote:
> > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >>>> additionalProperties to true
> > >>>>
> > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>> set additionalProperties to true
> > >>>>>>
> > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>>>> set additionalProperties to true
> > >>>>>>>>
> > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > >>>>>>>>> From: Peng Fan <[email protected]>
> > >>>>>>>>>
> > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > >> warning:
> > >>>>>>>>> "
> > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > >>>>>>>>> "
> > >>>>>>>>>
> > >>>>>>>>> Set additionalProperties to true to address the issue.
> > >>>>>>>>
> > >>>>>>>> I do not see anything addressed here, except making the
> > >>>>>>>> binding accepting anything anywhere...
> > >>>>>>>
> > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > >>>>>>> protocol
> > >> extension.
> > >>>>>>>
> > >>>>>>> With additionalProperties set to false, I not know how, please
> > suggest.
> > >>>>>>
> > >>>>>> First of all, you cannot affect negatively existing devices
> > >>>>>> (their
> > >>>>>> bindings) and your patch does exactly that. This should make
> > >>>>>> you thing what is the correct approach...
> > >>>>>>
> > >>>>>> Rob gave you the comment about missing compatible - you still
> > >>>>>> did not address that.
> > >>>>>
> > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > >>>>> =
> > >>>> "arm,scmi";"
> > >>>>
> > >>>> So you claim that your vendor extensions are the same or fully
> > >>>> compatible with arm,scmi and you add nothing... Are your
> > >>>> extensions/protocol valid for arm,scmi?
> > >>>
> > >>> Yes. They are valid for arm,scmi.
> > >>>
> > >>> If yes, why is this in separate binding. If no, why you use
> > >>> someone
> > >>>> else's compatible?
> > >>>
> > >>> Per SCMI Spec
> > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > >>> this interface
> > >>>
> > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > >>> the id for their own protocol.
> > >>
> > >> So how are they valid for arm,scmi? I don't understand.
> > >
> > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > to implement the protocols.
> > >
> > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > implement their own usage, so from firmware level, it is ARM SCMI
> > > spec
> > compatible.
> >
> > That's not the point. It is obvious that your firmware is compatible
> > with arm,scmi, but what you try to say in this and revised patch is
> > that every arm,scmi is compatible with your implementation. What you
> > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > NXP, Samsung, TI, Mediatek etc.
> >
> > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
>
> You are right. I am lost now on how to add vendor ID support, using
> arm,scmi.yaml or adding a new imx,scmi.yaml or else.
Do you have any suggestions on how to add vendor protocol in
dt-schema? I am not sure what to do next, still keep imx,scmi.yaml
or add vendor stuff in arm,scmi.yaml?
Thanks,
Peng.
>
> Please suggest.
>
> Thanks,
> Peng
> >
> > Best regards,
> > Krzysztof
On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> Hi Krzysztof,
>
> > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > additionalProperties to true
> > >
> > > On 08/04/2024 08:08, Peng Fan wrote:
> > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >> additionalProperties to true
> > > >>
> > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >>>> additionalProperties to true
> > > >>>>
> > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>> set additionalProperties to true
> > > >>>>>>
> > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>>>> set additionalProperties to true
> > > >>>>>>>>
> > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > >>>>>>>>> From: Peng Fan <[email protected]>
> > > >>>>>>>>>
> > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > >> warning:
> > > >>>>>>>>> "
> > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > >>>>>>>>> "
> > > >>>>>>>>>
> > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > >>>>>>>>
> > > >>>>>>>> I do not see anything addressed here, except making the
> > > >>>>>>>> binding accepting anything anywhere...
> > > >>>>>>>
> > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > >>>>>>> protocol
> > > >> extension.
> > > >>>>>>>
> > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > suggest.
> > > >>>>>>
> > > >>>>>> First of all, you cannot affect negatively existing devices
> > > >>>>>> (their
> > > >>>>>> bindings) and your patch does exactly that. This should make
> > > >>>>>> you thing what is the correct approach...
> > > >>>>>>
> > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > >>>>>> did not address that.
> > > >>>>>
> > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > >>>>> =
> > > >>>> "arm,scmi";"
> > > >>>>
> > > >>>> So you claim that your vendor extensions are the same or fully
> > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > >>>> extensions/protocol valid for arm,scmi?
> > > >>>
> > > >>> Yes. They are valid for arm,scmi.
> > > >>>
> > > >>> If yes, why is this in separate binding. If no, why you use
> > > >>> someone
> > > >>>> else's compatible?
> > > >>>
> > > >>> Per SCMI Spec
> > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > >>> this interface
> > > >>>
> > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > >>> the id for their own protocol.
> > > >>
> > > >> So how are they valid for arm,scmi? I don't understand.
> > > >
> > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > to implement the protocols.
> > > >
> > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > spec
> > > compatible.
> > >
> > > That's not the point. It is obvious that your firmware is compatible
> > > with arm,scmi, but what you try to say in this and revised patch is
> > > that every arm,scmi is compatible with your implementation. What you
> > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > NXP, Samsung, TI, Mediatek etc.
> > >
> > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> >
> > You are right. I am lost now on how to add vendor ID support, using
> > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
>
Hi Peng,
I dont think in the following you will find the solution to the problem,
it is just to recap the situation and constraints around vendor protocol
bindings.
Describing SCMI vendors protocols is tricky because while on one side
the protocol node has to be rooted under the main scmi fw DT node (like
all the standard protocols) and be 'derived' from the arm,scmi.yaml
protocol-node definition, the optional additional properties of the a specific
vendor protocol nodes can be customized by each single vendor, and since,
as you said, you can have multiple protocols from different vendors sharing the
same protocol number, you could have multiple disjoint sets of valid properties
allowed under that same protocol node number; so on one side you have to stick
to some basic protocol-node defs and be rooted under the SCMI node, while on
the other side you will have multiple possibly allowed sets of additional
properties to check against, so IOW you cannot anyway just set
additionalProperties to false since that will result in no checks at all.
As a consequence, at runtime, in the final DTB shipped with a specific
platform you should have only one of the possible vendor nodes for each
of these overlapping protocols, and the SCMI core at probe time will
pick the proper protocol implementation based on the vendor/sub_vendor
IDs gathered from the running SCMI fw platform at init: this way you
can just build the usual "all-inclusive" defconfig without worrying
about vendor protocol clashes since the SCMI core can pick the right
protocol implementation, you should just had taken care to provide the
proper DTB for your protocol; BUT this also means that it is not possible
to add multiple DT bindings based on a 'if vendor' condition since the
vendor itself is NOT defined and not needed in the bindings since it is
discoverable at runtime.
So, after all of this blabbing of mine about this, I am wondering if it
is not possible that the solution is to handle each and every vendor
protocol node that appears with a block of addtional properties that
are picked via a oneOf statement from some external vendor specific
yaml.
(...in a similar way to how pinctrl additional properties are added...)
NOTE THAT the following is just an example of what I mean, it is certainly
wrong, incomplete annd maybe just not acceptable (and could cause DT
maintainers eyes to bleed :P)...
..so it is just fr the sake of explaining what I mean...
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index e9d3f043c4ed..3c38a1e3ffed 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -278,6 +278,22 @@ properties:
required:
- reg
+ protocol@81:
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x81
+
+ patternProperties:
+ '$':
+ type: object
+ oneOf:
+ - $ref: /schemas/vendor-A/scmi-protos.yaml#
+ - $ref: /schemas/vendor-B/protos.yaml#
+ unevaluatedProperties: false
+
additionalProperties: false
..with each new Vendor coming to the party adding a line under
oneOf...which would mean probably also having a protocol@NN for each new
protocol that appears...
Thanks,
Cristian
On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
<[email protected]> wrote:
>
> On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > Hi Krzysztof,
> >
> > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > additionalProperties to true
> > >
> > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > additionalProperties to true
> > > >
> > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > >> additionalProperties to true
> > > > >>
> > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > >>>> additionalProperties to true
> > > > >>>>
> > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > >>>>>> set additionalProperties to true
> > > > >>>>>>
> > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > >>>>>>>> set additionalProperties to true
> > > > >>>>>>>>
> > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > >>>>>>>>> From: Peng Fan <[email protected]>
> > > > >>>>>>>>>
> > > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > > >> warning:
> > > > >>>>>>>>> "
> > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > > >>>>>>>>> "
> > > > >>>>>>>>>
> > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > >>>>>>>>
> > > > >>>>>>>> I do not see anything addressed here, except making the
> > > > >>>>>>>> binding accepting anything anywhere...
> > > > >>>>>>>
> > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > > >>>>>>> protocol
> > > > >> extension.
> > > > >>>>>>>
> > > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > > suggest.
> > > > >>>>>>
> > > > >>>>>> First of all, you cannot affect negatively existing devices
> > > > >>>>>> (their
> > > > >>>>>> bindings) and your patch does exactly that. This should make
> > > > >>>>>> you thing what is the correct approach...
> > > > >>>>>>
> > > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > > >>>>>> did not address that.
> > > > >>>>>
> > > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > > >>>>> =
> > > > >>>> "arm,scmi";"
> > > > >>>>
> > > > >>>> So you claim that your vendor extensions are the same or fully
> > > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > > >>>> extensions/protocol valid for arm,scmi?
> > > > >>>
> > > > >>> Yes. They are valid for arm,scmi.
> > > > >>>
> > > > >>> If yes, why is this in separate binding. If no, why you use
> > > > >>> someone
> > > > >>>> else's compatible?
> > > > >>>
> > > > >>> Per SCMI Spec
> > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > > >>> this interface
> > > > >>>
> > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > > >>> the id for their own protocol.
> > > > >>
> > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > >
> > > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > > to implement the protocols.
> > > > >
> > > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > > spec
> > > > compatible.
> > > >
> > > > That's not the point. It is obvious that your firmware is compatible
> > > > with arm,scmi, but what you try to say in this and revised patch is
> > > > that every arm,scmi is compatible with your implementation. What you
> > > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > > NXP, Samsung, TI, Mediatek etc.
> > > >
> > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > >
> > > You are right. I am lost now on how to add vendor ID support, using
> > > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> >
>
> Hi Peng,
>
> I dont think in the following you will find the solution to the problem,
> it is just to recap the situation and constraints around vendor protocol
> bindings.
>
> Describing SCMI vendors protocols is tricky because while on one side
> the protocol node has to be rooted under the main scmi fw DT node (like
> all the standard protocols) and be 'derived' from the arm,scmi.yaml
> protocol-node definition, the optional additional properties of the a specific
> vendor protocol nodes can be customized by each single vendor, and since,
> as you said, you can have multiple protocols from different vendors sharing the
> same protocol number, you could have multiple disjoint sets of valid properties
> allowed under that same protocol node number; so on one side you have to stick
> to some basic protocol-node defs and be rooted under the SCMI node, while on
> the other side you will have multiple possibly allowed sets of additional
> properties to check against, so IOW you cannot anyway just set
> additionalProperties to false since that will result in no checks at all.
>
> As a consequence, at runtime, in the final DTB shipped with a specific
> platform you should have only one of the possible vendor nodes for each
> of these overlapping protocols, and the SCMI core at probe time will
> pick the proper protocol implementation based on the vendor/sub_vendor
> IDs gathered from the running SCMI fw platform at init: this way you
> can just build the usual "all-inclusive" defconfig without worrying
> about vendor protocol clashes since the SCMI core can pick the right
> protocol implementation, you should just had taken care to provide the
> proper DTB for your protocol; BUT this also means that it is not possible
> to add multiple DT bindings based on a 'if vendor' condition since the
> vendor itself is NOT defined and not needed in the bindings since it is
> discoverable at runtime.
>
> So, after all of this blabbing of mine about this, I am wondering if it
> is not possible that the solution is to handle each and every vendor
> protocol node that appears with a block of addtional properties that
> are picked via a oneOf statement from some external vendor specific
> yaml.
> (...in a similar way to how pinctrl additional properties are added...)
>
>
> NOTE THAT the following is just an example of what I mean, it is certainly
> wrong, incomplete annd maybe just not acceptable (and could cause DT
> maintainers eyes to bleed :P)...
>
> ...so it is just fr the sake of explaining what I mean...
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index e9d3f043c4ed..3c38a1e3ffed 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -278,6 +278,22 @@ properties:
> required:
> - reg
>
> + protocol@81:
> + $ref: '#/$defs/protocol-node'
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + const: 0x81
> +
> + patternProperties:
> + '$':
> + type: object
Did you mean to have child nodes under the protocol node rather than in it?
> + oneOf:
> + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> + - $ref: /schemas/vendor-B/protos.yaml#
Moved up one level, this would work, but it would have to be an
'anyOf' because it is possible that 2 vendors have the exact same set
of properties.
I can think of 2 other ways to structure this.
First, is a specific vendor protocol discoverable? Not that is 0x81
protocol present, but that 0x81 is vendor Foo's extra special
value-add protocol? If not, I think we should require a compatible
string on vendor protocols. Then the base SCMI schema can require just
that, and each vendor protocol defines its node with a $ref to
'#/$defs/protocol-node'.
The 2nd way is just a variation of the oneOf above, but do we do 1
file per vendor protocol or 1 file per vendor. Either should be
doable, just a matter of where 'protocol@81', etc. are defined.
Rob
On Tue, Apr 09, 2024 at 09:09:46AM -0500, Rob Herring wrote:
> On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
> <[email protected]> wrote:
> >
> > On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > > Hi Krzysztof,
> > >
> > > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > additionalProperties to true
> > > >
> > > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > additionalProperties to true
> > > > >
> > > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >> additionalProperties to true
> > > > > >>
> > > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >>>> additionalProperties to true
> > > > > >>>>
> > > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>> set additionalProperties to true
> > > > > >>>>>>
> > > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>>>> set additionalProperties to true
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > > >>>>>>>>> From: Peng Fan <[email protected]>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > > > >> warning:
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > > >>>>>>>>
> > > > > >>>>>>>> I do not see anything addressed here, except making the
> > > > > >>>>>>>> binding accepting anything anywhere...
> > > > > >>>>>>>
> > > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > > > >>>>>>> protocol
> > > > > >> extension.
> > > > > >>>>>>>
> > > > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > > > suggest.
> > > > > >>>>>>
> > > > > >>>>>> First of all, you cannot affect negatively existing devices
> > > > > >>>>>> (their
> > > > > >>>>>> bindings) and your patch does exactly that. This should make
> > > > > >>>>>> you thing what is the correct approach...
> > > > > >>>>>>
> > > > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > > > >>>>>> did not address that.
> > > > > >>>>>
> > > > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > > > >>>>> =
> > > > > >>>> "arm,scmi";"
> > > > > >>>>
> > > > > >>>> So you claim that your vendor extensions are the same or fully
> > > > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > > > >>>> extensions/protocol valid for arm,scmi?
> > > > > >>>
> > > > > >>> Yes. They are valid for arm,scmi.
> > > > > >>>
> > > > > >>> If yes, why is this in separate binding. If no, why you use
> > > > > >>> someone
> > > > > >>>> else's compatible?
> > > > > >>>
> > > > > >>> Per SCMI Spec
> > > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > > > >>> this interface
> > > > > >>>
> > > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > > > >>> the id for their own protocol.
> > > > > >>
> > > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > > >
> > > > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > > > to implement the protocols.
> > > > > >
> > > > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > > > spec
> > > > > compatible.
> > > > >
> > > > > That's not the point. It is obvious that your firmware is compatible
> > > > > with arm,scmi, but what you try to say in this and revised patch is
> > > > > that every arm,scmi is compatible with your implementation. What you
> > > > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > > > NXP, Samsung, TI, Mediatek etc.
> > > > >
> > > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > > >
> > > > You are right. I am lost now on how to add vendor ID support, using
> > > > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> > >
> >
> > Hi Peng,
> >
> > I dont think in the following you will find the solution to the problem,
> > it is just to recap the situation and constraints around vendor protocol
> > bindings.
> >
> > Describing SCMI vendors protocols is tricky because while on one side
> > the protocol node has to be rooted under the main scmi fw DT node (like
> > all the standard protocols) and be 'derived' from the arm,scmi.yaml
> > protocol-node definition, the optional additional properties of the a specific
> > vendor protocol nodes can be customized by each single vendor, and since,
> > as you said, you can have multiple protocols from different vendors sharing the
> > same protocol number, you could have multiple disjoint sets of valid properties
> > allowed under that same protocol node number; so on one side you have to stick
> > to some basic protocol-node defs and be rooted under the SCMI node, while on
> > the other side you will have multiple possibly allowed sets of additional
> > properties to check against, so IOW you cannot anyway just set
> > additionalProperties to false since that will result in no checks at all.
> >
> > As a consequence, at runtime, in the final DTB shipped with a specific
> > platform you should have only one of the possible vendor nodes for each
> > of these overlapping protocols, and the SCMI core at probe time will
> > pick the proper protocol implementation based on the vendor/sub_vendor
> > IDs gathered from the running SCMI fw platform at init: this way you
> > can just build the usual "all-inclusive" defconfig without worrying
> > about vendor protocol clashes since the SCMI core can pick the right
> > protocol implementation, you should just had taken care to provide the
> > proper DTB for your protocol; BUT this also means that it is not possible
> > to add multiple DT bindings based on a 'if vendor' condition since the
> > vendor itself is NOT defined and not needed in the bindings since it is
> > discoverable at runtime.
> >
> > So, after all of this blabbing of mine about this, I am wondering if it
> > is not possible that the solution is to handle each and every vendor
> > protocol node that appears with a block of addtional properties that
> > are picked via a oneOf statement from some external vendor specific
> > yaml.
> > (...in a similar way to how pinctrl additional properties are added...)
> >
> >
> > NOTE THAT the following is just an example of what I mean, it is certainly
> > wrong, incomplete annd maybe just not acceptable (and could cause DT
> > maintainers eyes to bleed :P)...
> >
> > ...so it is just fr the sake of explaining what I mean...
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index e9d3f043c4ed..3c38a1e3ffed 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -278,6 +278,22 @@ properties:
> > required:
> > - reg
> >
> > + protocol@81:
> > + $ref: '#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + patternProperties:
> > + '$':
> > + type: object
>
> Did you mean to have child nodes under the protocol node rather than in it?
.. nope ... it is just as bad as my yaml-fu is :P ... but not sure if
vendors has also this needs or plain props will suffice...
>
> > + oneOf:
> > + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> > + - $ref: /schemas/vendor-B/protos.yaml#
>
> Moved up one level, this would work, but it would have to be an
> 'anyOf' because it is possible that 2 vendors have the exact same set
> of properties.
>
ok
> I can think of 2 other ways to structure this.
>
> First, is a specific vendor protocol discoverable? Not that is 0x81
> protocol present, but that 0x81 is vendor Foo's extra special
> value-add protocol? If not, I think we should require a compatible
> string on vendor protocols. Then the base SCMI schema can require just
> that, and each vendor protocol defines its node with a $ref to
> '#/$defs/protocol-node'.
Basically yes it is discoverable, since at runtime the SCMI core, early on,
normally discovers the vendor_id/sub_vendor_id by querying the platform via
Base protocol and then later only loads/initializes (by closest match) the
vendor protocols that are present in the DT AND that has been 'tagged' at
compile time with the same vendor_id/sub_vendor_id tuple (in the vendor
module code, struct scmi_protocol)
Of course you should take care to put the proper protocol@81 node in your
vendor_A DTB for the vendor_A SCMI driver to make use of the additional
vendor_A properties that you have defined under your node as referred
in your vendor-protos.yaml...if you botch that up I will load a protocol
and call your vendor_A driver with a vendor_X DT node.
DT is currrently vendor-agnostic.
>
> The 2nd way is just a variation of the oneOf above, but do we do 1
> file per vendor protocol or 1 file per vendor. Either should be
> doable, just a matter of where 'protocol@81', etc. are defined.
>
Oh, yes mine was just an ill example...one file per vendor will do just
fine: the important thing is that the list and the yaml itself can be
extended as new vendors appears (in a backward compatble way of course)
Thanks,
Cristian
On Fri, Apr 05, 2024 at 08:39:24PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> Add i.MX SCMI Extension protocols bindings for:
> - Battery Backed Secure Module(BBSM)
> - MISC settings such as General Purpose Registers settings.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../devicetree/bindings/firmware/imx,scmi.yaml | 80 ++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> new file mode 100644
> index 000000000000..7ee19a661d83
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2024 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/imx,scmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX System Control and Management Interface(SCMI) Vendor Protocols Extension
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +allOf:
> + - $ref: arm,scmi.yaml#
This needs to be the other way around. Add a ref to this file in
arm,scmi.yaml under an 'anyOf' entry.
> +
> +properties:
> + protocol@81:
> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> + unevaluatedProperties: false
> + description:
> + The BBM Protocol is for managing Battery Backed Secure Module (BBSM) RTC
> + and the ON/OFF Key
> +
> + properties:
> + reg:
> + const: 0x81
> +
> + required:
> + - reg
> +
> + protocol@84:
> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> + unevaluatedProperties: false
> + description:
> + The MISC Protocol is for managing SoC Misc settings, such as GPR settings
> +
> + properties:
> + reg:
> + const: 0x84
> +
> + wakeup-sources:
> + description:
> + Each entry consists of 2 integers, represents the source and electric signal edge
> + items:
> + items:
> + - description: the wakeup source
> + - description: the wakeup electric signal edge
No constraints on the entry values?
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> + required:
> + - reg
> +
> +additionalProperties: false
And then this can be true.
Rob
> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> On Fri, Apr 05, 2024 at 08:39:24PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > Add i.MX SCMI Extension protocols bindings for:
> > - Battery Backed Secure Module(BBSM)
> > - MISC settings such as General Purpose Registers settings.
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > .../devicetree/bindings/firmware/imx,scmi.yaml | 80
> ++++++++++++++++++++++
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > new file mode 100644
> > index 000000000000..7ee19a661d83
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> > @@ -0,0 +1,80 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright 2024
> > +NXP %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
> C02%7Cp
> >
> +eng.fan%40nxp.com%7C25c72418c9864a73924808dc59826288%7C686ea
> 1d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C638483663734828123%7CUnknown%
> 7CTWFpbGZsb
> >
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D
> >
> +%7C0%7C%7C%7C&sdata=Y2uSGDorqR9HK8PO4AQDQ%2FaTv%2BETnulvU
> C8u9ktDoio%3
> > +D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7C25c72418c9864a73924808dc59826288%7C686ea1d3bc2b4c6fa
> 92cd99c5c
> >
> +301635%7C0%7C0%7C638483663734841350%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=h6lSgnPvR88CEBxmU%2B%2FCfCx9GHUrogWVxck38sIdhB4%3D&r
> eserved=0
> > +
> > +title: i.MX System Control and Management Interface(SCMI) Vendor
> > +Protocols Extension
> > +
> > +maintainers:
> > + - Peng Fan <[email protected]>
> > +
> > +allOf:
> > + - $ref: arm,scmi.yaml#
>
> This needs to be the other way around. Add a ref to this file in arm,scmiyaml
> under an 'anyOf' entry.
ok, I will give a try.
>
> > +
> > +properties:
> > + protocol@81:
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > + description:
> > + The BBM Protocol is for managing Battery Backed Secure Module
> (BBSM) RTC
> > + and the ON/OFF Key
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + required:
> > + - reg
> > +
> > + protocol@84:
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > + description:
> > + The MISC Protocol is for managing SoC Misc settings, such as
> > + GPR settings
> > +
> > + properties:
> > + reg:
> > + const: 0x84
> > +
> > + wakeup-sources:
> > + description:
> > + Each entry consists of 2 integers, represents the source and electric
> signal edge
> > + items:
> > + items:
> > + - description: the wakeup source
> > + - description: the wakeup electric signal edge
>
> No constraints on the entry values?
I will change the property name to imx,wakup-sources with constraints
minItems: 1
maxItems: 32.
>
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + required:
> > + - reg
> > +
> > +additionalProperties: false
>
> And then this can be true.
Fix in v3.
Thanks
Peng.
>
> Rob
Hi Rob, Cristian,
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On Tue, Apr 09, 2024 at 09:09:46AM -0500, Rob Herring wrote:
> > On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
> > <[email protected]> wrote:
> > >
> > > On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > > > Hi Krzysztof,
> > > >
> > > > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > additionalProperties to true
> > > > >
> > > > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > > set additionalProperties to true
> > > > > >
> > > > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware:
> > > > > > >> arm,scmi: set additionalProperties to true
> > > > > > >>
> > > > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware:
> > > > > > >>>> arm,scmi: set additionalProperties to true
> > > > > > >>>>
> > > > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > > >>>>>> set additionalProperties to true
> > > > > > >>>>>>
> > > > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware:
> arm,scmi:
> > > > > > >>>>>>>> set additionalProperties to true
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > > > >>>>>>>>> From: Peng Fan <[email protected]>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> When adding vendor extension protocols, there is
> > > > > > >>>>>>>>> dt-schema
> > > > > > >> warning:
> > > > > > >>>>>>>>> "
> > > > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81',
> > > > > > >>>>>>>>> 'protocol@84' do not match any of the regexes: 'pinctrl-
> [0-9]+'
> > > > > > >>>>>>>>> "
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> I do not see anything addressed here, except making
> > > > > > >>>>>>>> the binding accepting anything anywhere...
> > > > > > >>>>>>>
> > > > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so
> > > > > > >>>>>>> will introduce a new yaml imx.scmi.yaml which add i.MX
> > > > > > >>>>>>> SCMI protocol
> > > > > > >> extension.
> > > > > > >>>>>>>
> > > > > > >>>>>>> With additionalProperties set to false, I not know
> > > > > > >>>>>>> how, please
> > > > > > suggest.
> > > > > > >>>>>>
> > > > > > >>>>>> First of all, you cannot affect negatively existing
> > > > > > >>>>>> devices (their
> > > > > > >>>>>> bindings) and your patch does exactly that. This should
> > > > > > >>>>>> make you thing what is the correct approach...
> > > > > > >>>>>>
> > > > > > >>>>>> Rob gave you the comment about missing compatible - you
> > > > > > >>>>>> still did not address that.
> > > > > > >>>>>
> > > > > > >>>>> I added the compatible in patch 2/6 in the examples
> > > > > > >>>>> "compatible =
> > > > > > >>>> "arm,scmi";"
> > > > > > >>>>
> > > > > > >>>> So you claim that your vendor extensions are the same or
> > > > > > >>>> fully compatible with arm,scmi and you add nothing... Are
> > > > > > >>>> your extensions/protocol valid for arm,scmi?
> > > > > > >>>
> > > > > > >>> Yes. They are valid for arm,scmi.
> > > > > > >>>
> > > > > > >>> If yes, why is this in separate binding. If no, why you
> > > > > > >>> use someone
> > > > > > >>>> else's compatible?
> > > > > > >>>
> > > > > > >>> Per SCMI Spec
> > > > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific
> > > > > > >>> extensions to this interface
> > > > > > >>>
> > > > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors
> > > > > > >>> will use the id for their own protocol.
> > > > > > >>
> > > > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > > > >
> > > > > > > arm,scmi is a firmware compatible string. The protocol node is a
> sub-node.
> > > > > > > I think the arm,scmi is that saying the firmware following
> > > > > > > SCMI spec to implement the protocols.
> > > > > > >
> > > > > > > For vendor reserved ID, firmware also follow the SCMI spec
> > > > > > > to implement their own usage, so from firmware level, it is
> > > > > > > ARM SCMI spec
> > > > > > compatible.
> > > > > >
> > > > > > That's not the point. It is obvious that your firmware is
> > > > > > compatible with arm,scmi, but what you try to say in this and
> > > > > > revised patch is that every arm,scmi is compatible with your
> > > > > > implementation. What you are saying is that 0x84 is MISC
> > > > > > protocol for every firmware, Qualcomm, NXP, Samsung, TI, Mediatek
> etc.
> > > > > >
> > > > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > > > >
> > > > > You are right. I am lost now on how to add vendor ID support,
> > > > > using arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> > > >
> > >
> > > Hi Peng,
> > >
> > > I dont think in the following you will find the solution to the
> > > problem, it is just to recap the situation and constraints around
> > > vendor protocol bindings.
> > >
> > > Describing SCMI vendors protocols is tricky because while on one
> > > side the protocol node has to be rooted under the main scmi fw DT
> > > node (like all the standard protocols) and be 'derived' from the
> > > arm,scmi.yaml protocol-node definition, the optional additional
> > > properties of the a specific vendor protocol nodes can be customized
> > > by each single vendor, and since, as you said, you can have multiple
> > > protocols from different vendors sharing the same protocol number,
> > > you could have multiple disjoint sets of valid properties allowed
> > > under that same protocol node number; so on one side you have to
> > > stick to some basic protocol-node defs and be rooted under the SCMI
> > > node, while on the other side you will have multiple possibly
> > > allowed sets of additional properties to check against, so IOW you cannot
> anyway just set additionalProperties to false since that will result in no checks
> at all.
> > >
> > > As a consequence, at runtime, in the final DTB shipped with a
> > > specific platform you should have only one of the possible vendor
> > > nodes for each of these overlapping protocols, and the SCMI core at
> > > probe time will pick the proper protocol implementation based on the
> > > vendor/sub_vendor IDs gathered from the running SCMI fw platform at
> > > init: this way you can just build the usual "all-inclusive"
> > > defconfig without worrying about vendor protocol clashes since the
> > > SCMI core can pick the right protocol implementation, you should
> > > just had taken care to provide the proper DTB for your protocol; BUT
> > > this also means that it is not possible to add multiple DT bindings
> > > based on a 'if vendor' condition since the vendor itself is NOT
> > > defined and not needed in the bindings since it is discoverable at runtime.
> > >
> > > So, after all of this blabbing of mine about this, I am wondering if
> > > it is not possible that the solution is to handle each and every
> > > vendor protocol node that appears with a block of addtional
> > > properties that are picked via a oneOf statement from some external
> > > vendor specific yaml.
> > > (...in a similar way to how pinctrl additional properties are
> > > added...)
> > >
> > >
> > > NOTE THAT the following is just an example of what I mean, it is
> > > certainly wrong, incomplete annd maybe just not acceptable (and
> > > could cause DT maintainers eyes to bleed :P)...
> > >
> > > ...so it is just fr the sake of explaining what I mean...
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > index e9d3f043c4ed..3c38a1e3ffed 100644
> > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > @@ -278,6 +278,22 @@ properties:
> > > required:
> > > - reg
> > >
> > > + protocol@81:
> > > + $ref: '#/$defs/protocol-node'
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + reg:
> > > + const: 0x81
> > > +
> > > + patternProperties:
> > > + '$':
> > > + type: object
> >
> > Did you mean to have child nodes under the protocol node rather than in it?
>
> ... nope ... it is just as bad as my yaml-fu is :P ... but not sure if vendors has
> also this needs or plain props will suffice...
>
> >
> > > + oneOf:
> > > + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> > > + - $ref: /schemas/vendor-B/protos.yaml#
> >
> > Moved up one level, this would work, but it would have to be an
> > 'anyOf' because it is possible that 2 vendors have the exact same set
> > of properties.
> >
I try this:
protocol@84:
anyOf:
- $ref: /schemas/firmware/imx,scmi.yaml#
- $ref: /schemas/firmware/vendor-B,scmi.yaml#
but unevaluatedProperties could not be set to false, otherwise the
example check will report
reg is unevaluated, fsl,wakeup-sources is unevaluated.
The imx,scmi.yaml is as below:
properties:
protocol@84:
$ref: 'arm,scmi.yaml#/$defs/protocol-node'
unevaluatedProperties: false
description:
The MISC Protocol is for managing SoC Misc settings, such as GPR settings
properties:
reg:
const: 0x84
fsl,wakeup-sources:
description:
Each entry consists of 2 integers, represents the source and electric signal edge
items:
items:
- description: the wakeup source
- description: the wakeup electric signal edge
minItems: 1
maxItems: 32
$ref: /schemas/types.yaml#/definitions/uint32-matrix
required:
- reg
additionalProperties: true
Is the upper ok?
Thanks,
Peng.
>
> ok
>
> > I can think of 2 other ways to structure this.
> >
> > First, is a specific vendor protocol discoverable? Not that is 0x81
> > protocol present, but that 0x81 is vendor Foo's extra special
> > value-add protocol? If not, I think we should require a compatible
> > string on vendor protocols. Then the base SCMI schema can require just
> > that, and each vendor protocol defines its node with a $ref to
> > '#/$defs/protocol-node'.
>
> Basically yes it is discoverable, since at runtime the SCMI core, early on,
> normally discovers the vendor_id/sub_vendor_id by querying the platform
> via Base protocol and then later only loads/initializes (by closest match) the
> vendor protocols that are present in the DT AND that has been 'tagged' at
> compile time with the same vendor_id/sub_vendor_id tuple (in the vendor
> module code, struct scmi_protocol)
>
> Of course you should take care to put the proper protocol@81 node in your
> vendor_A DTB for the vendor_A SCMI driver to make use of the additional
> vendor_A properties that you have defined under your node as referred in
> your vendor-protos.yaml...if you botch that up I will load a protocol and call
> your vendor_A driver with a vendor_X DT node.
>
> DT is currrently vendor-agnostic.
>
> >
> > The 2nd way is just a variation of the oneOf above, but do we do 1
> > file per vendor protocol or 1 file per vendor. Either should be
> > doable, just a matter of where 'protocol@81', etc. are defined.
> >
>
> Oh, yes mine was just an ill example...one file per vendor will do just
> fine: the important thing is that the list and the yaml itself can be extended as
> new vendors appears (in a backward compatble way of course)
>
> Thanks,
> Cristian