Messages in this thread | | | Date | Mon, 17 Aug 2015 15:59:23 +0100 | From | Srinivas Kandagatla <> | Subject | Re: [PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework |
| |
On 17/08/15 14:09, Andrew Lunn wrote: > On Mon, Aug 17, 2015 at 02:01:24PM +0100, Srinivas Kandagatla wrote: >> >> +Adding Maxime in the loop >> >> On 16/08/15 16:37, Stefan Wahren wrote: >>>>> Another question which spring to mind is, do we want the eeprom to be >>>>> in /sys twice, the old and the new way? Backwards compatibility says >>>>> the old must stay. Do we want a way to suppress the new? Or should we >>>>> be going as far as refractoring the code into a core library, and two >>>>> wrapper drivers, old and new? >>> I think these are questions for the framework maintainers. >>> >> One of the reasons for the NVMEM framework is to remove that >> duplicate code in the every driver. There was no framework/ABI >> which was guiding such old eeprom sysfs entry in first place, so I >> dont see an issue in removing it for good. Correct me if am wrong. > > The reason for keeping it is backwards compatibility. Having the > contents of the EEPROM as a file in /sys via this driver is now a part > of the Linux ABI. You cannot argue it is not an ABI, just because > there is no framework. Userspace will be assuming it exists at the > specified location. So we cannot remove it, for existing uses of the > driver. Am Ok as long as someone is happy to maintain it.
--srini > > However, for new uses of this driver, it is O.K. to only have the > NVMEM file. > > Andrew >
| |