Hi Stephen,

On Sat, Apr 22, 2017 at 4:10 AM, Stephen Boyd <[email protected]> wrote:
> On 04/20, Yoshihiro Kaneko wrote:
>> From: Gaku Inami <[email protected]>
>>
>> In the resume process, there is the case that other drivers call
>> cs2000_enable before cs2000_resume is called. Since the order of
>> resume process is not guaranteed, it is needed to reset the clk
>> rate in any cases before cs2000 is used.
>>
>> Also, the current cs2000 driver is using resume_early function.
>> The using .resume_early is bad idea because the dependency with
>> other drivers is to be complicated.
>>
>> This patch adds to reset the clk rate in cs2000_enable and
>> changes to use from .resume_early to .resume.
>>
>> Signed-off-by: Gaku Inami <[email protected]>
>> Signed-off-by: Hiroyuki Yokoyama <[email protected]>
>> Signed-off-by: Yoshihiro Kaneko <[email protected]>
>> ---
>
> Was this supposed to be sent as a series? This is the second
> patch in the series?
>
> In what situation does a driver call clk_prepare() on the clocks
> in here before the device's resume callback is called? I would
> think that any devices that use the clks provided by this driver
> would be probe defered until the clks are registered, so they
> would be later in the suspend/resume list than this clk driver?

Deferred probing is used during driver initialization only.
This patch is about clock users calling into the clock API during the resume
procedure, before the clock provider has been resumed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply via email to