From: Paul Walmsley <paul@pwsan.com>
To: Rajendra Nayak <rnayak@ti.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: Thu, 10 Feb 2011 21:37:57 -0700 (MST) [thread overview]
Message-ID: <alpine.DEB.2.00.1102102135220.21991@utopia.booyaka.com> (raw)
In-Reply-To: <3754d10e94217aa81846aa1d41fe0a9d@mail.gmail.com>
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?
> 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?
- Paul
WARNING: multiple messages have this Message-ID (diff)
From: paul@pwsan.com (Paul Walmsley)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support
Date: Thu, 10 Feb 2011 21:37:57 -0700 (MST) [thread overview]
Message-ID: <alpine.DEB.2.00.1102102135220.21991@utopia.booyaka.com> (raw)
In-Reply-To: <3754d10e94217aa81846aa1d41fe0a9d@mail.gmail.com>
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?
> 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?
- Paul
next prev parent reply other threads:[~2011-02-11 4:37 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 [this message]
2011-02-11 4:37 ` Paul Walmsley
2011-02-11 5:04 ` Rajendra Nayak
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=alpine.DEB.2.00.1102102135220.21991@utopia.booyaka.com \
--to=paul@pwsan.com \
--cc=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=rnayak@ti.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.