Flash Device API

[Gedare Bloom]

Thank you Aaron for contributing this. I have a few comments below,
and I'll also give some comments on your code shortly.

On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
>
>
> On 16.03.23 23:07, Chris Johns wrote:
> > On 16/3/2023 6:13 pm, Sebastian Huber wrote:
> >> Hello Aaron,
> >>
> >> this API seems to be RTEMS-specific. Maybe we should simply pick up an existing
> >> solution which is in more wide spread use, for example:
> >>
> >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html
> >
> > That interface seems Zepher specific and looks to me like a series of calls that
> > appear reasonable as a list to cover.
>
> The Zephyr API has drivers for a couple of chips:
>
> https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash
>
That code looks very zephyr-oriented. I think it would be a challenge
to go first toward porting this API, if it requires substantial
modifications of the upstream drivers to also use them, then it is
more of a maintenance burden than the probable benefits of the code
reuse. As a starting point, I do see a bespoke RTEMS implementation as
a suitable place to begin. But, it would be good to understand the
alternative flash driver frameworks that are out there, and what may
be pros/cons of adopting them.

> > The patch Aaron has posted is a driver. I
> > prefer a driver like we have for I2C, SPI etc because the of support it brings.
>
> The I2C and SPI APIs are ported from Linux, so not RTEMS-specific.
>
> >
> > The initial set of ioctl commands is small to start with. If you feel we should
> > offer more I suggest they get added once this is merged.
> >
> > Is the change OK?
>
> I am not opposed to commit this API, however, I don't think it is a step
> forward. It is yet another RTEMS-specific API. It has no related
> documentation patches. The API has no high level user (for example
> JAFFS2). The API has no implementation. It has no tests. It has no
> driver framework (ONFI, JEDEC). It has no example driver. It has no
> Doxygen documentation. The coding style of the new file has nothing to
> do with the RTEMS coding style.
>

I think the provided code appears to be a good starting point.  I
would request that you might add Doxygen something aligned with what
we have for the i2c or spi would be good.
https://docs.rtems.org/doxygen/branches/master/group__I2C.html

In addition to the shell command addition, can you create/extend a
testsuite for exercising the API?

I will address the code directly also, but these high-level additions
will greatly improve the submission of a new API. Unfortunately, my
work on code formatting is not quite complete enough to rely on it for
fixing any style issues. I'll do what I can to guide you through that.

Gedare