[PATCH] ARM: Kirkwood: Add DT description of QNAP 419

On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote:

On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote:

quoted

Re-implement the Marvell Kirkwood ts41x-setup.c in DT.

As with the QNAP 119, there are two variants, depending on which SoC
has been used. They differ on Ethernet PHY addresses and number of
PCIe busses.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>

On the assumption that this is basically the same as the think you asked
me to test last week:
Tested-by: Ian Campbell <redacted> (specifically kirkwood-ts419-6281.dtb)

 
It is the same. Thanks for testing.

What is the plan for the board files for the ts* platforms? Are they
going to go away? This seems to have happened for the Sheevaplug case,
which is causing some transition pain for distros (e.g.
http://bugs.debian.org/731345).

We plan to make them go away. We are not quite there yet, there are
still a couple of boards which don't have DT files. But we are working
on those.
 

The big issue for the ts devices is that each board file seems to be
splitting into two DTB files so in order to handle upgrades we need to
be able to detect which of the two variants we need, both when running
the previous board-file kernel and when running the DT version. Any
advice? You previously pointed me to a string in the dmesg but this
might not be reliable if the early boot messages have gone from the
circular buffer and in any case I'm not sure how wise it is to rely on
parsing those.

It looks like the board files determine things based on
kirkwood_pcie_id() -- is the result of that available in userspace
anywhere? I suppose counting the number of PCI buses would work, not a
brilliant solution but given the need to work with board file kernels
too maybe that's the best option.

This is an issue, which has been discussed a bit recently while fixing
an i2c issues on Marvell XP SoCs. As far as i know, there is no
reliable export of the version field. It might be available from
lspci, but so far i've not seen it. I will look into this in the next
few days.

The other issue I spotted is
that /dev/input/by-path/platform-gpio-keys-event has
become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered
valid for a by-path name to change? In particular the 3 here is
apparently the node depth in the DTB, which doesn't make much logical
sense as a "path" in this context I don't think (I expect it to be some
sort of path through the hardware buses, perhaps my expectation is
wrong?).

To be honest, i've no idea about this. I hope somebody else will
answer. If not, we might need to ask on the input mailing list.

	Andrew