On 09/20/2013 10:31 PM, Viresh Kumar wrote:
> On 20 September 2013 22:04, Linus Walleij wrote:
>> In this case we have neither. So the cpufreq driver fails to
>> register. But the kernel used to survive in any case, as you
>> could call cpufreq_get() without a cpufreq driver registered.
>
> Aha,
On 09/20/2013 10:24 PM, Viresh Kumar wrote:
> On 20 September 2013 20:46, Srivatsa S. Bhat
> wrote:
>> I think show() and store() also suffer
>> from a similar fate. So do you think we need to add these checks there as
>> well?
>> I'm not sure, since I can't think of a situation in which show() o
On 20 September 2013 21:09, Linus Walleij wrote:
> On Fri, Sep 20, 2013 at 11:35 AM, Viresh Kumar
> wrote:
>
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1460,6 +1460,9 @@ unsigned int cpufreq_get(unsigned int cpu)
>> {
>> unsigned int ret_freq = 0;
>>
>> + if (cpufreq_disabled() ||
On Fri, Sep 20, 2013 at 7:05 PM, Viresh Kumar wrote:
> On 20 September 2013 21:09, Linus Walleij wrote:
>> On Fri, Sep 20, 2013 at 11:35 AM, Viresh Kumar
>> wrote:
>>
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1460,6 +1460,9 @@ unsigned int cpufreq_get(unsigned int cpu)
>>> {
>>> unsi
On 20 September 2013 22:04, Linus Walleij wrote:
> In this case we have neither. So the cpufreq driver fails to
> register. But the kernel used to survive in any case, as you
> could call cpufreq_get() without a cpufreq driver registered.
Aha, so exactly what I suspected in my first mail..
--
To
On 20 September 2013 20:46, Srivatsa S. Bhat
wrote:
> I think show() and store() also suffer
> from a similar fate. So do you think we need to add these checks there as
> well?
> I'm not sure, since I can't think of a situation in which show() or store()
> can be invoked before the cpufreq-driver
On Fri, Sep 20, 2013 at 5:40 PM, Linus Walleij wrote:
> On Fri, Sep 20, 2013 at 5:32 PM, Srivatsa S. Bhat
> wrote:
>> On 09/20/2013 08:51 PM, Linus Walleij wrote:
>
>>> sa11x0_pcmcia_init() which starts this chain of events is called as
>>> an fs_initcall(), see drivers/pcmcia/sa1100_generic.c
>>
On Fri, Sep 20, 2013 at 11:35 AM, Viresh Kumar wrote:
> commit 389fbc3c8ad7c339cd2d9572d73c355b7b967823
> Author: Viresh Kumar
> Date: Fri Sep 20 14:55:31 2013 +0530
>
> cpufreq: check cpufreq driver is valid and cpufreq isn't disabled
> in cpufreq_get()
>
> cpufreq_get() can be called
On Fri, Sep 20, 2013 at 11:35 AM, Viresh Kumar wrote:
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1460,6 +1460,9 @@ unsigned int cpufreq_get(unsigned int cpu)
> {
> unsigned int ret_freq = 0;
>
> + if (cpufreq_disabled() || !cpufreq_driver)
> + return -ENOENT;
> +
But gi
On Fri, Sep 20, 2013 at 10:49 AM, Viresh Kumar wrote:
> We used to return early in case policy isn't found, but now we went
> and took the lock..
Aha!
> Hmm... Remember I told you last time that I have another way of fixing
> it up, probably we need that now..
>
> I wanted to add another variab
On 09/20/2013 08:51 PM, Linus Walleij wrote:
> On Fri, Sep 20, 2013 at 10:49 AM, Viresh Kumar
> wrote:
>
>> We used to return early in case policy isn't found, but now we went
>> and took the lock..
>
> Aha!
>
>> Hmm... Remember I told you last time that I have another way of fixing
>> it up,
On 09/20/2013 03:05 PM, Viresh Kumar wrote:
> On 20 September 2013 14:19, Viresh Kumar wrote:
>> Hmm... Remember I told you last time that I have another way of fixing
>> it up, probably we need that now..
>>
>> I wanted to add another variable to reflect if a cpufreq_driver is registered
>> or no
On Fri, Sep 20, 2013 at 5:32 PM, Srivatsa S. Bhat
wrote:
> On 09/20/2013 08:51 PM, Linus Walleij wrote:
>> sa11x0_pcmcia_init() which starts this chain of events is called as
>> an fs_initcall(), see drivers/pcmcia/sa1100_generic.c
>
> But fs_initcall() comes after arch_initcall() right? (looking
On 09/20/2013 09:49 AM, Viresh Kumar wrote:
> On 19 September 2013 23:41, Srivatsa S. Bhat
> wrote:
>> But there was no code to set the per-cpu values to -1 to begin with. Since
>> the per-cpu variable was defined as static, it would have been initialized
>> to zero. Thus, we would never actually
On 20 September 2013 14:19, Viresh Kumar wrote:
> Hmm... Remember I told you last time that I have another way of fixing
> it up, probably we need that now..
>
> I wanted to add another variable to reflect if a cpufreq_driver is registered
> or not, and if not then return early from these routines
On 20 September 2013 14:11, Linus Walleij wrote:
> Any other idea why this patch is causing the issue?
I went into looking that patch in more detail
after my first reply, not as if I ran away from answering that :)
Probably yes.. I know what's causing it:
unsigned int cpufreq_get(unsigned int
On Thu, Sep 19, 2013 at 8:11 PM, Srivatsa S. Bhat
wrote:
> To confirm this, you can perhaps try out one commit before 474deff74 and see
> if it works for you. Or equivalently, you can apply the following patch
> (revert of 474deff74) over mainline and see if it works.
Actually I did try to rever
On Fri, Sep 20, 2013 at 10:39 AM, Viresh Kumar wrote:
> On 20 September 2013 14:03, Linus Walleij wrote:
>> I suspect this hunk from the patch may be the cause:
>>
>> + if (cpufreq_driver) {
>> + /* get the CPU */
>> + policy = per_cpu(cpufreq_cpu_data, cpu);
>>
On 20 September 2013 14:03, Linus Walleij wrote:
> I suspect this hunk from the patch may be the cause:
>
> + if (cpufreq_driver) {
> + /* get the CPU */
> + policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (policy)
> + kobject_g
On Thu, Sep 19, 2013 at 2:55 PM, Linus Walleij wrote:
> On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
> wrote:
>
>> So I think we should first identify (bisect?) and understand what caused that
>> particular change and then we will be in a position to evaluate whether the
>> patch you propose
On 19 September 2013 23:41, Srivatsa S. Bhat
wrote:
> But there was no code to set the per-cpu values to -1 to begin with. Since
> the per-cpu variable was defined as static, it would have been initialized
> to zero. Thus, we would never actually hit the BUG_ON() condition, since
> policy_cpu didn
On 09/19/2013 11:41 PM, Srivatsa S. Bhat wrote:
> On 09/19/2013 06:28 PM, Srivatsa S. Bhat wrote:
>> On 09/19/2013 06:25 PM, Linus Walleij wrote:
>>> On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
>>> wrote:
>>>
>> I don't really know if this is the right solution at all, so please
>> h
On 09/19/2013 06:28 PM, Srivatsa S. Bhat wrote:
> On 09/19/2013 06:25 PM, Linus Walleij wrote:
>> On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
>> wrote:
>>
> I don't really know if this is the right solution at all, so please
> help me out here... if you want that patch I can send it
On 19 September 2013 18:28, Srivatsa S. Bhat
wrote:
> On 09/19/2013 06:25 PM, Linus Walleij wrote:
>> The problem is not what it returns, the system seems to survive no matter
>> whether it returns 0 or 17 or whatever.
>>
>
> Of course. What I intended to say was that I don't recall recent kernel
On 09/19/2013 06:25 PM, Linus Walleij wrote:
> On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
> wrote:
>
I don't really know if this is the right solution at all, so please
help me out here... if you want that patch I can send it once
I understand this properly.
>>
>> IIRC, rece
On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
wrote:
>>> I don't really know if this is the right solution at all, so please
>>> help me out here... if you want that patch I can send it once
>>> I understand this properly.
>
> IIRC, recent kernels didn't return 0 or any error code when the !p
On 09/19/2013 04:11 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 18, 2013 11:21:45 PM Linus Walleij wrote:
>> Hi Rafael, Viresh,
>>
>> I'm seeing this problem and maybe you can help me out fixing it
>> properly:
>>
>> On some machines like the StrongARM SA1100 it seems that
>> cpufreq_get
On Thu, Sep 19, 2013 at 12:41 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 18, 2013 11:21:45 PM Linus Walleij wrote:
>> Hi Rafael, Viresh,
>>
>> I'm seeing this problem and maybe you can help me out fixing it
>> properly:
>>
>> On some machines like the StrongARM SA1100 it seems that
>>
On Wednesday, September 18, 2013 11:21:45 PM Linus Walleij wrote:
> Hi Rafael, Viresh,
>
> I'm seeing this problem and maybe you can help me out fixing it
> properly:
>
> On some machines like the StrongARM SA1100 it seems that
> cpufreq_get() can be called before the cpufreq driver and thus the
29 matches
Mail list logo
