From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C842320CDE for ; Thu, 11 Sep 2025 12:15:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757592926; cv=none; b=uMNG1taRlCFFj3Pjk9v++ja+4q3n52vLMqVS6SqOR35p8d17tgWJ2AWdA2j070KKpACgwLz7kF1q850eSqHpeXUwMuPCz2uHDgUHuwA+QJ+GqHijOc03xg7Pk2KGcIb3nvcWx2/voqdVT0ocCD2LNC+umnnr0iXhpXARZm7PBVM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757592926; c=relaxed/simple; bh=/DNmTsKU2YQxjE0a0HP3UiiRHt/9KrkhYaTXKbwcjD0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UIwIprfBmnKMhz0Wv+BWkpT5GcZCAQD+M+aFFrF9aWBqhFIsEjn9iDIs49ZFOShwkrcKT94YqjCr5ukNFRZyeMPyaEDCfHi7yFRHSvTXgDDEn1HseX3owF4dYEX6TXr/iV9KZiZslMj3l2c9zrByLpAG7+Kp/j/xUxNn6XMcur0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=beagleboard.org; spf=fail smtp.mailfrom=beagleboard.org; dkim=pass (2048-bit key) header.d=beagleboard-org.20230601.gappssmtp.com header.i=@beagleboard-org.20230601.gappssmtp.com header.b=nwW6MrjD; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=beagleboard.org Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=beagleboard.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=beagleboard-org.20230601.gappssmtp.com header.i=@beagleboard-org.20230601.gappssmtp.com header.b="nwW6MrjD" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-77459bc5d18so484782b3a.2 for ; Thu, 11 Sep 2025 05:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beagleboard-org.20230601.gappssmtp.com; s=20230601; t=1757592924; x=1758197724; darn=vger.kernel.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=edkglS5aPIxkVAhweNonmsQnCtG5vsLjFWEbqDByJiU=; b=nwW6MrjD+OZJX6mH/V9OEhjahwKuEBid/hhioKIBczUzXovjuotueUhM9+UqOmHxI/ +dV+octOWCOYH7Y7X1/NnFN/pkV4NpDuQlwajP8Rd9ytbtR+XNkjWf1HKeQoTppEvLE0 8vnjfq9I8MlwDpw6C09neZZMEt7jXe6azbvPeqbiSDusdkHUcpGXSLd2Dp/f1l5kTCRT aPOUMXQx1vVmS6uxG4Qic7HQt1Fm5kDtM5rGmJF6ovRYjmm/o+Xi9eNlWaHajKKWrtSw yH5ic5BQDLb3LgRIFSnoS1uZ7uqa6LxMiSD66PHM1CjTmbbsfFzk67Wb5/cOOu5BxRWH +iyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757592924; x=1758197724; 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=edkglS5aPIxkVAhweNonmsQnCtG5vsLjFWEbqDByJiU=; b=oX6vdUeG0uiaQuiuFWH8ob0jy9yTJKK1gY7IY9/qjUV8j/CNGV9pRGrNXWQQaNUSOx 4UyFvYzi1GVKvcmA86+11FHUAr8/qPQ+o9t3W5dCKIVuK7pYFPERVIh8g5WZxZofuNNi cuq+d4oukLPKltETBGRYADZbrQJ0y/XaHz0hr9KMQyLdEt8xuhiFSoJBJpOLX1p+Sa7K 9qF01Qhdg/nuSY/JgSIrO5d6jrw3hEn7EokvWj75cB4mVBzMIHtnnKv0dAPA6wDVwQky ipgHPqHxNwlCa4SAsL3vfQGZ7cq1PsPZ9iQ4/Av3PXYLnayDjVpxOMtkdSEBm6fr5xfv ZD6w== X-Forwarded-Encrypted: i=1; AJvYcCWQubz4nK69d01tLEL3ieYPfLsYDj/lfYDgs4un+RrfHTiD2qdYIYEfRiueiHTpEm1FizuwoOio2OhO@vger.kernel.org X-Gm-Message-State: AOJu0Ywe61wmsGaxlAMq1LEBHkdv/Su8ctTH+Bbx5goSB+MuDGjwDq6S FRuK5HfxpKZ1cGTMWS0Nq9YwqMsNv374JOCdHkbSLowR3x920OFqJ0pk+1sqdr9LmNlSUCGv0S1 eWz4= X-Gm-Gg: ASbGncvvEny09TwsEzGK/dInj3c2ShX+WISUeo9HhY9D3bGFUAp+ti0Mwa8ZIHZPjw6 OeK7pAP2CvWpx8SNay331MaoSxLoJzlnXjchcIIlRDUieO5dPWcMsY0yihgTxIp+N9g+DrIU0tX LJSFvMCKGm1Gn7DX+Q/qNSa284hkGGL+mrs0QnBTQqsL1v/6nw78EsMQqgkhK7YzhnAC88IMuJ8 huhWWqXUudMX8AJqu9tvhCeszwXTDZisVcy9RDSSkGcJFyqyIcS1SFx9wfbIxohP7tH9kBy6B0V 2SFvXg0wg/PniP9c8R1K9/5FZ/9HMS4AFB/bav2QwX9y4eVVfDGvlkbCPk9LzCu7PIZXZ5YSSkw 5bD0JL7fa5Qmf3265r2y6irMTqMi0PPfbWD9ha254Ztc+qxKAhEKt/D+X5HDa7+eqXaG8go8= X-Google-Smtp-Source: AGHT+IFgOkdGq5x9NJ+zU1c1dBgNDsfTwSsAjnSI6VcIJfup8RDIJaGYOd3IR4zKYJVMBvEDdL+5xA== X-Received: by 2002:a05:6a00:1acb:b0:772:43a9:d587 with SMTP id d2e1a72fcca58-7742ddf13cfmr19926689b3a.20.1757592924243; Thu, 11 Sep 2025 05:15:24 -0700 (PDT) Received: from ?IPV6:2401:4900:8898:6c44:fc6:e0b:3bf0:1af0? ([2401:4900:8898:6c44:fc6:e0b:3bf0:1af0]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-77607b17acasm1957738b3a.58.2025.09.11.05.15.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Sep 2025 05:15:23 -0700 (PDT) Message-ID: <36a85af7-75b1-46db-8df8-e83372d33b93@beagleboard.org> Date: Thu, 11 Sep 2025 17:45:17 +0530 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Device tree representation of (hotplug) connectors: discussion at ELCE To: Herve Codina , Geert Uytterhoeven Cc: David Gibson , Luca Ceresoli , Krzysztof Kozlowski , devicetree@vger.kernel.org, Rob Herring , Jason Kridner , Krzysztof Kozlowski , Conor Dooley , devicetree-compiler@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Petazzoni , Andrew Davis References: <20250902105710.00512c6d@booty> <337281a8-77f9-4158-beef-ae0eda5000e4@beagleboard.org> <20250908145155.4f130aec@bootlin.com> <20250909114126.219c57b8@bootlin.com> <20250911104828.48ef2c0e@bootlin.com> <20250911122333.2e25e208@bootlin.com> Content-Language: en-US From: Ayush Singh In-Reply-To: <20250911122333.2e25e208@bootlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/11/25 15:53, Herve Codina wrote: > Hi Geert, > > On Thu, 11 Sep 2025 10:54:02 +0200 > Geert Uytterhoeven wrote: > >> Hi Hervé, >> >> On Thu, 11 Sept 2025 at 10:48, Herve Codina wrote: >>> On Wed, 10 Sep 2025 14:33:45 +1000 >>> David Gibson wrote: >>>> On Tue, Sep 09, 2025 at 11:41:26AM +0200, Herve Codina wrote: >>>>> Suppose a base board with 2 connectors: >>>>> - connA >>>>> - connB >>>>> >>>>> Case 1: Addons are independant >>>>> +--------+ >>>>> connA <----> | AddonA | >>>>> +--------+ >>>>> +--------+ >>>>> connB <---------------->| AddonB | >>>>> +--------+ >>>>> >>>>> With addonA and B two addon board each connected at one connector without any >>>>> relationship between addon A and B >>>>> >>>>> Case 2: Only one Addons using ressources from both connector >>>>> >>>>> +------+ >>>>> connA <-----> |Addon | >>>>> | | >>>>> connB <-----> | | >>>>> +------+ >>>> Case 2 is what I'm talking about. Case 1 is the easy one. >>>> >>>>> The addon is connected to both connector and uses ressources from connA and >>>>> connB in a dependent manner. >>>>> >>>>> >>>>> The Case 2 can be solved using a connector that described both connA and connB. >>>>> Having the split connA and connB is a mechanical point of view. >>>> I don't think that's a good solution, because it means you have to >>>> make that decision at the board layer. If I understand his case >>>> correctly, you have a board where you could do either case 1 or case 2 >>>> at runtime. We'd want the differences between these cases to only be >>>> reflected on the addon device tree, not the base board device tree. >>> Based on my understanding of Geer's use-case, I think decision at base >>> board level will be needed. >>> >>> base board addon board >>> connA +--------+conn1 >>> connB +--------+conn2 >>> connC + >>> >>> Or >>> >>> base board addon board >>> connA +--------+conn1 >>> connB + ,---+conn2 >>> connC +---' >>> >>> Or any other combination that would match. >>> >>> From the addon board point of view, the only think we can >>> say is "me, as an addon board, I need a connector of type 'foo' and a >>> connector of type 'bar'". >>> >>> Also, at base board level, statically defined in the DT >>> connA is described (type 'foo'), connB and connC are >>> described (type 'bar'). >> Correct. >> >>> The choice to map connA to the type 'foo' connector expected by the addon >>> and the choice to map connB or connC to the type 'bar' connector expected by >>> the addon can only be done at runtime and probably with the help of a driver >>> that have the knowledge of the 3 connectors. >>> >>> I have the feeling that the choice of physical connectors to which the addon >>> board is connected to is a human choice when the board is connected. >> All these choices and decisions apply to single-connector add-on boards, too. >> > Yes, in our use case (me and Luca), each addon has an eeprom, wired exactly the > same on all supported addon, which allows to known the exact addon. Also addon > insertions and removals are detected using some gpios wired to the connector. > > Based on that our specific driver handling our specific connector perform the > following operations on addon insertion detection: > - load a first addon DT to have access to the eeprom > - Read the eeprom to determine the addon type > - load the DT matching with the addon type > > This part is of course connector type specific. I mean having an eeprom with > some encoded addon type values and hotplug detection with gpio is a part of > the contract between the board and the addon (part of connector specification). > > Best regards, > Hervé > My usecase is a bit more complicated, since I am trying to model all the available headers on BeagleBoard.org sbcs (particularly PocketBeagle 2 initially) as connectors. However, that still ends up being a single connector which can have multiple addon-boards simultaneously instead of the other way around. Best Regards, Ayush Singh