Re: [PATCH v2 01/16] nvmem: remove unused APIs

From: Bartosz Golaszewski
Date: Mon Sep 10 2018 - 04:44:00 EST


2018-09-10 10:09 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>:
>
>
> On 10/09/18 08:58, Bartosz Golaszewski wrote:
>>
>> 2018-09-10 9:32 GMT+02:00 Srinivas Kandagatla
>> <srinivas.kandagatla@xxxxxxxxxx>:
>>>
>>>
>>>
>>> On 07/09/18 11:07, Bartosz Golaszewski wrote:
>>>>
>>>>
>>>> From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
>>>>
>>>> Remove all APIs dealing with nvmem_cell_info. There are no users and
>>>> this part of the subsystem will be reworked.
>>>>
>>>> This patch temprarily disables support for non-DT users.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
>>>> ---
>>>> drivers/nvmem/core.c | 212
>>>> ++-------------------------------
>>>> include/linux/nvmem-consumer.h | 26 ----
>>>> include/linux/nvmem-provider.h | 13 --
>>>> 3 files changed, 12 insertions(+), 239 deletions(-)
>>>
>>>
>>>
>>> This looks totally un-necessary, Other patches in this series adds them
>>> back.. Consider updating these in those respective patches.!
>>>
>>
>> While this may not be entirely necessary, it's very useful. There's
>
> Yes, thats exactly what am saying if it not necessary please do not do it.
>
>> almost nothing common between this API and the new one added later in
>
> There is more than 60%-70% of the code reused in new patches, which is
> unnecessary churn to me!
>

Pretty much the only thing that is reused are the contents of
nvmem_cell_info_to_nvmem_cell() and even they are placed in a
different function. Also: this change allows us to add new APIs
without having to update users at each step only to change them
afterwards with one of subsequent patches. I would really prefer that
this stay this way. If there are no users, then there's no breakage
that would make your point valid.

>> this series. Later patches are MUCH cleaner thanks to this removal and
>> I believe it makes them easier for review.
>
> Am not sure about that, it definitely did not help me!
>

Why exactly? Aren't clean patches resulting from this removal easier
to read then if they'd also have to take into account the burden of
existing code that will be changes anyway later? I really don't see
why you insist on removing this.

Best regards,
Bart

> --srini
>>
>>
>> Best regards,
>> Bart
>>
>