public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	linux-pcmcia@lists.infradead.org, linux-kernel@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into dev_pm_ops.complete
Date: Mon, 9 Jul 2012 16:01:31 -0700	[thread overview]
Message-ID: <20120709160131.ed3d18d4.akpm@linux-foundation.org> (raw)
In-Reply-To: <201207100054.54535.chunkeey@googlemail.com>

On Tue, 10 Jul 2012 00:54:54 +0200
Christian Lamparter <chunkeey@googlemail.com> wrote:

> On Monday, July 09, 2012 11:59:39 PM Andrew Morton wrote:
> > On Fri, 6 Jul 2012 14:30:16 -0700
> > Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> > > On Fri, Jul 06, 2012 at 11:23:52PM +0200, Christian Lamparter wrote:
> > > > The idea of moving rebind procedure into pm.complete
> > > > was taken from the usb-subsystem, which has similar
> > > > problems with reattaching devices during/after
> > > > resume.
> > > > 
> > > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > > ---
> > > > To Greg:
> > > > 
> > > > I have submitted this patch back in March and again in May.
> > > > As far as I can tell it was neither rejected nor was it
> > > > accepted into linux-pcmcia.git since. So I'm asking you,
> > > > if you could take the patch instead... please.
> > > 
> > > There is a PCMCIA "team" who should be taking these types of patches.
> > > Why are they not doing so?
> > > 
> > 
> > Things are pretty quiet in pcmcia world, but Dominik does appear to
> > still be doing stuff.
> > 
> > I sometimes queue PCMCIA patches for people, but not this one.  The
> > changelog is just junk.  What does the patch do?  Why does it do it? 
> > What problems does it solve?  What are these mysterious "problems with
> > reattaching devices" to which it refers?  Useless...
> > 
> Well, that can be improved, but it is a bit tricky. 
> AFAICT the usb subsystem dealt with pm in this commit:
> 
> "commit 5096aedcd2eb70fbea83f09281f97f9ec973d9de
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date:   Tue Aug 12 14:34:14 2008 -0400
> 
>     USB: Don't rebind before "complete" callback
> 
> 	[...] We are not allowed to call drivers' probe routines during 
> 	a system sleep transition between the "prepare" and "complete"
> 	callbacks, but that's exactly what we do when a driver doesn't
> 	have full suspend/resume support. [...]"
> 
> And on the pcmcia subsystem we have this:
> 
> "commit 88b060d6c03fcb9e4d2018b4349954c4242a5c7f
> Author: Dominik Brodowski <linux@dominikbrodowski.net>
> Date:   Sat Jan 2 14:14:23 2010 +0100
> 
>     pcmcia: improve check for same card in slot after resume
> 
>     During a suspend/resume cycle, an user may change the card in the
>     PCMCIA/CardBus slot. [...]
>     
>     For CardBus devices, the PCI hotplug interface doesn't offer a "rescan"
>     facility which also _removes_ devices no longer to be found behind a
>     bridge. Therefore, remove and re-add all devices unconditionally."
> 
> Unfortunately, the "re-add" is currently done in the *pm resume* callback
> (socket_late_resume), but according to "USB: Don't rebind..." is not
> allowed to have it there, so the patch moves it into the *pm complete*
> callback. The Documentation/power/* contains mostly informations for
> drivers developers, but AFAICT it doesn't say much about the subsystem
> to which the device is connected should behave, so there's a bit of a
> "citing-gap".

hm, it does seem a bit of a screwup.

What's unclear to me is whether your patch fixes any observed runtime
problems.  Or adds any runtime problems, which looks to be a distinct
possibility.

> So, my question now: Would you accept the pcmcia patch if I add the
> "USB: Don't rebind..." as a reference to why the re-add needs to be
> done in complete? Or do you think that I should bug the pm people
> (and Alan - since he wrote that it is "not allowed") in this case
> so I can link their official answer to this patch?

Well I could grab it and give it a little bit of testing in linux-next.
But I'd be super-reluctant to send such a patch upstream without
detailed input from Alan/Greg/Rafael/Dominik/etc.


  reply	other threads:[~2012-07-09 23:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 21:23 [RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into dev_pm_ops.complete Christian Lamparter
2012-07-06 21:30 ` Greg KH
2012-07-09 21:59   ` Andrew Morton
2012-07-09 22:54     ` Christian Lamparter
2012-07-09 23:01       ` Andrew Morton [this message]
2012-07-09 23:07         ` Christian Lamparter
  -- strict thread matches above, loose matches on Subject: below --
2012-07-09 23:19 Christian Lamparter
2012-07-10 14:20 ` Alan Stern

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=20120709160131.ed3d18d4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=chunkeey@googlemail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=linux@dominikbrodowski.net \
    /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