From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8D92CC47DD9 for ; Fri, 22 Mar 2024 18:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u0MykLzvj5+IsrsgEhrZO++gba+M1iYgAinHMWqeI8g=; b=GeSU5COal6jSZ2 1tEWEojQAJ0x0dIEzDNCgJT0NcUjiDUx+CunwKgHSIek43iAFFiilnV420oUlMxqyYLqpVLwxAdfG 9GLFoo4rbNnxqpfVOuaTmCmkrWciQFIVjdczf9CargMEdmaaEZSMns9sWtBhN//Cq6gEp1qOhGH2q F/gpD/vdWecauCRKqHPoaJ1C9o22kDGA+GEMINAJGene84bAnazCxePt83IjRwmtOVCGysVFqTHiI kP7EAzySfwmeKa1uad4IMe7LwUH7ysM+mENYvmERW5oNZiOtc+NDYqzEPzy/V3pyFpytxYHHFwqBe +jwHl7jvvi/5Mzkzxx6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnjVk-00000008Kwz-34An; Fri, 22 Mar 2024 18:21:00 +0000 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnjVh-00000008Kvp-1YRD for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 18:20:58 +0000 Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dcc84ae94c1so2395019276.1 for ; Fri, 22 Mar 2024 11:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711131655; x=1711736455; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=cVym+5J84D0U9MB20cuLgiHbdn7KsrTiTTYLm5nU3Ns=; b=KdXEK2k4bxdi7Oifjq8ErV0cQODcKe6eXxZqXL74xAtQmRblQ8l72F+OIaOlgag9Un uzuYsAdDxTqCN+GoOfkEAA4wKv8TlefNZ+adzbe5wtgkw7ZdplIcuXrYy9/+hjZ8x7gG KOY9BmRmuOkSEmwtRg1jnsvrobQlJU1Ehv47OmQQgpiG3QBYSr9gbgHRrgjZedbMoIoE bj1KHHl7u8IO5yDGZyzG1cseiZnUqyvfVRInq1uvi9QHiAfTqqCOp9fgcp5LXKaUsi2i i8AILXBdWV3ZJk3zhjozr4HODJaa3nCK4e6rFdJyMGvRmgHu/pVwDzmzvKOcsZTxW3Dc MmPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711131655; x=1711736455; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cVym+5J84D0U9MB20cuLgiHbdn7KsrTiTTYLm5nU3Ns=; b=h7jPzFswFLt151ZqlbkR4a84agb85uThjH+3siMvE8iZyjfsQ4jc1i+bk3k/2x/ZiB tyBGpM6OIt4QkPdAjWzA4WGeQ8qnmG8dX/vFSq3c0+xYE6ZKBnR0Q51CfRcV+z3odbkK H0JRKQVhlln+a85H/x33fubPON/7IuACT/JgVb6rlZHgAH0KC+yu+b6Y8xPiKKT03Sf/ aIAstzpGb4gJJk3R6d33duaa9U+KyegG+pnpN4Ch9gZWStl1kbpRsxTYyNGSQTt1PQx3 92it2vpTgxuA3M73GPTrOU8k5Zla3w8xBThyvwvYDxYTuAacDDvZoRTLeQIrl5nDqA83 xi4A== X-Forwarded-Encrypted: i=1; AJvYcCUezkKHoHtfVVjNdG7G68qKHw69AAZbAK2nUXPGI4a+tJOdSt7YPZIib1zFRBnPZOV001cpW7wMJXTKnPjb1YNJod7f/ZcumEnb3KMOTWOr1mcdHm0= X-Gm-Message-State: AOJu0YwGh0AfdkgGXhww6xQ4w50w7ilPnN/8fMEQntiGQNv9QZGLmWFR iY4OJakqN0wJ9nuu94MU1Em9TtTpTmczFfjptI874aXsXajO85SOE4mIREVV/nE= X-Google-Smtp-Source: AGHT+IG/LMCZJH7aXi9h/am5L+n244m9THHyeSa1Xy+XIaj8rR+qWj8t1DixCN81CE+f8Df4CyPlww== X-Received: by 2002:a05:6a21:329e:b0:1a3:a89b:a70a with SMTP id yt30-20020a056a21329e00b001a3a89ba70amr394321pzb.37.1711131352895; Fri, 22 Mar 2024 11:15:52 -0700 (PDT) Received: from [172.16.116.58] ([103.15.228.94]) by smtp.gmail.com with ESMTPSA id c6-20020aa78c06000000b006e5af565b1dsm43048pfd.201.2024.03.22.11.15.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Mar 2024 11:15:52 -0700 (PDT) Message-ID: <711ff5ea-244d-4b64-a39c-3f2da63e30c0@gmail.com> Date: Fri, 22 Mar 2024 23:45:32 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Content-Language: en-US To: open list Cc: jkridner@beagleboard.org, robertcnelson@beagleboard.org, lorforlinux@beagleboard.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Greg Kroah-Hartman , Vaishnav M A , Mark Brown , Johan Hovold , Alex Elder , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE" , "open list:SPI SUBSYSTEM" , "moderated list:GREYBUS SUBSYSTEM" , Vaishnav M A , Michael Walle , Andrew Lunn References: <20240317193714.403132-1-ayushdevel1325@gmail.com> <20240317193714.403132-2-ayushdevel1325@gmail.com> From: Ayush Singh In-Reply-To: <20240317193714.403132-2-ayushdevel1325@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_112057_454264_E5C5E355 X-CRM114-Status: GOOD ( 31.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/18/24 01:07, 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. > > mikroBUS is a connector and does not have a controller. Instead the > software is responsible for identification of board and setting up / > registering uart, spi, i2c, pwm and other buses. Thus it needs a way to > get uart, spi, i2c, pwm and gpio controllers / adapters. > > A mikroBUS addon board is free to leave some of the pins unused which > are marked as NC or Not Connected. > > Some of the pins might need to be configured as GPIOs deviating from their > reserved purposes Eg: SHT15 Click where the SCL and SDA Pins need to be > configured as GPIOs for the driver (drivers/hwmon/sht15.c) to work. > > For some add-on boards the driver may not take care of some additional > signals like reset/wake-up/other. Eg: ENC28J60 click where the reset line > (RST pin on the mikrobus port) needs to be pulled high. > > Here's the list of pins in mikroBUS connector: > 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 > > Additionally, some new mikroBUS boards contain 1-wire EEPROM that contains > a manifest to describe the addon board to provide plug and play > capabilities. > > Link: https://www.mikroe.com/mikrobus > Link: > https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-specification-v200.pdf > mikroBUS specification > Link: https://www.mikroe.com/sht1x-click SHT15 Click > Link: https://www.mikroe.com/eth-click ENC28J60 Click > Link: https://www.mikroe.com/clickid ClickID > > Co-developed-by: Vaishnav M A > Signed-off-by: Vaishnav M A > Signed-off-by: Ayush Singh > --- > .../connector/mikrobus-connector.yaml | 113 ++++++++++++++++++ > MAINTAINERS | 6 + > 2 files changed, 119 insertions(+) > create mode 100644 Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > > diff --git a/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > new file mode 100644 > index 000000000000..ee3736add41c > --- /dev/null > +++ b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > @@ -0,0 +1,113 @@ > +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: mikroBUS add-on board socket > + > +maintainers: > + - Ayush Singh > + > +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: > + - | > + #include > + > + mikrobus { > + compatible = "mikrobus-connector"; > + 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>; > + pwms = <&ehrpwm1 0 500000 0>; > + i2c-adapter = <&i2c1>; > + spi-controller = <&spi1>; > + spi-cs = <0 1>; > + uart = <&uart1>; > + mikrobus-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>, <&gpio0 23 GPIO_ACTIVE_HIGH>, > + <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 31 GPIO_ACTIVE_HIGH>, > + <&gpio0 15 GPIO_ACTIVE_HIGH>, <&gpio0 14 GPIO_ACTIVE_HIGH>, > + <&gpio0 4 GPIO_ACTIVE_HIGH>, <&gpio0 3 GPIO_ACTIVE_HIGH>, > + <&gpio0 2 GPIO_ACTIVE_HIGH>, <&gpio0 5 GPIO_ACTIVE_HIGH>, > + <&gpio2 25 GPIO_ACTIVE_HIGH>, <&gpio2 3 GPIO_ACTIVE_HIGH>; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index 375d34363777..69418a058c6b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14767,6 +14767,12 @@ M: Oliver Neukum > S: Maintained > F: drivers/usb/image/microtek.* > > +MIKROBUS > +M: Ayush Singh > +M: Vaishnav M A > +S: Maintained > +F: Documentation/devicetree/bindings/misc/mikrobus-connector.yaml > + > MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT > M: Luka Kovacic > M: Luka Perkov After going through all the discussions here, I have a few questions: 1. Is the old `*_register_device(controller, board_info)` style discouraged in favor of using device tree, at least for drivers using multiple fundamental buses (i2c, spi, etc)? Or is the problem just that these bindings do not leave open the possibility of using device tree overlays? Will it be fine if the dt bindings allow for dt overlays, but the driver still uses imperative registering of board? 2. Is the preferred way to handle virtual devices (like those created by greybus subsystem) now device tree? Is that one of the blockers for greybus i2c, spi etc to still be in staging? 3. How are virtual devices created in device tree? If I register an i2c adapter using `i2c_add_adapter`, is the device tree entry is dynamically created, which can then be used by a device tree overlay? Ayush Singh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel