On Tue, Feb 21, 2017 at 6:32 PM, Andy Shevchenko
[off-list ref] wrote:

On Tue, Feb 21, 2017 at 6:21 PM, Alexandre Belloni
[off-list ref] wrote:

quoted

On 21/02/2017 at 18:09:09 +0200, Andy Shevchenko wrote:

quoted

On Tue, Feb 21, 2017 at 1:27 PM, Alexandre Belloni
[off-list ref] wrote:

quoted

On 21/02/2017 at 13:02:21 +0200, Andy Shevchenko wrote:

quoted

Abusing platform data with pointers is also not welcome.

quoted

quoted

quoted

quoted

quoted

(in this case, avr32).

It's dead de facto.

When last time did you compile kernel for it? What was the version of kernel?
Did it get successfully?

v4.10-rc3 was building successfully but had some issues in the network
code.

Newer kernel doesn't link...

quoted

quoted

When are we going to remove avr32 support from kernel completely?

quoted

Ask that to the avr32 maintainers. It still builds and is still booted
by some people. And that actually seems to be you as you reported a bug
we introduced in 4.3. I don't think we had any other report after that.

https://patchwork.kernel.org/patch/9505727/

After that I gave up on it. Next time I will escalate directly to
Linus. It's a complete necrophilia. I spent already enough time to
look at that code. It brings now more burden than supports someone
somewhere.

As said, it builds fine without networking.

It sounds a bit sarcastic. Irony is that I *have* hardware here which
was dedicated as Network Gateway (ATNGW100). I'm accessing to it
remotely.
How useful it would be?

quoted

Maybe the first step is to
ask the avr32 maintainers. If you already did so,

I did it ~year or so before where another relocation bug was discovered (fixed).

quoted

please feel free to
send a patch to remove the whole architecture.
The benefits for atmel will be: proper big endian support, removal of
platform data from all the drivers, better clocksource handling.

That is good point, but if maintainers don't care, why anyone else should?
Neither do I.

quoted

quoted

quoted

It can be frustrating at times to handle that platform but if it is
working for someone, I don't see why we would remove it.

How it's working if it's not linked?

Come on, v4.10 has just been release and

It doesn't build anymore. And current case even worse
Face it. It's dead.

  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x1f2bd4): Section mismatch in reference from
the variable __param_ops_mtd to the functio
n .init.text:ubi_mtd_param_parse()
The function __param_ops_mtd() references
the function __init ubi_mtd_param_parse().
This is often because __param_ops_mtd lacks a __init
annotation or the annotation of ubi_mtd_param_parse is wrong.

crypto/built-in.o: warning: input is not relaxable
virt/built-in.o: warning: input is not relaxable
net/built-in.o: In function `rtnl_fill_ifinfo':
net/socket.c:451: relocation truncated to fit: R_AVR32_11H_PCREL
against `.text'+22768
Makefile:969: recipe for target 'vmlinux' failed

v4.9 was building just fine. Do

quoted

you really expect everybody to closely follow linux-next or update
overnight?

What version do you use as compiler?

Today's linux-next:
$ make O=~/prj/TMP/out/avr32 C=1 CF=-D__CHECK_ENDIAN__ -j64 CONFIG_DEBUG_INFO=
y CONFIG_DEBUG_SECTION_MISMATCH=y

  CC      lib/sbitmap.o
{standard input}: Assembler messages:
{standard input}:378: Warning: Unary operator + ignored because bad
operand follows
{standard input}:378: Warning: missing operand; zero assumed
{standard input}:378: Internal error!
Assertion failure in finish_insn at .././gas/config/tc-avr32.c line 3498.
Please report this bug.
scripts/Makefile.build:294: recipe for target 'lib/sbitmap.o' failed

$ avr32-linux-gcc --version
avr32-linux-gcc (GCC) 4.2.2-atmel.1.0.8

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html