From: Chen Gang <hidden> Date: 2014-08-04 18:24:16
For HISAX_NETJET, HISAX_NETJET_U or related config needs !__BIG_ENDIAN,
so skip microblaze, just like skip all other architectures which have
no CONFIG_*_ENDIAN.
The related error (with allmodconfig under microblaze):
CC [M] drivers/isdn/hisax/nj_s.o
drivers/isdn/hisax/nj_s.c: In function 'setup_netjet_s':
drivers/isdn/hisax/nj_s.c:265:2: error: #error "not running on big endian machines now"
#error "not running on big endian machines now"
^
Signed-off-by: Chen Gang <redacted>
---
drivers/isdn/hisax/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Jean Delvare <hidden> Date: 2014-08-04 19:24:00
Hi Chen Gang,
On Tue, 05 Aug 2014 02:24:09 +0800, Chen Gang wrote:
quoted hunk
For HISAX_NETJET, HISAX_NETJET_U or related config needs !__BIG_ENDIAN,
so skip microblaze, just like skip all other architectures which have
no CONFIG_*_ENDIAN.
The related error (with allmodconfig under microblaze):
CC [M] drivers/isdn/hisax/nj_s.o
drivers/isdn/hisax/nj_s.c: In function 'setup_netjet_s':
drivers/isdn/hisax/nj_s.c:265:2: error: #error "not running on big endian machines now"
#error "not running on big endian machines now"
^
Signed-off-by: Chen Gang <redacted>
---
drivers/isdn/hisax/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Fine with me, however the list is getting long. It would be better if
we could depend on a functional symbol rather than a negated list of
architectures. Would it make sense to have CONFIG_CPU_LITTLE_ENDIAN
defined on all little-endian architectures, so that driver can depend
on that if needed?
Alternatively, it might make more sense to list the architectures where
these drivers are actually used in practice. I guess that's X86, maybe
ARM and IA64, and that's all?
--
Jean Delvare
SUSE L3 Support
Fine with me, however the list is getting long. It would be better if
we could depend on a functional symbol rather than a negated list of
architectures. Would it make sense to have CONFIG_CPU_LITTLE_ENDIAN
defined on all little-endian architectures, so that driver can depend
on that if needed?
Yes, that idea pops up once in a while.
BTW, these days little endian PPC is also supported by Linux...
Alternatively, it might make more sense to list the architectures where
these drivers are actually used in practice. I guess that's X86, maybe
ARM and IA64, and that's all?
|| COMPILE_TEST ....
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
Fine with me, however the list is getting long. It would be better if
we could depend on a functional symbol rather than a negated list of
architectures. Would it make sense to have CONFIG_CPU_LITTLE_ENDIAN
defined on all little-endian architectures, so that driver can depend
on that if needed?
Yes, that idea pops up once in a while.
BTW, these days little endian PPC is also supported by Linux...
quoted
Alternatively, it might make more sense to list the architectures where
these drivers are actually used in practice. I guess that's X86, maybe
ARM and IA64, and that's all?
|| COMPILE_TEST ....
OK, thanks, what all of you said sounds reasonable to me.
Hello Geert:
Could you help send the related patch for it?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Fine with me, however the list is getting long. It would be better if
we could depend on a functional symbol rather than a negated list of
architectures. Would it make sense to have CONFIG_CPU_LITTLE_ENDIAN
defined on all little-endian architectures, so that driver can depend
on that if needed?
Yes, that idea pops up once in a while.
BTW, these days little endian PPC is also supported by Linux...
quoted
Alternatively, it might make more sense to list the architectures where
these drivers are actually used in practice. I guess that's X86, maybe
ARM and IA64, and that's all?
|| COMPILE_TEST ....
If no additional response within 3 days, I shall continue to try to send
patch for it.
Excuse me, I need additional thinking of for it, so I plan to send patch
for discussing and review within next week end (2014-08-17).
And welcome any members' ideas, suggestions and completions.
Thanks.
OK, thanks, what all of you said sounds reasonable to me.
Hello Geert:
Could you help send the related patch for it?
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed