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 01404CD54B9 for ; Mon, 25 Sep 2023 18:45:33 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1qkqYZ-0004K2-0T; Mon, 25 Sep 2023 14:43:43 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1qk5BV-0007vd-0o for kernelnewbies@kernelnewbies.org; Sat, 23 Sep 2023 12:08:45 -0400 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2c124adf469so65454071fa.0 for ; Sat, 23 Sep 2023 09:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1695485313; x=1696090113; darn=kernelnewbies.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1gQp1lHFtm6dVr89Oz44O+Ki0nF77ZeDnLLnv/g+WjQ=; b=Q4scNpzgv4Kuh/QOwEADbix3cN8lBogEn4ob4A7fk9TTKq1AUxhXLSkzU0GNZAih+a B7V7rX808DJHVY6AueSlv6pbQIqe/7b375X2PXJrYLiPe09Fck0Um0Of/EdRET7+KTdg TlOzEajA+A+qLZKzzJ5DNMoY+KHfFOkxfju6E9wWE4fFeoKhwjODJ+LRLxC/w6BOhGEE NYlN/i08CH99+b23QLRlHVusxUEnUcFS3jyrygpFI6H6Ps04YWXsk4hp5Z1WoHsNOgeY YmVFdIBRz2jWe5GQvfPFd2eLnfovAzIekgHY9JpALUSqXB8SnjhqkaqRhSNe6pgGeNf8 mgcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695485313; x=1696090113; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1gQp1lHFtm6dVr89Oz44O+Ki0nF77ZeDnLLnv/g+WjQ=; b=XdpSPrKJKEYECceuXV+0kV/RTzcxJCH7idTFBWsfk/kRdpo7ghRKWUiXazSvaz2hHB 6/e8MLSCBmSEYzf4RNitW02b4B5OubxazrYphCcBcQrwhtuRZSqEB1rLjRuG2Vw7rnBk VUAmXgVagpjZusPjs+g1+Ch2NH8gBubhaSa12cdU+leDVFop/bMGaDBcN2ORzzwMoLMr jUy8ueOGuHAKlFJh6kOO2Qx3nxjB/JTwBL+eoAsLl94xYKxfT1ggDO4vpmGjq41FP32c nr7JEYlV92VyhJH0cn+U/zBWCUJTL8Qnmgz3gfSjr5pCLJVfHkxAyPkxoWsw0j8uxCRB hGgw== X-Gm-Message-State: AOJu0Yy21k+0ACgBDtVrtbBdkrRdDjckk9zrOh76nlWtLpya3VrFqiPN FZnUqTkTlLbP0XZ9izevFYNz4w== X-Google-Smtp-Source: AGHT+IFi+pCfungV/iDgNe4t69PNFQAwB/38MJZKPJ192MQa6pcc8M3u3WhB/PbaRC/MzPED4JCuVA== X-Received: by 2002:a2e:9b8b:0:b0:2bc:c38a:bd7c with SMTP id z11-20020a2e9b8b000000b002bcc38abd7cmr1865010lji.33.1695485312607; Sat, 23 Sep 2023 09:08:32 -0700 (PDT) Received: from [192.168.1.20] ([178.197.219.100]) by smtp.gmail.com with ESMTPSA id q19-20020a056402041300b005330e1e7da0sm3429882edv.92.2023.09.23.09.08.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Sep 2023 09:08:32 -0700 (PDT) Message-ID: Date: Sat, 23 Sep 2023 18:08:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [Question] dt bindings for BeagleConnect To: Ayush Singh , devicetree@vger.kernel.org References: Content-Language: en-US From: Krzysztof Kozlowski In-Reply-To: X-Mailman-Approved-At: Mon, 25 Sep 2023 14:43:36 -0400 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On 23/09/2023 18:04, Ayush Singh wrote: > 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? Referring to some comments without the context - patch and the comments given - makes any discussion difficult. We do not work like this in upstream communities. Please respond inline, not top posting, to the comments you received. > 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. There are plenty of other serial-attached MCUs. Just look for "mcu {" (for serial) or mcu@ (for other buses). Best regards, Krzysztof _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies