On 03/12/15 20:29, Shawn Guo wrote:
> On Thu, Mar 12, 2015 at 12:43:40PM -0700, Stephen Boyd wrote:
>> On 03/12/15 10:20, Sebastian Andrzej Siewior wrote:
>>> On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
diff =
--- arch/arm/mach-imx/mach-imx6q.c
+++ /tmp/cocci-output-11792-b6
On Fri, Mar 13, 2015 at 09:20:10AM +0100, Sebastian Andrzej Siewior wrote:
> Hi Shawn,
>
> On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
>
> > We did not add a DT property for it, because there was already enough
> > info (clock configuration) in DT for kernel to figure it out.
> Cor
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
> We did not add a DT property for it, because there was already enough
> info (clock configuration) in DT for kernel to figure it out.
Correct. My understanding is whatever can be figured out without DT should
be done that way.
On Thu, Mar 12, 2015 at 12:43:40PM -0700, Stephen Boyd wrote:
> On 03/12/15 10:20, Sebastian Andrzej Siewior wrote:
> > On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
> >> diff =
> >> --- arch/arm/mach-imx/mach-imx6q.c
> >> +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
> >> @@ -211,7 +211,6
On 03/12/15 10:20, Sebastian Andrzej Siewior wrote:
> On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
>> diff =
>> --- arch/arm/mach-imx/mach-imx6q.c
>> +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
>> @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
>> * set bit IOMUXC_GPR
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
> diff =
> --- arch/arm/mach-imx/mach-imx6q.c
> +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
> @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
>* set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad
>* (exte
On Thu, Feb 19, 2015 at 01:32:33PM -0800, Mike Turquette wrote:
> Quoting Stephen Boyd (2015-02-06 11:30:18)
> > On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> > >
> > >> From what I can tell this code is
> > >> now broken be
Quoting Stephen Boyd (2015-02-06 11:30:18)
> On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> >
> >> From what I can tell this code is
> >> now broken because we made all clk getting functions (there's quite a
> >> few...) return
On 02/05/15 18:15, Stephen Boyd wrote:
> On 02/05/15 07:45, Quentin Lambert wrote:
>> On 05/02/2015 00:26, Stephen Boyd wrote:
If you want me to I can enlarge the search to other directories.
>>> Yes please do. And if you could share the coccinelle patch that would be
>>> great. Thanks.
>>>
>>
On 02/06/15 11:37, Russell King - ARM Linux wrote:
> On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
>> Why don't we make the legacy lookup more specific and actually indicate
>> "internal" for the con_id? Then the external clock would fail to be
>> found, but we can detect that case
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
> Why don't we make the legacy lookup more specific and actually indicate
> "internal" for the con_id? Then the external clock would fail to be
> found, but we can detect that case and figure out that it's not due to
> probe defer, but i
On 02/06/15 05:39, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
>
>> From what I can tell this code is
>> now broken because we made all clk getting functions (there's quite a
>> few...) return unique pointers every time they're called. It seems th
On 02/06/15 01:12, Julia Lawall wrote:
>
> On Fri, 6 Feb 2015, Quentin Lambert wrote:
>
>> On 06/02/2015 03:15, Stephen Boyd wrote:
>>> Thanks for the coccinelle patch. Thinking more about it, I don't think
>>> we care if the pointer is dereferenced because that would require a
>>> definition of st
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> On 02/05/15 16:42, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
> >> Actually we can bury the __clk_create_clk() inside
> >> __of_clk_get_from_provider(). We should also move __clk_g
On Fri, 6 Feb 2015, Quentin Lambert wrote:
>
> On 06/02/2015 03:15, Stephen Boyd wrote:
> > Thanks for the coccinelle patch. Thinking more about it, I don't think
> > we care if the pointer is dereferenced because that would require a
> > definition of struct clk and that is most likely not the
On 06/02/2015 03:15, Stephen Boyd wrote:
Thanks for the coccinelle patch. Thinking more about it, I don't think
we care if the pointer is dereferenced because that would require a
definition of struct clk and that is most likely not the case outside of
the clock framework. Did you scan the entir
On 02/05/15 07:45, Quentin Lambert wrote:
>
> On 05/02/2015 00:26, Stephen Boyd wrote:
>>> If you want me to I can enlarge the search to other directories.
>> Yes please do. And if you could share the coccinelle patch that would be
>> great. Thanks.
>>
> structclk.cocci is the coccinelle patch
> st
On 02/05/15 08:02, Quentin Lambert wrote:
> Sorry let me do that properly.
>
> On 05/02/2015 16:45, Quentin Lambert wrote:
>>
>> On 05/02/2015 00:26, Stephen Boyd wrote:
If you want me to I can enlarge the search to other directories.
>>> Yes please do. And if you could share the coccinelle pa
On 02/05/15 16:42, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
>> Actually we can bury the __clk_create_clk() inside
>> __of_clk_get_from_provider(). We should also move __clk_get() into there
>> because right now we have a hole where whoever call
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
> Actually we can bury the __clk_create_clk() inside
> __of_clk_get_from_provider(). We should also move __clk_get() into there
> because right now we have a hole where whoever calls
> of_clk_get_from_provider() never calls __clk_get() o
On 02/05/15 12:07, Stephen Boyd wrote:
> On 02/05/15 11:44, Sylwester Nawrocki wrote:
>> Hi Tomeu,
>>
>> On 23/01/15 12:03, Tomeu Vizoso wrote:
>>> int __clk_get(struct clk *clk)
>>> {
>>> - if (clk) {
>>> - if (!try_module_get(clk->owner))
>>> + struct clk_core *core = !clk ? NULL
On 02/05/15 11:44, Sylwester Nawrocki wrote:
> Hi Tomeu,
>
> On 23/01/15 12:03, Tomeu Vizoso wrote:
>> int __clk_get(struct clk *clk)
>> {
>> -if (clk) {
>> -if (!try_module_get(clk->owner))
>> +struct clk_core *core = !clk ? NULL : clk->core;
>> +
>> +if (core) {
>> +
On 05/02/15 20:44, Sylwester Nawrocki wrote:
>> +void __clk_put(struct clk *clk)
>> > +{
>> > + if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>> > + return;
>> > +
>> > + clk_core_put(clk->core);
>> > + kfree(clk);
>
> Why do we have kfree() here? clk_get() doesn't allocate the data structure
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
> int __clk_get(struct clk *clk)
> {
> - if (clk) {
> - if (!try_module_get(clk->owner))
> + struct clk_core *core = !clk ? NULL : clk->core;
> +
> + if (core) {
> + if (!try_module_get(core->owner))
>
Sorry let me do that properly.
On 05/02/2015 16:45, Quentin Lambert wrote:
On 05/02/2015 00:26, Stephen Boyd wrote:
If you want me to I can enlarge the search to other directories.
Yes please do. And if you could share the coccinelle patch that would be
great. Thanks.
structclk.cocci is the
On 05/02/2015 00:26, Stephen Boyd wrote:
If you want me to I can enlarge the search to other directories.
Yes please do. And if you could share the coccinelle patch that would be
great. Thanks.
structclk.cocci is the coccinelle patch
structclk-arm.patch is the result I got when applying it to
On 02/03/15 08:04, Quentin Lambert wrote:
> Hello,
> Julia asked me to have a look and see if I can help.
>
> I have found these three cases using Coccinnelle in the mach-omap2
> directory.
>
>
>
> ./arch/arm/mach-omap2/clkt_clksel.c
> @@ -67,7 +67,6 @@ static const struct clksel *_get_clksel_
>
Hello,
Julia asked me to have a look and see if I can help.
On 02/02/2015 23:50, Mike Turquette wrote:
Quoting Stephen Boyd (2015-02-02 14:35:59)
On 02/02/15 13:31, Julia Lawall wrote:
On Mon, 2 Feb 2015, Stephen Boyd wrote:
Julia,
Is there a way we can write a coccinelle script to check fo
* Tero Kristo [150203 00:49]:
> On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
> >
> >I think you got it right, just wanted to mention that we can and
> >probably should make the clk_get_parent_* calls in the consumer API to
> >return per-user clk instances but that we need to make sure first that
>
On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
On 02/02/2015 11:41 PM, Mike Turquette wrote:
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
On 02/02/2015 11:41 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
>>
* Mike Turquette [150202 14:51]:
> Quoting Tony Lindgren (2015-02-02 12:44:02)
> >
> > Thanks Tero, looks like your fix fixes all the issues I'm seeing with
> > commit 59cf3fcf9baf. That is noisy dmesg, dpll_abe_ck not locking
> > on 4430sdp, and off-idle not working for omap3.
> >
> > I could n
On 02/02/15 14:41, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>>
>>> AFAICT this doesn't break anything, but booting on OMAP3+ results in
>>> noisy WARNs.
>>>
>>> I think the correct fix is to replace clk_bypass and clk_ref po
Quoting Stephen Boyd (2015-02-02 14:35:59)
> On 02/02/15 13:31, Julia Lawall wrote:
> >
> > On Mon, 2 Feb 2015, Stephen Boyd wrote:
> >
> >> Julia,
> >>
> >> Is there a way we can write a coccinelle script to check for this? The
> >> goal being to find all drivers that are comparing struct clk poin
Quoting Tony Lindgren (2015-02-02 12:44:02)
> * Tero Kristo [150202 11:35]:
> > On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > >Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> > >
> > >AFAICT this doesn't break anything, but booting on OMAP3+ results in
> > >noisy WARNs.
> > >
> > >I think the cor
Quoting Tero Kristo (2015-02-02 11:32:01)
> On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >> Moves clock state to struct clk_core, but takes care to change as little
> >> API as
> >> possible.
> >>
> >> struct clk_hw still has a pointer to a struct
On 02/02/15 13:31, Julia Lawall wrote:
>
> On Mon, 2 Feb 2015, Stephen Boyd wrote:
>
>> Julia,
>>
>> Is there a way we can write a coccinelle script to check for this? The
>> goal being to find all drivers that are comparing struct clk pointers or
>> attempting to dereference them. There are probab
On Mon, 2 Feb 2015, Stephen Boyd wrote:
> On 02/01/15 13:24, Mike Turquette wrote:
> > Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >> Moves clock state to struct clk_core, but takes care to change as little
> >> API as
> >> possible.
> >>
> >> struct clk_hw still has a pointer to a struct clk,
* Tero Kristo [150202 11:35]:
> On 02/01/2015 11:24 PM, Mike Turquette wrote:
> >Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >
> >AFAICT this doesn't break anything, but booting on OMAP3+ results in
> >noisy WARNs.
> >
> >I think the correct fix is to replace clk_bypass and clk_ref pointers
> >wi
On 02/01/15 13:24, Mike Turquette wrote:
> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
>> Moves clock state to struct clk_core, but takes care to change as little API
>> as
>> possible.
>>
>> struct clk_hw still has a pointer to a struct clk, which is the
>> implementation's per-user clk instance,
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backward
* Mike Turquette [150201 13:27]:
> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> > Moves clock state to struct clk_core, but takes care to change as little
> > API as
> > possible.
> >
> > struct clk_hw still has a pointer to a struct clk, which is the
> > implementation's per-user clk instance,
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> Moves clock state to struct clk_core, but takes care to change as little API
> as
> possible.
>
> struct clk_hw still has a pointer to a struct clk, which is the
> implementation's per-user clk instance, for backwards compatibility.
>
> The struct clk
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, bu
44 matches
Mail list logo
