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 B2843C54E58 for ; Thu, 21 Mar 2024 11:56:12 +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=koXJ78Wdjnm+UdPmK97aleYhGtwfGwNTBcXIzcBxFzc=; b=CvSlBdIOzFJcLg gq1bcmujrzOzR2CoaDR++MYQ+KX6LYexPmcclMPTbUAolWUl6+mgkYoAKrF1fF+80bMDiSWvgbAyO eMffi2kF7G3JPUohY2n5cmmQwmlU0eyJF91r2/HSlnDTejRoOVLdTH3H6WcVLHZTMnJiThUpO54b6 lvz2yvE9m3eH40GyA/3Tzgo3Rghj2OvoSYKzQSc32vWKk/8gpmXH8G2kP4Q6/LiRWLaRWBRTnastI KHGLGYbazJMp5e3/N9d5/vC5l92bT9qOeQwp+aac5WN30yS7HB9sahGIvpNsxzs75bNKK0nRpgu/4 PueE2l9UfC6gvyRD48BQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnH1X-00000002saJ-0dhO; Thu, 21 Mar 2024 11:55:55 +0000 Received: from fllv0016.ext.ti.com ([198.47.19.142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnH1T-00000002sZe-0MMD for linux-arm-kernel@lists.infradead.org; Thu, 21 Mar 2024 11:55:52 +0000 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 42LBtIum009191; Thu, 21 Mar 2024 06:55:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1711022118; bh=bfXSNgzfF39TmycWQT9ljrIkLfLOmINJWk7nXQyV6gU=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=wLyXcSx94ZSt8JqZDiY6Ry8Ubk8G1CwXaejforsyVW7LKcjbYEi9+6tIwpVDAS/yo agpOJCZdtJ8VLLYAnPSZSyK1kQ2nQYVxTjllp40J54ikcgBili0q9Zx4GdZsiei8kV Zkx9l6Yg/JahLyS2WsZYKN19Bc61AsbWYZEvknPY= Received: from DLEE110.ent.ti.com (dlee110.ent.ti.com [157.170.170.21]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 42LBtIV2032767 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Mar 2024 06:55:18 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE110.ent.ti.com (157.170.170.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Thu, 21 Mar 2024 06:55:18 -0500 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Thu, 21 Mar 2024 06:55:18 -0500 Received: from [10.24.69.142] ([10.24.69.142]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 42LBtAWR111394; Thu, 21 Mar 2024 06:55:10 -0500 Message-ID: Date: Thu, 21 Mar 2024 17:25:09 +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: Michael Walle , Andrew Lunn CC: "Russell King (Oracle)" , Ayush Singh , open list , , , , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Greg Kroah-Hartman , 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 References: <20240317193714.403132-1-ayushdevel1325@gmail.com> <20240317193714.403132-2-ayushdevel1325@gmail.com> <4b319264-bff7-48e5-85e8-201ca0bafec6@ti.com> <4c299d42-84c7-46fc-952f-292cef1bb4b4@lunn.ch> From: Vaishnav Achath In-Reply-To: X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240321_045551_317322_E32AD312 X-CRM114-Status: GOOD ( 30.45 ) 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 21/03/24 15:08, Michael Walle wrote: > Hi, > >>> Is that because the current software support is too limited? Are there >>> manufactures who want to create more complex designed, but are limited >>> by what can be described in the manifest? >>> >> >> most mikroBUS add-on boards in production lies in the category of >> sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you >> look at the existing bindings under bindings/iio/ , most devices need >> only simple descriptions and the properties are mainly standard bus >> properties (SPI/I2C properties), IRQ, named-gpios, named properties, >> regulators, clocks the extension to manifest was made taking this into >> account and the named property description interface just maps the >> manifest entries to the unified device property interface under >> include/linux/property.h > > How will the ethernet boards ([1], [2]) work? Where do they get > their MAC address from, for example. The DT has some nice properties > for that, but I doubt that will be possible with the manifest files. > I've looked at the manifest file for the w5500 board [3] and to me > it looks like that board will come up with a random MAC address on > each start. Thus, even today, you have some boards which require > a more complex description. > Agreed, this is a limitation, unless the corresponding drivers/subsystems use device_property_read_* helper to fetch properties, it will not work and net/core/of_net.c only implements of_get_* helpers even though the underlying functions can be implemented with equivalent device_property_read_* equivalent as well. > Apart from the discussion whether the manifest is a suitable or > sufficient mechanism to describe the hardware, I think the main > problem with the proposed binding, is that it doesn't follow the > binding Rob was proposing for a socket. If I want to use DT > overlays, how would you describe an add-on board? > > The proposal was that the base board has something like > > mikrobus: socket { > compatible = "mikrobus-socket"; > i2c-parent = <&i2c0>; > spi-parent = <&spi0>; > > i2c {}; > spi {}; > }; > > an add-on board can then have a DT snippet/overlay like the > following: > > &mikrobus { > i2c { > eeprom@52: { > reg = <52>; > compatible = ; > } > }; > > spi { > sensor@0: { > reg = <0>; > compatible = ; > }; > }; > }; > > That should be possible with a binding for the mikrobus, which > in fact it is just a pin header with a standard pinout. Also as > Russell pointed out in v3, the EEPROM/manifest is not part of the > mikrobus standard. So maybe that deserves an own compatible, like > > compatible = "mikroe,click", "mikrobus-socket"; > > Or maybe click-eeprom? Although click seems to be the brand name of > MikroElektronika. Agreed, there is nothing preventing us to convert the binding and update the driver to follow the above proposed format and will be done in next revision. Click is brand name of MikroElektronika and they don't allow custom boards to use that branding, however clickid can be used in the case where EEPROM is present/enable the socket to be probeable. Thanks and Regards, Vaishnav > > -michael > > [1] https://www.mikroe.com/eth-3-click > [2] https://www.mikroe.com/eth-wiz-click > [3] https://github.com/MikroElektronika/click_id/blob/main/manifests/ETH-WIZ-CLICK.mnfs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel