All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, Kevin Hilman <khilman@ti.com>,
	Benoit Cousson <b-cousson@ti.com>,
	linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support
Date: Fri, 11 Feb 2011 10:34:34 +0530	[thread overview]
Message-ID: <74b7dfbe67e19da4358f7df0bc4dd8f1@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1102102135220.21991@utopia.booyaka.com>

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Friday, February 11, 2011 10:08 AM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org; Kevin Hilman; Benoit Cousson;
linux-arm-kernel@lists.infradead.org
> Subject: RE: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency
support
>
> On Fri, 11 Feb 2011, Rajendra Nayak wrote:
>
> > My initial version actually did have a check for cd->clkdm_name
instead
> > of cd->clkdm, and then I ran into aborts when a clkdm, though
belonging
> > to the right chip version, failed lookup (in clkdm_init) and left the
> > cd->clkdm pointer NULL. This however was due to the fact that the
> > clkdm_name populated was'nt matching the actual name,
>
> So those aborts were due to clockdomain or clockdomain dependency data
> that had errors that caused it not to have referential integrity?

Yes, I specifically found it when my script updates were actually
generating some non-matching (and hence wrong) clkdm_names.
The aborts actually helped me fix it...

>
> > Would it make sense to add an additional check here to avoid
> > an abort in case of mismatches in clkdm_name populated and
> > lookup's failing in clkdm_init?
> >
> > Something like...
> >
> > 		If (cd->clkdm) {
> > 			|= 1 << cd->clkdm->dep_bit;
> > 			atomic_set(&cd->wkdep_usecount, 0);
> > 		}
>
> That is going to fail silently.  If I'm understanding the problem
> that you're referring to correctly, it seems to me that in these
> circumstances, we want to fail loudly.  Especially now that all that
data
> is supposed to be autogenerated.  It is a symptom of a more profound
> problem that the end user should never see, no?

... so you are right. Failing silently is going to make it more difficult
to identify and fix. Maybe a WARN in else?

	if (cd->clkdm) {
		...
	} else
		WARN()

>
>
> - Paul

WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support
Date: Fri, 11 Feb 2011 10:34:34 +0530	[thread overview]
Message-ID: <74b7dfbe67e19da4358f7df0bc4dd8f1@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1102102135220.21991@utopia.booyaka.com>

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Friday, February 11, 2011 10:08 AM
> To: Rajendra Nayak
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; Benoit Cousson;
linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency
support
>
> On Fri, 11 Feb 2011, Rajendra Nayak wrote:
>
> > My initial version actually did have a check for cd->clkdm_name
instead
> > of cd->clkdm, and then I ran into aborts when a clkdm, though
belonging
> > to the right chip version, failed lookup (in clkdm_init) and left the
> > cd->clkdm pointer NULL. This however was due to the fact that the
> > clkdm_name populated was'nt matching the actual name,
>
> So those aborts were due to clockdomain or clockdomain dependency data
> that had errors that caused it not to have referential integrity?

Yes, I specifically found it when my script updates were actually
generating some non-matching (and hence wrong) clkdm_names.
The aborts actually helped me fix it...

>
> > Would it make sense to add an additional check here to avoid
> > an abort in case of mismatches in clkdm_name populated and
> > lookup's failing in clkdm_init?
> >
> > Something like...
> >
> > 		If (cd->clkdm) {
> > 			|= 1 << cd->clkdm->dep_bit;
> > 			atomic_set(&cd->wkdep_usecount, 0);
> > 		}
>
> That is going to fail silently.  If I'm understanding the problem
> that you're referring to correctly, it seems to me that in these
> circumstances, we want to fail loudly.  Especially now that all that
data
> is supposed to be autogenerated.  It is a symptom of a more profound
> problem that the end user should never see, no?

... so you are right. Failing silently is going to make it more difficult
to identify and fix. Maybe a WARN in else?

	if (cd->clkdm) {
		...
	} else
		WARN()

>
>
> - Paul

  reply	other threads:[~2011-02-11  5:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 13:17 [PATCH 0/3] OMAP4 static dependency support Rajendra Nayak
2011-02-07 13:17 ` Rajendra Nayak
2011-02-07 13:17 ` [PATCH 1/3] OMAP4: clockdomain: Add clkdm static dependency srcs Rajendra Nayak
2011-02-07 13:17   ` Rajendra Nayak
2011-02-07 13:17   ` [PATCH 2/3] OMAP4: CM: Add CM accesor api for bitwise control Rajendra Nayak
2011-02-07 13:17     ` Rajendra Nayak
2011-02-07 13:17     ` [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support Rajendra Nayak
2011-02-07 13:17       ` Rajendra Nayak
2011-02-08 23:52       ` Paul Walmsley
2011-02-08 23:52         ` Paul Walmsley
2011-02-11  2:06       ` Paul Walmsley
2011-02-11  2:06         ` Paul Walmsley
2011-02-11  4:04         ` Rajendra Nayak
2011-02-11  4:04           ` Rajendra Nayak
2011-02-11  4:37           ` Paul Walmsley
2011-02-11  4:37             ` Paul Walmsley
2011-02-11  5:04             ` Rajendra Nayak [this message]
2011-02-11  5:04               ` Rajendra Nayak
2011-02-11  5:14               ` Paul Walmsley
2011-02-11  5:14                 ` Paul Walmsley
2011-02-11  5:21                 ` Rajendra Nayak
2011-02-11  5:21                   ` Rajendra Nayak
2011-02-12 22:56                   ` Paul Walmsley
2011-02-12 22:56                     ` Paul Walmsley
2011-02-14 12:12                     ` Rajendra Nayak
2011-02-14 12:12                       ` Rajendra Nayak
2011-02-14 16:48                       ` Paul Walmsley
2011-02-14 16:48                         ` Paul Walmsley
2011-02-12 23:07                   ` Paul Walmsley
2011-02-12 23:07                     ` Paul Walmsley
2011-02-08 23:49 ` [PATCH 0/3] OMAP4 static " Paul Walmsley
2011-02-08 23:49   ` Paul Walmsley

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=74b7dfbe67e19da4358f7df0bc4dd8f1@mail.gmail.com \
    --to=rnayak@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    /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.