Thank you for the help everyone! I have some follow-up questions:

>  You should use the struct file instance to access the driver, not the raw 
> driver interface.

Greg, can you clarify what you mean? My understanding is that it would be 
preferred that I use `file_open()` to get the
struct file instance to access the driver this way, instead of doing something 
like this example of an I2C device driver
startup that gets the raw driver interface: 
https://github.com/apache/nuttx/blob/master/boards/arm/rp2040/common/src/rp2040_bmp280.c#L90

To clarify, I was not suggesting that the LoRa driver contain any architecture 
specific code; I would like to be generic
over a serial interface. The pattern that I am familiar with from my knowledge 
of sensor drivers on NuttX is that the
device's `register` function takes a reference to the underlying interface 
driver (I2C, SPI, etc.). However, that
reference comes from somewhere.

For the RP2040, the reference is obtained like in link above. This method of 
obtaining a reference to the I2C driver
does not register it as part of the path name space, it returns the struct 
reference only. I was not able to find an
analogous function for UART interface drivers on any platform except the STM32 
example I gave in my previous email. The
`file_open` call works, but if I'm understanding correctly, requires first that 
the UART interface be registered in the
pathname space.

I am mainly wondering, if I implement this driver as generic over a UART 
interface (`uart_dev_s`) like how sensor
drivers are generic over an I2C/SPI interface, would it be permissible to 
implement something analogous to the
`rp2040_i2cbus_initialize()` but for UART interfaces on the platform startup 
code where I want to initialize the driver?

And if I make the driver generic over the UART interface, is it suitable to 
require the platform specific startup code
to access the underlying `uart_dev_s` struct within the file struct returned by 
`file_open()` (i.e. cast what is stored
in file->f_priv)?

Thanks,
Matteo

Attachment: signature.asc
Description: PGP signature

Reply via email to