Re: [PATCH 2/2] staging/greybus: Add BeaglePlay Linux Driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 8/30/23 18:18, Greg KH wrote:

On Wed, Aug 30, 2023 at 06:06:54PM +0530, Ayush Singh wrote:
On 8/30/23 17:58, Greg KH wrote:

On Wed, Aug 30, 2023 at 05:54:27PM +0530, Ayush Singh wrote:
This is Serdev driver that communicates with Greybus SVC connected over
UART. This driver has only been tested on BeaglePlay (with CC1352 in
BeaglePlay serving as SVC).

This driver is responsible for the following:
- Start SVC (CC1352) on driver load.
- Send/Receive Greybus messages to/from CC1352 using HDLC over UART.
- Print Logs from CC1352.
- Stop SVC (CC1352) on driver load.

This patch does the following:
- Add Driver
- Add Kconfig option to enable the driver
- Update Makefile to build the driver

Signed-off-by: Ayush Singh <ayushdevel1325@xxxxxxxxx>
   MAINTAINERS                             |   5 +
   drivers/staging/greybus/Kconfig         |   9 +
   drivers/staging/greybus/Makefile        |   3 +
   drivers/staging/greybus/gb-beagleplay.c | 493 ++++++++++++++++++++++++
Why is this in drivers/staging/ and not in drivers/greybus/ ?
Well, there are a few reasons I can give:

1. It has not been thoroughly tested. I have only tested it in my personal

2. Since mikrobus code has not been merged, running a normal beagleconnect
freedom as the greybus node is not possible.
What is "mikrobus"?

mikroBUS is a standard specification by MikroElektronika that can be freely used by anyone following the guidelines. It includes SPI, I2C, UART, PWM, ADC, reset, interrupt, and power (3.3V and 5V) connections to common embedded peripherals.

Currently, an extension to the normal greybus manifest is used for mikrobus which needs additional parsing logic. It was submitted to the mailing list at one point but never merged:

I might take it up after I am finished with this driver.

3. I thought new and experimental drivers should go into staging?
staging is only for code that is not ready to be in the real portion of
the kernel and it comes with a list of what needs to be done to get it
out of staging.

For this, new driver, it should just go into the real portion of the
kernel as obviously you've tested it and it works :)

I see. I will submit it as a real driver in the next patch then.

However, I still have questions regarding the dts changes. I am not trying to introduce a new type of device in the device tree. I just need a way to identify that specific UART device in that particular board.  For all intents and purposes, it is a normal UART.  So I am not sure if a new DT schema should be written for it.

Ayush Singh

greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx
To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx

[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux