Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

[...] >>> Index: linux-pm/drivers/base/power/domain.c >>> === >>> --- linux-pm.orig/drivers/base/power/domain.c >>> +++ linux-pm/drivers/base/power/domain.c >>> @@ -1048,8 +1048,9 @@ static int genpd_finish_suspend(struct d >>>

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 9 January 2018 at 17:28, Rafael J. Wysocki wrote: > On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: >> On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven >> wrote: >> > Hi Rafael, >> > >> > CC usb >> > >> > On Tue, Jan 9, 2018 at

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 5 December 2017 at 04:23, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM >> >> On 1 December 2017 at 12:03, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com>

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 1 December 2017 at 12:03, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM >> >> + Kishon >> >> On 30 November 2017 at 13:51, Yoshihiro Shimoda >> <yoshihiro.shim

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

+ Kishon On 30 November 2017 at 13:51, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM >> >> On 29 November 2017 at 10:43, Geert Uytterhoeven <ge...@linux-m68k.org> &

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 29 November 2017 at 10:43, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 29 November 2017 at 09:21, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com&

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 29 November 2017 at 09:21, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM >> >> On 28 November 2017 at 13:48, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com>

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 28 November 2017 at 13:48, Yoshihiro Shimoda wrote: > Hi Geert-san, > >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM >> >> Hi Rafael, Shimoda-san, >> >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki >> wrote:

Re: [PATCH] mmc: vub300: Use common code in __download_offload_pseudocode()

On 31 October 2017 at 09:45, Dan Carpenter <dan.carpen...@oracle.com> wrote: > On Mon, Oct 30, 2017 at 02:03:13PM +0100, Ulf Hansson wrote: >> On 30 October 2017 at 13:15, Dan Carpenter <dan.carpen...@oracle.com> wrote: >> > On Mon, Oct 30, 2017 at 12:40:39PM +0100,

Re: [PATCH] mmc: vub300: Use common code in __download_offload_pseudocode()

On 30 October 2017 at 13:15, Dan Carpenter <dan.carpen...@oracle.com> wrote: > On Mon, Oct 30, 2017 at 12:40:39PM +0100, Ulf Hansson wrote: >> On 27 October 2017 at 21:31, SF Markus Elfring >> <elfr...@users.sourceforge.net> wrote: >> > From: Markus El

Re: [PATCH] mmc: vub300: Use common code in __download_offload_pseudocode()

On 27 October 2017 at 21:31, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 27 Oct 2017 21:21:40 +0200 > > Add a jump target so that a specific string copy operation is stored > only once at the end of this function

Re: [PATCH] mmc: Convert timers to use timer_setup()

Cc: Ludovic Desroches <ludovic.desroc...@microchip.com> > Cc: Ulf Hansson <ulf.hans...@linaro.org> > Cc: Jaehoon Chung <jh80.ch...@samsung.com> > Cc: Carlo Caione <ca...@caione.org> > Cc: Kevin Hilman <khil...@baylibre.com> > Cc: Nicolas Pitre <n...@flux

Re: [PATCH] mmc: vub300: constify usb_device_id

On 9 August 2017 at 19:50, Arvind Yadav wrote: > usb_device_id are not supposed to change at runtime. All functions > working with usb_device_id provided by work with > const usb_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH 00/12] constify mmc_host_ops structures

On 29 July 2017 at 07:59, Julia Lawall wrote: > > The mmc_host_ops structure is only stored in the ops field of an > mmc_host structure, which is declared as const. Thus the mmc_host_ops > structure itself can be const. > > Done with the help of Coccinelle. > > --- > >

Re: [PATCH v15 2/7] power: add power sequence library

[...] >> > >> > Unlike the MMC design, there is no dts entry to indicate whether this >> > device needs pwrseq or not at this design, it will only carry out power >> > on sequence after matching. So, return -EPROBE_DEFER may not work since >> > this device may never need pwrseq. >> >> Then, how

Re: [PATCH v15 2/7] power: add power sequence library

On 15 June 2017 at 12:06, Peter Chen <hzpeterc...@gmail.com> wrote: > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote: >> On 15 June 2017 at 11:11, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wro

Re: [PATCH v15 2/7] power: add power sequence library

On 15 June 2017 at 11:11, Peter Chen <hzpeterc...@gmail.com> wrote: > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote: >> > Yes, you are right. This is the limitation for this power sequence >> > library, the registration for the 1st power sequence instance m

