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 21788C54E68 for ; Thu, 21 Mar 2024 12:44:51 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:To:From:Cc: Subject:Message-Id:Date:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YaJSw+khZbq1uJjWz+9Tl5cDYtEvSTT8TFv0x4D3+P8=; b=MDKBBpCW6z2APq RXoosHZZu1/tdBQVPm0eYWrSqiusnXu5KC8HLGa/4wZQvAm2GZKGMiNKu/1mP24q8sY8LOMKDOWix pE5IjIeley6m51mulXzQgrcWlAlAtQwnUQhgSV27WIdaE5iXhquBd/cBwF3jNGaCVb78Rr7WAyNIN t40MshzzvMihLS3oNg3nHaB8k/w9K7SKxmlr8lqcP3h2jN561oJ4q58AZKOmvCTvVzpHUGtOxBw/q DMcQRzOv4r35BxEqcY8ytlsUOPOllyz1l7hzlzEuPD9YcW5Sc0S5RAf4R0A3x5A/3geveGI64PYb4 iEqyQh46lXyTCUsEvV4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnHmg-000000030UG-3Ayx; Thu, 21 Mar 2024 12:44:38 +0000 Received: from 0001.3ffe.de ([159.69.201.130] helo=mail.3ffe.de) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnHmd-000000030TR-2J6i for linux-arm-kernel@lists.infradead.org; Thu, 21 Mar 2024 12:44:37 +0000 Received: from localhost (unknown [IPv6:2a02:810b:4340:6430:4685:ff:fe12:5967]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 1D1C9AA; Thu, 21 Mar 2024 13:44:30 +0100 (CET) Mime-Version: 1.0 Date: Thu, 21 Mar 2024 13:44:29 +0100 Message-Id: Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector 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" From: "Michael Walle" To: "Vaishnav Achath" , "Andrew Lunn" X-Mailer: aerc 0.16.0 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> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240321_054435_903738_C76B942D X-CRM114-Status: GOOD ( 36.92 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. And I don't think this is a good idea given that the alternative is just working. > > 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. Thinking about this again. I'm not sure this additional compatible really helps the discovery. It's a chicken egg problem. Only the modules knows if it has an EEPROM, but then, we already have to know it's in the socket. So while it might help for a static configuration, it does not for the discovery. -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