linux-kernel - Re: [RFC PATCH 2/3] drivers: misc: eeprom: at24: support reading mac eeprom from different addresses

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:   Wed, 5 Jul 2017 12:31:37 +0300
From:   m18063 <Claudiu.Beznea@...rochip.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Sekhar Nori <nsekhar@...com>,
        David Lechner <david@...hnology.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        devicetree <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>
Subject: Re: [RFC PATCH 2/3] drivers: misc: eeprom: at24: support reading mac
 eeprom from different addresses



On 29.06.2017 16:30, Ludovic Desroches wrote:
> On Thu, Jun 29, 2017 at 02:56:03PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 29, 2017 at 2:39 PM, Claudiu Beznea
>> <claudiu.beznea@...rochip.com> wrote:
>>> Add support for reading from different offsets of EEPROM.
>>> The offset is initialized via device tree. If nothing is
>>> given as input the old value, 0x90, is used. In this way
>>> the driver could be used as generic driver for different
>>> vendor memories by only changing the reading offset via
>>> device tree.
>>
>>> +       err = device_property_read_u8(dev, "start-offset", &chip->offset);
>>
>> This property has to be documented.
Sure! In this patch series it was documented in patch 2 from series.
Are you talking about documenting it in another place?

>>
>> Moreover, the name looks too broad (I checked current use of
>> "*-offset" type of properties and they either vendor specific, or data
>> type specific.
>>
>> Taking above into consideration mac-offset sounds better to me.
Ok, I will use that name.
> 
> I agree, it sounds better to me too.
Ok, I will use that name.
Thanks,
Claudiu
> 
> Regards
> 
> Ludovic
>