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 1165AC54E5D for ; Tue, 19 Mar 2024 13:04:20 +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=KOplvYM1p6lxT9yfisiEyrclS9R9Z1A+9gUlqJxplPU=; b=hgW/7hMplMi834 8A53hPjB1KIDNstB0RENUFk2m4ky5qufN64uiwaej9xlUfVjTyUXq8+p4YxGTjkL4qWLvqQsDbbMR c042YwSOFHCQmfuB8TykMzZtetG4cL9aT8WubstVUbz5XANTtAASzU0ZMftbbye0CwHhEFIS8xijx vZ+QOttVD3PBHwiXlPYn3fJVFCBxBSLxaghhSYqwai/GWhcMOmrtwj/cVJEShE8p3soSHJyqPS1aQ ulJg6lzUX4pi4vg7axlKt7p8R37LZHZUsLQ0XWjFHQsI8URwmHKMYng6LhXn4DD0b2YPpHpNmGToe oHGXz9qeUCDnosw8Ew/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmZ8P-0000000Ci4y-2SjX; Tue, 19 Mar 2024 13:04:05 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmZ8L-0000000Ci3y-0oef for linux-arm-kernel@lists.infradead.org; Tue, 19 Mar 2024 13:04:03 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1e04ac200a6so3716105ad.1 for ; Tue, 19 Mar 2024 06:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710853440; x=1711458240; 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=TB3+Jx7RLucIKEs6eH+0Nj3AnIcH8F/JCvJNLp7YE6g=; b=RvtLDjcoFAdpRoIEDCkIYQcL8mhtjvmJIpL2rGCxBTyCQDx/jdVeM2zDrxx6n2Afir VJpsh2/bHP7sxj4vOi6rO/pJ87zNYh1m/QtZIcZo91it0b3zIAXbAr0zVyvuYwYaQ+Xh rylyYCeWVs62aVpsm6+kLBIRMVmR1ym4cN9bKWG+DhMjkP67fOv/3/2xjwUcoL85LZrz +koFRyOT9aNMdj3SiBkzTePls9iQj2EseJlxPvDTavG/ieh0ch584lByQAOMCn5zoK8q nBI+xNtMx3OazTCuCOde5OdBd5pnkL4PFgUf1TWVxA33j+DYJEUR1WQLO39MrV3tx4QR wWrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710853440; x=1711458240; 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=TB3+Jx7RLucIKEs6eH+0Nj3AnIcH8F/JCvJNLp7YE6g=; b=Ws0cF5lskckjngD8VynPPV/s2JEWwHP/xvsTZEtOgzGUhT8+/LR1DlT4BHabErKx/I ZvEfw2TZkGCob2EByaUA9BUVUJrqSJy5HBcQd1RCwmrrDjq6RZ4i09uSWrXgMTPxb0PG 2o9m4srdWHPYQdmmmphurtOqt3qydVlg2SUVUtp+DYA2l0IAEGU/cu0P8yWzfpvGoz7D BXpt+BPBHI0PXqRvrpYzmgBSdarN2aHor8KiNnztf/roS23NNOXRovhYAeAm6svXvqVZ 2/GuSTBXT5nNYdv/aITzXDZMEOHS4c9kV8oCVSm76CU63MC3W5p2VRONNKSY9NwmhD8G XNhw== X-Forwarded-Encrypted: i=1; AJvYcCUMD4zGokUkHXVqZ6mfC6Hqnfku0UMLDzXSFoXcsrYJs6ntfhXUZZ/Qfj7aipHnRp97JBGaw2VMM+x3BjxVg0A8FxVpumLBg37lpDF4r1lMtqmXCZU= X-Gm-Message-State: AOJu0YwNdu7Nkakp6WTphI+5HFrFWlCCB+6jC6P05nQYVKhHXCF/sUGd 3lfCkJG0lLhshPCvk9nHhkRedbp54X5k4ipQCuP2cqPt+bhScVwt X-Google-Smtp-Source: AGHT+IHp9n/ieIqxsK6SNAifPecss5n/WcUXZF+7gmtGuEG/9nF1SdfwSwoEsfEnrazkiPBdUXRu0g== X-Received: by 2002:a17:903:2308:b0:1e0:119e:f925 with SMTP id d8-20020a170903230800b001e0119ef925mr3803743plh.26.1710853439734; Tue, 19 Mar 2024 06:03:59 -0700 (PDT) Received: from [172.16.116.58] ([103.15.228.94]) by smtp.gmail.com with ESMTPSA id x8-20020aa79a48000000b006e685994cdesm9676540pfj.63.2024.03.19.06.03.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Mar 2024 06:03:59 -0700 (PDT) Message-ID: <81ec4156-8758-406e-876b-5acf13951d09@gmail.com> Date: Tue, 19 Mar 2024 18:33:39 +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 , Krzysztof Kozlowski , 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 References: <20240317193714.403132-1-ayushdevel1325@gmail.com> <20240317193714.403132-2-ayushdevel1325@gmail.com> <0f3f56d4-3381-44f1-91bc-c126f3ced085@linaro.org> <5a9b1cd9-05ec-4606-92b6-eadbc7af6202@gmail.com> From: Ayush Singh In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240319_060401_279700_D4B11536 X-CRM114-Status: GOOD ( 39.46 ) 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/19/24 17:38, Michael Walle wrote: > On Tue Mar 19, 2024 at 12:36 PM CET, Ayush Singh wrote: >>>> Regardless, this patch actually does not contain any code for EEPROM >>>> support I have just mentioned it to give more context on why mikroBUS >>>> manifest is the focus of this patch instead of DT overlay or something >>>> else. >>> Right, and I think this is the crux here. Why can't you use DT >>> overlays? The manifest files, seem to be yet another hardware >>> description (method) and we already have DT. Can't we have some kind >>> of userspace helper that could translate them to DT overlays? That >>> way, you could also handle the EEPROM vs non-EEPROM case, or have >>> some other kind of method to load a DT overlay. >>> >>> Admittedly, I've never worked with in-kernel overlays, but AFAIK >>> they work with some subsystems. >>> >>> -michael >> >> So let me 1st go over 3 cases that the driver needs to support: >> >> 1. Non EEPROM boards: >> >> Using overlays should be pretty similar to current solution. If the >> manifest is converted to overlay in userspace, then we do not even need >> to do manifest parsing, setting up spi, i2c etc in the kernel driver. >> >> >> 2. EEPROM boards >> >> How do you propose handling these. If you are proposing storing dt >> overlay in EEPROM, then this raises some questions regarding support >> outside of Linux. >> >> The other option would be generating overlay from manifest in the kernel >> driver, which I'm not sure is significantly better than registering the >> i2c, spi, etc. interfaces separately using standard kernel APIs. > You did answer that yourself in (1): you could use a user space > helper to translate it to a DT overlay, I don't think this has to be > done in the kernel. I do not understand what you mean. For EEPROM supported boards, user space is not involved. The driver can directly read the manifest from add-on board and setup everything, so it is plug and play. The manual involvement of user space is only for non EEPROM boards since we do not have a way to identify the board without the user needing to provide the manifest. > Also how do you know whether there is an EEPROM > or not? Set RST GPIO to low. clickID supported board will enter ID MODE, Then check if CS line has a w1 gpio bus. >> 3. Over Greybus >> >> It is quite important to have mikroBUS over greybus for BeagleConnect. >> This is one of the major reasons why greybus manifest was chosen for the >> manifest format. >> >> Also, it is important to note that mikroBUS manifest is being used since >> 2020 now and thus manifests for a lot of boards (both supporting clickID >> and not supporting it exist). So I would prefer using it, unless of >> course there are strong reasons not to. > And also here, I'm not really familiar with greybus. Could you give > a more complex example? My concern is that some driver might need > additional properties from DT (or software nodes) to function > properly. It might not only be a node with a compatible string but > also more advanced bindings. How would that play together with this? > My gut feeling is that you can handle any missing properties > easier/better (eg. for existing modules) in user space. But maybe > that is already solved in/with greybus? Greybus is a communication protocol designed for modular electronic devices. It allows different parts of a device to be hot plugged (added or removed) while the device is still running. Greybus manifest is used to describe the capabilities of a module in the greybus network. The host then creates appropriate bidirectional unipro connections with the module based on the cports described in the manifest. I have added a link to lwn article that goes into more detail. BeagleConnect simply allows using greybus over any bidirectional transport, instead of just Unipro. I cannot comment much about how greybus handles missing properties. While greybus also works just in kernel space, greybus protocols are inherently higher level than kernel driver, so it might have an easier time with this. I have also added a link to eLInux page which provides rational for the mikroBUS manifest. But the crux seems to be that dynamic overlays were not well-supported back then. Also, the use of mikroBUS using greybus subsystem was already used. Hence the mikroBUS driver. Greybus is not a big blocker from my perspective, since it is always possible to introduce a new protocol for mikroBUS in Greybus spec. I think as long as both EEPROM and non EEPROM boards can be supported by mikroBUS driver and dt-bindings, are can be used outside of Linux (eg: ZephyrRTOS, nuttx, etc), it is fine. > Here's a random one: the manifest [1] just lists the compatible > string apparently, but the actual DT binding has also reset-gpios, > some -supply and interrupt properties. > > -michael > > [1] https://github.com/MikroElektronika/click_id/blob/main/manifests/WEATHER-CLICK.mnfs Yes, the concern is valid. Support for validating the manifest is nowhere near as good as devicetree overlays. But I think that would be a problem with the device rather than the responsibility of the kernel. It is up to the manufacturer to have valid manifests. Link: https://lwn.net/Articles/715955/ Greybus Link https://elinux.org/Mikrobus eLinux article Ayush Singh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel