Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <7e244edd-0dfc-4363-b41d-579f1685f33e@gmail.com>
Date:   Wed, 6 Dec 2023 21:13:29 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH V3] greybus: gb-beagleplay: Ensure le for values in
 transport
Content-Language: en-US
To:     Alex Elder <elder@ieee.org>, Greg KH <gregkh@linuxfoundation.org>
Cc:     Johan Hovold <johan@kernel.org>, greybus-dev@lists.linaro.org,
        elder@kernel.org, linux-kernel@vger.kernel.org,
        jkridner@beagleboard.org, kernel test robot <yujie.liu@intel.com>
References: <20231204131008.384583-1-ayushdevel1325@gmail.com>
 <ZW3ePt-c4Mu43DOV@hovoldconsulting.com>
 <7ead544b-9234-483f-aacb-55ed05b01fa3@gmail.com>
 <2023120515-mongrel-undertook-6e5a@gregkh>
 <4cafbb5a-8ecd-407e-81a0-76d6505d013b@gmail.com>
 <2023120616-rely-naturist-01db@gregkh>
 <3cd7fc7d-075f-4945-b84d-7326e3c99553@gmail.com>
 <98911f33-6932-46e1-9846-ae3f558b2409@ieee.org>
From:   Ayush Singh <ayushdevel1325@gmail.com>
In-Reply-To: <98911f33-6932-46e1-9846-ae3f558b2409@ieee.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 12/6/23 20:22, Alex Elder wrote:
> On 12/5/23 2:32 PM, Ayush Singh wrote:
>> On 12/6/23 01:15, Greg KH wrote:
>>
>>> I'm confused, what exactly is needed here to be sent that isn't in the
>>> existing message definition.
>>>
>>> And as to your original statement, the protocol definition was not
>>> designed for any specific use case that would make IoT "special" here
>>> that I can see.  It was designed to provide a discoverable way to
>>> describe and control hardware on an unknown transport layer for devices
>>> that are not discoverable by definition (serial, i2c, etc.)
>>>
>>> The fact that we implemented this on both USB and unipro successfully
>>> provided that the transport layer for the data should be working and
>>> agnositic.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> So, the missing information is the AP cport which is sending the 
>> message/for which the message is intended. Each AP cport will be 
>> connected to a cport in some greybus node. For a simple case like 
>> USB, where AP can directly talk to the node, and we do not really 
>> need the cport information outside of kernel driver.
>
> I think I lack some context here, but as Greg said Greybus
> is intended to be a pure transport, and anything using it
> should be able to get all information it needs as a layered
> protocol on top of it.
>
> If the BeaglePlay stuff requires CPort information, it sounds
> like it's not managing the layering of abstractions properly.
Well, I used gbridge as a reference during my GSoC work. So I just 
followed it's lead of using pad bytes for cport information.
>
>> I think under normal circumstances, the kernel driver is supposed to 
>> directly communicate with the node. However, in beagle play, the 
>> subghz transport is only present in CC1352 coprocessor. This means 
>> CC1352 needs to act as the middle man between AP and node (aka 
>> perform the APBridge tasks). So it needs to maintain a way to keep 
>> track of all active greybus connections, and route the messages 
>> between AP and Node cports.
>>
>> I am not quite sure where SVC is supposed to be in Linux kernel 
>> greybus setup. Since SVC needs to be able to detect module 
>> insertion/removal, it needs to be able to access the same transport 
>> as APBridge. Thus, CC1352 (and gbridge in old setup) are responsible 
>> for both SVC and APBridge roles.
>
> It sounds like CC1352 is serving in an SVC role... sort of? Again, I 
> don't have enough context right now to understand.
>
> Greybus was developed for a particular hardware platform, and it
> included an SVC.  The SVC was an independent processor that managed
> the "endo", or the basic hardware "backplane" that held modules).
> The AP bridge was how the AP connected to that, and the GP bridge
> was how a given module interface connected to that.
>
> It seems to me (this is partly from an impression I had a few years
> ago) that the BeaglePlay model doesn't align perfectly with that.
> And if that's the case, we need to figure out how to resolve any
> mismatches.
>
> (I'm not sure this is very helpful, but it's a little background.)
>
>                     -Alex

Yes, the BeaglePlay (and older gbridge) model does deviate from that. 
You can read more about beagle connect technology here [1] and the 
initial presentation [2].

However, to put it simply, it is trying to use greybus over transports 
other than Unipro. This means we do not have a Unipro switch. Instead, 
we use a coprocessor (CC1352) running specialized firmware to handle all 
the things Unipro switch would.

The current focus is 6lowpan (due to it's range). However, CC1352 also 
has a 2.4 and 5 ghz antenna, so in the future, that might also be used 
for transportation.

Since I am not much aware of greybus use outside of beagle connect, I do 
not have much knowledge of how it is supposed to be used in a 
traditional setting.

I have submitted new patches that remove the need for using pad bytes.


Ayush Singh


[1]: https://docs.beagleboard.org/latest/projects/beagleconnect/index.html

[2]: https://www.youtube.com/watch?v=7H50pv-4YXw