Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753844AbdLDJRy (ORCPT ); Mon, 4 Dec 2017 04:17:54 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:41846 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753745AbdLDJRt (ORCPT ); Mon, 4 Dec 2017 04:17:49 -0500 X-Google-Smtp-Source: AGs4zMZnDV5jZ0kZzWUAPMWvbPIXFIWIfSxk1L1kNRCrkZI2KVut8m5qovTxetrXtkTkCPrAFl/+7wiuw7l9SALJRtY= MIME-Version: 1.0 In-Reply-To: <1512048586-17534-2-git-send-email-geert+renesas@glider.be> References: <1512048586-17534-1-git-send-email-geert+renesas@glider.be> <1512048586-17534-2-git-send-email-geert+renesas@glider.be> From: Geert Uytterhoeven Date: Mon, 4 Dec 2017 10:17:47 +0100 X-Google-Sender-Auth: oLG-eOiCA0-S9JGJ3um3BIM3BkM Message-ID: Subject: Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits To: Ivo Sieben Cc: Arnd Bergmann , Greg Kroah-Hartman , Rob Herring , 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: 3824 Lines: 92 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. AT25M01 uses 3-byte addressing (it needs 17 bits). So I tend to believe EEPROMs using 16 + 1 or 24 + 1 address bits (with the extra bit in the instruction byte) do not exist? > --- > Documentation/devicetree/bindings/eeprom/at25.txt | 4 +++- > drivers/misc/eeprom/at25.c | 4 ++++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt > index 1d3447165c374f67..d00779e4ab4377b9 100644 > --- a/Documentation/devicetree/bindings/eeprom/at25.txt > +++ b/Documentation/devicetree/bindings/eeprom/at25.txt > @@ -6,7 +6,9 @@ Required properties: > - spi-max-frequency : max spi frequency to use > - pagesize : size of the eeprom page > - size : total eeprom size in bytes > -- address-width : number of address bits (one of 8, 16, or 24) > +- address-width : number of address bits (one of 8, 9, 16, 17, 24, or 25). > + For odd values, the MSB of the address is sent as bit 3 of the instruction > + byte, before the address byte(s). Alternatively, we can drop the binding change, i.e. keep on using address-width = <8> for 512-byte '040... > Optional properties: > - spi-cpha : SPI shifted clock phase, as per spi-bus bindings. > diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c > index 5afe4cd165699060..a50a0f16fa0e1d1d 100644 > --- a/drivers/misc/eeprom/at25.c > +++ b/drivers/misc/eeprom/at25.c > @@ -275,6 +275,10 @@ static int at25_fw_to_chip(struct device *dev, struct spi_eeprom *chip) > "Error: missing \"address-width\" property\n"); > return -ENODEV; > } > + if (val & 1) { > + chip->flags |= EE_INSTR_BIT3_IS_ADDR; > + val -= 1; > + } ... and handle it here like: if (chip->byte_len == 2U << val) chip->flags |= EE_INSTR_BIT3_IS_ADDR; However, that would IMHO be a bit confusing, as the "address-width" property is no longer the real address width, but indicates how many bits are specified in address bytes sent after the read/write command. So "address-bytes" = 1, 2, or 3 would be more correct ;-) Or deprecate this whole "specify parameters using DT properties" business, and derive them from the compatible value. But that would mean adding a large and ever growing table to an old driver... Thoughts? Thanks again! 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