Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] clk: export __clk_get_hw for re-use in others

1 view
Skip to first unread message

SeongJae Park

unread,
Jan 19, 2014, 1:00:01 AM1/19/14
to
Following build comes while modprobe process:
> ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2

Export the symbol to fix it and for other part's usecase.

Signed-off-by: SeongJae Park <sj38...@gmail.com>
---
drivers/clk/clk.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2b38dc9..3883fba 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk->hw;
}
+EXPORT_SYMBOL_GPL(__clk_get_hw);

u8 __clk_get_num_parents(struct clk *clk)
{
--
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Greg KH

unread,
Jan 19, 2014, 12:40:02 PM1/19/14
to
On Sun, Jan 19, 2014 at 02:55:07PM +0900, SeongJae Park wrote:
> Following build comes while modprobe process:
> > ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
> > make[2]: *** [__modpost] Error 1
> > make[1]: *** [modules] Error 2
>
> Export the symbol to fix it and for other part's usecase.
>
> Signed-off-by: SeongJae Park <sj38...@gmail.com>
> ---
> drivers/clk/clk.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 2b38dc9..3883fba 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
> {
> return !clk ? NULL : clk->hw;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_hw);

__ functions should usually only be for "internal" use, why does this
get exported to modules? Why not just put it in a .h file?

greg k-h

Mike Turquette

unread,
Jan 20, 2014, 2:50:01 AM1/20/14
to
On Sun, Jan 19, 2014 at 9:37 AM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Sun, Jan 19, 2014 at 02:55:07PM +0900, SeongJae Park wrote:
>> Following build comes while modprobe process:
>> > ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
>> > make[2]: *** [__modpost] Error 1
>> > make[1]: *** [modules] Error 2
>>
>> Export the symbol to fix it and for other part's usecase.
>>
>> Signed-off-by: SeongJae Park <sj38...@gmail.com>
>> ---
>> drivers/clk/clk.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 2b38dc9..3883fba 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
>> {
>> return !clk ? NULL : clk->hw;
>> }
>> +EXPORT_SYMBOL_GPL(__clk_get_hw);
>
> __ functions should usually only be for "internal" use, why does this
> get exported to modules? Why not just put it in a .h file?

It was originally used only within the clock core but it is sensible
for hardware-specific clock drivers to use this as well. I plan to
audit all of the double-underscore functions in
include/linux/clk-provider.h for 3.15.

Regards,
Mike

SeongJae Park

unread,
Jan 20, 2014, 3:10:02 AM1/20/14
to
Thank you very much for answering about it, Mike.

I agree Greg's indication and think Mike's explanation is reasonable.

So, I think it would be better to just export the symbol now
because it would be easier for future functions renaming and
similar issues were solved in this way in past:
https://lkml.org/lkml/2013/4/15/50

Or, maybe I can change the client code of __clk_get_hw to not use the function.

What do you think would be better to fix this build error? Or, do you
have better idea?
I will respect your opinion.

Thanks and Regards.
SeongJae Park.

SeongJae Park

unread,
Jan 21, 2014, 10:10:02 PM1/21/14
to
Dear Greg, Mike,

May I ask your answer or other opinion, please?

Greg KH

unread,
Jan 22, 2014, 12:00:02 AM1/22/14
to
On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
> Dear Greg, Mike,
>
> May I ask your answer or other opinion, please?

It's the middle of the merge window, it's not time for new development,
or much time for free-time for me, sorry. Feel free to fix it the best
way you know how.

SeongJae Park

unread,
Jan 22, 2014, 12:30:02 AM1/22/14
to
On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>> Dear Greg, Mike,
>>
>> May I ask your answer or other opinion, please?
>
> It's the middle of the merge window, it's not time for new development,
> or much time for free-time for me, sorry. Feel free to fix it the best
> way you know how.

Oops, I've forgot about the merge window. Thank you very much for your
kind answer.
Sorry if I bothered you while you're in busy time.
Because the build problem is not a big deal because it exists only in
-next tree,
I will wait until merge window be closed and then fix it again if it
still exist.

SeongJae Park.

Stephen Boyd

unread,
Jan 22, 2014, 1:00:02 PM1/22/14
to
On 01/21/14 21:23, SeongJae Park wrote:
> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>> Dear Greg, Mike,
>>>
>>> May I ask your answer or other opinion, please?
>> It's the middle of the merge window, it's not time for new development,
>> or much time for free-time for me, sorry. Feel free to fix it the best
>> way you know how.
> Oops, I've forgot about the merge window. Thank you very much for your
> kind answer.
> Sorry if I bothered you while you're in busy time.
> Because the build problem is not a big deal because it exists only in
> -next tree,
> I will wait until merge window be closed and then fix it again if it
> still exist.
>

I've already sent a patch that exports this and other clock provider
functions. Please use this one:

https://patchwork.kernel.org/patch/3507921/

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Mike Turquette

unread,
Jan 22, 2014, 1:20:02 PM1/22/14
to
On Wed, Jan 22, 2014 at 9:59 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 01/21/14 21:23, SeongJae Park wrote:
>> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>>> Dear Greg, Mike,
>>>>
>>>> May I ask your answer or other opinion, please?
>>> It's the middle of the merge window, it's not time for new development,
>>> or much time for free-time for me, sorry. Feel free to fix it the best
>>> way you know how.
>> Oops, I've forgot about the merge window. Thank you very much for your
>> kind answer.
>> Sorry if I bothered you while you're in busy time.
>> Because the build problem is not a big deal because it exists only in
>> -next tree,
>> I will wait until merge window be closed and then fix it again if it
>> still exist.
>>
>
> I've already sent a patch that exports this and other clock provider
> functions. Please use this one:
>
> https://patchwork.kernel.org/patch/3507921/

I'm going to take Stephen's patch into a fixes branch and send it as
part of a pull request. Maybe -rc1 or -rc2 at the latest.

Thanks all.

Regards,
Mike

SeongJae Park

unread,
Jan 22, 2014, 9:10:02 PM1/22/14
to
On Thu, Jan 23, 2014 at 3:11 AM, Mike Turquette <mturq...@linaro.org> wrote:
> On Wed, Jan 22, 2014 at 9:59 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
>> On 01/21/14 21:23, SeongJae Park wrote:
>>> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>>>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>>>> Dear Greg, Mike,
>>>>>
>>>>> May I ask your answer or other opinion, please?
>>>> It's the middle of the merge window, it's not time for new development,
>>>> or much time for free-time for me, sorry. Feel free to fix it the best
>>>> way you know how.
>>> Oops, I've forgot about the merge window. Thank you very much for your
>>> kind answer.
>>> Sorry if I bothered you while you're in busy time.
>>> Because the build problem is not a big deal because it exists only in
>>> -next tree,
>>> I will wait until merge window be closed and then fix it again if it
>>> still exist.
>>>
>>
>> I've already sent a patch that exports this and other clock provider
>> functions. Please use this one:
>>
>> https://patchwork.kernel.org/patch/3507921/
>
> I'm going to take Stephen's patch into a fixes branch and send it as
> part of a pull request. Maybe -rc1 or -rc2 at the latest.

Got it. Thank you for let me know :)

David Rientjes

unread,
Jan 29, 2014, 2:30:02 AM1/29/14
to
On Wed, 22 Jan 2014, SeongJae Park wrote:

> Oops, I've forgot about the merge window. Thank you very much for your
> kind answer.
> Sorry if I bothered you while you're in busy time.
> Because the build problem is not a big deal because it exists only in
> -next tree,

This problem exists in Linus's tree, not only in -next.

SeongJae Park

unread,
Jan 29, 2014, 3:20:02 AM1/29/14
to
Hi,

On Wed, Jan 29, 2014 at 4:29 PM, David Rientjes <rien...@google.com> wrote:
> On Wed, 22 Jan 2014, SeongJae Park wrote:
>
>> Oops, I've forgot about the merge window. Thank you very much for your
>> kind answer.
>> Sorry if I bothered you while you're in busy time.
>> Because the build problem is not a big deal because it exists only in
>> -next tree,
>
> This problem exists in Linus's tree, not only in -next.

Yes, it looks like the problem caused commit is in Linus's tree
now(Maybe between this merge window).

But, because similar and better patch was
submitted(https://patchwork.kernel.org/patch/3507921/)
before mine by Stephen and Mike said he will merge the patch during rc1 or rc2,
looks like there is nothing we can rather than just waiting rc1 or rc2.

If there is anything I am thinking or doing wrong, please let me know.

Thanks and Regards,
SeongJae Park
0 new messages