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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170629133029.fq6jjivu5cx22j6q@rfolt0960.corp.atmel.com>
Date:   Thu, 29 Jun 2017 15:30:29 +0200
From:   Ludovic Desroches <ludovic.desroches@...rochip.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Claudiu Beznea <claudiu.beznea@...rochip.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 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.
> 
> 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.

I agree, it sounds better to me too.

Regards

Ludovic