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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 19 Jul 2017 12:08:39 +0300
From:   m18063 <Claudiu.Beznea@...rochip.com>
To:     Rob Herring <robh@...nel.org>
CC:     <mark.rutland@....com>, <nsekhar@...com>, <david@...hnology.com>,
        <wsa@...-dreams.de>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
        <nicolas.ferre@...rochip.com>, <ludovic.desroches@...rochip.com>
Subject: Re: [PATCH 3/3] dt-bindings: i2c: eeprom: document "mac-offset"
 binding



On 10.07.2017 06:46, Rob Herring wrote:
> On Thu, Jul 06, 2017 at 01:16:57PM +0300, Claudiu Beznea wrote:
>> Document "mac-offset" binding that will be used by at24 EEPROM driver.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
>> ---
>>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> index a50dc01..3dd267c 100644
>> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -35,10 +35,13 @@ Optional properties:
>>  
>>    - read-only: this parameterless property disables writes to the eeprom
>>  
>> +  - mac-offset: offset in EEPROM where MAC address starts
>> +
> 
> This doesn't scale if you have multiple things you need the offset to, 
> and we already have a binding for this. Use the nvmem binding.
Are you talking about nvmem-cells, nvmem-cell-names bindings? Since
at24 is i2c driver, I can only think at it as a nvmem provider. Using these
bindings it will imply, as per my understanding about nvmem subsystem, that
this should also become a nvmem consumer. It looks a little strange to
me but I don't have deep knowledge about subsystem, correct me if I'm wrong.
Please let me know if you are talking about using these bindings and reading
them (just to get the offset passed in "reg" binding) by not passing the nvmem
APIs defined in nvmem core.

Thank you,
Claudiu
> 
> Rob
> 

Powered by blists - more mailing lists