Re: [PATCH v15 2/7] power: add power sequence library

On 15 June 2017 at 08:58, Peter Chen <hzpeterc...@gmail.com> wrote: > On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote: >> On 14 June 2017 at 03:53, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Tue, Jun 13, 2017 at 12:24

Re: [PATCH v15 2/7] power: add power sequence library

On 14 June 2017 at 03:53, Peter Chen <hzpeterc...@gmail.com> wrote: > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote: >> [...] >> >> > + >> > +/** >> > + * of_pwrseq_on - Carry out power sequence on for device node >> &

Re: [PATCH v15 2/7] power: add power sequence library

[...] > + > +/** > + * of_pwrseq_on - Carry out power sequence on for device node > + * > + * @np: the device node would like to power on > + * > + * Carry out a single device power on. If multiple devices > + * need to be handled, use of_pwrseq_on_list() instead. > + * > + * Return a pointer to

Re: [PATCH] mmc: vub3000: add missing USB-descriptor endianness conversions

On 12 May 2017 at 12:03, Johan Hovold wrote: > Add the missing endianness conversions when printing the USB > device-descriptor idVendor and idProduct fields during probe. > > Signed-off-by: Johan Hovold Thanks, applied for next! Kind regards Uffe > --- >

Re: [PATCH] mmc: ushc: fix NULL-deref at probe

On 13 March 2017 at 13:40, Johan Hovold wrote: > Make sure to check the number of endpoints to avoid dereferencing a > NULL-pointer should a malicious device lack endpoints. > > Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver") > Cc: stable

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

+Alan On 15 March 2017 at 15:00, Diego Viola wrote: > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola wrote: >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola wrote: >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola

Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues

On 13 October 2016 at 13:37, Ulf Hansson <ulf.hans...@linaro.org> wrote: > The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing > an rtsx_usb device (managed by an mfd driver) while communicating with the > cards. The mmc/sd and memstick devices are chil

[PATCH 4/6] memstick: rtsx_usb_ms: Manage runtime PM when accessing the device

is runtime resumed, when serving requests via the ->request() callback or changing settings via the ->set_param() callbacks. Cc: <sta...@vger.kernel.org> Cc: Ritesh Raj Sarraf <r...@researchut.com> Cc: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hans.

[PATCH 1/6] mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused

rg> Cc: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/host/rtsx_usb_sdmmc.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 4106295..e0b8590 10

[PATCH 6/6] mmc: core: Don't power off the card when starting the host

don't need to claim the host for that execution path. Cc: Ritesh Raj Sarraf <r...@researchut.com> Cc: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/core/core.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(

[PATCH 5/6] mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend

rn <st...@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/host/rtsx_usb_sdmmc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 6e9c0f8..dc1abd1 100644 --- a/drivers/mmc/hos

[PATCH 3/6] memstick: rtsx_usb_ms: Runtime resume the device when polling for cards

e sure accesses is done when the rtsx usb device is runtime resumed. Reported-by: Ritesh Raj Sarraf <r...@researchut.com> Tested-by: Ritesh Raj Sarraf <r...@researchut.com> Signed-off-by: Alan Stern <st...@rowland.harvard.edu> Cc: <sta...@vger.kernel.org> Signed-off-by: Ulf H

[PATCH 2/6] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

t;r...@researchut.com> Tested-by: Ritesh Raj Sarraf <r...@researchut.com> Cc: <sta...@vger.kernel.org> Cc: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++ 1 file changed, 2 insertion

[PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues

when polling for cards Ulf Hansson (5): mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led memstick: rtsx_usb_ms: Manage runtime PM when accessing the device mmc: rtsx_usb_sdmmc: Enable runtime PM

Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

On 21 September 2016 at 16:45, Alan Stern <st...@rowland.harvard.edu> wrote: > On Wed, 21 Sep 2016, Ulf Hansson wrote: > >> > > My concern is also 2s autosuspend timeout which is set for the usb >> > > device. Somehow I feel we need to be able "share"

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 21 September 2016 at 13:10, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi Alan, > > On Tue, 2016-09-20 at 10:16 -0400, Alan Stern wrote: >> This is a lot better. No more I/O errors. >> >> We still have irregular suspends and resumes,

Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

On 20 September 2016 at 16:09, Alan Stern <st...@rowland.harvard.edu> wrote: > > On Tue, 20 Sep 2016, Ulf Hansson wrote: > > > >> I am wondering what you think would be a good autosuspend timeout in > > >> this case? It seems to me that the only thing t

Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

On 19 September 2016 at 20:02, Alan Stern <st...@rowland.harvard.edu> wrote: > On Mon, 19 Sep 2016, Ulf Hansson wrote: > >> On 18 September 2016 at 04:30, Alan Stern <st...@rowland.harvard.edu> wrote: >> > On Sat, 17 Sep 2016, Ulf Hansson wrote: >> > &

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 18 September 2016 at 03:42, Alan Stern wrote: > On Sat, 17 Sep 2016, Ritesh Raj Sarraf wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hello Alan, >> >> >> On Fri, 2016-09-16 at 17:40 -0400, Alan Stern wrote: >> > We're still getting runtime

Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

On 18 September 2016 at 04:30, Alan Stern <st...@rowland.harvard.edu> wrote: > On Sat, 17 Sep 2016, Ulf Hansson wrote: > >> Each access of the parent device (usb device) needs to be done in runtime >> resumed state. Currently this isn't case while changing t

[PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

Each access of the parent device (usb device) needs to be done in runtime resumed state. Currently this isn't case while changing the leds, so let's add pm_runtime_get_sync() and pm_runtime_put() around these calls. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- While disc

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 14 September 2016 at 17:19, Alan Stern wrote: > On Wed, 14 Sep 2016, Ritesh Raj Sarraf wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hello Ulf and Alan, >> >> On Fri, 2016-09-09 at 19:34 +0530, Ritesh Raj Sarraf wrote: >> > For #2, I'm building

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 7 September 2016 at 22:48, Alan Stern <st...@rowland.harvard.edu> wrote: > On Tue, 6 Sep 2016, Ulf Hansson wrote: > >> On 5 September 2016 at 17:58, Alan Stern <st...@rowland.harvard.edu> wrote: >> > On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote: >>

Re: [PATCH v6 0/8] power: add power sequence library

[...] We had an agreement that keep mmc's pwrseq framework unchanging. Unless Ulf and rob both agree to change. >>> >>> Why 2 separate approach for same problem ? >>> And I see this as possible duplication of code/functionality :) >> >> How the new kernel compatibles old dts? If we

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 5 September 2016 at 17:58, Alan Stern wrote: > On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On Sun, 2016-09-04 at 15:46 -0400, Alan Stern wrote: >> > >> > This is not the problem I was discussing with Ulf.

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On 25 August 2016 at 19:17, Alan Stern wrote: > Ulf: > > Ritesh has collected logs showing that his Realtek RTS5129 USB card > reader (drivers/mfd/rtsx_usb.c, drivers/mmc/host/rtsx_usb_sdmmc.c) goes > into runtime autosuspend every 3 seconds and then immediately

Re: [PATCH] mmc: host: vub300: don't print error when allocating urb fails

On 11 August 2016 at 23:03, Wolfram Sang wrote: > kmalloc will print enough information in case of failure. > > Signed-off-by: Wolfram Sang Thanks, applied for next! Kind regards Uffe > --- > drivers/mmc/host/vub300.c | 2 -- > 1

Re: [PATCH 08/12] doc: binding: pwrseq-usb-generic: add binding doc for generic usb power sequence driver

On 21 June 2016 at 23:26, Rob Herring wrote: > On Tue, Jun 21, 2016 at 10:11:17AM +0800, Peter Chen wrote: >> On Mon, Jun 20, 2016 at 11:16:07AM -0500, Rob Herring wrote: >> > On Mon, Jun 20, 2016 at 07:26:51PM +0800, Peter Chen wrote: >> > > On Fri, Jun 17, 2016 at 12:16:48PM

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

+ Arnd [...] >> >> Solution >> >> >> >> This is very similar to the MMC pwrseq behavior so the idea is to: >> >> 1. Move MMC pwrseq drivers to generic place, >> > >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside >> > of MMC. I think it is the wrong way to do

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On 6 May 2016 at 00:42, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> This is a different, second try to fix usb3503+lan on Odroid U3 board >> if it was initialized by bootloader (e.g. for TFTP boot). >> >> First version:

[PATCH] usb: musb: ux500: Fix NULL pointer dereference at system PM

a lacking validation of the corresponding ->driver_data pointer, which won't be set when the musb core driver fails to probe (or haven't yet been probed). Fixes: 7d32cdef5356 ("usb: musb: fail with error when no DMA...") Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> ---

Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB

On 9 December 2015 at 09:55, Arnd Bergmann wrote: > On Wednesday 09 December 2015 16:12:24 Peter Chen wrote: >> On Tue, Dec 08, 2015 at 09:24:03PM -0600, Rob Herring wrote: >> > On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote: >> > > On Tuesday 08 December 2015

Re: [BUG] mfd: rtsx_usb data corruption with SDCX microsd

On 20 October 2015 at 18:29, Marcus Overhagen wrote: > I tested again with a 4.2 kernel but the bug is still present and > happens more often. So far nobody has responded. > I don't know what to do, and whether it's related to usb, mmc or mfd. > Please advise. Sorry

Re: [PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

eroo.c | 10 +- > drivers/misc/mei/pci-me.c | 5 +++-- > drivers/misc/mei/pci-txe.c| 5 +++-- > drivers/usb/core/port.c | 6 ++ > drivers/usb/core/usb.c| 11 ++- > include/linux/device.h| 2 ++ > include/linux/pm.h

Re: [PATCH 2/2] mmc: vub300: Remove unneded semicolons

On 16 September 2015 at 11:30, Javier Martinez Canillas wrote: > They aren't needed and are just creating null statements so remove it. > > Signed-off-by: Javier Martinez Canillas Thanks, applied for next! Kind regards Uffe > > --- > >

Re: [PATCH v2 3/7] mmc: mediatek: build as module

On 18 June 2015 at 14:17, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: while building as module with mn10300 it failed with: warning: data definition has no type or storage class module_init(__driver##_init); Signed-off-by: Sudip Mukherjee su...@vectorindia.org Thanks for the

Re: [PATCH] mmc: vub300: remove unreachable return value handling

On 18 January 2015 at 02:51, Nicholas Mc Guire der.h...@hofr.at wrote: Signed-off-by: Nicholas Mc Guire der.h...@hofr.at Thanks! Applied for next. Kind regards Uffe --- The return value of wait_for_completion_timeout is unsigned long, as it is used here for wait_for_completion_timeout only

Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME

the tree. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com I am impressed , in this short period of time we managed to remove all *PM_RUNTIME configurations! Great work! Reviewed-by: Ulf Hansson ulf.hans...@linaro.org --- arch/arm/configs/ape6evm_defconfig |2 +- arch

Re: [PATCH 3/3] usb: phy: msm: use ASSIGN_*_PM_OPS variants

On 28 February 2014 17:52, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Feb 28, 2014 at 09:48:08AM +0100, Ulf Hansson wrote: On 28 February 2014 00:44, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Feb 27, 2014 at 03:41:31PM -0800, David Cohen wrote: On Thu

Re: [PATCH 3/3] usb: phy: msm: use ASSIGN_*_PM_OPS variants

point is certainly valid. I suppose the footprint of the kernel is nothing we should bother about? We have other solutions for that, right? Kind regards Ulf Hansson ick. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [RFC/PATCH 3/3] usb/xhci-plat: remove unnecessary #ifdef checks for CONFIG_PM_SLEEP

believe, without the need for changing the existing SET_SYSTEM_SLEEP_PM_OPS macro in patch1. Kind regards Ulf Hansson #ifdef CONFIG_OF static const struct of_device_id usb_xhci_of_match[] = { @@ -235,7 +230,7 @@ static struct platform_driver usb_xhci_driver = { .remove

Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

to know what the consequences are. :-) Maybe there could even be some cases were it actually makes good sense of using them for subsystems, even if I yet not have come a cross such a case. Kind regards Ulf Hansson Rafael -- To unsubscribe from this list: send the line unsubscribe linux-usb

Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

their the runtime PM callbacks to invoke them during system suspend, if they need them. In my view, I don't think your idea is conflict or can replace what I suggest. Both can improve the situation, but maybe for different scenarios. Kind regards Ulf Hansson Thanks! -- I speak only for myself. Rafael J

Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

On 27 November 2013 17:05, Ulf Hansson ulf.hans...@linaro.org wrote: We first need to clarify the terminology as that seems to be the source of the confusion to some extent at least. When I (or Alan presumably too) say a subsystem, I mean a bus type, a device type or a device class

Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. The PM core

[PATCH 1/2] PM / Runtime: Add second macro for definition of runtime PM callbacks

...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- include/linux/pm.h |9 + 1 file changed, 9 insertions(+) diff --git a/include/linux/pm.h b/include/linux/pm.h index a224c7f..7a830a7 100644 --- a/include/linux/pm.h +++ b/include/linux

[PATCH 2/2] PM / Sleep: Add macro to define common late/early system PM callbacks

for -resume_early, -thaw_early and -restore_early. Cc: Kevin Hilman khil...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- include/linux/pm.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux/pm.h b/include/linux/pm.h

Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

On 26 November 2013 22:09, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM

[PATCH] PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM

prevents the platform bus from by-passing driver's runtime PM callbacks while only CONFIG_PM_SLEEP and not CONFIG_PM_RUNTIME is being used. Cc: Kevin Hilman khil...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/power/generic_ops.c

[PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

CONFIG_PM instead of CONFIG_PM_RUNTIME. A special thanks to Alan Stern who came up with this idea. Cc: Kevin Hilman khil...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/power/generic_ops.c | 86

[PATCH] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks

st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/power/generic_ops.c | 130 ++ include/linux/pm.h |6 ++ 2 files changed, 136 insertions(+) diff --git a/drivers/base/power/generic_ops.c b/drivers

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 19 November 2013 19:03, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Nov 2013, Kevin Hilman wrote: Alan Stern st...@rowland.harvard.edu writes: On Tue, 19 Nov 2013, Ulf Hansson wrote: At the moment, system PM is already affecting behaviour of runtime PM since

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 14 November 2013 16:55, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 14 Nov 2013, Ulf Hansson wrote: If you want a driver to do the same thing for runtime PM and system suspend/resume, point its .suspend_late() and .runtime_suspend() to the same routine and analogously

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 19 November 2013 16:35, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Nov 2013, Ulf Hansson wrote: At the moment, system PM is already affecting behaviour of runtime PM since it is preventing runtime suspend during system suspend. Sure. And that behavior is documented. In any

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 20 November 2013 12:23, Pavel Machek pa...@ucw.cz wrote: On Wed 2013-11-20 11:52:05, Ulf Hansson wrote: On 19 November 2013 16:35, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Nov 2013, Ulf Hansson wrote: At the moment, system PM is already affecting behaviour of runtime PM

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 18 November 2013 16:17, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 18 Nov 2013, Ulf Hansson wrote: I favour the pm_runtime_no_prevent_suspend API approach, since it would mean a change in behaviour of the PM core. That's exactly why I don't favor it! :-) I will try my best

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

to implement it's own .suspend_late callback to handle this. Kind regards Ulf Hansson (Actually, it would be superior. The generic suspend_late approach will work even if the user writes on to /sys/.../power/control, whereas your approach won't work.) We have different view here. :-) Whether

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 14 November 2013 18:57, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 14 Nov 2013, Ulf Hansson wrote: Bear in mind that drivers _cannot_ rely on runtime PM to inactivate a device during system suspend. The user can always prevent a device from going into runtime suspend

[PATCH 1/2] PM / Runtime: Fix error path for prepare

Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/power/main.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index ee039af..2a1b06a 100644 --- a/drivers/base/power/main.c +++ b/drivers

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

of the PM core? Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

Ulf Hansson Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On 14 November 2013 16:59, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 14 Nov 2013, Ulf Hansson wrote: The reason for doing things the way they are is to avoid races between system PM callbacks and runtime PM callbacks. We don't want to have a runtime_resume routine powering up

[RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

their system suspend tasks, those can easily just restore the runtime PM usage count, pm_runtime_put_sync(), once done with it's suspend operations, which then will inactivate the device. Cc: Kevin Hilman khil...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ulf Hansson ulf.hans

[PATCH] mmc: vub300: Move away from using deprecated APIs

-usb@vger.kernel.org Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu --- drivers/mmc/host/vub300.c | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-) diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c index e9028ad

Re: [PATCH 10/27] mmc: vub300: Remove redundant suspend and resume callbacks

On 27 September 2013 18:22, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 26 Sep 2013, Ulf Hansson wrote: Suspend and resume of cards are handled by the protocol layer and consequently the mmc_suspend|resume_host APIs are marked as deprecated. While moving away from using

[PATCH 10/27] mmc: vub300: Remove redundant suspend and resume callbacks

tony.ol...@elandigitalsystems.com Cc: linux-usb@vger.kernel.org Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/mmc/host/vub300.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c index e9028ad

Re: [PATCH 03/10] usb: phy: ab8500-usb: add transceiver clock control

-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Acked-by: Ulf Hansson ulf.hans...@linaro.org