Flash Device API

[Will]

On Fri, Mar 17, 2023 at 4:24 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>

Aaron,
Just in case you haven't already found it, the document you should be using
for style and header documentation is here:
https://docs.rtems.org/branches/master/eng/coding-conventions.html

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230317/9a0ac794/attachment.htm>