Perfect, thank you so much for the pointers! When there is a draft ready
hopefully we'll be able to get more valuable feedback on the
implementation! Our goal is to implement things the NuttX way and be
consistent, so we appreciate all the information so we can get it as close
to right the first time as possible!

Matteo

On Tue, Oct 1, 2024, 9:47 AM Gregory Nutt <spudan...@gmail.com> 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
>
>
>

Reply via email to