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.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel