| Message ID | 20211126102339.28908-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [v1,1/1] MIPS: TXx9: Convert SPI platform data to software nodes | expand |
On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > In order to get rid of legacy platform data in AT25 driver, > convert its users to use software nodes. > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> This looks good to me, thanks for cleaning this up! I think Geert has this hardware, adding him to Cc in case he wants to give it a spin. Arnd > arch/mips/include/asm/txx9/spi.h | 4 ++-- > arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ > arch/mips/txx9/rbtx4938/setup.c | 6 +++--- > 3 files changed, 24 insertions(+), 18 deletions(-) > > diff --git a/arch/mips/include/asm/txx9/spi.h b/arch/mips/include/asm/txx9/spi.h > index 0d727f354557..1ca87a516b81 100644 > --- a/arch/mips/include/asm/txx9/spi.h > +++ b/arch/mips/include/asm/txx9/spi.h > @@ -16,11 +16,11 @@ > #include <linux/errno.h> > > #ifdef CONFIG_SPI > -int spi_eeprom_register(int busid, int chipid, int size); > +int spi_eeprom_register(int busid, int chipid); > int spi_eeprom_read(int busid, int chipid, > int address, unsigned char *buf, int len); > #else > -static inline int spi_eeprom_register(int busid, int chipid, int size) > +static inline int spi_eeprom_register(int busid, int chipid) > { > return -ENODEV; > } > diff --git a/arch/mips/txx9/generic/spi_eeprom.c b/arch/mips/txx9/generic/spi_eeprom.c > index d833dd2c9b55..cb4b4d47437e 100644 > --- a/arch/mips/txx9/generic/spi_eeprom.c > +++ b/arch/mips/txx9/generic/spi_eeprom.c > @@ -9,18 +9,32 @@ > * > * Support for TX4938 in 2.6 - Manish Lachwani (mlachwani@mvista.com) > */ > +#include <linux/device.h> > +#include <linux/export.h> > #include <linux/init.h> > +#include <linux/property.h> > #include <linux/slab.h> > -#include <linux/export.h> > -#include <linux/device.h> > + > #include <linux/spi/spi.h> > -#include <linux/spi/eeprom.h> > + > #include <asm/txx9/spi.h> > > +#define AT250X0_SIZE 128 > #define AT250X0_PAGE_SIZE 8 > > +static const struct property_entry spi_eeprom_properties[] = { > + PROPERTY_ENTRY_U32("size", AT250X0_SIZE), > + PROPERTY_ENTRY_U32("pagesize", AT250X0_PAGE_SIZE), > + PROPERTY_ENTRY_U32("address-width", 8), > + { } > +}; > + > +static const struct software_node spi_eeprom_node = { > + .properties = spi_eeprom_properties, > +}; > + > /* register board information for at25 driver */ > -int __init spi_eeprom_register(int busid, int chipid, int size) > +int __init spi_eeprom_register(int busid, int chipid) > { > struct spi_board_info info = { > .modalias = "at25", > @@ -28,16 +42,8 @@ int __init spi_eeprom_register(int busid, int chipid, int size) > .bus_num = busid, > .chip_select = chipid, > /* Mode 0: High-Active, Sample-Then-Shift */ > + .swnode = &spi_eeprom_node, > }; > - struct spi_eeprom *eeprom; > - eeprom = kzalloc(sizeof(*eeprom), GFP_KERNEL); > - if (!eeprom) > - return -ENOMEM; > - strcpy(eeprom->name, "at250x0"); > - eeprom->byte_len = size; > - eeprom->page_size = AT250X0_PAGE_SIZE; > - eeprom->flags = EE_ADDR1; > - info.platform_data = eeprom; > return spi_register_board_info(&info, 1); > } > > diff --git a/arch/mips/txx9/rbtx4938/setup.c b/arch/mips/txx9/rbtx4938/setup.c > index e68eb2e7ce0c..136af1cace75 100644 > --- a/arch/mips/txx9/rbtx4938/setup.c > +++ b/arch/mips/txx9/rbtx4938/setup.c > @@ -283,9 +283,9 @@ static int __init rbtx4938_spi_init(void) > .mode = SPI_MODE_1 | SPI_CS_HIGH, > }; > spi_register_board_info(&srtc_info, 1); > - spi_eeprom_register(SPI_BUSNO, SEEPROM1_CS, 128); > - spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM2_CS, 128); > - spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM3_CS, 128); > + spi_eeprom_register(SPI_BUSNO, 0 + SEEPROM1_CS); > + spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM2_CS); > + spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM3_CS); > gpio_request(16 + SRTC_CS, "rtc-rs5c348"); > gpio_direction_output(16 + SRTC_CS, 0); > gpio_request(SEEPROM1_CS, "seeprom1"); > -- > 2.33.0 >
Hi Arnd, On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > In order to get rid of legacy platform data in AT25 driver, > > convert its users to use software nodes. > > > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > This looks good to me, thanks for cleaning this up! I think Geert has this > hardware, adding him to Cc in case he wants to give it a spin. The SPI controller is only present on TX4938, not on TX4927, so it is unused on my rbtx4927 board. > > arch/mips/include/asm/txx9/spi.h | 4 ++-- > > arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ > > arch/mips/txx9/rbtx4938/setup.c | 6 +++--- > > 3 files changed, 24 insertions(+), 18 deletions(-) Probably all of this can be removed, given the SPI controller driver itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove driver")? 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
On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: ... > Probably all of this can be removed, given the SPI controller driver > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > driver")? Even better! Let Thomas speak on this.
On Fri, Nov 26, 2021 at 04:41:00PM +0200, Andy Shevchenko wrote: > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > ... > > > Probably all of this can be removed, given the SPI controller driver > > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > > driver")? > > Even better! Let Thomas speak on this. let's remove it then. Thomas.
On Fri, Nov 26, 2021 at 06:37:07PM +0100, Thomas Bogendoerfer wrote: > On Fri, Nov 26, 2021 at 04:41:00PM +0200, Andy Shevchenko wrote: > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > ... > > > > > Probably all of this can be removed, given the SPI controller driver > > > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > > > driver")? > > > > Even better! Let Thomas speak on this. > > let's remove it then. Okay, who will send a patch? P.S. I'm not a MIPS expert, I feel I'm not the right person to do, but I can try my best.
On Mon, Nov 29, 2021 at 01:28:56PM +0200, Andy Shevchenko wrote: > On Fri, Nov 26, 2021 at 06:37:07PM +0100, Thomas Bogendoerfer wrote: > > On Fri, Nov 26, 2021 at 04:41:00PM +0200, Andy Shevchenko wrote: > > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > ... > > > > > > > Probably all of this can be removed, given the SPI controller driver > > > > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > > > > driver")? > > > > > > Even better! Let Thomas speak on this. > > > > let's remove it then. > > Okay, who will send a patch? > > P.S. I'm not a MIPS expert, I feel I'm not the right person to do, > but I can try my best. ok, I'll do it. Thomas.
On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > Hi Arnd, > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > In order to get rid of legacy platform data in AT25 driver, > > > convert its users to use software nodes. > > > > > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > This looks good to me, thanks for cleaning this up! I think Geert has this > > hardware, adding him to Cc in case he wants to give it a spin. > > The SPI controller is only present on TX4938, not on TX4927, so it is > unused on my rbtx4927 board. > > > > arch/mips/include/asm/txx9/spi.h | 4 ++-- > > > arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ > > > arch/mips/txx9/rbtx4938/setup.c | 6 +++--- > > > 3 files changed, 24 insertions(+), 18 deletions(-) > > Probably all of this can be removed, given the SPI controller driver > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > driver")? are you ok with completly removing rbtx4938 support ? Can I rbtx4939 board support, too ? Thomas.
Hi Thomas, On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote: > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > In order to get rid of legacy platform data in AT25 driver, > > > > convert its users to use software nodes. > > > > > > > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > > > This looks good to me, thanks for cleaning this up! I think Geert has this > > > hardware, adding him to Cc in case he wants to give it a spin. > > > > The SPI controller is only present on TX4938, not on TX4927, so it is > > unused on my rbtx4927 board. > > > > > > arch/mips/include/asm/txx9/spi.h | 4 ++-- > > > > arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ > > > > arch/mips/txx9/rbtx4938/setup.c | 6 +++--- > > > > 3 files changed, 24 insertions(+), 18 deletions(-) > > > > Probably all of this can be removed, given the SPI controller driver > > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > > driver")? > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > board support, too ? Fine for me, I only have rbtx4927. BTW, I'm using it in 32-bit mode, as the VxWorks bootloader cannot boot 64-bit images. Are there other boards with such a limitation? Perhaps there's even shim support for booting 64-bit kernels on such boards, so I can test both 32-bit and 64-bit kernels? 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
On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > Hi Thomas, > > On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > > On Fri, Nov 26, 2021 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > In order to get rid of legacy platform data in AT25 driver, > > > > > convert its users to use software nodes. > > > > > > > > > > Suggested-by: Arnd Bergmann <arnd@arndb.de> > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > > > > > This looks good to me, thanks for cleaning this up! I think Geert has this > > > > hardware, adding him to Cc in case he wants to give it a spin. > > > > > > The SPI controller is only present on TX4938, not on TX4927, so it is > > > unused on my rbtx4927 board. > > > > > > > > arch/mips/include/asm/txx9/spi.h | 4 ++-- > > > > > arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ > > > > > arch/mips/txx9/rbtx4938/setup.c | 6 +++--- > > > > > 3 files changed, 24 insertions(+), 18 deletions(-) > > > > > > Probably all of this can be removed, given the SPI controller driver > > > itself was removed in commit 74523a5dae0c96d6 ("spi: txx9: Remove > > > driver")? > > > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > > board support, too ? > > Fine for me, I only have rbtx4927. > > BTW, I'm using it in 32-bit mode, as the VxWorks bootloader cannot boot > 64-bit images. Are there other boards with such a limitation? Perhaps > there's even shim support for booting 64-bit kernels on such boards, > so I can test both 32-bit and 64-bit kernels? maybe BOOT_ELF32 could help here. Thomas.
Hi Thomas, On Mon, Nov 29, 2021 at 2:33 PM Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote: > On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > > BTW, I'm using it in 32-bit mode, as the VxWorks bootloader cannot boot > > 64-bit images. Are there other boards with such a limitation? Perhaps > > there's even shim support for booting 64-bit kernels on such boards, > > so I can test both 32-bit and 64-bit kernels? > > maybe BOOT_ELF32 could help here. Yes it does, thanks a lot for the suggestion! Patch sent. Took me a bit to test proper operation, as contemporary cross-toolchains create userland binaries that can no longer run on MIPS-II/III CPUs, and native development is slow and memory-constrained (dpkg OOM)... 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
On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: ... > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > > board support, too ? > > Fine for me, I only have rbtx4927. Is there any news? I still see my patch well applied against latest Linux Next. If the removal is going to be postponed, consider applying this patch then. So we may move forward.
On Wed, Dec 08, 2021 at 07:38:16PM +0200, Andy Shevchenko wrote: > On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > > On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer > > <tsbogend@alpha.franken.de> wrote: > > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > ... > > > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > > > board support, too ? > > > > Fine for me, I only have rbtx4927. > > Is there any news? I still see my patch well applied against latest Linux Next. > If the removal is going to be postponed, consider applying this patch then. So > we may move forward. https://lore.kernel.org/all/20211130164558.85584-1-tsbogend@alpha.franken.de/ The second patch in that series touches drivers/mtd so I'm waiting for a Acked-by. But I could apply the first patch... Thomas.
On Wed, Dec 08, 2021 at 11:07:59PM +0100, Thomas Bogendoerfer wrote: > On Wed, Dec 08, 2021 at 07:38:16PM +0200, Andy Shevchenko wrote: > > On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > > > On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer > > > <tsbogend@alpha.franken.de> wrote: > > > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: ... > > > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > > > > board support, too ? > > > > > > Fine for me, I only have rbtx4927. > > > > Is there any news? I still see my patch well applied against latest Linux Next. > > If the removal is going to be postponed, consider applying this patch then. So > > we may move forward. > > https://lore.kernel.org/all/20211130164558.85584-1-tsbogend@alpha.franken.de/ > > The second patch in that series touches drivers/mtd so I'm waiting for > a Acked-by. But I could apply the first patch... Yes, please!
On Thu, Dec 09, 2021 at 12:12:02PM +0200, Andy Shevchenko wrote: > On Wed, Dec 08, 2021 at 11:07:59PM +0100, Thomas Bogendoerfer wrote: > > On Wed, Dec 08, 2021 at 07:38:16PM +0200, Andy Shevchenko wrote: > > > On Mon, Nov 29, 2021 at 01:30:17PM +0100, Geert Uytterhoeven wrote: > > > > On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer > > > > <tsbogend@alpha.franken.de> wrote: > > > > > On Fri, Nov 26, 2021 at 01:16:22PM +0100, Geert Uytterhoeven wrote: > > ... > > > > > > are you ok with completly removing rbtx4938 support ? Can I rbtx4939 > > > > > board support, too ? > > > > > > > > Fine for me, I only have rbtx4927. > > > > > > Is there any news? I still see my patch well applied against latest Linux Next. > > > If the removal is going to be postponed, consider applying this patch then. So > > > we may move forward. > > > > https://lore.kernel.org/all/20211130164558.85584-1-tsbogend@alpha.franken.de/ > > > > The second patch in that series touches drivers/mtd so I'm waiting for > > a Acked-by. But I could apply the first patch... > > Yes, please! I've applied it, should show up in linux-next soon. Thomas.
Hi Geert, > Took me a bit to test proper operation, as contemporary cross-toolchains > create userland binaries that can no longer run on MIPS-II/III CPUs, > and native development is slow and memory-constrained (dpkg OOM)... You mean cross-toolchains included with (some) distributions, right? I do hope so or otherwise I'd be very concerned. Myself I've been using a self-built MIPS cross-compiler, running on POWER9, which builds MIPS I binaries just fine, e.g.: $ file install/usr/sysroot/{lib/ld-2.32.9000.so,usr/bin/gdbserver} install/usr/sysroot/lib/ld-2.32.9000.so: ELF 32-bit LSB pie executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, with debug_info, not stripped install/usr/sysroot/usr/bin/gdbserver: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, not stripped $ install/usr/bin/mipsel-linux-gnu-gcc -dumpversion 11.0.0 $ (time to upgrade perhaps). Maciej
Hi Maciej, On Tue, Jan 18, 2022 at 8:59 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote: > > Took me a bit to test proper operation, as contemporary cross-toolchains > > create userland binaries that can no longer run on MIPS-II/III CPUs, > > and native development is slow and memory-constrained (dpkg OOM)... > > You mean cross-toolchains included with (some) distributions, right? Yep, the MIPS cross-toolchain that comes with Ubuntu. > I do hope so or otherwise I'd be very concerned. Myself I've been using > a self-built MIPS cross-compiler, running on POWER9, which builds MIPS I > binaries just fine, e.g.: > > $ file install/usr/sysroot/{lib/ld-2.32.9000.so,usr/bin/gdbserver} > install/usr/sysroot/lib/ld-2.32.9000.so: ELF 32-bit LSB pie executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, with debug_info, not stripped > install/usr/sysroot/usr/bin/gdbserver: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, not stripped Debian raised the minimum requirements for MIPS, hence mine are ELF 32-bit MSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV) 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
diff --git a/arch/mips/include/asm/txx9/spi.h b/arch/mips/include/asm/txx9/spi.h index 0d727f354557..1ca87a516b81 100644 --- a/arch/mips/include/asm/txx9/spi.h +++ b/arch/mips/include/asm/txx9/spi.h @@ -16,11 +16,11 @@ #include <linux/errno.h> #ifdef CONFIG_SPI -int spi_eeprom_register(int busid, int chipid, int size); +int spi_eeprom_register(int busid, int chipid); int spi_eeprom_read(int busid, int chipid, int address, unsigned char *buf, int len); #else -static inline int spi_eeprom_register(int busid, int chipid, int size) +static inline int spi_eeprom_register(int busid, int chipid) { return -ENODEV; } diff --git a/arch/mips/txx9/generic/spi_eeprom.c b/arch/mips/txx9/generic/spi_eeprom.c index d833dd2c9b55..cb4b4d47437e 100644 --- a/arch/mips/txx9/generic/spi_eeprom.c +++ b/arch/mips/txx9/generic/spi_eeprom.c @@ -9,18 +9,32 @@ * * Support for TX4938 in 2.6 - Manish Lachwani (mlachwani@mvista.com) */ +#include <linux/device.h> +#include <linux/export.h> #include <linux/init.h> +#include <linux/property.h> #include <linux/slab.h> -#include <linux/export.h> -#include <linux/device.h> + #include <linux/spi/spi.h> -#include <linux/spi/eeprom.h> + #include <asm/txx9/spi.h> +#define AT250X0_SIZE 128 #define AT250X0_PAGE_SIZE 8 +static const struct property_entry spi_eeprom_properties[] = { + PROPERTY_ENTRY_U32("size", AT250X0_SIZE), + PROPERTY_ENTRY_U32("pagesize", AT250X0_PAGE_SIZE), + PROPERTY_ENTRY_U32("address-width", 8), + { } +}; + +static const struct software_node spi_eeprom_node = { + .properties = spi_eeprom_properties, +}; + /* register board information for at25 driver */ -int __init spi_eeprom_register(int busid, int chipid, int size) +int __init spi_eeprom_register(int busid, int chipid) { struct spi_board_info info = { .modalias = "at25", @@ -28,16 +42,8 @@ int __init spi_eeprom_register(int busid, int chipid, int size) .bus_num = busid, .chip_select = chipid, /* Mode 0: High-Active, Sample-Then-Shift */ + .swnode = &spi_eeprom_node, }; - struct spi_eeprom *eeprom; - eeprom = kzalloc(sizeof(*eeprom), GFP_KERNEL); - if (!eeprom) - return -ENOMEM; - strcpy(eeprom->name, "at250x0"); - eeprom->byte_len = size; - eeprom->page_size = AT250X0_PAGE_SIZE; - eeprom->flags = EE_ADDR1; - info.platform_data = eeprom; return spi_register_board_info(&info, 1); } diff --git a/arch/mips/txx9/rbtx4938/setup.c b/arch/mips/txx9/rbtx4938/setup.c index e68eb2e7ce0c..136af1cace75 100644 --- a/arch/mips/txx9/rbtx4938/setup.c +++ b/arch/mips/txx9/rbtx4938/setup.c @@ -283,9 +283,9 @@ static int __init rbtx4938_spi_init(void) .mode = SPI_MODE_1 | SPI_CS_HIGH, }; spi_register_board_info(&srtc_info, 1); - spi_eeprom_register(SPI_BUSNO, SEEPROM1_CS, 128); - spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM2_CS, 128); - spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM3_CS, 128); + spi_eeprom_register(SPI_BUSNO, 0 + SEEPROM1_CS); + spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM2_CS); + spi_eeprom_register(SPI_BUSNO, 16 + SEEPROM3_CS); gpio_request(16 + SRTC_CS, "rtc-rs5c348"); gpio_direction_output(16 + SRTC_CS, 0); gpio_request(SEEPROM1_CS, "seeprom1");
In order to get rid of legacy platform data in AT25 driver, convert its users to use software nodes. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- arch/mips/include/asm/txx9/spi.h | 4 ++-- arch/mips/txx9/generic/spi_eeprom.c | 32 +++++++++++++++++------------ arch/mips/txx9/rbtx4938/setup.c | 6 +++--- 3 files changed, 24 insertions(+), 18 deletions(-)