diff mbox series

[v3,1/8] dt-bindings: misc: Add mikrobus-connector

Message ID 20240315184908.500352-2-ayushdevel1325@gmail.com (mailing list archive)
State Superseded
Headers show
Series misc: Add mikroBUS driver | expand

Commit Message

Ayush Singh March 15, 2024, 6:48 p.m. UTC
Add DT bindings for mikroBUS interface. MikroBUS is an open standard
developed by MikroElektronika for connecting add-on boards to
microcontrollers or microprocessors.

Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
---
 .../bindings/misc/mikrobus-connector.yaml     | 110 ++++++++++++++++++
 MAINTAINERS                                   |   6 +
 2 files changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/mikrobus-connector.yaml

Comments

Krzysztof Kozlowski March 15, 2024, 8:09 p.m. UTC | #1
On 15/03/2024 19:48, Ayush Singh wrote:
> Add DT bindings for mikroBUS interface. MikroBUS is an open standard
> developed by MikroElektronika for connecting add-on boards to
> microcontrollers or microprocessors.
> 
> Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
> ---
>  .../bindings/misc/mikrobus-connector.yaml     | 110 ++++++++++++++++++
>  MAINTAINERS                                   |   6 +
>  2 files changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
> 
> diff --git a/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
> new file mode 100644
> index 000000000000..6eace2c0dddc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml

Please put it in connector directory.

> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/mikrobus-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: mikroBUS add-on board socket
> +
> +maintainers:
> +  - Ayush Singh <ayushdevel1325@gmail.com>
> +
> +properties:
> +  compatible:
> +    const: mikrobus-connector

Hm, why do you create binding for the connector, not for some sort of
controller? Please provide some rationale for this in commit msg.

> +
> +  pinctrl-0: true
> +  pinctrl-1: true
> +  pinctrl-2: true
> +  pinctrl-3: true
> +  pinctrl-4: true
> +  pinctrl-5: true
> +  pinctrl-6: true
> +  pinctrl-7: true
> +  pinctrl-8: true
> +
> +  pinctrl-names:
> +    items:
> +      - const: default
> +      - const: pwm_default
> +      - const: pwm_gpio
> +      - const: uart_default
> +      - const: uart_gpio
> +      - const: i2c_default
> +      - const: i2c_gpio
> +      - const: spi_default
> +      - const: spi_gpio

I fail to see why such choice is related to the connector itself.
Connector could have just SPI attached, so why all other entries needs
to be provided? Or is it fully plugable? But then really please explain
the hardware in the binding description.

> +
> +  mikrobus-gpios:
> +    minItems: 11
> +    maxItems: 12
> +
> +  i2c-adapter:
> +    description: i2c adapter attached to the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  spi-controller:
> +    description: spi bus number of the spi-master attached to the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  uart:
> +    description: uart port attached to the mikrobus socket
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  pwms:
> +    description: the pwm-controller corresponding to the mikroBUS PWM pin.
> +    maxItems: 1
> +
> +  spi-cs:
> +    description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    items:
> +      - description: chip select corresponding to CS pin
> +      - description: chip select corresponding to RST pin

I don't understand why do you need all these properties. First, if this
is connector then I would rather see some sort of graph, not phandles.
Why would connector need to do anything with SPI controller?

All this looks like made for software. For the driver.

