On Wed, Feb 7, 2024 at 8:33 PM Joy Chakraborty <joychakr@xxxxxxxxxx> wrote: > > On Wed, Feb 7, 2024 at 3:04 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Feb 06, 2024 at 05:22:15PM +0530, Joy Chakraborty wrote: > > > > > Userspace will see a false error with nvmem cell reads from > > > > > nvmem_cell_attr_read() in current code, which should be fixed on > > > > > returning 0 for success. > > > > > > > > So maybe fix this all up to allow the read to return the actual amount > > > > read? That feels more "correct" to me. > > > > > > > > > > If I change the behavior of the nvmem_reg_read_t callback to negative > > > for error and number of bytes actually read for success then, other > > > than the core driver I would also have to change all the > > > nvmem-provider drivers. > > > Is it okay to do so ? > > > > Sure, why not? That seems like the correct fix to me, right? > > Sure, I can do that. > > Is it okay to change the if checks on the return code to "if (rc < 0)" > instead of "if (rc)" as a fix for the immediate issue with how return > value from rmem is handled which can be applied to older kernels. > In a separate patch I can change the definition of nvmem_reg_read_t() > to return ssize_t instead of int and make corresponding changes to > nvmem-provider drivers. > > Does that sound okay ? Hi Greg, Sent a patch https://lore.kernel.org/all/20240219113149.2437990-2-joychakr@xxxxxxxxxx/ to change the return type for read/write callbacks. Do I mark that with the "Fixes:" tag as well ? It affects a lot of files so might not be able to easily pick to an older kernel when needed. Thanks Joy > > > > thanks, > > > > greg k-h > > Thanks > Joy
