platform: surface: Introduce Surface XBL Driver
Subsystems (5)
v5 cover platform: surface: Introduce Surface XBL Driver
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
Signature · 1 line
2.25.1
PATCH v5 1/4 dt-bindings: platform: microsoft: Document surface xbl
From: Jarrett Schultz <[email protected]>
Introduce yaml for surface xbl driver.
---
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
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +70 -0
@@ -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>; + }; + };
MAINTAINERS +7 -0
@@ -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]
Signature · 1 line
2.25.1
Rob Herring
maintainerRe: [PATCH v5 1/4] dt-bindings: platform: microsoft: Document surface xbl
Quoted 3 lines · Jarrett Schultz
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'.
Quoted 25 lines
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
Quoted 8 lines
---
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/.
Quoted 27 lines
MAINTAINERS | 7 ++ 2 files changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yamlDocumentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +17
-0@@ -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
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml line 27
Quoted 10 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +10
-0+ * 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.
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml line 32
Quoted 5 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +5
-0+ + reg: + maxItems: 1 + + child-node:
This literally means you have a node called 'child-node'.
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml line 39
Quoted 7 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +7
-0+ 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'.
Quoted 7 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +7
-0+ + reg: + maxItems: 1 + + required: + - compatible + - reg
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml line 55
Quoted 10 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +9
-0+ +additionalProperties: false + +required: + - compatible + - reg + - ranges + - address-cells + - size-cells
Not documented and also the wrong names (missing '#').
Quoted 37 lines
Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml new file +15
-0+ +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>; + }; + };MAINTAINERS +7
-0@@ -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]Signature · 1 line
2.25.1
RE: [EXTERNAL] Re: [PATCH v5 1/4] dt-bindings: platform: microsoft: Document surface xbl
Quoted 6 lines
From: Rob Herring <[email protected]>
On Wednesday, April 13, 2022 at 11:27 AM, Rob wrote:Quoted 2 lines · Jarrett Schultz
From: Jarrett Schultz <[email protected]>
Quoted 11 lines
Quoted 1 line
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'.
Quoted 3 lines
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
RE: [EXTERNAL] Re: [PATCH v5 1/4] dt-bindings: platform: microsoft: Document surface xbl
Quoted 22 lines · Jarrett Schultz
From: Jarrett Schultz <[email protected]>
Quoted 6 lines
From: Rob Herring <[email protected]>
On Wednesday, April 13, 2022 at 11:27 AM, Rob wrote:Quoted 2 lines · Jarrett Schultz
From: Jarrett Schultz <[email protected]>
Quoted 7 lines
Quoted 1 line
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'.
Quoted 4 lines
Quoted 4 lines
Signed-off-by Jarrett Schultz <[email protected]>
Quoted 8 lines
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
PATCH v5 2/4 platform: surface: Add surface xbl
In reply to Jarrett SchultzFrom: Jarrett Schultz <[email protected]>
Introduce support for the Extensible Boot Loader driver found on the Surface Duo. Makes device information available to users via sysfs.
---
Changes in v4:
- N/A
---
Changes in v3:
- Updated several descriptions in the yaml to be more descriptive
- Renamed files to use an underscore instead of a dash
---
Changes in v2:
- 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
- Changed target KernelVersion in sysfs documentation
--- .../ABI/testing/sysfs-platform-surface-xbl | 79 ++++++++ MAINTAINERS | 2 + drivers/platform/surface/Kconfig | 12 ++ drivers/platform/surface/Makefile | 1 + drivers/platform/surface/surface_xbl.c | 186 ++++++++++++++++++ 5 files changed, 280 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-surface-xbl create mode 100644 drivers/platform/surface/surface_xbl.c
Documentation/ABI/testing/sysfs-platform-surface-xbl new file +79 -0
@@ -0,0 +1,79 @@ +What: /sys/devices/platform/146bfa94.xbl/battery_present +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns whether the battery is present. Valid + values are: + 0 - battery absent + 1 - battery present + +What: /sys/devices/platform/146bfa94.xbl/board_id +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns a Microsoft specific board id. + +What: /sys/devices/platform/146bfa94.xbl/hw_init_retries +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns a Microsoft specific value related to the + retries attempted to properly initialize the battery charging + subsystem. + +What: /sys/devices/platform/146bfa94.xbl/is_act_mode +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns whether ACT mode is enabled. Valid values + are: + 0 - ACT disabled + 1 - ACT enabled + + ACT mode is used to run checks and put the device to shipmode + at factory. + +What: /sys/devices/platform/146bfa94.xbl/is_customer_mode +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + + mode. Valid values are: + 0 - Not in manufacturing mode + 1 - In manufacturing mode + +What: /sys/devices/platform/146bfa94.xbl/ocp_error_location +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns 0 or the id of the power rail which has the + OCP error. Valid values are: + Bit(s) Meaning + 15 More than one OCP error occurred + 14-12 PMIC + 11-7 SMPS + 6-2 LDO + 1-0 BOB + +What: /sys/devices/platform/146bfa94.xbl/pmic_reset_reason +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns the reason for the reset. Valid values + are: + 0 - no reason lol + 9 - Battery driver triggered + +What: /sys/devices/platform/146bfa94.xbl/touch_fw_version +Date: October 2021 +KernelVersion: 5.16 +Contact: [email protected] +Description: + Read only. It returns the version of the firmware.
MAINTAINERS +2 -0
@@ -12654,7 +12654,9 @@ M: Jarrett Schultz <[email protected]> L: [email protected] L: [email protected] S: Supported +F: Documentation/ABI/testing/sysfs-platform-surface-xbl F: Documentation/devicetree/bindings/platform/microsoft/surface-xbl.yaml +F: drivers/platform/surface/surface-xbl.c MICROSOFT SURFACE GPE LID SUPPORT DRIVER M: Maximilian Luz <[email protected]>
drivers/platform/surface/Kconfig +12 -0
@@ -185,6 +185,18 @@ config SURFACE_PRO3_BUTTON help This driver handles the power/home/volume buttons on the Microsoft Surface Pro 3/4 tablet. +config SURFACE_XBL + tristate "Surface XBL Driver" + depends on ARM64 || COMPILE_TEST + depends on OF + help + If you say 'Y' to this option, support will be included for the + Surface Extensible Boot Loader (XBL) Driver. This driver exposes + information about the device through sysfs. + + This driver can also be built as a module. If so, the module + will be called surface-xbl. + source "drivers/platform/surface/aggregator/Kconfig" endif # SURFACE_PLATFORMS
drivers/platform/surface/Makefile +1 -0
@@ -16,3 +16,4 @@ obj-$(CONFIG_SURFACE_GPE) += surface_gpe.o obj-$(CONFIG_SURFACE_HOTPLUG) += surface_hotplug.o obj-$(CONFIG_SURFACE_PLATFORM_PROFILE) += surface_platform_profile.o obj-$(CONFIG_SURFACE_PRO3_BUTTON) += surfacepro3_button.o +obj-$(CONFIG_SURFACE_XBL) += surface_xbl.o
drivers/platform/surface/surface_xbl.c new file +186 -0
186 lines not on this page · raw message
Signature · 1 line
2.25.1
PATCH v5 3/4 arm64: dts: qcom: sm8150: Add imem section
In reply to Jarrett SchultzFrom: Jarrett Schultz <[email protected]>
Introduce the imem section in preparation for the surface xbl driver.
---
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(+)
arch/arm64/boot/dts/qcom/sm8150.dtsi +8 -0
@@ -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>;
Signature · 1 line
2.25.1
PATCH v5 4/4 arm64: dts: qcom: surface-duo: Add surface xbl
In reply to Jarrett SchultzFrom: Jarrett Schultz <[email protected]>
Introduce device tree source for the surface xbl driver.
---
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(+)
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +10 -0
@@ -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";
Signature · 1 line
2.25.1
Hi Jarrett,
Quoted 8 lines · Jarrett Schultz
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
Quoted 74 lines
~ 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,
* Addedtypes.hinclusion and removed unused inclusions
* Minor updates to code and acronym style
* Remove__packedattribute on driver struct
* Use .dev_groups for sysfs
- Added more in-depth description of driver inKconfig
- Modified dts to reference a newly added section insm8150.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
Rob Herring
maintainerQuoted 11 lines · Hans de Goede
Hi Jarrett,
Quoted 8 lines · Jarrett Schultz
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 :)
Quoted 6 lines
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