mbox series

[v2,00/16] nvmem: rework of the subsystem for non-DT users

Message ID 20180907100750.14564-1-brgl@bgdev.pl (mailing list archive)
Headers show
Series nvmem: rework of the subsystem for non-DT users | expand

Message

Bartosz Golaszewski Sept. 7, 2018, 10:07 a.m. UTC
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

Comments

Srinivas Kandagatla Sept. 10, 2018, 7:54 a.m. UTC | #1
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
Bartosz Golaszewski Sept. 10, 2018, 8:24 a.m. UTC | #2
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
>
>
Srinivas Kandagatla Sept. 10, 2018, 10:02 a.m. UTC | #3
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
Bartosz Golaszewski Sept. 10, 2018, 2:58 p.m. UTC | #4
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