All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Danny Huang <dahuang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2] ARM: tegra: expose chip ID and revision
Date: Tue, 12 Mar 2013 13:45:14 -0600	[thread overview]
Message-ID: <513F85CA.2000800@wwwdotorg.org> (raw)
In-Reply-To: <201303121910.55141.arnd-r2nGTMty4D4@public.gmane.org>

On 03/12/2013 01:10 PM, Arnd Bergmann wrote:
> On Tuesday 12 March 2013, Stephen Warren wrote:
>>> You are dropping the soc_dev on the floor here by just returning.
>>>
>>> The idea of the soc node is to have all on-soc components be children
>>> of that node, so you should instead pass it into of_platform_populate
>>> as the parent device.
>>
>> Tegra DTs don't have a separate node for on-soc vs. off-soc components.
>> Wouldn't passing soc_dev into of_platform_populate() make everything a
>> child of this soc_dev; is that what we want?
> 
> Yes, we had long discussions about this when the soc infrastructure was
> merged. Right now, everything is a child of /sys/devices/platform/,
> basically saying that all devices are random stuff that cannot be
> probed. Moving it to /sys/devices/soc0 would not make the hierarchy
> any deeper but show much clearer which devices are part of the
> soc, and which ones are added as anonymous platform devices by code
> that does not use DT based probing. Ideally the second category is
> empty.

OK, that makes sense.

Danny, in that case, the initialization of this SoC object should
definitely happen inside tegra_init_fuse(), which is called from
tegra_init_early(), so that mach-tegra/tegra.c:tegra_dt_init() can call
a function in fuse.c to retrieve that SoC object in order to pass it
into of_platform_populate().

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: tegra: expose chip ID and revision
Date: Tue, 12 Mar 2013 13:45:14 -0600	[thread overview]
Message-ID: <513F85CA.2000800@wwwdotorg.org> (raw)
In-Reply-To: <201303121910.55141.arnd@arndb.de>

On 03/12/2013 01:10 PM, Arnd Bergmann wrote:
> On Tuesday 12 March 2013, Stephen Warren wrote:
>>> You are dropping the soc_dev on the floor here by just returning.
>>>
>>> The idea of the soc node is to have all on-soc components be children
>>> of that node, so you should instead pass it into of_platform_populate
>>> as the parent device.
>>
>> Tegra DTs don't have a separate node for on-soc vs. off-soc components.
>> Wouldn't passing soc_dev into of_platform_populate() make everything a
>> child of this soc_dev; is that what we want?
> 
> Yes, we had long discussions about this when the soc infrastructure was
> merged. Right now, everything is a child of /sys/devices/platform/,
> basically saying that all devices are random stuff that cannot be
> probed. Moving it to /sys/devices/soc0 would not make the hierarchy
> any deeper but show much clearer which devices are part of the
> soc, and which ones are added as anonymous platform devices by code
> that does not use DT based probing. Ideally the second category is
> empty.

OK, that makes sense.

Danny, in that case, the initialization of this SoC object should
definitely happen inside tegra_init_fuse(), which is called from
tegra_init_early(), so that mach-tegra/tegra.c:tegra_dt_init() can call
a function in fuse.c to retrieve that SoC object in order to pass it
into of_platform_populate().

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Danny Huang <dahuang@nvidia.com>,
	linux@arm.linux.org.uk, hdoyu@nvidia.com, olof@lixom.net,
	gregkh@linuxfoundation.org, josephl@nvidia.com,
	pdeschrijver@nvidia.com, pgaikwad@nvidia.com,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ARM: tegra: expose chip ID and revision
Date: Tue, 12 Mar 2013 13:45:14 -0600	[thread overview]
Message-ID: <513F85CA.2000800@wwwdotorg.org> (raw)
In-Reply-To: <201303121910.55141.arnd@arndb.de>

On 03/12/2013 01:10 PM, Arnd Bergmann wrote:
> On Tuesday 12 March 2013, Stephen Warren wrote:
>>> You are dropping the soc_dev on the floor here by just returning.
>>>
>>> The idea of the soc node is to have all on-soc components be children
>>> of that node, so you should instead pass it into of_platform_populate
>>> as the parent device.
>>
>> Tegra DTs don't have a separate node for on-soc vs. off-soc components.
>> Wouldn't passing soc_dev into of_platform_populate() make everything a
>> child of this soc_dev; is that what we want?
> 
> Yes, we had long discussions about this when the soc infrastructure was
> merged. Right now, everything is a child of /sys/devices/platform/,
> basically saying that all devices are random stuff that cannot be
> probed. Moving it to /sys/devices/soc0 would not make the hierarchy
> any deeper but show much clearer which devices are part of the
> soc, and which ones are added as anonymous platform devices by code
> that does not use DT based probing. Ideally the second category is
> empty.

OK, that makes sense.

Danny, in that case, the initialization of this SoC object should
definitely happen inside tegra_init_fuse(), which is called from
tegra_init_early(), so that mach-tegra/tegra.c:tegra_dt_init() can call
a function in fuse.c to retrieve that SoC object in order to pass it
into of_platform_populate().

  parent reply	other threads:[~2013-03-12 19:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-12 12:01 [PATCH v2] ARM: tegra: expose chip ID and revision Danny Huang
2013-03-12 12:01 ` Danny Huang
2013-03-12 12:01 ` Danny Huang
     [not found] ` <1363089667-15737-1-git-send-email-dahuang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-12 12:16   ` Russell King - ARM Linux
2013-03-12 12:16     ` Russell King - ARM Linux
2013-03-12 12:16     ` Russell King - ARM Linux
2013-03-12 12:59   ` Arnd Bergmann
2013-03-12 12:59     ` Arnd Bergmann
2013-03-12 12:59     ` Arnd Bergmann
     [not found]     ` <201303121259.18710.arnd-r2nGTMty4D4@public.gmane.org>
2013-03-12 18:04       ` Stephen Warren
2013-03-12 18:04         ` Stephen Warren
2013-03-12 18:04         ` Stephen Warren
     [not found]         ` <513F6E2C.1000101-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-12 19:10           ` Arnd Bergmann
2013-03-12 19:10             ` Arnd Bergmann
2013-03-12 19:10             ` Arnd Bergmann
     [not found]             ` <201303121910.55141.arnd-r2nGTMty4D4@public.gmane.org>
2013-03-12 19:45               ` Stephen Warren [this message]
2013-03-12 19:45                 ` Stephen Warren
2013-03-12 19:45                 ` Stephen Warren
2013-03-12 17:58   ` Stephen Warren
2013-03-12 17:58     ` Stephen Warren
2013-03-12 17:58     ` Stephen Warren
2013-03-12 18:01   ` Stephen Warren
2013-03-12 18:01     ` Stephen Warren
2013-03-12 18:01     ` Stephen Warren

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=513F85CA.2000800@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=dahuang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /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.