From: Jarrett Schultz <[email protected]>
After v4, there were some suggestions to change the driver again to use
nvmem that would include some other changes to the sm8150 dtsi. While
the suggestions make sense, this driver was supposed to remain simple
for the introduction in order to get it into the tree and I think that
it would be best to implement those and any other suggestions in a future
patch. Hopefully this patch is now in a state where it can be accepted.
Thanks to all who have helped and been patient along the way, this was
my first patch :)
~ Jarrett
---
Introduce the Surface Extensible Boot Loader driver for the Surface Duo.
Exposes information about the driver to user space via sysfs for
consumption in manufacturing mode.
---
Changes in v5:
- Minor changes to yaml
---
Changes in v4:
- Small binding definition changes
- Removed ACPI propagation from patch series since it has been
cherry-picked
- Fixed the Signed-off-by: and From: mismatch
---
Changes in v3:
- For the yaml documentation:
* Updated description
* Fixed examples
* Updated 'required' field
- Further propogated ACPI dependency in Kconfigs
- Updated sysfs several binding descriptions
- Renamed files to conform to naming conventions
---
Changes in v2:
- Per Maximilian, added patch 2: propagated ACPI dependency from the
directory as a whole to each individual driver
- For the yaml documentation:
* Removed json-schema dependence
* Elaborated on description of driver
* Updated example
- Changed target KernelVersion in sysfs documentation
- Updated MAINTAINER changes to be properly applied across patches
- For the driver itself,
* Added types.h inclusion and removed unused inclusions
* Minor updates to code and acronym style
* Remove __packed attribute on driver struct
* Use .dev_groups for sysfs
- Added more in-depth description of driver in Kconfig
- Modified dts to reference a newly added section in sm8150.dtsi
---
Jarrett Schultz (4):
dt-bindings: platform: microsoft: Document surface xbl
platform: surface: Add surface xbl
arm64: dts: qcom: sm8150: Add imem section
arm64: dts: qcom: surface-duo: Add surface xbl
.../ABI/testing/sysfs-platform-surface-xbl | 79 ++++++++
.../platform/microsoft/surface-xbl.yaml | 70 +++++++
MAINTAINERS | 9 +
.../dts/qcom/sm8150-microsoft-surface-duo.dts | 10 +
arch/arm64/boot/dts/qcom/sm8150.dtsi | 8 +
drivers/platform/surface/Kconfig | 12 ++
drivers/platform/surface/Makefile | 1 +
drivers/platform/surface/surface_xbl.c | 186 ++++++++++++++++++
8 files changed, 375 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-platform-surface-xbl
create mode 100644 Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
create mode 100644 drivers/platform/surface/surface_xbl.c
--
2.25.1
From: Jarrett Schultz <[email protected]>
Introduce yaml for surface xbl driver.
Signed-off-by: Jarrett Schultz <[email protected]>
---
Changed in v5:
- Updated description
- Added child node for imem
- Simplified example
---
Changes in v4:
- Addressed small formatting changes
- Removed unnecessary lines
---
Changes in v3:
- Updated description to only pertain to the hardware
- Updated the required field to properly reflect the binding
- Removed the first example
- Fixed the size of the reg field in the second example
---
Changes in v2:
- Removed json-schema dependence
- Elaborated on description of driver
- Updated example
---
.../platform/microsoft/surface-xbl.yaml | 70 +++++++++++++++++++
MAINTAINERS | 7 ++
2 files changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
diff --git a/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml b/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
new file mode 100644
index 000000000000..648476670bbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/platform/microsoft/surface-xbl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Surface Extensible Bootloader for Microsoft Surface Duo
+
+maintainers:
+ - Jarrett Schultz <[email protected]>
+
+description: |
+ Defined to expose information that is used during production when
+ the device is in manufacturing mode. Some of the information included
+ in the imem section is -
+ * board_id
+ * battery_present
+ * hw_init_retries
+ * is_customer_mode
+ * is_act_mode
+ * pmic_reset_reason
+ * touch_fw_version
+ * ocp_error_location
+
+properties:
+ compatible:
+ const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ child-node:
+ description: A description of the xbl space within imem
+
+ type: object
+
+ properties:
+ compatible:
+ const: microsoft,sm8150-surface-duo-xbl
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - address-cells
+ - size-cells
+
+examples:
+ - |
+ imem@146bf000 {
+ compatible = "simple-mfd";
+ reg = <0x146bf000 0x1000>;
+ ranges = <0x0 0x146bf000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ xbl@a94 {
+ compatible = "microsoft,sm8150-surface-duo-xbl";
+ reg = <0xa94 0x100>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 13f9a84a617e..5d0ca2a98b57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12649,6 +12649,13 @@ F: Documentation/driver-api/surface_aggregator/clients/dtx.rst
F: drivers/platform/surface/surface_dtx.c
F: include/uapi/linux/surface_aggregator/dtx.h
+MICROSOFT SURFACE DUO XBL DRIVER
+M: Jarrett Schultz <[email protected]>
+L: [email protected]
+L: [email protected]
+S: Supported
+F: Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
+
MICROSOFT SURFACE GPE LID SUPPORT DRIVER
M: Maximilian Luz <[email protected]>
L: [email protected]
--
2.25.1
From: Jarrett Schultz <[email protected]>
Introduce device tree source for the surface xbl driver.
Signed-off-by: Jarrett Schultz <[email protected]>
---
Changes in v4:
- N/A
---
Changes in v3:
- N/A
---
Changes in v2:
- Updated to reference an offset inside of imem
---
.../boot/dts/qcom/sm8150-microsoft-surface-duo.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
index 5901c28e6696..abb7964daac4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
@@ -430,6 +430,16 @@ &i2c19 {
/* MAX34417 @ 0x1e */
};
+&imem {
+ status = "okay";
+
+ xbl@a94 {
+ compatible = "microsoft,sm8150-surface-duo-xbl";
+ reg = <0xa94 0x100>;
+ status = "okay";
+ };
+};
+
&pon {
pwrkey {
status = "okay";
--
2.25.1
From: Jarrett Schultz <[email protected]>
Introduce the imem section in preparation for the surface xbl driver.
Signed-off-by: Jarrett Schultz <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
---
Changes in v4:
- N/A
---
Changes in v3:
- N/A
---
Changes in v2:
- Created to properly reference the xbl section inside of imem
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 81b4ff2cc4cd..bcfcb7306cdc 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -1175,6 +1175,14 @@ gpi_dma1: dma-controller@a00000 {
status = "disabled";
};
+ imem: imem@146bf000 {
+ compatible = "simple-mfd";
+ reg = <0x0 0x146bf000 0x0 0x1000>;
+ ranges = <0x0 0x0 0x146bf000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
qupv3_id_1: geniqup@ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x00ac0000 0x0 0x6000>;
--
2.25.1
Hi Jarrett,
On 1/1/70 01:00, Jarrett Schultz wrote:
> After v4, there were some suggestions to change the driver again to use
> nvmem that would include some other changes to the sm8150 dtsi. While
> the suggestions make sense, this driver was supposed to remain simple
> for the introduction in order to get it into the tree and I think that
> it would be best to implement those and any other suggestions in a future
> patch. Hopefully this patch is now in a state where it can be accepted.
> Thanks to all who have helped and been patient along the way, this was
> my first patch :)
I appreciate your efforts to get this upstream, but this is not
how upstream development typically works. We usually iterate a patch
until all stakeholders are happy and then merge it.
So unless Rob changes its mind and gives his Reviewed-by for the
devicetree bits from this v5, then this cannot be merged as is.
Regards,
Hans
> ~ Jarrett
>
> ---
>
> Introduce the Surface Extensible Boot Loader driver for the Surface Duo.
> Exposes information about the driver to user space via sysfs for
> consumption in manufacturing mode.
>
> ---
>
> Changes in v5:
>
> - Minor changes to yaml
>
> ---
>
> Changes in v4:
>
> - Small binding definition changes
> - Removed ACPI propagation from patch series since it has been
> cherry-picked
> - Fixed the Signed-off-by: and From: mismatch
>
> ---
>
> Changes in v3:
> - For the yaml documentation:
> * Updated description
> * Fixed examples
> * Updated 'required' field
> - Further propogated ACPI dependency in Kconfigs
> - Updated sysfs several binding descriptions
> - Renamed files to conform to naming conventions
>
> ---
>
> Changes in v2:
> - Per Maximilian, added patch 2: propagated ACPI dependency from the
> directory as a whole to each individual driver
> - For the yaml documentation:
> * Removed json-schema dependence
> * Elaborated on description of driver
> * Updated example
> - Changed target KernelVersion in sysfs documentation
> - Updated MAINTAINER changes to be properly applied across patches
> - For the driver itself,
> * Added types.h inclusion and removed unused inclusions
> * Minor updates to code and acronym style
> * Remove __packed attribute on driver struct
> * Use .dev_groups for sysfs
> - Added more in-depth description of driver in Kconfig
> - Modified dts to reference a newly added section in sm8150.dtsi
>
> ---
>
> Jarrett Schultz (4):
> dt-bindings: platform: microsoft: Document surface xbl
> platform: surface: Add surface xbl
> arm64: dts: qcom: sm8150: Add imem section
> arm64: dts: qcom: surface-duo: Add surface xbl
>
> .../ABI/testing/sysfs-platform-surface-xbl | 79 ++++++++
> .../platform/microsoft/surface-xbl.yaml | 70 +++++++
> MAINTAINERS | 9 +
> .../dts/qcom/sm8150-microsoft-surface-duo.dts | 10 +
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 8 +
> drivers/platform/surface/Kconfig | 12 ++
> drivers/platform/surface/Makefile | 1 +
> drivers/platform/surface/surface_xbl.c | 186 ++++++++++++++++++
> 8 files changed, 375 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-surface-xbl
> create mode 100644 Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
> create mode 100644 drivers/platform/surface/surface_xbl.c
>
On Tue, Apr 05, 2022 at 02:07:47PM -0700, Jarrett Schultz wrote:
> From: Jarrett Schultz <[email protected]>
>
> Introduce yaml for surface xbl driver.
From Bjorn's reply on v4, it sounds like the QCom folks need to work out
how to describe 'imem' first. I'd think that would use 'mmio-sram'
binding and then this could be a child of that. If it's DDR, then it
belongs under /reserved-memory node. Either way, that's all kind of
outside the scope of the binding unless there's something special about
'imem'.
>
> Signed-off-by: Jarrett Schultz <[email protected]>
>
> ---
>
> Changed in v5:
>
> - Updated description
> - Added child node for imem
> - Simplified example
>
> ---
>
> Changes in v4:
> - Addressed small formatting changes
> - Removed unnecessary lines
>
> ---
>
> Changes in v3:
> - Updated description to only pertain to the hardware
> - Updated the required field to properly reflect the binding
> - Removed the first example
> - Fixed the size of the reg field in the second example
>
> ---
>
> Changes in v2:
> - Removed json-schema dependence
> - Elaborated on description of driver
> - Updated example
> ---
> .../platform/microsoft/surface-xbl.yaml | 70 +++++++++++++++++++
That's not a binding path. Probably bindings/nvmem/.
> MAINTAINERS | 7 ++
> 2 files changed, 77 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
>
> diff --git a/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml b/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
> new file mode 100644
> index 000000000000..648476670bbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/platform/microsoft/surface-xbl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Surface Extensible Bootloader for Microsoft Surface Duo
> +
> +maintainers:
> + - Jarrett Schultz <[email protected]>
> +
> +description: |
> + Defined to expose information that is used during production when
> + the device is in manufacturing mode. Some of the information included
> + in the imem section is -
> + * board_id
> + * battery_present
> + * hw_init_retries
> + * is_customer_mode
> + * is_act_mode
> + * pmic_reset_reason
> + * touch_fw_version
> + * ocp_error_location
> +
> +properties:
> + compatible:
> + const: simple-mfd
This schema will never be applied (your example would fail if it did)
because we filter out matching on 'simple-mfd' as it is not valid on its
own.
> +
> + reg:
> + maxItems: 1
> +
> + child-node:
This literally means you have a node called 'child-node'.
> + description: A description of the xbl space within imem
> +
> + type: object
> +
> + properties:
> + compatible:
> + const: microsoft,sm8150-surface-duo-xbl
This should be moved up a level removing 'simple-mfd'.
> +
> + reg:
> + maxItems: 1
> +
> + required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - ranges
> + - address-cells
> + - size-cells
Not documented and also the wrong names (missing '#').
> +
> +examples:
> + - |
> + imem@146bf000 {
> + compatible = "simple-mfd";
> + reg = <0x146bf000 0x1000>;
> + ranges = <0x0 0x146bf000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + xbl@a94 {
> + compatible = "microsoft,sm8150-surface-duo-xbl";
> + reg = <0xa94 0x100>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 13f9a84a617e..5d0ca2a98b57 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12649,6 +12649,13 @@ F: Documentation/driver-api/surface_aggregator/clients/dtx.rst
> F: drivers/platform/surface/surface_dtx.c
> F: include/uapi/linux/surface_aggregator/dtx.h
>
> +MICROSOFT SURFACE DUO XBL DRIVER
> +M: Jarrett Schultz <[email protected]>
> +L: [email protected]
> +L: [email protected]
> +S: Supported
> +F: Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml
> +
> MICROSOFT SURFACE GPE LID SUPPORT DRIVER
> M: Maximilian Luz <[email protected]>
> L: [email protected]
> --
> 2.25.1
>
>
On Mon, Apr 11, 2022 at 02:13:42PM +0200, Hans de Goede wrote:
> Hi Jarrett,
>
> On 1/1/70 01:00, Jarrett Schultz wrote:
> > After v4, there were some suggestions to change the driver again to use
> > nvmem that would include some other changes to the sm8150 dtsi. While
> > the suggestions make sense, this driver was supposed to remain simple
> > for the introduction in order to get it into the tree and I think that
> > it would be best to implement those and any other suggestions in a future
> > patch. Hopefully this patch is now in a state where it can be accepted.
> > Thanks to all who have helped and been patient along the way, this was
> > my first patch :)
> I appreciate your efforts to get this upstream, but this is not
> how upstream development typically works. We usually iterate a patch
> until all stakeholders are happy and then merge it.
>
> So unless Rob changes its mind and gives his Reviewed-by for the
> devicetree bits from this v5, then this cannot be merged as is.
This is dependent on the QCom folks. We can't really define the child
without first defining the parent binding.
Rob
> From: Rob Herring <[email protected]>
> On Wednesday, April 13, 2022 at 11:27 AM, Rob wrote:
>
> On Tue, Apr 05, 2022 at 02:07:47PM -0700, Jarrett Schultz wrote:
> > From: Jarrett Schultz <[email protected]>
> >
> > Introduce yaml for surface xbl driver.
>
> From Bjorn's reply on v4, it sounds like the QCom folks need to work out how
> to describe 'imem' first. I'd think that would use 'mmio-sram'
> binding and then this could be a child of that. If it's DDR, then it belongs
> under /reserved-memory node. Either way, that's all kind of outside the
> scope of the binding unless there's something special about 'imem'.
>
> >
> > Signed-off-by: Jarrett Schultz <[email protected]>
> >
Hi Rajendra and Vinod,
I'm currently working with Felipe Balbi on submitting an XBL driver that reads from imem.
Could you help me properly describe the 'imem' binding for sm8150?
Thank you,
Jarrett Schultz
> On Monday, April 18, 2022 3:53 PM, Jarrett Schultz wrote:
> From: Jarrett Schultz <[email protected]>
>
> > From: Rob Herring <[email protected]>
> > On Wednesday, April 13, 2022 at 11:27 AM, Rob wrote:
> >
> > On Tue, Apr 05, 2022 at 02:07:47PM -0700, Jarrett Schultz wrote:
> > > From: Jarrett Schultz <[email protected]>
> > >
> > > Introduce yaml for surface xbl driver.
> >
> > From Bjorn's reply on v4, it sounds like the QCom folks need to work
> > out how to describe 'imem' first. I'd think that would use 'mmio-sram'
> > binding and then this could be a child of that. If it's DDR, then it
> > belongs under /reserved-memory node. Either way, that's all kind of
> > outside the scope of the binding unless there's something special about
> 'imem'.
> >
> > >
> > > Signed-off-by: Jarrett Schultz <[email protected]>
> > >
>
> Hi Rajendra and Vinod,
>
> I'm currently working with Felipe Balbi on submitting an XBL driver that reads
> from imem.
> Could you help me properly describe the 'imem' binding for sm8150?
>
> Thank you,
> Jarrett Schultz
Oops, forgot to CC in Vinod and Rejendra.
-Jarrett