Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbdLEOBs (ORCPT ); Tue, 5 Dec 2017 09:01:48 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:46680 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753141AbdLEOBm (ORCPT ); Tue, 5 Dec 2017 09:01:42 -0500 X-Google-Smtp-Source: AGs4zMY/kiSC7qOtCD/fa0dUbgfhZtsbqOpcm7+oRviy/Qgvayj125bC5oc26Ez2B2IR4apc4kp63UvdmYqw+Zu2NII= MIME-Version: 1.0 In-Reply-To: References: <1512048586-17534-1-git-send-email-geert+renesas@glider.be> <1512048586-17534-2-git-send-email-geert+renesas@glider.be> <20171204211705.543xjzvttbrt65pm@rob-hp-laptop> From: Geert Uytterhoeven Date: Tue, 5 Dec 2017 15:01:39 +0100 X-Google-Sender-Auth: UiOh5WyUcSvYOcNLJi6eTxSwsVI Message-ID: Subject: Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits To: Rob Herring Cc: Ivo Sieben , Arnd Bergmann , Greg Kroah-Hartman , Mark Rutland , Chris Wright , Wolfram Sang , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2979 Lines: 70 Hi Rob, On Tue, Dec 5, 2017 at 2:56 PM, Rob Herring wrote: > On Tue, Dec 5, 2017 at 3:09 AM, Geert Uytterhoeven wrote: >> On Tue, Dec 5, 2017 at 9:57 AM, Geert Uytterhoeven wrote: >>> On Mon, Dec 4, 2017 at 10:17 PM, Rob Herring wrote: >>>> On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote: >>>>> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven >>>>> wrote: >>>>> > Certain EEPROMS have a size that is larger than the number of address >>>>> > bytes would allow, and store the MSB of the address in bit 3 of the >>>>> > instruction byte. >>>>> > >>>>> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or >>>>> > in DT using the obsolete legacy "at25,addr-mode" property. >>>>> > But currently there exists no non-deprecated way to describe this in DT. >>>>> > >>>>> > Hence extend the existing "address-width" DT property to allow >>>>> > specifying 9, 17, or 25 address bits, and enable support for that in the >>>>> > driver. >>>>> > >>>>> > Signed-off-by: Geert Uytterhoeven >>>>> > --- >>>>> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040). >>>>> > Do EEPROMs using 17 or 25 address bits, as mentioned in >>>>> > include/linux/spi/eeprom.h, really exist? >>>>> > Or should we just limit it to a single odd value (9 bits)? >>>>> >>>>> At least for the real Atmel parts, only the AT25040 part uses odd (8 + >>>>> 1 bit) addressing. >>>> >>>> Seems like we should have a specific compatible for it. >>> >>> Possibly. But currently all configuration is done through DT properties, not >>> through matching on compatible values. >> >> Adding compatible values for all known/used parts could quickly become a >> large table. >> E.g. Atmel/Microchip has 3 variants of 512-byte EEPROMs: AT25040B, >> 25LC040A, and 25AA040A. The former uses an 8-byte pagesize, while the >> latter parts use 16-byte pagesizes. >> Not to mention "compatible" parts from other manufacturers, and all other >> supported size. >> >> Currently all of this is configured through the "pagesize", "size", and >> "address-width" DT properties, with matching on generic "atmel,at25". > > I wasn't suggesting throwing out all these. Just add a compatible for > the one oddball 9-bit part. > > But I'm fine adding address-width=9 too. OK. Then I'll go for the least intrusive solution (address-width=9). These EEPROMs are fairly small and simple, and I can imagine them being used on small systems too, so driver code/data size matters. Stay tuned for v2. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds