public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ayush Singh <ayushdevel1325@gmail.com>
To: 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>
Subject: Re: [PATCH V3] greybus: gb-beagleplay: Ensure le for values in transport
Date: Wed, 6 Dec 2023 02:02:57 +0530	[thread overview]
Message-ID: <3cd7fc7d-075f-4945-b84d-7326e3c99553@gmail.com> (raw)
In-Reply-To: <2023120616-rely-naturist-01db@gregkh>

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 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.

Simply put, if the kernel driver cannot directly connect to the node, 
the processor / network entity handling APBridge tasks will need to 
cport information. And it probably is good to make it possible to 
separate APBridge from AP in complex networks.

Feel free to ask questions if I was unclear regarding something. Also 
feel free to correct me if I got something wrong since I only started 
working on greybus this summer.

Ayush Singh


  reply	other threads:[~2023-12-05 20:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 13:10 [PATCH V3] greybus: gb-beagleplay: Ensure le for values in transport Ayush Singh
2023-12-04 14:12 ` Johan Hovold
2023-12-04 16:28   ` Ayush Singh
2023-12-05  0:14     ` Greg KH
2023-12-05 11:45       ` Ayush Singh
2023-12-05 19:45         ` Greg KH
2023-12-05 20:32           ` Ayush Singh [this message]
2023-12-06 14:52             ` Alex Elder
2023-12-06 15:43               ` Ayush Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3cd7fc7d-075f-4945-b84d-7326e3c99553@gmail.com \
    --to=ayushdevel1325@gmail.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=jkridner@beagleboard.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yujie.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox