All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	stable@vger.kernel.org,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v2 1/2] ARM: mvebu: Add support to get the ID and the revision of a SoC
Date: Sun, 5 Jan 2014 15:25:52 +0100	[thread overview]
Message-ID: <201401051525.52459.arnd@arndb.de> (raw)
In-Reply-To: <1388743185-24822-2-git-send-email-gregory.clement@free-electrons.com>

On Friday 03 January 2014, Gregory CLEMENT wrote:
> All the mvebu SoCs have information related to their variant and
> revision that can be read from the PCI control register.
> 
> This patch adds support for Armada XP and Armada 370. This reading of
> the revision and the ID are done before the PCI initialization to
> avoid any conflicts. Once these data are retrieved, the resources are
> freed to let the PCI subsystem use it.

I like the idea of identifying the soc version for any number of
reasons, but I would hope there was some way of doing this that didn't
involve probing the PCI device. I know this is the traditional way
on orion/kirkwood/dove/... but it always felt wrong to me.

> +static u32 soc_dev_id;
> +static u32 soc_rev;
> +static bool is_id_valid;

Would it be reasonable to reuse the global "system_rev" variable for this
rather than a platform specific exported function?

> +static const struct of_device_id mvebu_pcie_of_match_table[] = {
> +	{ .compatible = "marvell,armada-xp-pcie", },
> +	{ .compatible = "marvell,armada-370-pcie", },
> +	{},
> +};
> +
> +int mvebu_get_soc_id(u32 *dev, u32 *rev)
> +{
> +	if (is_id_valid) {
> +		*dev = soc_dev_id;
> +		*rev = soc_rev;
> +		return 0;
> +	} else
> +		return -1;
> +}
> +
> +EXPORT_SYMBOL(mvebu_get_soc_id);

Maybe EXPORT_SYMBOL_GPL, out of principle?

