Well, to contradict myself, there is a driver that works in the way you
were thinking: nuttx/drivers/wireless/bluetooth/bt_uart.c This is a
bluetooth driver built on an RS-232 bluetooth module and uses the lower
half UART interface directly.
But this driver was much despised because of this (my) design and
someone replaced it with nuttx/drivers/wireless/bluetooth/bt_uart_shim.c
which uses file_open() as I recommended. So I suppose that bt_uart.c is
a precedent, but bt_uart_shim.c is proof that that approach is disliked
and a bad idea.
I think all usage of bt_uart.c has been removed from the boards.
bt_uart.c should probably be removed.
Ya win some and ya lose some.
On 10/1/2024 7:47 AM, Gregory Nutt wrote:
The driver structure is contained in the struct file (filep->struct
file->inode->u.file_operations. The operation of many file systems,
drivers, etc. depend on the additional in these other structures.
The driver interface is given by file_operations. Notice that each
method requires an instance of struct file as the "this" pointer to
allow driver access to the whole operating context.
Please don't do anything differently. Consistency is a virtue;
creative inconsistency is destructive to the integrity of the OS.
Please do not go the naive way that you are considering. That kind of
change would certainly be rejected (I hope).
On 10/1/2024 7:33 AM, Matteo Golin wrote:
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
