linux-kernel - Re: [PATCHv7 3/7] eeprom: at24: extend driver to plug into the NVMEM framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2016 01:03:05 +0200
From:	Vladimir Zapolskiy <vz@...ia.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	GregKH <greg@...ah.com>, srinivas.kandagatla@...aro.org,
	maxime.ripard@...e-electrons.com, wsa@...-dreams.de,
	broonie@...nel.org, linux-kernel@...r.kernel.org,
	pantelis.antoniou@...sulko.com, bgolaszewski@...libre.com
Subject: Re: [PATCHv7 3/7] eeprom: at24: extend driver to plug into the NVMEM
 framework

On 02.03.2016 23:48, Andrew Lunn wrote:
> On Wed, Mar 02, 2016 at 11:46:39PM +0200, Vladimir Zapolskiy wrote:
>> Hi Andrew,
>>
>> On 26.02.2016 21:59, Andrew Lunn wrote:
>>> Add a regmap for accessing the EEPROM, and then use that with the
>>> NVMEM framework. Set the NVMEM config structure to enable backward, so
>>> that the 'eeprom' file in sys is provided by the framework.
>>>
>>> Signed-off-by: Andrew Lunn <andrew@...n.ch>
>>> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>>> Tested-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>> ---
>>
>> [snip]
>>
>>> +static int at24_regmap_read(void *context, const void *reg, size_t reg_size,
>>> +			    void *val, size_t val_size)
>>> +{
>>> +	struct at24_data *at24 = context;
>>> +	off_t offset = *(u32 *)reg;
>>> +	int err;
>>> +
>>> +	err = at24_read(at24, val, offset, val_size);
>>> +	if (err)
>>> +		return err;
>>> +	return 0;
>>
>> return at24_read(at24, val, offset, val_size);
>>
>> Minus 5 LoC.
> 
> And everything breaks :-(
> 
> regmap expects either an error code, or 0. Return a positive value and
> it is not happy.
> 

Well, do you agree that semantically my proposed change is equal to the
original one?

Let see...

	static int at24_regmap_read() {

		int err;

		err = at24_read(at24, val, offset, val_size);
		if (err)
			return err;
		return 0;
	}

I don't see a check for (err <= 0) returned.

--
With best wishes,
Vladimir