Message ID | 20180907100750.14564-1-brgl@bgdev.pl (mailing list archive) |
---|---|
Headers | show |
Series | nvmem: rework of the subsystem for non-DT users | expand |
On 07/09/18 11:07, Bartosz Golaszewski wrote: > Next three patches improve the framework by adding a notifier chain > for future use and fixing the issue with nvmem device names. > > Finally we add support for cell definitions, cell lookups and make > DT systems resolve the nvmem cells during provider's registration. > > Last patches just use the SPDX license identifiers and make the > naming convention for some arguments more consistent. Please send separate series for fixes and things that do not depend on this new apis or Order/place them at the end of the series. This can help reviewer when there is large number of patches in series with unrelated subject. -s-rini
2018-09-10 9:54 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>: > > > On 07/09/18 11:07, Bartosz Golaszewski wrote: >> >> Next three patches improve the framework by adding a notifier chain >> for future use and fixing the issue with nvmem device names. >> >> Finally we add support for cell definitions, cell lookups and make >> DT systems resolve the nvmem cells during provider's registration. >> >> Last patches just use the SPDX license identifiers and make the >> naming convention for some arguments more consistent. > > Please send separate series for fixes and things that do not depend on this > new apis or Order/place them at the end of the series. > The API changes change so many things, that these series would be incompatible. I can send the series separately but they would be co-dependent anyway. Does it sound good? Bart > This can help reviewer when there is large number of patches in series with > unrelated subject. > > -s-rini > >
On 10/09/18 09:24, Bartosz Golaszewski wrote: > The API changes change so many things, that these series would be > incompatible. I can send the series separately but they would be > co-dependent anyway. Does it sound good? What am asking is to reorder the patches in a such a way that its easy to review. ex: Order can be : 1> kref and update nvmem_unregister followed by the provider changes. 2> Add support to cell tables, cell lookup, notifier 3> general cleanup patches followed by fixes Current set seems to jump from one thing to other which makes it hard to follow and time consuming while review! --srini > > Bart
2018-09-10 12:02 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>: > > > On 10/09/18 09:24, Bartosz Golaszewski wrote: >> >> The API changes change so many things, that these series would be >> incompatible. I can send the series separately but they would be >> co-dependent anyway. Does it sound good? > > > What am asking is to reorder the patches in a such a way that its easy to > review. > ex: Order can be : > 1> kref and update nvmem_unregister followed by the provider changes. > 2> Add support to cell tables, cell lookup, notifier > 3> general cleanup patches followed by fixes > > Current set seems to jump from one thing to other which makes it hard to > follow and time consuming while review! > I would just change that ordering a bit: I think we should fix stuff that's broken first, so fix the name field of struct nvmem_device, then the rest as you listed it. Bart
From: Bartosz Golaszewski <bgolaszewski@baylibre.com> This series contains nvmem framework changes prerequisite for further development of my previous series[1] that aims at removal of the platform data struct from at24 EEPROM driver. First we remove unused APIs and the global cell list. We then switch to using kref instead of manual user counting. Next we simplify the provider unregistration by removing the return value from nvmem_unregister(). Next three patches improve the framework by adding a notifier chain for future use and fixing the issue with nvmem device names. Finally we add support for cell definitions, cell lookups and make DT systems resolve the nvmem cells during provider's registration. Last patches just use the SPDX license identifiers and make the naming convention for some arguments more consistent. Tested both DT and non-DT use cases. [1] https://lkml.org/lkml/2018/8/10/149 v1 -> v2: - extended the lookup structure with a proper con_id independent from the cell name defined in the cell definition table - added a patch that makes the naming convention for the cell name argument in the nvmem_cell_get() family of functions consistent - there were two users of nvmem_unregister() that still checked the return value, now switched to devm_nvmem_register() - fixed build failures reported by kbuild test robot Bartosz Golaszewski (16): nvmem: remove unused APIs nvmem: remove the global cell list nvmem: use kref nvmem: lpc18xx_eeprom: use devm_nvmem_register() nvmem: sunxi_sid: use devm_nvmem_register() nvmem: mxs-ocotp: use devm_nvmem_register() nvmem: change the signature of nvmem_unregister() nvmem: provide nvmem_dev_name() nvmem: remove the name field from struct nvmem_device nvmem: add a notifier chain nvmem: add support for cell info nvmem: resolve cells from DT at registration time nvmem: add support for cell lookups from machine code Documentation: nvmem: document cell tables and lookup entries nvmem: use SPDX license identifiers nvmem: make the naming of arguments in nvmem_cell_get() consistent Documentation/nvmem/nvmem.txt | 31 ++ MAINTAINERS | 1 + drivers/nvmem/core.c | 676 ++++++++++++++++++--------------- drivers/nvmem/lpc18xx_eeprom.c | 6 +- drivers/nvmem/mxs-ocotp.c | 4 +- drivers/nvmem/sunxi_sid.c | 20 +- include/linux/nvmem-consumer.h | 62 ++- include/linux/nvmem-machine.h | 57 +++ include/linux/nvmem-provider.h | 27 +- 9 files changed, 493 insertions(+), 391 deletions(-) create mode 100644 include/linux/nvmem-machine.h