All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 6/6] pinctrl: add pinctrl gpio binding support
Date: Tue, 29 May 2012 21:52:08 -0600	[thread overview]
Message-ID: <4FC59968.1060600@wwwdotorg.org> (raw)
In-Reply-To: <20120530030157.GA2235@b29396-Latitude-E6410>

On 05/29/2012 09:01 PM, Dong Aisheng wrote:
> On Sun, May 27, 2012 at 09:39:19AM -0600, Stephen Warren wrote:
>> On 05/26/2012 10:52 AM, Dong Aisheng wrote:
>>> On Fri, May 25, 2012 at 10:03 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 05/25/2012 07:36 AM, Dong Aisheng wrote:
>> ...
>>>> If we don't do that, [lock ranges[i].gc] I would argue that we
>>>> shouldn't store ranges[i].gc, since it might become invalid - I
>>>> believe the only use of it is withinthis function?
>>>>
>>> In my option, i think it's ok to store it since they're just some data
>>> to describe
>>> hw properties. The gpio function may become invalid but not data.
>>> Is it reasonable to you?
>>
>> The problem is that if someone tries to dereference the gc field, and
>> it's no longer valid, which could cause an OOPS. Perhaps we can get away
>> just with a comment in the struct definition indicating that this field
>> should only be used by drivers that provided the gc field directly
>> rather than having it set up by DT, but then why even store it when
>> creating the ranges from DT in that case?
>
> Yes, you're right.
> Maybe we could both not store the gc filed for DT (currently we did not see
> the need to store it for dt, right?) and add a comment in the struct definition
> as you said. For non-dt users the driver owner should manage that field
> correctly with lock since it's provided directly by driver.
> Is that ok?

Yes, that makes sense to me. Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Dong Aisheng <dongas86@gmail.com>
Cc: Dong Aisheng <b29396@freescale.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linus.walleij@stericsson.com,
	devicetree-discuss@lists.ozlabs.org, grant.likely@secretlab.ca,
	rob.herring@calxeda.com
Subject: Re: [PATCH v4 6/6] pinctrl: add pinctrl gpio binding support
Date: Tue, 29 May 2012 21:52:08 -0600	[thread overview]
Message-ID: <4FC59968.1060600@wwwdotorg.org> (raw)
In-Reply-To: <20120530030157.GA2235@b29396-Latitude-E6410>

On 05/29/2012 09:01 PM, Dong Aisheng wrote:
> On Sun, May 27, 2012 at 09:39:19AM -0600, Stephen Warren wrote:
>> On 05/26/2012 10:52 AM, Dong Aisheng wrote:
>>> On Fri, May 25, 2012 at 10:03 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 05/25/2012 07:36 AM, Dong Aisheng wrote:
>> ...
>>>> If we don't do that, [lock ranges[i].gc] I would argue that we
>>>> shouldn't store ranges[i].gc, since it might become invalid - I
>>>> believe the only use of it is withinthis function?
>>>>
>>> In my option, i think it's ok to store it since they're just some data
>>> to describe
>>> hw properties. The gpio function may become invalid but not data.
>>> Is it reasonable to you?
>>
>> The problem is that if someone tries to dereference the gc field, and
>> it's no longer valid, which could cause an OOPS. Perhaps we can get away
>> just with a comment in the struct definition indicating that this field
>> should only be used by drivers that provided the gc field directly
>> rather than having it set up by DT, but then why even store it when
>> creating the ranges from DT in that case?
>
> Yes, you're right.
> Maybe we could both not store the gc filed for DT (currently we did not see
> the need to store it for dt, right?) and add a comment in the struct definition
> as you said. For non-dt users the driver owner should manage that field
> correctly with lock since it's provided directly by driver.
> Is that ok?

Yes, that makes sense to me. Thanks.

  reply	other threads:[~2012-05-30  3:52 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25 13:36 [PATCH v4 1/6] gpio: fix a typo of comment message Dong Aisheng
2012-05-25 13:36 ` Dong Aisheng
2012-05-25 13:36 ` Dong Aisheng
2012-05-25 13:36 ` [PATCH v4 2/6] gpio: re-add of_node_to_gpiochip function Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-26  0:01   ` Grant Likely
2012-05-26  0:01     ` Grant Likely
2012-05-26  0:01     ` Grant Likely
2012-05-26 16:15     ` Dong Aisheng
2012-05-26 16:15       ` Dong Aisheng
2012-05-25 13:36 ` [PATCH v4 3/6] of: release node fix for of_parse_phandle_with_args Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-26  0:09   ` Grant Likely
2012-05-26  0:09     ` Grant Likely
2012-05-26  0:09     ` Grant Likely
2012-05-25 13:36 ` [PATCH v4 4/6] gpio: introduce lock mechanism for gpiochip_find Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-26  0:25   ` Grant Likely
2012-05-26  0:25     ` Grant Likely
2012-05-26  0:25     ` Grant Likely
2012-05-26 16:17     ` Dong Aisheng
2012-05-26 16:17       ` Dong Aisheng
2012-05-30  4:10     ` Dong Aisheng
2012-05-30  4:10       ` Dong Aisheng
2012-05-30  6:33       ` Grant Likely
2012-05-30  6:33         ` Grant Likely
2012-05-25 13:36 ` [PATCH v4 5/6] of: add of_parse_phandle_with_args_ext function Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 16:50   ` Stephen Warren
2012-05-25 16:50     ` Stephen Warren
2012-05-25 13:36 ` [PATCH v4 6/6] pinctrl: add pinctrl gpio binding support Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 13:36   ` Dong Aisheng
2012-05-25 17:03   ` Stephen Warren
2012-05-25 17:03     ` Stephen Warren
2012-05-25 17:03     ` Stephen Warren
2012-05-26 16:52     ` Dong Aisheng
2012-05-26 16:52       ` Dong Aisheng
2012-05-26 16:52       ` Dong Aisheng
2012-05-27 15:39       ` Stephen Warren
2012-05-27 15:39         ` Stephen Warren
2012-05-30  3:01         ` Dong Aisheng
2012-05-30  3:01           ` Dong Aisheng
2012-05-30  3:52           ` Stephen Warren [this message]
2012-05-30  3:52             ` Stephen Warren
2012-05-30  6:35     ` Grant Likely
2012-05-30  6:35       ` Grant Likely
2012-05-26  0:29   ` Grant Likely
2012-05-26  0:29     ` Grant Likely
2012-05-26  0:29     ` Grant Likely
2012-05-26 16:58     ` Dong Aisheng
2012-05-26 16:58       ` Dong Aisheng
2012-05-30  6:46       ` Grant Likely
2012-05-30  6:46         ` Grant Likely
2012-05-30  6:46         ` Grant Likely
2012-05-30  7:29         ` Dong Aisheng
2012-05-30  7:29           ` Dong Aisheng
2012-05-25 23:57 ` [PATCH v4 1/6] gpio: fix a typo of comment message Grant Likely
2012-05-25 23:57   ` Grant Likely
2012-05-25 23:57   ` Grant Likely

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=4FC59968.1060600@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.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.