| Message ID | 20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | misc: Add mikroBUS driver | expand |
On 6/27/24 21:56, Ayush Singh wrote: > MikroBUS is an open standard developed by MikroElektronika for connecting > add-on boards to microcontrollers or microprocessors. It essentially > allows you to easily expand the functionality of your main boards using > these add-on boards. > > This patchset adds mikroBUS as a Linux bus type and provides a driver to > parse and register the mikroBUS board using device tree infrastructure. > > The patchset is based on work originally done by Vaishnav. > > Link: https://www.mikroe.com/mikrobus > Link: https://docs.beagleboard.org/latest/boards/beagleplay/ > Link: https://lore.kernel.org/all/20240317193714.403132-1-ayushdevel1325@gmail.com/ Patch v4 > > Changes v5 > - Complete rewrite to use device tree instead of mikroBUS manifest. > - Only support for SPI. > - Adds `mikrobus,spi` compatible property. > > Changes v4: > - Better commit messages > - Remove clickID, serdev, pwm, regulator, clocks etc. Just the basic > mikroBUS driver. > - Fix a lot of memory leaks, unused variables, etc. > - Create accompanying PR in Greybus Spec repository > - Switch to 80 columns formatting > - Some other fixes pointed out in v3 > > Changes in v3: > - Use phandle instead of busname for spi > - Use spi board info for registering new device > - Convert dt bindings to yaml > - Add support for clickID > - Code cleanup and style changes > - Additions required to spi, serdev, w1 and regulator subsystems > > Changes in v2: > - support for adding mikroBUS ports from DT overlays, > - remove debug sysFS interface for adding mikrobus ports, > - consider extended pin usage/deviations from mikrobus standard > specifications > - use greybus CPort protocol enum instead of new protocol enums > - Fix cases of wrong indentation, ignoring return values, freeing allocated > resources in case of errors and other style suggestions in v1 review. > > Signed-off-by: Ayush Singh <ayush@beagleboard.org> > --- > Ayush Singh (7): > dt-bindings: connector: Add mikrobus-connector > dt-bindings: mikrobus: Add mikrobus board base > dt-bindings: mikrobus: Add mikrobus-spi binding > spi: Make of_find_spi_controller_by_node() available > spi: Make of_register_spi_device() available > mikrobus: Add mikroBUS driver > dts: ti: k3-am625-beagleplay: Add mikroBUS > > .../bindings/connector/mikrobus-connector.yaml | 107 ++++++ > .../bindings/mikrobus/mikrobus-board.yaml | 20 ++ > .../devicetree/bindings/mikrobus/mikrobus-spi.yaml | 37 +++ > MAINTAINERS | 9 + > arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 94 +++++- > drivers/misc/Kconfig | 16 + > drivers/misc/Makefile | 1 + > drivers/misc/mikrobus.c | 361 +++++++++++++++++++++ > drivers/spi/spi.c | 209 ++++++------ > include/linux/spi/spi.h | 7 + > 10 files changed, 750 insertions(+), 111 deletions(-) > --- > base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7 > change-id: 20240627-mikrobus-scratch-spi-ad8c98dcec98 > > Best regards, I would just like to summarize the discussions on different patches here to give information regarding why the board is not subnode of mikrobus-connector along with what questions need to be answered for a subnode based architecture. I will be using (```) to differentiate between code section and non-code section. It is just for seperation not for any formatting since I am using plaintext. Let me first summarise the goals that should be possible with any architecture chosen. 1. Keeping the device tree properties upstream in a system independent way. 2. Editing system dt at kernel build time to add the pre-defined board or applying dt overlay using uboot or dynamic overlays. 3. Allowing creation of sysfs entries `new_device` and `delete_device` similar to what already exists for I2C, etc. 4. Allow using 1-wire-eeprom in a fashion that allows automatic board discovery. Let me now introduce the 2 architectures we will be discussing: 1. mikrobus-connector has phandle to mikrobus-board: ``` \ { connector1 { board = <&board1>; }; mikrobus_boards { board1 { ... }; }; }; ``` 2. mikrobus board is a child node of mikrobus-connector: ``` \ { connector1 { ... spi { board1 { ... }; }; }; }; ``` I will now go over how each of these goals might look like in both of the architecture. 1. Keeping the device tree properties upstream in a system independent way: a. mikrobus-connector has phandle to mikrobus-board It is possible to create an overlay as follows which will work with any system that defines the `mikrobus_boards` node. This node is completely independent of mikroBUS connector and thus does not need to be rewritten (or generated) for each board. There are no problems for system with more than 1 mikrobus connector. ``` &mikrobus_boards { board2 { ... }; board3 { ... }; }; ``` b. mikrobus board is a child node of mikrobus-connector: Not sure how to do something similar here. The overlay needs to be rewritten (or generated) for each board. Systems with multiple mikrobus connectors will need multiple overlays adding the boards as child node of each connector (with status = "disabled"). Considering how many mikrobus boards are available, this can also lead to problem (especially in embeded Linux) with the dt binary size since each connector is replicating the same overlay. ``` &connector1 { spi = { board 2 { ... }; board 3 { ... }; }; }; &connector2 { spi = { board 2 { ... }; board 3 { ... }; }; }; ``` Maybe it is possible to have special behavior for mikrobus-connector nodes in dt overlay but that will break compatibility with exisiting infrastructure which isn't great. 2. Editing system dt at kernel build time to add the pre-defined board or applying dt overlay using uboot or dynamic overlays. a. mikrobus-connector has phandle to mikrobus-board ``` &connector1 { board = <&board1>; }; ``` b. mikrobus board is a child node of mikrobus-connector: ``` &connector1 { spi = { board 2 { ... }; }; }; ``` Both the cases will need to generate these overlays at build time. However, in case (a), the overlay will be much smaller than case (b). This is important for embeded Linux. 3. Allowing creation of sysfs entries `new_device` and `delete_device` similar to what already exists for I2C, etc. a. mikrobus-connector has phandle to mikrobus-board It is quite simple with the current changeset APIs. I have an example implementation here: https://github.com/Ayush1325/linux/blob/c4e3d5138b7ad5c24bdbc1dd02d89720d3a5de82/drivers/misc/mikrobus.c#L59 . Essentially, it is possible to pass the mikroBUS board name or id to create changeset as long as the board has been defined in dt. The boards definition can be added using overlay in uboot of dynamic overlays using configfs patch. b. mikrobus board is a child node of mikrobus-connector: Since even the board definition overlay is now dependent on the connector, any person writing the board overlay needs to know the name's of the connector nodes and generate overlays for all connectors. We can toggle a `status` property to `okay` based on the board id passed through sysfs. 4. Allow using 1-wire-eeprom in a fashion that allows automatic board discovery. a. mikrobus-connector has phandle to mikrobus-board 1-wire-eeprom only needs to contain the board definition overlay which is not dependent on the connector. The connector can generate the changeset of add `board` property to itself. The board should work irrespective of if the dt overlay is actually present in the kernel config since we can read the overlay from 1-wire-eeprom and apply it using `of_overlay_fdt_apply()`. b. mikrobus board is a child node of mikrobus-connector: Cannot really use the normal dt overlay. Maybe we can use the mikroBUS manifest to dynamically create the overlay, but well, I do not wish to support both the manifest and devicetree at the same time. Maybe we can introduce something like partial device tree which only contains properties to be applied to a target device node? Since `of_overlay_fdt_apply` does contain target node property, maybe it is already possible to have an overlay that is generic over a type of node instead of the exact node? I will also go through the overlay kernel internals to see if there are any better ways to use child-nodes. Feel free to chime in if you have any ideas. Yours Sincerely, Ayush Singh
> 3. Allowing creation of sysfs entries `new_device` and `delete_device` > similar to what already exists for I2C, etc. On the I2C bus, these operate at the device level, you instantiate a new I2C device. I assume here you are actually talking about board level operations? So they would be 'new_board', and 'delete_board' files in sysfs? > > 4. Allow using 1-wire-eeprom in a fashion that allows automatic board > discovery. > > > Let me now introduce the 2 architectures we will be discussing: > > 1. mikrobus-connector has phandle to mikrobus-board: > > ``` > > \ { > > connector1 { > > board = <&board1>; > > }; > > > mikrobus_boards { > > board1 { > > ... > > }; > > }; > > }; > > ``` > > > 2. mikrobus board is a child node of mikrobus-connector: > > ``` > > \ { > > connector1 { > > ... > > spi { So there would actually be multiple child nodes, one per bus, and then maybe a simple-bus for nodes which do not correspond to a bus, e.g. gpio-key, gpio-leds, etc., > > board1 { > > ... > > }; > > }; > > }; > > }; > > ``` > > > I will now go over how each of these goals might look like in both of the > architecture. > > 1. Keeping the device tree properties upstream in a system independent way: > > a. mikrobus-connector has phandle to mikrobus-board > > It is possible to create an overlay as follows which will work with any > system that defines the `mikrobus_boards` node. This node is completely > independent of mikroBUS connector and thus does not need to be rewritten (or > generated) for each board. There are no problems for system with more than 1 > mikrobus connector. > > ``` > > &mikrobus_boards { > > board2 { > > ... > > }; > > > board3 { > > ... > > }; > > }; So by default, you have an empty mikrobus_boards node? You then use DT overlay to load the needed board into this node, and then update the phandle in the connection node to point to the newly loaded node? > b. mikrobus board is a child node of mikrobus-connector: > > Not sure how to do something similar here. The overlay needs to be rewritten > (or generated) for each board. It would be good to explain why... > Systems with multiple mikrobus connectors > will need multiple overlays adding the boards as child node of each > connector (with status = "disabled"). Why? Just load the one overlay actually required. > &connector1 { > > spi = { > > board 2 { > > ... > > }; > > board 3 { > > ... > > }; > > }; > > }; I don't actually understand this description. I was expecting more like: connector1: { spi = { /* Optional TI TSC2046 touchscreen controller */ opt_touch: touchscreen@0 { compatible = "ti,tsc2046"; spi-max-frequency = <2500000>; reg = <0>; pinctrl-0 = <&pmx_gpio_13>; pinctrl-names = "default"; interrupts-extended = <&gpio0 13 IRQ_TYPE_EDGE_FALLING>; }; }; i2c = { opt_audio: audio@1a { compatible = "ti,tlv320aic23"; reg = <0x1a>; }; the_rest = { gpio_keys { compatible = "gpio-keys"; #address-cells = <1>; #size-cells = <0>; pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; pinctrl-names = "default"; copy { label = "USB Copy"; linux,code = <KEY_COPY>; gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; }; reset { label = "Reset"; linux,code = <KEY_RESTART>; gpios = <&gpio0 16 GPIO_ACTIVE_LOW>; }; }; This is completely made up. You probably should use an example of a real complex board using multiple busses. So for each actual bus on Mikrobus, you have a bus node, and then a node for everything which is not bus orientated, like gpio-keys. So the overlay would simply populate these child nodes. > Maybe it is possible to have special behavior for mikrobus-connector nodes > in dt overlay but that will break compatibility with exisiting > infrastructure which isn't great. You have not explain what special behaviour is actually needed. Andrew
On Thu, 27 Jun 2024 21:56:10 +0530, Ayush Singh wrote: > MikroBUS is an open standard developed by MikroElektronika for connecting > add-on boards to microcontrollers or microprocessors. It essentially > allows you to easily expand the functionality of your main boards using > these add-on boards. > > This patchset adds mikroBUS as a Linux bus type and provides a driver to > parse and register the mikroBUS board using device tree infrastructure. > > The patchset is based on work originally done by Vaishnav. > > Link: https://www.mikroe.com/mikrobus > Link: https://docs.beagleboard.org/latest/boards/beagleplay/ > Link: https://lore.kernel.org/all/20240317193714.403132-1-ayushdevel1325@gmail.com/ Patch v4 > > Changes v5 > - Complete rewrite to use device tree instead of mikroBUS manifest. > - Only support for SPI. > - Adds `mikrobus,spi` compatible property. > > Changes v4: > - Better commit messages > - Remove clickID, serdev, pwm, regulator, clocks etc. Just the basic > mikroBUS driver. > - Fix a lot of memory leaks, unused variables, etc. > - Create accompanying PR in Greybus Spec repository > - Switch to 80 columns formatting > - Some other fixes pointed out in v3 > > Changes in v3: > - Use phandle instead of busname for spi > - Use spi board info for registering new device > - Convert dt bindings to yaml > - Add support for clickID > - Code cleanup and style changes > - Additions required to spi, serdev, w1 and regulator subsystems > > Changes in v2: > - support for adding mikroBUS ports from DT overlays, > - remove debug sysFS interface for adding mikrobus ports, > - consider extended pin usage/deviations from mikrobus standard > specifications > - use greybus CPort protocol enum instead of new protocol enums > - Fix cases of wrong indentation, ignoring return values, freeing allocated > resources in case of errors and other style suggestions in v1 review. > > Signed-off-by: Ayush Singh <ayush@beagleboard.org> > --- > Ayush Singh (7): > dt-bindings: connector: Add mikrobus-connector > dt-bindings: mikrobus: Add mikrobus board base > dt-bindings: mikrobus: Add mikrobus-spi binding > spi: Make of_find_spi_controller_by_node() available > spi: Make of_register_spi_device() available > mikrobus: Add mikroBUS driver > dts: ti: k3-am625-beagleplay: Add mikroBUS > > .../bindings/connector/mikrobus-connector.yaml | 107 ++++++ > .../bindings/mikrobus/mikrobus-board.yaml | 20 ++ > .../devicetree/bindings/mikrobus/mikrobus-spi.yaml | 37 +++ > MAINTAINERS | 9 + > arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 94 +++++- > drivers/misc/Kconfig | 16 + > drivers/misc/Makefile | 1 + > drivers/misc/mikrobus.c | 361 +++++++++++++++++++++ > drivers/spi/spi.c | 209 ++++++------ > include/linux/spi/spi.h | 7 + > 10 files changed, 750 insertions(+), 111 deletions(-) > --- > base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7 > change-id: 20240627-mikrobus-scratch-spi-ad8c98dcec98 > > Best regards, > -- > Ayush Singh <ayush@beagleboard.org> > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y ti/k3-am625-beagleplay.dtb' for 20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org: arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: mikrobus-connector: mikrobus-gpio-names:6: 'mosi' is not one of ['pwm', 'int', 'rx', 'tx', 'scl', 'sda', 'an', 'rst', 'cs', 'sck', 'cipo', 'copi'] from schema $id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: mikrobus-connector: mikrobus-gpio-names:7: 'miso' is not one of ['pwm', 'int', 'rx', 'tx', 'scl', 'sda', 'an', 'rst', 'cs', 'sck', 'cipo', 'copi'] from schema $id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: thermo-click: compatible: ['maxim,max31855k', 'mikrobus-spi'] is too long from schema $id: http://devicetree.org/schemas/iio/temperature/maxim,max31855k.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: thermo-click: 'reg' is a required property from schema $id: http://devicetree.org/schemas/iio/temperature/maxim,max31855k.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: thermo-click: Unevaluated properties are not allowed ('compatible', 'pinctrl-apply' were unexpected) from schema $id: http://devicetree.org/schemas/iio/temperature/maxim,max31855k.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: lsm6dsl-click: compatible: 'oneOf' conditional failed, one must be fixed: ['st,lsm6ds3', 'mikrobus-spi'] is too long 'st,lsm6ds3' is not one of ['st,asm330lhhx', 'st,asm330lhhxg1'] 'st,lsm6dstx' was expected 'st,lsm6dsv16x' was expected 'st,ism330is' was expected 'st,asm330lhb' was expected 'st,lsm6dsr' was expected 'st,lsm6dst' was expected 'st,lsm6dsv' was expected 'st,lsm6dso16is' was expected 'st,asm330lhh' was expected from schema $id: http://devicetree.org/schemas/iio/imu/st,lsm6dsx.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: lsm6dsl-click: 'reg' is a required property from schema $id: http://devicetree.org/schemas/iio/imu/st,lsm6dsx.yaml# arch/arm64/boot/dts/ti/k3-am625-beagleplay.dtb: lsm6dsl-click: Unevaluated properties are not allowed ('compatible', 'pinctrl-apply' were unexpected) from schema $id: http://devicetree.org/schemas/iio/imu/st,lsm6dsx.yaml#
On 6/28/24 19:22, Andrew Lunn wrote: >> 3. Allowing creation of sysfs entries `new_device` and `delete_device` >> similar to what already exists for I2C, etc. > On the I2C bus, these operate at the device level, you instantiate a > new I2C device. I assume here you are actually talking about board > level operations? So they would be 'new_board', and 'delete_board' > files in sysfs? > >> 4. Allow using 1-wire-eeprom in a fashion that allows automatic board >> discovery. >> >> >> Let me now introduce the 2 architectures we will be discussing: >> >> 1. mikrobus-connector has phandle to mikrobus-board: >> >> ``` >> >> \ { >> >> connector1 { >> >> board = <&board1>; >> >> }; >> >> >> mikrobus_boards { >> >> board1 { >> >> ... >> >> }; >> >> }; >> >> }; >> >> ``` >> >> >> 2. mikrobus board is a child node of mikrobus-connector: >> >> ``` >> >> \ { >> >> connector1 { >> >> ... >> >> spi { > So there would actually be multiple child nodes, one per bus, and then > maybe a simple-bus for nodes which do not correspond to a bus, > e.g. gpio-key, gpio-leds, etc., > >> board1 { >> >> ... >> >> }; >> >> }; >> >> }; >> >> }; >> >> ``` >> >> >> I will now go over how each of these goals might look like in both of the >> architecture. >> >> 1. Keeping the device tree properties upstream in a system independent way: >> >> a. mikrobus-connector has phandle to mikrobus-board >> >> It is possible to create an overlay as follows which will work with any >> system that defines the `mikrobus_boards` node. This node is completely >> independent of mikroBUS connector and thus does not need to be rewritten (or >> generated) for each board. There are no problems for system with more than 1 >> mikrobus connector. >> >> ``` >> >> &mikrobus_boards { >> >> board2 { >> >> ... >> >> }; >> >> >> board3 { >> >> ... >> >> }; >> >> }; > So by default, you have an empty mikrobus_boards node? You then use DT > overlay to load the needed board into this node, and then update the > phandle in the connection node to point to the newly loaded node? > >> b. mikrobus board is a child node of mikrobus-connector: >> >> Not sure how to do something similar here. The overlay needs to be rewritten >> (or generated) for each board. > It would be good to explain why... > >> Systems with multiple mikrobus connectors >> will need multiple overlays adding the boards as child node of each >> connector (with status = "disabled"). > Why? Just load the one overlay actually required. > >> &connector1 { >> >> spi = { >> >> board 2 { >> >> ... >> >> }; >> >> board 3 { >> >> ... >> >> }; >> >> }; >> >> }; > I don't actually understand this description. I was expecting more > like: > > connector1: { > > spi = { > /* Optional TI TSC2046 touchscreen controller */ > opt_touch: touchscreen@0 { > compatible = "ti,tsc2046"; > spi-max-frequency = <2500000>; > reg = <0>; > pinctrl-0 = <&pmx_gpio_13>; > pinctrl-names = "default"; > interrupts-extended = <&gpio0 13 IRQ_TYPE_EDGE_FALLING>; > }; > }; > > i2c = { > opt_audio: audio@1a { > compatible = "ti,tlv320aic23"; > reg = <0x1a>; > }; > > the_rest = { > gpio_keys { > compatible = "gpio-keys"; > #address-cells = <1>; > #size-cells = <0>; > pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; > pinctrl-names = "default"; > > copy { > label = "USB Copy"; > linux,code = <KEY_COPY>; > gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; > }; > reset { > label = "Reset"; > linux,code = <KEY_RESTART>; > gpios = <&gpio0 16 GPIO_ACTIVE_LOW>; > }; > }; > > This is completely made up. You probably should use an example of a > real complex board using multiple busses. > > So for each actual bus on Mikrobus, you have a bus node, and then a > node for everything which is not bus orientated, like gpio-keys. > > So the overlay would simply populate these child nodes. I think I had a fundamental misunderstanding of what dt overlays can do. My understanding was that to say add thermo click in the above style with child nodes, the overlay needs to look as follows &connector1 { spi { thermo_click: { compatible = "maxim,max31855k", "mikrobus-spi"; spi-max-frequency = <1000000>; pinctrl-apply = "spi_default"; }; }; }; However, after going through the drm PR pointed by Rob and your description, it seems it is possible to create an overlay as follows: &spi { thermo_click: { compatible = "maxim,max31855k"; spi-max-frequency = <1000000>; pinctrl-apply = "spi_default"; }; }; and apply it to the particular connector node (say connector1), at least from the driver. If that is the case, then yes, all of my reasons for not wanting to use child nodes become irrelevant. DRM PR: https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-0-ec32f2c66d56@bootlin.com/ Ayush Singh
MikroBUS is an open standard developed by MikroElektronika for connecting add-on boards to microcontrollers or microprocessors. It essentially allows you to easily expand the functionality of your main boards using these add-on boards. This patchset adds mikroBUS as a Linux bus type and provides a driver to parse and register the mikroBUS board using device tree infrastructure. The patchset is based on work originally done by Vaishnav. Link: https://www.mikroe.com/mikrobus Link: https://docs.beagleboard.org/latest/boards/beagleplay/ Link: https://lore.kernel.org/all/20240317193714.403132-1-ayushdevel1325@gmail.com/ Patch v4 Changes v5 - Complete rewrite to use device tree instead of mikroBUS manifest. - Only support for SPI. - Adds `mikrobus,spi` compatible property. Changes v4: - Better commit messages - Remove clickID, serdev, pwm, regulator, clocks etc. Just the basic mikroBUS driver. - Fix a lot of memory leaks, unused variables, etc. - Create accompanying PR in Greybus Spec repository - Switch to 80 columns formatting - Some other fixes pointed out in v3 Changes in v3: - Use phandle instead of busname for spi - Use spi board info for registering new device - Convert dt bindings to yaml - Add support for clickID - Code cleanup and style changes - Additions required to spi, serdev, w1 and regulator subsystems Changes in v2: - support for adding mikroBUS ports from DT overlays, - remove debug sysFS interface for adding mikrobus ports, - consider extended pin usage/deviations from mikrobus standard specifications - use greybus CPort protocol enum instead of new protocol enums - Fix cases of wrong indentation, ignoring return values, freeing allocated resources in case of errors and other style suggestions in v1 review. Signed-off-by: Ayush Singh <ayush@beagleboard.org> --- Ayush Singh (7): dt-bindings: connector: Add mikrobus-connector dt-bindings: mikrobus: Add mikrobus board base dt-bindings: mikrobus: Add mikrobus-spi binding spi: Make of_find_spi_controller_by_node() available spi: Make of_register_spi_device() available mikrobus: Add mikroBUS driver dts: ti: k3-am625-beagleplay: Add mikroBUS .../bindings/connector/mikrobus-connector.yaml | 107 ++++++ .../bindings/mikrobus/mikrobus-board.yaml | 20 ++ .../devicetree/bindings/mikrobus/mikrobus-spi.yaml | 37 +++ MAINTAINERS | 9 + arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 94 +++++- drivers/misc/Kconfig | 16 + drivers/misc/Makefile | 1 + drivers/misc/mikrobus.c | 361 +++++++++++++++++++++ drivers/spi/spi.c | 209 ++++++------ include/linux/spi/spi.h | 7 + 10 files changed, 750 insertions(+), 111 deletions(-) --- base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7 change-id: 20240627-mikrobus-scratch-spi-ad8c98dcec98 Best regards,