LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Kristian H?gsberg <krh@bitplanet.net>,
	linux1394-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firewire: reread config ROM when device reset the bus
Date: Mon, 3 Mar 2008 21:54:48 -0800	[thread overview]
Message-ID: <20080304055448.GB15566@suse.de> (raw)
In-Reply-To: <47CC44DB.1060203@s5r6.in-berlin.de>

On Mon, Mar 03, 2008 at 07:35:07PM +0100, Stefan Richter wrote:
> I wrote:
>>> On Mon, Mar 3, 2008 at 11:51 AM, Stefan Richter
>>> <stefanr@s5r6.in-berlin.de> wrote:
> [...rewriting data of a device with children devices whose driver probe 
> accesses these data...]
>>>>  Maybe I should rather use fw-device.c::idr_rwsem instead of device.sem,
>>>>  to have better control over who takes the mutex when.  Could also be a
>>>>  new dedicated mutex but we don't want to end up with too many of  
>>>> them...
> [...]
>> Ah, wait, there is a 3rd reader: sbp2_probe's sbp2_scan_unit_dir.  So, 
>> using dev->sem is actually the nicest way for now.
>
> Or not.  The necessary protection for this and other driver->probe()s would 
> be the device->parent.sem, not the device->sem itself.  There seem to be 
> several ways how a driver probe may be entered (adding a device when the 
> driver is already there; attaching a driver when the device is already 
> there...) and I am not sure whether all these paths take the 
> device->parent.sem around the probe.  It doesn't seem to be always the 
> case.
>
> Greg, can you comment on this?

Hm, comment on what?  Ah, semaphore fun in the device.  If at all
possible, use your own, not the driver core as the locking there is a
bit "odd" as you have seen.  I think Alan Stern has some patches pending
to mess with it all to try to make it sane during the suspend/resume
path.

thanks,

greg k-h

  reply	other threads:[~2008-03-04  5:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-02 18:35 [PATCH] firewire: replace static ROM cache by allocated cache Stefan Richter
2008-03-03  0:48 ` [PATCH] firewire: reread config ROM when device reset the bus Stefan Richter
2008-03-03 16:17   ` Kristian Høgsberg
2008-03-03 16:51     ` Stefan Richter
2008-03-03 17:28       ` Kristian Høgsberg
2008-03-03 17:58         ` Stefan Richter
2008-03-03 18:35           ` Stefan Richter
2008-03-04  5:54             ` Greg KH [this message]
2008-03-04  8:39               ` Stefan Richter
2008-03-05  0:34     ` [PATCH update] " Stefan Richter
2008-03-05  0:48       ` Stefan Richter
2008-03-05 23:53         ` Stefan Richter
2008-03-06  1:25           ` Stefan Richter
2008-03-03 20:28   ` [PATCH] " Jarod Wilson

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=20080304055448.GB15566@suse.de \
    --to=gregkh@suse.de \
    --cc=krh@bitplanet.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /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;
as well as URLs for NNTP newsgroup(s).