In order to get rid of legacy platform data in AT25 driver,
convert its users to use software nodes.
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
---
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 ([email protected])
*/
+#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
On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
<[email protected]> wrote:
>
> In order to get rid of legacy platform data in AT25 driver,
> convert its users to use software nodes.
>
> Suggested-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Andy Shevchenko <[email protected]>
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 ([email protected])
> */
> +#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 <[email protected]> wrote:
> On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> <[email protected]> wrote:
> > In order to get rid of legacy platform data in AT25 driver,
> > convert its users to use software nodes.
> >
> > Suggested-by: Arnd Bergmann <[email protected]>
> > Signed-off-by: Andy Shevchenko <[email protected]>
>
> 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 -- [email protected]
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 <[email protected]> wrote:
> > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
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 <[email protected]> wrote:
> > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > > <[email protected]> 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
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 <[email protected]> wrote:
> > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > > > <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
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 <[email protected]> wrote:
> > > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > > > > <[email protected]> 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
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 <[email protected]> wrote:
> > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > <[email protected]> wrote:
> > > In order to get rid of legacy platform data in AT25 driver,
> > > convert its users to use software nodes.
> > >
> > > Suggested-by: Arnd Bergmann <[email protected]>
> > > Signed-off-by: Andy Shevchenko <[email protected]>
> >
> > 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Hi Thomas,
On Mon, Nov 29, 2021 at 1:21 PM Thomas Bogendoerfer
<[email protected]> 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 <[email protected]> wrote:
> > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > > <[email protected]> wrote:
> > > > In order to get rid of legacy platform data in AT25 driver,
> > > > convert its users to use software nodes.
> > > >
> > > > Suggested-by: Arnd Bergmann <[email protected]>
> > > > Signed-off-by: Andy Shevchenko <[email protected]>
> > >
> > > 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 -- [email protected]
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
> <[email protected]> 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 <[email protected]> wrote:
> > > > On Fri, Nov 26, 2021 at 11:23 AM Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > > In order to get rid of legacy platform data in AT25 driver,
> > > > > convert its users to use software nodes.
> > > > >
> > > > > Suggested-by: Arnd Bergmann <[email protected]>
> > > > > Signed-off-by: Andy Shevchenko <[email protected]>
> > > >
> > > > 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Hi Thomas,
On Mon, Nov 29, 2021 at 2:33 PM Thomas Bogendoerfer
<[email protected]> 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 -- [email protected]
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
> <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
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
> > <[email protected]> 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/[email protected]/
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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
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
> > > <[email protected]> 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/[email protected]/
>
> 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!
--
With Best Regards,
Andy Shevchenko
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
> > > > <[email protected]> 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/[email protected]/
> >
> > 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
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 <[email protected]> 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 -- [email protected]
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