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
- Update MAINTAINERS
Signed-off-by: Ayush Singh ayushdevel1325@gmail.com
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:
- It has not been thoroughly tested. I have only tested it in my personal
setup.
- 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: https://lore.kernel.org/lkml/20200818124815.11029-3-vaishnav@beagleboard.org...
I might take it up after I am finished with this driver.
- 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