linux-kernel - Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120917083237.GB21928@lunn.ch>
Date:	Mon, 17 Sep 2012 10:32:37 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc:	Nicolas Pitre <nico@...xnic.net>,
	Jason Cooper <jason@...edaemon.net>,
	Andrew Lunn <andrew@...n.ch>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Lior Amsalem <alior@...vell.com>,
	Russell King <linux@....linux.org.uk>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

> I had a closer look at how kirkwood probes its id. I mentionend kirkwood_id()
> earlier but in fact it is kirkwood_pcie_id(). I assume pcie registers are shut
> down with pcie clk gated? That would require to have pcie running at least at
> boot-time on all boards.
> 
> While it is still possible to grab the id and power down pcie later, I still
> think that using five different compatible strings is better here. Of course,
> there is some effort to obtain the kirkwood SoC variant for all boards.

Hi Sebastian

I did the monkey work last night for converting all existing kirkwood
DT boards over to pinctrl. I noticed that in all the DT descriptions,
they all declare themselves as 88f6281. This is probably cut/paste
from the first board we ever had. For these boards, i doubt it will be
a problem, finding out what chip is really used, as there are active
maintainers. The problem comes with old style devices which we want to
convert. But if we do the monkey work for older boards, we are going
to have to find testers anyway and they can tell us what SoC is used.

Having said that, not probing the hardware, having it configurable is
a source of errors. We already probe the hardware in order to display:

Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.

so we just need to cache this and make it available to anybody who
wants it.

I'm surprised we don't have the infrastructure of this already. We
have info about the CPU, e.g.

cat /proc/cpuinfo 
Processor	  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS	  : 1587.60
Features	  : swp half thumb fastmult edsp 
CPU implementer	  : 0x56
CPU architecture: 5TE
CPU variant	  : 0x2
CPU part	  : 0x131
CPU revision	  : 1

Hardware	  : Marvell Kirkwood (Flattened Device Tree)
Revision	  : 0000
Serial		    : 0000000000000000

but don't seem to have anything about the SoC the CPU is embedded in.

AT91 has at91_get_soc_type(struct at91_socinfo *c) which is what we
would need for Kirkwood. However, interestingly, its never used
outside of arch/arm/mach-at91/setup.c!

davinci has a global structure davinci_soc_info which
gpio/gpio-davinci.c uses.

So we would not be the only architecture making such information
available. We just need to make sure we do it such that its multi-arch
kernel compatible.

       Andrew

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/