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