> +
> +required:
> +  - compatible
> +  - pinctrl-0
> +  - pinctrl-1
> +  - pinctrl-2
> +  - pinctrl-3
> +  - pinctrl-4
> +  - pinctrl-5
> +  - pinctrl-6
> +  - pinctrl-7
> +  - pinctrl-8
> +  - i2c-adapter
> +  - spi-controller
> +  - spi-cs
> +  - uart
> +  - pwms
> +  - mikrobus-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +      mikrobus-0 {

mikrobus {

and fix the indentation. Use 4 spaces for example indentation.

> +        compatible = "mikrobus-connector";
> +        status = "okay";

Drop.

> +        pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default",
> +                        "i2c_gpio", "spi_default", "spi_gpio";
> +        pinctrl-0 = <&P2_03_gpio_input_pin &P1_04_gpio_pin &P1_02_gpio_pin>;
> +        pinctrl-1 = <&P2_01_pwm_pin>;
> +        pinctrl-2 = <&P2_01_gpio_pin>;
> +        pinctrl-3 = <&P2_05_uart_pin &P2_07_uart_pin>;
> +        pinctrl-4 = <&P2_05_gpio_pin &P2_07_gpio_pin>;
> +        pinctrl-5 = <&P2_09_i2c_pin &P2_11_i2c_pin>;
> +        pinctrl-6 = <&P2_09_gpio_pin &P2_11_gpio_pin>;
> +        pinctrl-7 = <&P1_12_spi_pin &P1_10_spi_pin &P1_08_spi_sclk_pin &P1_06_spi_cs_pin>;
> +        pinctrl-8 = <&P1_12_gpio_pin &P1_10_gpio_pin &P1_08_gpio_pin &P1_06_gpio_pin>;
> +        i2c-adapter = <&i2c1>;
> +        spi-controller = <&spi1>;
> +        spi-cs = <0 1>;
> +        uart = <&uart1>;
> +        pwms = <&ehrpwm1 0 500000 0>;
> +        mikrobus-gpios = <&gpio1 18 0> , <&gpio0 23 0>, <&gpio0 30 0> , <&gpio0 31 0>, <&gpio0 15 0>,
> +                         <&gpio0 14 0>, <&gpio0 4 0> , <&gpio0 3 0>, <&gpio0 2 0>, <&gpio0 5 0>,
> +                         <&gpio2 25 0>, <&gpio2 3 0>;

Use proper defines for GPIO flags.



Best regards,
Krzysztof
Russell King (Oracle) March 15, 2024, 8:20 p.m. UTC | #2
On Fri, Mar 15, 2024 at 09:09:11PM +0100, Krzysztof Kozlowski wrote:
> > +properties:
> > +  compatible:
> > +    const: mikrobus-connector
> 
> Hm, why do you create binding for the connector, not for some sort of
> controller? Please provide some rationale for this in commit msg.

I think you have a distorted view. I refer you to the Mikroe mikroBUS
specification - it's _just_ a connector which provides a fairly
standardised purpose for each pin and the electrical specifications.
For example of the pins: power, UART, SPIs, I2C, PWM, and analogue
pins.

> > +  pinctrl-names:
> > +    items:
> > +      - const: default
> > +      - const: pwm_default
> > +      - const: pwm_gpio
> > +      - const: uart_default
> > +      - const: uart_gpio
> > +      - const: i2c_default
> > +      - const: i2c_gpio
> > +      - const: spi_default
> > +      - const: spi_gpio
> 
> I fail to see why such choice is related to the connector itself.

This isn't a choice at all. Here's the list of pins:

Analog - AN
Reset - RST
SPI Chip Select - CS
SPI Clock - SCK
SPI Master Input Slave Output - MISO
SPI Master Output Slave Input - MOSI
VCC-3.3V power - +3.3V
Reference Ground - GND
PWM - PWM output
INT - Hardware Interrupt
RX - UART Receive
TX - UART Transmit
SCL - I2C Clock
SDA - I2C Data
+5V - VCC-5V power
GND - Reference Ground

Any data pin can be a GPIO if e.g. a relay board is plugged in, even
if some of the other pins are used for e.g. UART purposes. For example,
a GPS board that provides the GPS data over the UART pins, and the
PPS signal through a different pin.
Krzysztof Kozlowski March 15, 2024, 8:40 p.m. UTC | #3
On 15/03/2024 21:20, Russell King (Oracle) wrote:
> On Fri, Mar 15, 2024 at 09:09:11PM +0100, Krzysztof Kozlowski wrote:
>>> +properties:
>>> +  compatible:
>>> +    const: mikrobus-connector
>>
>> Hm, why do you create binding for the connector, not for some sort of
>> controller? Please provide some rationale for this in commit msg.
> 
> I think you have a distorted view. I refer you to the Mikroe mikroBUS
> specification - it's _just_ a connector which provides a fairly
> standardised purpose for each pin and the electrical specifications.
> For example of the pins: power, UART, SPIs, I2C, PWM, and analogue
> pins.

I refer to the commit msg or description in the binding and there is
nothing explained like this. Yeah, true, I could google every possible
bus specification, but I also expect some sort of help here by the patch
submitter.

The binding looks like binding for a connector, not for some sort of
controller, then are you saying the control part it is purely in
software? That's how DTS looks like, but then my question is are there
some sort of controller which would also perform this?

> 
>>> +  pinctrl-names:
>>> +    items:
>>> +      - const: default
>>> +      - const: pwm_default
>>> +      - const: pwm_gpio
>>> +      - const: uart_default
>>> +      - const: uart_gpio
>>> +      - const: i2c_default
>>> +      - const: i2c_gpio
>>> +      - const: spi_default
>>> +      - const: spi_gpio
>>
>> I fail to see why such choice is related to the connector itself.
> 
> This isn't a choice at all. Here's the list of pins:
> 
> Analog - AN
> Reset - RST
> SPI Chip Select - CS
> SPI Clock - SCK
> SPI Master Input Slave Output - MISO
> SPI Master Output Slave Input - MOSI
> VCC-3.3V power - +3.3V
> Reference Ground - GND
> PWM - PWM output
> INT - Hardware Interrupt
> RX - UART Receive
> TX - UART Transmit
> SCL - I2C Clock
> SDA - I2C Data
> +5V - VCC-5V power
> GND - Reference Ground
> 
> Any data pin can be a GPIO if e.g. a relay board is plugged in, even
> if some of the other pins are used for e.g. UART purposes. For example,
> a GPS board that provides the GPS data over the UART pins, and the
> PPS signal through a different pin.

And could you not have some certain features supported? Could have some
pins just pull down / not connected?

Best regards,
Krzysztof
Russell King (Oracle) March 15, 2024, 9 p.m. UTC | #4
On Fri, Mar 15, 2024 at 09:40:13PM +0100, Krzysztof Kozlowski wrote:
> On 15/03/2024 21:20, Russell King (Oracle) wrote:
> > On Fri, Mar 15, 2024 at 09:09:11PM +0100, Krzysztof Kozlowski wrote:
> >>> +properties:
> >>> +  compatible:
> >>> +    const: mikrobus-connector
> >>
> >> Hm, why do you create binding for the connector, not for some sort of
> >> controller? Please provide some rationale for this in commit msg.
> > 
> > I think you have a distorted view. I refer you to the Mikroe mikroBUS
> > specification - it's _just_ a connector which provides a fairly
> > standardised purpose for each pin and the electrical specifications.
> > For example of the pins: power, UART, SPIs, I2C, PWM, and analogue
> > pins.
> 
> I refer to the commit msg or description in the binding and there is
> nothing explained like this. Yeah, true, I could google every possible
> bus specification, but I also expect some sort of help here by the patch
> submitter.
> 
> The binding looks like binding for a connector, not for some sort of
> controller, then are you saying the control part it is purely in
> software? That's how DTS looks like, but then my question is are there
> some sort of controller which would also perform this?

There is, as far as I'm aware, no "controller" for a mikroBUS. As I
tried to explain, it's a bunch of pins with defined standard functions.
The idea seems to be they're connected to a SoC with a pinmux that can
reconfigure the function of the pin.

At least that's how the hardware implementations I've seen do it.

> > This isn't a choice at all. Here's the list of pins:
> > 
> > Analog - AN
> > Reset - RST
> > SPI Chip Select - CS
> > SPI Clock - SCK
> > SPI Master Input Slave Output - MISO
> > SPI Master Output Slave Input - MOSI
> > VCC-3.3V power - +3.3V
> > Reference Ground - GND
> > PWM - PWM output
> > INT - Hardware Interrupt
> > RX - UART Receive
> > TX - UART Transmit
> > SCL - I2C Clock
> > SDA - I2C Data
> > +5V - VCC-5V power
> > GND - Reference Ground
> > 
> > Any data pin can be a GPIO if e.g. a relay board is plugged in, even
> > if some of the other pins are used for e.g. UART purposes. For example,
> > a GPS board that provides the GPS data over the UART pins, and the
> > PPS signal through a different pin.
> 
> And could you not have some certain features supported? Could have some
> pins just pull down / not connected?

A board plugged in doesn't have to use all the functions. I gave two
examples. Apart from the power pins,

The GPS board as I stated uses the two UART pins, and some GPS boards
route the PPS signal to another pin on the connector, but that's
entirely optional. Another pin might be used as a GPIO as an enable.

In the case of a relay board I've had, the SPI CS pin is used for one
relay, and the PWM pin for the other relay.

I also have a BME280 humidity/pressure sensor board, which just uses
the two I2C pins.

What is supported by a board is down to the board. Which pins it
connects to is down to the board. Which board is plugged in is up
to the user.

That is essentially the long and short of mikroBUS - I hope I've
given a good overview of it.

I am slightly confused by this series, because it seems the Linux
"mikroBUS" layer requires a one-wire EEPROM on the boards, but the
official mikroBUS specification doesn't state this. The author
really needs to clarify what they are implementing here. Are they
truly implementing mikroBUS as defined by Mikroe, or are they
implementing someone's custom extension to it that adds an
identification EEPROM - in which case I would argue that this
code as it stands is not suitable for mainline as long as it
purports to be implementing support for Mikroe's mikroBUS.

Hence, I think we should back off on reviewing this until we have
that clarification.
Rob Herring (Arm) March 17, 2024, 8:59 p.m. UTC | #5
On Sat, Mar 16, 2024 at 12:18:59AM +0530, Ayush Singh wrote:
> Add DT bindings for mikroBUS interface. MikroBUS is an open standard
> developed by MikroElektronika for connecting add-on boards to
> microcontrollers or microprocessors.
> 
> Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
> ---
>  .../bindings/misc/mikrobus-connector.yaml     | 110 ++++++++++++++++++
>  MAINTAINERS                                   |   6 +
>  2 files changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
> 
> diff --git a/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
> new file mode 100644
> index 000000000000..6eace2c0dddc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/mikrobus-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: mikroBUS add-on board socket
> +
> +maintainers:
> +  - Ayush Singh <ayushdevel1325@gmail.com>
> +
> +properties:
> +  compatible:
> +    const: mikrobus-connector
> +
> +  pinctrl-0: true
> +  pinctrl-1: true
> +  pinctrl-2: true
> +  pinctrl-3: true
> +  pinctrl-4: true
> +  pinctrl-5: true
> +  pinctrl-6: true
> +  pinctrl-7: true
> +  pinctrl-8: true
> +
> +  pinctrl-names:
> +    items:
> +      - const: default
> +      - const: pwm_default
> +      - const: pwm_gpio
> +      - const: uart_default
> +      - const: uart_gpio
> +      - const: i2c_default
> +      - const: i2c_gpio
> +      - const: spi_default
> +      - const: spi_gpio
> +
> +  mikrobus-gpios:
> +    minItems: 11
> +    maxItems: 12

What is each GPIO entry?

> +
> +  i2c-adapter:

We already have i2c-bus and i2c-parent properties. Neither of those work 
for you?

> +    description: i2c adapter attached to the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  spi-controller:
> +    description: spi bus number of the spi-master attached to the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  uart:

Nice and consistent. In 3 properties, we have 'adapter', 'controller' 
and <null>...

Also, DT generally uses 'serial' rather than 'uart'.

> +    description: uart port attached to the mikrobus socket
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  pwms:
> +    description: the pwm-controller corresponding to the mikroBUS PWM pin.
> +    maxItems: 1
> +
> +  spi-cs:
> +    description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    items:
> +      - description: chip select corresponding to CS pin
> +      - description: chip select corresponding to RST pin

How would someone handle any of the properties defined in 
spi-peripheral-props.yaml?


Rob
Ayush Singh March 18, 2024, 12:37 p.m. UTC | #6
A new version of the patch is up and can be found here: 
https://lore.kernel.org/lkml/20240317193714.403132-1-ayushdevel1325@gmail.com/


On 3/18/24 02:29, Rob Herring wrote:

> On Sat, Mar 16, 2024 at 12:18:59AM +0530, Ayush Singh wrote:
>> Add DT bindings for mikroBUS interface. MikroBUS is an open standard
>> developed by MikroElektronika for connecting add-on boards to
>> microcontrollers or microprocessors.
>>
>> Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
>> ---
>>   .../bindings/misc/mikrobus-connector.yaml     | 110 ++++++++++++++++++
>>   MAINTAINERS                                   |   6 +
>>   2 files changed, 116 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
>> new file mode 100644
>> index 000000000000..6eace2c0dddc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
>> @@ -0,0 +1,110 @@
>> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/misc/mikrobus-connector.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: mikroBUS add-on board socket
>> +
>> +maintainers:
>> +  - Ayush Singh <ayushdevel1325@gmail.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: mikrobus-connector
>> +
>> +  pinctrl-0: true
>> +  pinctrl-1: true
>> +  pinctrl-2: true
>> +  pinctrl-3: true
>> +  pinctrl-4: true
>> +  pinctrl-5: true
>> +  pinctrl-6: true
>> +  pinctrl-7: true
>> +  pinctrl-8: true
>> +
>> +  pinctrl-names:
>> +    items:
>> +      - const: default
>> +      - const: pwm_default
>> +      - const: pwm_gpio
>> +      - const: uart_default
>> +      - const: uart_gpio
>> +      - const: i2c_default
>> +      - const: i2c_gpio
>> +      - const: spi_default
>> +      - const: spi_gpio
>> +
>> +  mikrobus-gpios:
>> +    minItems: 11
>> +    maxItems: 12
> What is each GPIO entry?




>
>> +
>> +  i2c-adapter:
> We already have i2c-bus and i2c-parent properties. Neither of those work
> for you?

I think i2c-bus should work. Although I could only find information 
about what it is supposed to be in some old kernel i2c.txt so is there a 
general place for such properties to be discovered?

>> +    description: i2c adapter attached to the mikrobus socket.
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +  spi-controller:
>> +    description: spi bus number of the spi-master attached to the mikrobus socket.
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +  uart:
> Nice and consistent. In 3 properties, we have 'adapter', 'controller'
> and <null>...

Right. So the names I am currently using are from v2 of the patch and 
are based on Linux kernel names for this. But yes, they probably need to 
be changed since dt-bindings are not supposed to be tied to Linux. Not 
sure if `spi-bus` and `serial-bus` are appropriate though, so maybe 
`{spi, serial}-controller` is fine?

To explain why these are here in the first place, mikroBUS addon boards 
are free to only use a few of these buses or multiple of these 
simultaneously. Also, some of the properties of spi, i2c etc device 
needs to be changed depending on the mikroBUS board (mostly described by 
mikroBUS manifest). This means, the driver needs access to i2c adapter, 
spi controller, serdev-controller, pwm associated with the mikroBUS 
connector to configure them (or not use them in case of Not Connected) 
and register the board.

> Also, DT generally uses 'serial' rather than 'uart'.
Noted
>> +    description: uart port attached to the mikrobus socket
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +  pwms:
>> +    description: the pwm-controller corresponding to the mikroBUS PWM pin.
>> +    maxItems: 1
>> +
>> +  spi-cs:
>> +    description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket.
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    items:
>> +      - description: chip select corresponding to CS pin
>> +      - description: chip select corresponding to RST pin
> How would someone handle any of the properties defined in
> spi-peripheral-props.yaml?
>
>
> Rob

After taking a look at `spi-peripheral-props.yaml`, the properties 
described here will actually be specified by mikroBUS manifest and thus 
will be set by the driver after parsing the manifest.

If you are referring to keeping `spi-cs` in sync with `reg`, well I'm 
not quite sure how to do it better than the current implementation.

Ayush Singh
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
new file mode 100644
index 000000000000..6eace2c0dddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
@@ -0,0 +1,110 @@ 
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/mikrobus-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: mikroBUS add-on board socket
+
+maintainers:
+  - Ayush Singh <ayushdevel1325@gmail.com>
+
+properties:
+  compatible:
+    const: mikrobus-connector
+
+  pinctrl-0: true
+  pinctrl-1: true
+  pinctrl-2: true
+  pinctrl-3: true
+  pinctrl-4: true
+  pinctrl-5: true
+  pinctrl-6: true
+  pinctrl-7: true
+  pinctrl-8: true
+
+  pinctrl-names:
+    items:
+      - const: default
+      - const: pwm_default
+      - const: pwm_gpio
+      - const: uart_default
+      - const: uart_gpio
+      - const: i2c_default
+      - const: i2c_gpio
+      - const: spi_default
+      - const: spi_gpio
+
+  mikrobus-gpios:
+    minItems: 11
+    maxItems: 12
+
+  i2c-adapter:
+    description: i2c adapter attached to the mikrobus socket.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  spi-controller:
+    description: spi bus number of the spi-master attached to the mikrobus socket.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  uart:
+    description: uart port attached to the mikrobus socket
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  pwms:
+    description: the pwm-controller corresponding to the mikroBUS PWM pin.
+    maxItems: 1
+
+  spi-cs:
+    description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    items:
+      - description: chip select corresponding to CS pin
+      - description: chip select corresponding to RST pin
+
+required:
+  - compatible
+  - pinctrl-0
+  - pinctrl-1
+  - pinctrl-2
+  - pinctrl-3
+  - pinctrl-4
+  - pinctrl-5
+  - pinctrl-6
+  - pinctrl-7
+  - pinctrl-8
+  - i2c-adapter
+  - spi-controller
+  - spi-cs
+  - uart
+  - pwms
+  - mikrobus-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+      mikrobus-0 {
+        compatible = "mikrobus-connector";
+        status = "okay";
+        pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default",
+                        "i2c_gpio", "spi_default", "spi_gpio";
+        pinctrl-0 = <&P2_03_gpio_input_pin &P1_04_gpio_pin &P1_02_gpio_pin>;
+        pinctrl-1 = <&P2_01_pwm_pin>;
+        pinctrl-2 = <&P2_01_gpio_pin>;
+        pinctrl-3 = <&P2_05_uart_pin &P2_07_uart_pin>;
+        pinctrl-4 = <&P2_05_gpio_pin &P2_07_gpio_pin>;
+        pinctrl-5 = <&P2_09_i2c_pin &P2_11_i2c_pin>;
+        pinctrl-6 = <&P2_09_gpio_pin &P2_11_gpio_pin>;
+        pinctrl-7 = <&P1_12_spi_pin &P1_10_spi_pin &P1_08_spi_sclk_pin &P1_06_spi_cs_pin>;
+        pinctrl-8 = <&P1_12_gpio_pin &P1_10_gpio_pin &P1_08_gpio_pin &P1_06_gpio_pin>;
+        i2c-adapter = <&i2c1>;
+        spi-controller = <&spi1>;
+        spi-cs = <0 1>;
+        uart = <&uart1>;
+        pwms = <&ehrpwm1 0 500000 0>;
+        mikrobus-gpios = <&gpio1 18 0> , <&gpio0 23 0>, <&gpio0 30 0> , <&gpio0 31 0>, <&gpio0 15 0>,
+                         <&gpio0 14 0>, <&gpio0 4 0> , <&gpio0 3 0>, <&gpio0 2 0>, <&gpio0 5 0>,
+                         <&gpio2 25 0>, <&gpio2 3 0>;
+      };
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 375d34363777..69418a058c6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14767,6 +14767,12 @@  M:	Oliver Neukum <oliver@neukum.org>
 S:	Maintained
 F:	drivers/usb/image/microtek.*
 
+MIKROBUS
+M:	Ayush Singh <ayushdevel1325@gmail.com>
+M:	Vaishnav M A <vaishnav@beagleboard.org>
+S:	Maintained
+F:	Documentation/devicetree/bindings/misc/mikrobus-connector.yaml
+
 MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT
 M:	Luka Kovacic <luka.kovacic@sartura.hr>
 M:	Luka Perkov <luka.perkov@sartura.hr>