From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Ming Lei <ming.lei@canonical.com>
Cc: anish singh <anish198519851985@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] driver core: fix possible missing of device probe
Date: Fri, 28 Sep 2012 15:13:38 +0100 [thread overview]
Message-ID: <20120928141338.GI7916@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CACVXFVPs-TSoep3T_Pn3PgNEKWYSCiRNSnNOD66TcERUQJmmeA@mail.gmail.com>
On Fri, Sep 28, 2012 at 10:07:22PM +0800, Ming Lei wrote:
> On Fri, Sep 28, 2012 at 9:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> I do not mention threads case in one CPU because the context in
> >> which device_add runs will always see the driver added into
> >
> > There you go again. Look at my _much_ better description of the problem
> > and you'll notice that device_add has nothing to do with this.
>
> OK, I explain it again:
>
> CPU0 CPU1
>
> driver_register
> ...
> bus_add_driver
> driver_attach
> device_add(devb)
>
> klist_add_tail(klist_drivers)
>
> When device_add(devb) is run just after completion of driver_attach
> and before klist_add_tail(klist_drivers), the 'devb' can't be probed
> in device_add because the driver hasn't been added into bus,
> and it wasn't be probed in driver_attach because driver_attach didn't
> see the device in the bus.
>
> So the 'devb' will be missed to be probed in the bus, won't it?
Wait a moment. You're describing a *totally* *different* problem to
the problem I reported. I say - for the third time - that in the
problem I reported, device_add() has NOTHING TO DO WITH IT.
In your previous mail, you complained that my description did not
cover another case. I throw that back at you and say to you that
_your_ description does _not_ cover my case, but refers to a
_different_ problem which happens to be fixed by the _same_ fix.
To attach my "reported-by" to a problem description which is not
the problem that I reported is bad practice, and actually creates
a lie. If you wish to keep your problem description, then you must
remove my Reported-by, because the problem you refer to in your
description is not _my_ problem.
next prev parent reply other threads:[~2012-09-28 14:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 0:52 Ming Lei
2012-09-28 3:31 ` anish singh
2012-09-28 8:46 ` Russell King - ARM Linux
2012-09-28 10:50 ` anish singh
2012-09-28 13:42 ` Ming Lei
2012-09-28 13:55 ` Russell King - ARM Linux
2012-09-28 14:07 ` Ming Lei
2012-09-28 14:13 ` Russell King - ARM Linux [this message]
2012-09-28 14:22 ` Ming Lei
2012-09-28 13:53 ` Ming Lei
2012-09-28 14:31 ` anish kumar
2012-09-28 14:44 ` Ming Lei
2012-09-28 15:00 ` anish kumar
2012-09-28 15:05 ` Russell King - ARM Linux
2012-09-28 15:17 ` Ming Lei
2012-09-28 8:46 ` Russell King - ARM Linux
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=20120928141338.GI7916@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=anish198519851985@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®