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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 C2591CE7A88 for ; Sat, 23 Sep 2023 16:10:19 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1qk5BJ-0007vC-1y; Sat, 23 Sep 2023 12:08:33 -0400 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1qk5BD-0007v5-06 for kernelnewbies@kernelnewbies.org; Sat, 23 Sep 2023 12:08:32 -0400 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1c5bbb205e3so36150795ad.0 for ; Sat, 23 Sep 2023 09:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695485297; x=1696090097; darn=kernelnewbies.org; h=content-transfer-encoding:subject:from:cc:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=yhETjAN6xvTReHaikteN+zQl14Ngc/lm9zyyXs36d6E=; b=kTVuAPNbs3Hb8ZmfUzO9ycoH0SKvb3bhdmub3ftx3aP5LOfw809s9/y/5/lM5XM4MG dTIMq8Od2EBwFJ8YlKS/FHVPxwpsv4jASqYZJUWWzuXbOYjFevqhwLCQPbR2dQbzy8iq IBup3Xu8ol2Y3kf6PAYQ/xiSiHeB0sK66BBxxEBjrJgtUF/NxSk6hOA6mltp2RjsSOEJ aq8o9jyJsvEw0mix9K3vlD6cVzrcug46NFb2sAQA1p0r0pcMCYDRlR/2hPzjT9LlKs27 t6sK5DWXTqaMojysUu2gL3AO/i1RmTIG6JSom7WSrc/jEpXs2GvK0X0lulkWB38pHb7a y/4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695485297; x=1696090097; h=content-transfer-encoding:subject:from:cc:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=yhETjAN6xvTReHaikteN+zQl14Ngc/lm9zyyXs36d6E=; b=IO2YI1l6vEN7blGKjUZWDYt39+sdiozJ1YMtDc+eRckeZjw/9nt3mA+Uyx4wE8CEjw R8ZkfD4Sfkme4WGVD0Pi0x797VdEzDej/+pq+lfDcKGgYbr4KTIzVp27WRkA62IBY22W k7RWPCM7BjxIYKmOap8YpnToUDEZcg2Du2D8so1mV6ifr+tHs7dD9bTNtc0VpIAoRbFk 2xtHyBUtvazsYNcO85itsdmTg2sSY5AVgEdXqH5+lM2RA3z98ZwFCG3RWz4Vt1kUo5A7 ETsKyqQwShkJB6aZEtm9TDOlOGRaW2Cd/tlGRuoE/OecQlmB3MNYXkUWQgzrg1jX+4hp TPiA== X-Gm-Message-State: AOJu0Yw8zaqFVyogXOqnN9Q3G64JB+pDWOP7k3gdPz/d1X4cNljFLfDD b/+liGwO0udc+l9hZbyFB5M= X-Google-Smtp-Source: AGHT+IFzUjRlS5gb3bUczacToCgHjdqCSQqjwnw0PGlrl3rIbq9BK0q3npcElcTyYsfnxI4RJfGXUw== X-Received: by 2002:a17:902:e74c:b0:1c5:a7b7:291c with SMTP id p12-20020a170902e74c00b001c5a7b7291cmr3267831plf.12.1695485297396; Sat, 23 Sep 2023 09:08:17 -0700 (PDT) Received: from [172.16.116.58] ([103.15.228.93]) by smtp.gmail.com with ESMTPSA id c13-20020a170902d48d00b001c5fa48b9a0sm1675818plg.33.2023.09.23.09.08.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Sep 2023 09:08:16 -0700 (PDT) Message-ID: Date: Sat, 23 Sep 2023 21:38:10 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: en-US To: devicetree@vger.kernel.org From: Ayush Singh Subject: [Question] dt bindings for BeagleConnect Cc: conor+dt@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kernelnewbies-bounces@kernelnewbies.org Hello everyone, I am working on writing a BeagleConnect driver for Beagleplay board. Let me first go over some terminology: BeagleConnect is both a technology concept and a line of board designs that implement the technology. Born from Greybus, a mechanism for dynamically extending a Linux system with embedded peripherals, BeagleConnect adds two key elements: a 6LoWPAN transport and mikroBUS manifests. The 6LoWPAN transport provides for arbitrary connections, including the IEEE802.15.4g long-range wireless transport supported between BeaglePlay and BeagleConnect Freedom (the first BeagleConnect board design). The mikroBUS manifests provide for rapid prototyping and low-node-count production with sensor boards following the mikroBUS freely-licensable embedded bus standard, such that existing Linux drivers can be loaded upon Greybus discovery of the nodes. BeaglePlay consists of a main AM62 processor and a CC1352 co-processor which is responsible for providing 6LoWPAN support along with Greybus node discovery. The AM62 processor and CC1352 are internally connected over UART. The CC1352 coprocessor is supposed to run a specific firmware as a part BeagleConnect setup. It looks as follows: AM62 (Linux Driver) <--UART--> CC1352 (Zephyr Firmware) <--6LoWPAN--> BeagleConnect Freedom I need a way to access this bridge UART. The most straightforward method is adding a `compatible` property to the device tree of this UART. But I am not sure how to go about adding a DT binding for it that can be merged upstream. Here are a few comments I have encountered: 1. DT bindings need to be hardware I am not sure which hardware the bindings need to target in my case. Should the bindings be serial in nature, since I need to use the UART device? Or they should be about SoC since CC1352 is the device I am actually communicating with? Or maybe there is a 3rd category for an SoC running a specialized firmware for a technology/protocol? 2. DON'T create nodes just for the sake of instantiating drivers. I guess this means that adding a child node just to add a `compatible` property is not allowed? For some reason, the driver probe is not called if I simply try to override the top level `compatible` property of the serial device. But maybe that is just an issue with my approach? 3. DO attempt to make bindings complete even if a driver doesn't support some features. This is only relevant if the answer to 1) is the SoC. Since the CC1352 device cannot be directly controlled by, the capability of this device is defined by the firmware running on top of it rather than the hardware. So I am not quite sure what a complete binding for such a device even mean. The only property I can make required would be the `compatible` property and everything else will be optional I guess? I understand that strict guidelines are required since once a property is added to the Kernel device tree, it will almost be impossible to remove without breaking compatibility. So I would like some guidance or maybe some similar devices that are already a part of the kernel which I can look to for guidance. Ayush Singh [BeagleConnect]: https://docs.beagleboard.org/latest/boards/beagleconnect/index.html [BeaglePlay]: https://docs.beagleboard.org/latest/boards/beagleplay/index.html [My Last Patch]: https://lists.linaro.org/archives/list/greybus-dev@lists.linaro.org/thread/GKOFWZ5IJMNXIWVDOM3WRNU2B2S4244G/ [My Patch Github]: https://github.com/Ayush1325/linux/tree/gb-beagleplay _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies