All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"eduardo.valentin@ti.com" <eduardo.valentin@ti.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] thermal: of: look for sensor driver parent node if device node missing
Date: Wed, 30 Jul 2014 10:26:22 -0400	[thread overview]
Message-ID: <20140730142622.GA3808@developer> (raw)
In-Reply-To: <53D8F578.1030409@nvidia.com>

Hello Laxman,

On Wed, Jul 30, 2014 at 07:09:04PM +0530, Laxman Dewangan wrote:
> On Wednesday 30 July 2014 06:48 PM, Eduardo Valentin wrote:
> > Laxman,
> >
> > On Mon, Jul 14, 2014 at 02:04:55PM +0200, Lucas Stach wrote:
> >> Am Montag, den 14.07.2014, 16:42 +0530 schrieb Laxman Dewangan:
> >>> There are some mfd devices which supports junction thermal interrupt
> >>> like ams,AS3722. The DT binding of these devices are defined as the
> >>> flat and drivers for sub module of such devices are registered as
> >>> the mfd_add_devices. In this method, the sub devices registered as
> >>> platform driver and these do not have the of_node pointer on their
> >>> device structure. In this case, use the parent of_node pointer to
> >>> get the required of_node pointer.
> >>>
> >>> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> >>> ---
> >>>   drivers/thermal/of-thermal.c | 2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> >>> index 04b1be7..85a7d71 100644
> >>> --- a/drivers/thermal/of-thermal.c
> >>> +++ b/drivers/thermal/of-thermal.c
> >>> @@ -396,6 +396,8 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
> >>>   		return ERR_PTR(-EINVAL);
> >>>   
> >>>   	sensor_np = dev->of_node;
> >>> +	if (!sensor_np && dev->parent)
> >>> +		sensor_np = dev->parent->of_node;
> >>>   
> >>>   	for_each_child_of_node(np, child) {
> >>>   		struct of_phandle_args sensor_specs;
> >> This seems like the wrong way around. If the MFD has subdev information
> >> stored in the parent node it should be the MFD drivers responsibility to
> >> populate the subdev of_node with its own node. The subdev should not be
> >> forced to make such possible unsafe assumptions.
> >>
> > This is my understanding too. MFD device drivers must populate the
> > required data onto their sub devices while creating them.
> >
> 
> Sometime ago, Stephen sent patch on MFD to initialize the mfd sub 
> devices of_node with parent node.
> 
> mfd: always assign of_node in mfd_add_device()
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/217482.html
> 

In fact, as I mentioned, this is a controversal subject.

> But it has unforeseen issue and reverted with patch
> mfd: Revert "mfd: Always assign of_node in mfd_add_device()"
> https://groups.google.com/forum/#!msg/rtc-linux/2LeLipSPFs0/XfPCKpT1BnUJ
> 

Indeed, the strategy had issues.

> So we do not have any mechanism here to pass the parent of_node to the 
> of-thermal.

Yeah, but still, as you can see this issue is present in other places apart from
of-thermal. Therefore, it is clear that needs to be fixed somewhere else
than in of-thermal so that others benefit too, don't you agree?

> 
> Adding Stephen and Lee for more comment.

Sure.

In general, I believe letting sub devices to access the MFD core data
(in this case, the parent of node data) is somehow racy. I would prefer
we could have a way to populate the of_node of subdevs with only the
required info.

  reply	other threads:[~2014-07-30 14:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-14 11:12 [PATCH] thermal: of: look for sensor driver parent node if device node missing Laxman Dewangan
2014-07-14 11:12 ` Laxman Dewangan
2014-07-14 12:04 ` Lucas Stach
2014-07-30 13:18   ` Eduardo Valentin
2014-07-30 13:39     ` Laxman Dewangan
2014-07-30 14:26       ` Eduardo Valentin [this message]
2014-07-24  9:49 ` Laxman Dewangan
2014-07-24 15:15   ` Zhang, Rui
2014-07-24 16:38     ` Eduardo Valentin
2014-07-25  8:22     ` Laxman Dewangan
2014-07-25  8:35       ` Javi Merino

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=20140730142622.GA3808@developer \
    --to=edubezval@gmail.com \
    --cc=eduardo.valentin@ti.com \
    --cc=l.stach@pengutronix.de \
    --cc=ldewangan@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=swarren@wwwdotorg.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.