From: Russ Dill <Russ.Dill@ti.com>
To: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Tony Lindgren <tony@atomide.com>,
linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
Koen Kooi <koen@dominion.thruhere.net>,
Matt Porter <mporter@ti.com>,
linux-omap@vger.kernel.org
Subject: Re: [RFC 1/7] capebus: Core capebus support
Date: Wed, 31 Oct 2012 17:55:29 -0700 [thread overview]
Message-ID: <CA+Bv8XZ2bMNvb77R5gqz7FVaCF1RtfTbiaCDE6iAKk3UUmnj6w@mail.gmail.com> (raw)
In-Reply-To: <EBB972CD-D9D9-4704-AABF-2DFCED584297@antoniou-consulting.com>
On Wed, Oct 31, 2012 at 3:07 PM, Pantelis Antoniou
<panto@antoniou-consulting.com> wrote:
>
> On Oct 31, 2012, at 11:55 PM, Russ Dill wrote:
>
>> On Wed, Oct 31, 2012 at 9:52 AM, Pantelis Antoniou
>> <panto@antoniou-consulting.com> wrote:
>>> Introducing capebus; a bus that allows small boards (capes) to connect
>>> to a complex SoC using simple expansion connectors.
>>>
>
> [snip]
>>> + if (drv) {
>>> + /* call the removed bus method (if added prev.) */
>>> + if (cape_dev->added) {
>>> + BUG_ON(cape_dev->bus == NULL);
>>> + BUG_ON(cape_dev->bus->ops == NULL);
>>> + if (cape_dev->bus->ops->dev_removed)
>>> + cape_dev->bus->ops->dev_removed(cape_dev);
>>> + cape_dev->added = 0;
>>> + }
>>
>> Is there any case where added will not track drv?
>
>
> Yes, there is a corner case here.
>
> There is the case where while the device is created there is no matching
> driver yet. Either that's the case of a not supported cape, or the
> cape driver hasn't been loaded yet.
>
> We do need the device to be created, so that the user can browse in the
> sysfs it's eeprom attributes.
>
> There's some further complications with runtime cape overrides, but
> that's the gist of it.
I'm trying to figure out how that would come about, here is where
added is set to 1:
+ /* all is fine... */
+ cape_dev->driver = drv;
+ cape_dev->added = 1;
This is after calling drv->probe, so drv is not null.
There is a brief time here where added is 0, but driver is not.
+ if (drv) {
+ /* call the removed bus method (if added prev.) */
+ if (cape_dev->added) {
+ BUG_ON(cape_dev->bus == NULL);
+ BUG_ON(cape_dev->bus->ops == NULL);
+ if (cape_dev->bus->ops->dev_removed)
+ cape_dev->bus->ops->dev_removed(cape_dev);
+ cape_dev->added = 0;
+ }
+ if (drv->remove) {
+ pm_runtime_get_sync(dev);
+ drv->remove(cape_dev);
+ pm_runtime_put_noidle(dev);
+ }
+ cape_dev->driver = NULL;
Is one of the remove or resume functions check added in this case?
WARNING: multiple messages have this Message-ID (diff)
From: Russ.Dill@ti.com (Russ Dill)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/7] capebus: Core capebus support
Date: Wed, 31 Oct 2012 17:55:29 -0700 [thread overview]
Message-ID: <CA+Bv8XZ2bMNvb77R5gqz7FVaCF1RtfTbiaCDE6iAKk3UUmnj6w@mail.gmail.com> (raw)
In-Reply-To: <EBB972CD-D9D9-4704-AABF-2DFCED584297@antoniou-consulting.com>
On Wed, Oct 31, 2012 at 3:07 PM, Pantelis Antoniou
<panto@antoniou-consulting.com> wrote:
>
> On Oct 31, 2012, at 11:55 PM, Russ Dill wrote:
>
>> On Wed, Oct 31, 2012 at 9:52 AM, Pantelis Antoniou
>> <panto@antoniou-consulting.com> wrote:
>>> Introducing capebus; a bus that allows small boards (capes) to connect
>>> to a complex SoC using simple expansion connectors.
>>>
>
> [snip]
>>> + if (drv) {
>>> + /* call the removed bus method (if added prev.) */
>>> + if (cape_dev->added) {
>>> + BUG_ON(cape_dev->bus == NULL);
>>> + BUG_ON(cape_dev->bus->ops == NULL);
>>> + if (cape_dev->bus->ops->dev_removed)
>>> + cape_dev->bus->ops->dev_removed(cape_dev);
>>> + cape_dev->added = 0;
>>> + }
>>
>> Is there any case where added will not track drv?
>
>
> Yes, there is a corner case here.
>
> There is the case where while the device is created there is no matching
> driver yet. Either that's the case of a not supported cape, or the
> cape driver hasn't been loaded yet.
>
> We do need the device to be created, so that the user can browse in the
> sysfs it's eeprom attributes.
>
> There's some further complications with runtime cape overrides, but
> that's the gist of it.
I'm trying to figure out how that would come about, here is where
added is set to 1:
+ /* all is fine... */
+ cape_dev->driver = drv;
+ cape_dev->added = 1;
This is after calling drv->probe, so drv is not null.
There is a brief time here where added is 0, but driver is not.
+ if (drv) {
+ /* call the removed bus method (if added prev.) */
+ if (cape_dev->added) {
+ BUG_ON(cape_dev->bus == NULL);
+ BUG_ON(cape_dev->bus->ops == NULL);
+ if (cape_dev->bus->ops->dev_removed)
+ cape_dev->bus->ops->dev_removed(cape_dev);
+ cape_dev->added = 0;
+ }
+ if (drv->remove) {
+ pm_runtime_get_sync(dev);
+ drv->remove(cape_dev);
+ pm_runtime_put_noidle(dev);
+ }
+ cape_dev->driver = NULL;
Is one of the remove or resume functions check added in this case?
next prev parent reply other threads:[~2012-11-01 0:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 16:52 [RFC 0/7] Capebus; a bus for SoCs using simple expansion connectors Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 16:52 ` [RFC 1/7] capebus: Core capebus support Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 21:55 ` Russ Dill
2012-10-31 21:55 ` Russ Dill
2012-10-31 22:07 ` Pantelis Antoniou
2012-10-31 22:07 ` Pantelis Antoniou
2012-11-01 0:55 ` Russ Dill [this message]
2012-11-01 0:55 ` Russ Dill
2012-10-31 16:52 ` [RFC 2/7] capebus: Add beaglebone board support Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-30 19:36 ` Tony Lindgren
2012-10-30 19:36 ` Tony Lindgren
2012-10-30 19:39 ` Tony Lindgren
2012-10-30 19:39 ` Tony Lindgren
2012-10-30 20:16 ` Pantelis Antoniou
2012-10-30 20:16 ` Pantelis Antoniou
2012-10-30 23:57 ` Tony Lindgren
2012-10-30 23:57 ` Tony Lindgren
2012-10-31 16:52 ` [RFC 3/7] capebus: Beaglebone generic cape support Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 16:52 ` [RFC 4/7] capebus: Beaglebone geiger " Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 16:52 ` [RFC 5/7] capebus: Beaglebone capebus DT update Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 16:52 ` [RFC 6/7] capebus: Document DT bindings Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 16:52 ` [RFC 7/7] capebus: Documentation; capebus-summary Pantelis Antoniou
2012-10-31 16:52 ` Pantelis Antoniou
2012-10-31 21:56 ` [RFC 0/7] Capebus; a bus for SoCs using simple expansion connectors Russ Dill
2012-10-31 21:56 ` Russ Dill
2012-10-31 22:03 ` Pantelis Antoniou
2012-10-31 22:03 ` Pantelis Antoniou
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=CA+Bv8XZ2bMNvb77R5gqz7FVaCF1RtfTbiaCDE6iAKk3UUmnj6w@mail.gmail.com \
--to=russ.dill@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=koen@dominion.thruhere.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mporter@ti.com \
--cc=panto@antoniou-consulting.com \
--cc=tony@atomide.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.