> +static int __init mvebu_soc_id_init(void)
> +{
> +	struct device_node *np;
> +	int ret = 0;
> +
> +	np = of_find_matching_node(NULL, mvebu_pcie_of_match_table);
> +	if (np) {
> +		void __iomem *pci_base;
> +		struct clk *clk;
> +		/*
> +		 * ID and revision are available from any port, so we
> +		 * just pick the first one
> +		 */
> +		struct device_node *child = of_get_next_child(np, NULL);

I guess all this will fail if for some reason the PCIe node is not
present on machines that don't use PCIe.

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] ARM: mvebu: Add support to get the ID and the revision of a SoC
Date: Sun, 5 Jan 2014 15:25:52 +0100	[thread overview]
Message-ID: <201401051525.52459.arnd@arndb.de> (raw)
In-Reply-To: <1388743185-24822-2-git-send-email-gregory.clement@free-electrons.com>

On Friday 03 January 2014, Gregory CLEMENT wrote:
> All the mvebu SoCs have information related to their variant and
> revision that can be read from the PCI control register.
> 
> This patch adds support for Armada XP and Armada 370. This reading of
> the revision and the ID are done before the PCI initialization to
> avoid any conflicts. Once these data are retrieved, the resources are
> freed to let the PCI subsystem use it.

I like the idea of identifying the soc version for any number of
reasons, but I would hope there was some way of doing this that didn't
involve probing the PCI device. I know this is the traditional way
on orion/kirkwood/dove/... but it always felt wrong to me.

> +static u32 soc_dev_id;
> +static u32 soc_rev;
> +static bool is_id_valid;

Would it be reasonable to reuse the global "system_rev" variable for this
rather than a platform specific exported function?

> +static const struct of_device_id mvebu_pcie_of_match_table[] = {
> +	{ .compatible = "marvell,armada-xp-pcie", },
> +	{ .compatible = "marvell,armada-370-pcie", },
> +	{},
> +};
> +
> +int mvebu_get_soc_id(u32 *dev, u32 *rev)
> +{
> +	if (is_id_valid) {
> +		*dev = soc_dev_id;
> +		*rev = soc_rev;
> +		return 0;
> +	} else
> +		return -1;
> +}
> +
> +EXPORT_SYMBOL(mvebu_get_soc_id);

Maybe EXPORT_SYMBOL_GPL, out of principle?

> +static int __init mvebu_soc_id_init(void)
> +{
> +	struct device_node *np;
> +	int ret = 0;
> +
> +	np = of_find_matching_node(NULL, mvebu_pcie_of_match_table);
> +	if (np) {
> +		void __iomem *pci_base;
> +		struct clk *clk;
> +		/*
> +		 * ID and revision are available from any port, so we
> +		 * just pick the first one
> +		 */
> +		struct device_node *child = of_get_next_child(np, NULL);

I guess all this will fail if for some reason the PCIe node is not
present on machines that don't use PCIe.

  parent reply	other threads:[~2014-01-05 14:25 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03  9:59 [PATCH v2 0/2] Fix i2c bus hang on A0 version of the Armada XP SoCs Gregory CLEMENT
2014-01-03  9:59 ` Gregory CLEMENT
     [not found] ` <1388743185-24822-1-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-03  9:59   ` [PATCH v2 1/2] ARM: mvebu: Add support to get the ID and the revision of a SoC Gregory CLEMENT
2014-01-03  9:59     ` Gregory CLEMENT
2014-01-03 14:47     ` Andrew Lunn
2014-01-03 14:47       ` Andrew Lunn
2014-01-03 14:51       ` Gregory CLEMENT
2014-01-03 14:51         ` Gregory CLEMENT
     [not found]         ` <52C6CE7E.5010800-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-03 15:13           ` Gregory CLEMENT
2014-01-03 15:13             ` Gregory CLEMENT
2014-01-03 16:41             ` Andrew Lunn
2014-01-03 16:41               ` Andrew Lunn
2014-01-03 19:30               ` Gregory CLEMENT
2014-01-03 19:30                 ` Gregory CLEMENT
     [not found]     ` <1388743185-24822-2-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-03 18:48       ` Thomas Petazzoni
2014-01-03 18:48         ` Thomas Petazzoni
2014-01-03 19:25         ` Gregory CLEMENT
2014-01-03 19:25           ` Gregory CLEMENT
2014-01-03 18:59     ` Jason Gunthorpe
2014-01-03 18:59       ` Jason Gunthorpe
2014-01-03 19:35       ` Gregory CLEMENT
2014-01-03 19:35         ` Gregory CLEMENT
2014-01-05 14:25     ` Arnd Bergmann [this message]
2014-01-05 14:25       ` Arnd Bergmann
2014-01-05 15:40       ` Andrew Lunn
2014-01-05 15:40         ` Andrew Lunn
     [not found]         ` <20140105154023.GA2048-g2DYL2Zd6BY@public.gmane.org>
2014-01-05 17:27           ` Jason Gunthorpe
2014-01-05 17:27             ` Jason Gunthorpe
     [not found]             ` <20140105172756.GA11280-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2014-01-05 17:37               ` Sebastian Hesselbarth
2014-01-05 17:37                 ` Sebastian Hesselbarth
2014-01-05 23:07                 ` Jason Gunthorpe
2014-01-05 23:07                   ` Jason Gunthorpe
2014-01-05 23:12                   ` Sebastian Hesselbarth
2014-01-05 23:12                     ` Sebastian Hesselbarth
     [not found]                     ` <52C9E6D0.3000406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-01-05 23:40                       ` Jason Gunthorpe
2014-01-05 23:40                         ` Jason Gunthorpe
2014-01-06  0:05                         ` Sebastian Hesselbarth
2014-01-06  0:05                           ` Sebastian Hesselbarth
2014-01-06  0:17                           ` Andrew Lunn
2014-01-06  0:17                             ` Andrew Lunn
     [not found]                             ` <20140106001709.GD4093-g2DYL2Zd6BY@public.gmane.org>
2014-01-06  9:55                               ` Gregory CLEMENT
2014-01-06  9:55                                 ` Gregory CLEMENT
2014-01-06 10:10                                 ` Gregory CLEMENT
2014-01-06 10:10                                   ` Gregory CLEMENT
2014-01-05 19:17           ` Arnd Bergmann
2014-01-05 19:17             ` Arnd Bergmann
     [not found]             ` <201401052017.10982.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-05 23:51               ` Andrew Lunn
2014-01-05 23:51                 ` Andrew Lunn
2014-01-06 15:37                 ` Arnd Bergmann
2014-01-06 15:37                   ` Arnd Bergmann
     [not found]                   ` <201401061637.28194.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-06 16:24                     ` Andrew Lunn
2014-01-06 16:24                       ` Andrew Lunn
     [not found]                       ` <20140106162442.GB13111-g2DYL2Zd6BY@public.gmane.org>
2014-01-07 14:41                         ` Arnd Bergmann
2014-01-07 14:41                           ` Arnd Bergmann
2014-01-06 10:28       ` Gregory CLEMENT
2014-01-06 10:28         ` Gregory CLEMENT
2014-01-03  9:59 ` [PATCH v2 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs Gregory CLEMENT
2014-01-03  9:59   ` Gregory CLEMENT
     [not found]   ` <1388743185-24822-3-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-03 12:20     ` Gregory CLEMENT
2014-01-03 12:20       ` Gregory CLEMENT
2014-01-03 18:49   ` Thomas Petazzoni
2014-01-03 18:49     ` Thomas Petazzoni
2014-01-03 19:31     ` Gregory CLEMENT
2014-01-03 19:31       ` Gregory CLEMENT
2014-01-05 14:33   ` Arnd Bergmann
2014-01-05 14:33     ` Arnd Bergmann
     [not found]     ` <201401051533.58931.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-06  9:09       ` Gregory CLEMENT
2014-01-06  9:09         ` Gregory CLEMENT
     [not found]         ` <52CA72BF.10604-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-07  9:03           ` Arnd Bergmann
2014-01-07  9:03             ` Arnd Bergmann
     [not found]             ` <201401071003.31309.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-07 13:17               ` Gregory CLEMENT
2014-01-07 13:17                 ` Gregory CLEMENT
2014-01-07 20:50                 ` Arnd Bergmann
2014-01-07 20:50                   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201401051525.52459.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=andrew@lunn.ch \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.