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:
>> http://www.spini
+ 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
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 -0500, Rob Herring w
[...]
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
On 7 September 2016 at 22:48, Alan Stern wrote:
> On Tue, 6 Sep 2016, Ulf Hansson wrote:
>
>> On 5 September 2016 at 17:58, Alan Stern wrote:
>> > On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote:
>> >
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >>
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 the 4.8-rc5 kernel with the
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
---
While discussing an issue[1] related
On 18 September 2016 at 04:30, Alan Stern 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 the leds, so let's
>> add pm_run
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 suspends, but now at 2-second in
On 19 September 2016 at 20:02, Alan Stern wrote:
> On Mon, 19 Sep 2016, Ulf Hansson wrote:
>
>> On 18 September 2016 at 04:30, Alan Stern wrote:
>> > On Sat, 17 Sep 2016, Ulf Hansson wrote:
>> >
>> >> Each access of the parent device (usb device) needs
On 20 September 2016 at 16:09, Alan Stern 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 the rtsx driver really
> > >
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, but that's to be
>> ex
On 21 September 2016 at 16:45, Alan Stern 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" more information
>> > &g
y: Ritesh Raj Sarraf
Tested-by: Ritesh Raj Sarraf
Cc:
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index e0b8590..6e9c0f8 100644
--
sume the device 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: En
Enable runtime PM autosuspend for the rtsx_usb_sdmmc driver to avoid the
device being runtime suspended and runtime resumed between each request.
Let's use a default timeout of 50ms, to be consistent with other mmc hosts.
Cc: Ritesh Raj Sarraf
Cc: Alan Stern
Signed-off-by: Ulf Ha
n the
rtsx usb device is runtime resumed.
Reported-by: Ritesh Raj Sarraf
Tested-by: Ritesh Raj Sarraf
Signed-off-by: Alan Stern
Cc:
Signed-off-by: Ulf Hansson
---
drivers/memstick/host/rtsx_usb_ms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/memstick/host/rtsx_usb_ms.c
as it don't need
to claim the host for that execution path.
Cc: Ritesh Raj Sarraf
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
drivers/mmc/core/core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2553d90
ce is runtime resumed, when serving requests via the
->request() callback or changing settings via the ->set_param() callbacks.
Cc:
Cc: Ritesh Raj Sarraf
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
drivers/memstick/host/rtsx_usb_ms.c | 4
1 file changed, 4 insertions(+)
diff --gi
The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.
Tested-by: Ritesh Raj Sarraf
Cc:
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
On 13 October 2016 at 13:37, Ulf Hansson 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 children of the usb device.
>
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 10:50:49 Philipp Zabel
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
---
drivers/usb/musb/ux
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 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/host/
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 resumes.
> This sounds like somethi
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. The problem was why
>> > t
+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 wrote:
On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola wrote:
> On Wed, Mar 8,
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 # 2.6.37
> Cc: David Vrabel
> Signe
: linux-usb@vger.kernel.org
Signed-off-by: Ulf Hansson
---
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..db99edc 100644
--- a/drivers/mmc/host/vub300.c
+++ b/drivers
-by: Ulf Hansson
Cc: Alan Stern
---
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..4262296 100644
--- a/drivers/mmc/host/vub300.c
+++ b/drivers/mmc/host/vub300.c
On 27 September 2013 18:22, Alan Stern 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 us
le 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
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
There are a quite long history for ho
reventing
"runtime suspend" as a part of the system suspend, down to the driver
to decide instead 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
But, I am also sure
that quite many drivers should be able to cope with only runtime PM
callbacks. I have collected a bunch of examples that I can share, if
you are interested?
Kind regards
Ulf Hansson
>
> Thanks!
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open
On 14 November 2013 16:59, Alan Stern 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_resu
On 14 November 2013 18:57, Alan Stern 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 runti
On 15 November 2013 10:29, Bjørn Mork wrote:
> Ulf Hansson writes:
>
>> I think it is kind of strange to give provision to userspace to
>> control a "request based" power management feature in the kernel. Me
>> personally can't think of any good use cas
-by: Ulf Hansson
---
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/base/power/main.c
@@ -1350,6 +1350,9 @@ static int
cks, these can rely on the PM core to trigger a
runtime suspend (if the runtime PM usage count doesn't prevent it)
to inactivate their devices during system suspend.
Cc: Kevin Hilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
Some discussion started recently while I posted below patch:
, for those
who are deploying it.
Another advantage of "pm_runtime_no_prevent_suspend" is that driver's
can still easily prevent runtime suspend, during system suspend, by an
extra call to "pm_runtime_get*". Typically this could be used when the
device is configured for wake
On 18 November 2013 16:17, Alan Stern 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 wil
On 19 November 2013 16:35, Alan Stern 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.
On 20 November 2013 12:23, Pavel Machek wrote:
> On Wed 2013-11-20 11:52:05, Ulf Hansson wrote:
>> On 19 November 2013 16:35, Alan Stern wrote:
>> > On Tue, 19 Nov 2013, Ulf Hansson wrote:
>> >
>> >> At the moment, system PM is already affecting be
On 19 November 2013 19:03, Alan Stern wrote:
> On Tue, 19 Nov 2013, Kevin Hilman wrote:
>
>> Alan Stern writes:
>>
>> > On Tue, 19 Nov 2013, Ulf Hansson wrote:
>> >
>> >> At the moment, system PM is already affecting behaviour of runtime PM
>
On 14 November 2013 16:55, Alan Stern 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 an
Signed-off-by: Ulf Hansson
---
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/base/power/generic_ops.c
index 5ee030a..b8d31f6 10064
lemented inside CONFIG_PM instead of CONFIG_PM_RUNTIME.
A special thanks to Alan Stern who came up with this idea.
Cc: Kevin Hilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
drivers/base/power/generic_ops.c | 86 ++
include/linux/pm.h |
On 26 November 2013 00:10, Rafael J. Wysocki 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.
>&
ilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
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/pm.h
@@ -320,6 +320,15 @@ struct dev_pm
ppens for ->resume_early, ->thaw_early and
->restore_early.
Cc: Kevin Hilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
include/linux/pm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 7a830a7..8c6583a 100644
--- a/includ
On 26 November 2013 22:09, Alan Stern 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 wrote:
>> > > On Monday, November 25, 2013 01:40:21
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
Cc: Alan Stern
Signed-off-by: Ulf Hansson
---
drivers/base/power/generic_ops.c |4 ++--
include/linux/pm_runtime.h |
these callbacks.
Though, I don't think we need to prevent subsystems or power domains
from using them, they will only have 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
ycle than the core does.
I am not sure I understand how this will solve my issues (except the
minor "if that device has been runtime suspended, don't touch it" -
thing).
I will still have to have a complex power domain and still
drivers/buses need wrapper functions around their t
On 27 November 2013 17:05, Ulf Hansson 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
v, ab);
> if (err < 0)
> return err;
> --
> 1.8.2
>
> --
> 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
--
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
plat_suspend,
xhci_plat_resume)"
That should do the trick I 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 pl
gned-off-by: Rafael J. Wysocki
I am impressed , in this short period of time we managed to remove all
*PM_RUNTIME" configurations! Great work!
Reviewed-by: Ulf Hansson
> ---
> arch/arm/configs/ape6evm_defconfig |2 +-
> arch/arm/configs/armadillo800eva_defconfig |2 +
ASSIGN_RUNTIME_PM_OPS(msm_otg_runtime_suspend,
>> > > > msm_otg_runtime_resume,
>> > > > + msm_otg_runtime_idle)
>> > >
>> > > if the patch introducing assign_if() gets accepted, I'm ok with this
>> > >
On 28 February 2014 17:52, Greg Kroah-Hartman
wrote:
> On Fri, Feb 28, 2014 at 09:48:08AM +0100, Ulf Hansson wrote:
>> On 28 February 2014 00:44, Greg Kroah-Hartman
>> wrote:
>> > On Thu, Feb 27, 2014 at 03:41:31PM -0800, David Cohen wrote:
>> >> On Thu, Fe
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
>
> ---
>
> drivers/mmc/host/vub300.c | 6 +++---
> 1 file changed,
On 18 June 2015 at 14:17, Sudip Mukherjee 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
Thanks for the patch. It's although already been fixed on
ers/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| 1 +
> includ
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 for the delay. I was hoping to
On 18 January 2015 at 02:51, Nicholas Mc Guire wrote:
> Signed-off-by: Nicholas Mc Guire
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 the type
> of commretval wa
On 24 October 2017 at 17:03, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Ludovic Desroches
> Cc:
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 implementation.
> Replace two calls of the function "strncpy" by go
On 30 October 2017 at 13:15, Dan Carpenter wrote:
> On Mon, Oct 30, 2017 at 12:40:39PM +0100, Ulf Hansson wrote:
>> On 27 October 2017 at 21:31, SF Markus Elfring
>> wrote:
>> > From: Markus Elfring
>> > Date: Fri, 27 Oct 2017 21:21:40 +0200
>> >
>&g
On 31 October 2017 at 09:45, Dan Carpenter wrote:
> On Mon, Oct 30, 2017 at 02:03:13PM +0100, Ulf Hansson wrote:
>> On 30 October 2017 at 13:15, Dan Carpenter wrote:
>> > On Mon, Oct 30, 2017 at 12:40:39PM +0100, Ulf Hansson wrote:
>> >> On 27 October 20
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:
>> > From: Rafael J. Wysocki
>> >
>> > The check for "a
On 29 November 2017 at 09:21, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>
>> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>> wrote:
>> > Hi Geert-san,
>> >
>> >> From:
On 29 November 2017 at 10:43, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson wrote:
>> On 29 November 2017 at 09:21, Yoshihiro Shimoda
>> wrote:
>>>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>>
+ Kishon
On 30 November 2017 at 13:51, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
>>
>> On 29 November 2017 at 10:43, Geert Uytterhoeven
>> wrote:
>> > Hi Ulf,
>
>> Okay, so the problem
On 1 December 2017 at 12:03, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM
>>
>> + Kishon
>>
>> On 30 November 2017 at 13:51, Yoshihiro Shimoda
>> wrote:
>> > Hi,
>> >
>>
On 5 December 2017 at 04:23, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM
>>
>> On 1 December 2017 at 12:03, Yoshihiro Shimoda
>> wrote:
>
>> > Sure! I tested your patch, and then the following message
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 4:00 PM, Rafael J. Wysocki
>> > wrote:
>>
[...]
>>> 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
>>>
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
> ---
> drivers/mmc/host/vub300.c | 3 ++-
>
[...]
> +
> +/**
> + * 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
On 14 June 2017 at 03:53, Peter Chen 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
>> > + *
>> > + * @np: the devi
On 15 June 2017 at 08:58, Peter Chen wrote:
> On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote:
>> On 14 June 2017 at 03:53, Peter Chen wrote:
>> > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
>> >> [...]
>> >>
>> >
On 15 June 2017 at 11:11, Peter Chen 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 must
>> > be finishe
On 15 June 2017 at 12:06, Peter Chen wrote:
> On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
>> On 15 June 2017 at 11:11, Peter Chen wrote:
>> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
>> >> > Yes, you are right. This is the l
[...]
>> >
>> > 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 wi
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.
>
> ---
>
> drivers/mmc/host/bcm2835.c
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
Thanks, applied for next!
Kind r
On 24 October 2018 at 10:49, Kai-Heng Feng wrote:
> We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put}
> helpers to let memstick host support runtime pm.
>
> There's a small window between memstick_detect_change() and its queued
> work, memstick_check(). In this window the rpm coun
On 29 October 2018 at 17:31, Kai Heng Feng wrote:
>
>
>> On Oct 29, 2018, at 20:25, Ulf Hansson wrote:
>>
>> On 24 October 2018 at 10:49, Kai-Heng Feng
>> wrote:
>>> We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put}
>>>
On 30 October 2018 at 16:23, Kai Heng Feng wrote:
>
>
>> On Oct 30, 2018, at 21:03, Ulf Hansson wrote:
>>
>> On 29 October 2018 at 17:31, Kai Heng Feng
>> wrote:
>>>
>>>
>>>> On Oct 29, 2018, at 20:25, Ulf Hansson wrote:
>&
On 31 October 2018 at 07:59, Kai-Heng Feng wrote:
> In order to let host's parent device, rtsx_usb, to use USB remote wake
> up signaling to do card detection, it needs to be suspended. Hence it's
> necessary to add runtime PM support for the memstick host.
>
> To keep memstick host stays suspende
On Fri, 23 Nov 2018 at 07:06, Kai Heng Feng wrote:
>
> Hi Ulf,
>
> > On Nov 8, 2018, at 8:17 PM, Oleksandr Natalenko
> > wrote:
> >
> >> This is based on Ulf's work [1] [2].
> >> This patch series can keep rtsx_usb suspended, to save ~0.5W on Intel
> >> platforms and ~1.5W on AMD platforms.
> >>
On Fri, 23 Nov 2018 at 13:21, Ulf Hansson wrote:
>
> On Fri, 23 Nov 2018 at 07:06, Kai Heng Feng
> wrote:
> >
> > Hi Ulf,
> >
> > > On Nov 8, 2018, at 8:17 PM, Oleksandr Natalenko
> > > wrote:
> > >
> > >> This is based
92 matches
Mail list logo
