Arm sub architectures missing clk_round_rate()

Arm sub architectures missing clk_round_rate()

[Jonathan Cameron]

At least one Arm subarch (pxa) does no provide an implementation of this
function.  As far as I can see there is no way for a driver wishing to use
it to detect it's absence.  This is marked in clk.h as being optional
for 'Machine Class support'. Obvious solutions to this are:

1) It is effectively only usable by platform specific drivers as no
   more generic driver can know it is available.  Perhaps even a stub that
   returns an appropriate error would be acceptable.

2) It is not as optional as the header implies and should always be implemented
   if the rest of the clk framework is.

3) There should be some means of detecting its absense so that drivers can
   be dependant on its presene.

Which is the correct one?

This issue came up as a result of the thread
http://marc.info/?l=linux-iio&m=137026653516438&w=2
[PATCH RESEND V2 3/4] iio: frequency: adf4350: Add support for clock consumer framework
on linux-iio at vger.kernel.org


Thanks,

Jonathan

Arm sub architectures missing clk_round_rate()

[Jonathan Cameron]

At least one Arm subarch (pxa) does no provide an implementation of this
function.  As far as I can see there is no way for a driver wishing to use
it to detect it's absence.  This is marked in clk.h as being optional
for 'Machine Class support'. Obvious solutions to this are:

1) It is effectively only usable by platform specific drivers as no
   more generic driver can know it is available.  Perhaps even a stub that
   returns an appropriate error would be acceptable.

2) It is not as optional as the header implies and should always be implemented
   if the rest of the clk framework is.

3) There should be some means of detecting its absense so that drivers can
   be dependant on its presene.

Which is the correct one?

This issue came up as a result of the thread
http://marc.info/?l=linux-iio&m=137026653516438&w=2
[PATCH RESEND V2 3/4] iio: frequency: adf4350: Add support for clock consumer framework
on linux-iio@vger.kernel.org


Thanks,

Jonathan

Arm sub architectures missing clk_round_rate()

[Russell King - ARM Linux]

On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
> At least one Arm subarch (pxa) does no provide an implementation of this
> function.  As far as I can see there is no way for a driver wishing to use
> it to detect it's absence.  This is marked in clk.h as being optional
> for 'Machine Class support'. Obvious solutions to this are:
> 
> 1) It is effectively only usable by platform specific drivers as no
>    more generic driver can know it is available.  Perhaps even a stub that
>    returns an appropriate error would be acceptable.
> 
> 2) It is not as optional as the header implies and should always be implemented
>    if the rest of the clk framework is.
> 
> 3) There should be some means of detecting its absense so that drivers can
>    be dependant on its presene.
> 
> Which is the correct one?

The right answer is (2) now that we have things like the clk framework and
soo many users.

Re: Arm sub architectures missing clk_round_rate()

[Russell King - ARM Linux]

On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
> At least one Arm subarch (pxa) does no provide an implementation of this
> function.  As far as I can see there is no way for a driver wishing to use
> it to detect it's absence.  This is marked in clk.h as being optional
> for 'Machine Class support'. Obvious solutions to this are:
> 
> 1) It is effectively only usable by platform specific drivers as no
>    more generic driver can know it is available.  Perhaps even a stub that
>    returns an appropriate error would be acceptable.
> 
> 2) It is not as optional as the header implies and should always be implemented
>    if the rest of the clk framework is.
> 
> 3) There should be some means of detecting its absense so that drivers can
>    be dependant on its presene.
> 
> Which is the correct one?

The right answer is (2) now that we have things like the clk framework and
soo many users.

Arm sub architectures missing clk_round_rate()

[Jonathan Cameron]

cc'd Eric and Haojian, sorry should have done that in the first place.

On 06/08/2013 10:21 AM, Russell King - ARM Linux wrote:
> On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
>> At least one Arm subarch (pxa) does no provide an implementation of this
>> function.  As far as I can see there is no way for a driver wishing to use
>> it to detect it's absence.  This is marked in clk.h as being optional
>> for 'Machine Class support'. Obvious solutions to this are:
>>
>> 1) It is effectively only usable by platform specific drivers as no
>>    more generic driver can know it is available.  Perhaps even a stub that
>>    returns an appropriate error would be acceptable.
>>
>> 2) It is not as optional as the header implies and should always be implemented
>>    if the rest of the clk framework is.
>>
>> 3) There should be some means of detecting its absense so that drivers can
>>    be dependant on its presene.
>>
>> Which is the correct one?
> The right answer is (2) now that we have things like the clk framework and
> soo many users.

Re: Arm sub architectures missing clk_round_rate()

[Jonathan Cameron]

cc'd Eric and Haojian, sorry should have done that in the first place.

On 06/08/2013 10:21 AM, Russell King - ARM Linux wrote:
> On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
>> At least one Arm subarch (pxa) does no provide an implementation of this
>> function.  As far as I can see there is no way for a driver wishing to use
>> it to detect it's absence.  This is marked in clk.h as being optional
>> for 'Machine Class support'. Obvious solutions to this are:
>>
>> 1) It is effectively only usable by platform specific drivers as no
>>    more generic driver can know it is available.  Perhaps even a stub that
>>    returns an appropriate error would be acceptable.
>>
>> 2) It is not as optional as the header implies and should always be implemented
>>    if the rest of the clk framework is.
>>
>> 3) There should be some means of detecting its absense so that drivers can
>>    be dependant on its presene.
>>
>> Which is the correct one?
> The right answer is (2) now that we have things like the clk framework and
> soo many users.

Arm sub architectures missing clk_round_rate()

[Haojian Zhuang]

On Sat, Jun 8, 2013 at 5:21 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
>> At least one Arm subarch (pxa) does no provide an implementation of this
>> function.  As far as I can see there is no way for a driver wishing to use
>> it to detect it's absence.  This is marked in clk.h as being optional
>> for 'Machine Class support'. Obvious solutions to this are:
>>
>> 1) It is effectively only usable by platform specific drivers as no
>>    more generic driver can know it is available.  Perhaps even a stub that
>>    returns an appropriate error would be acceptable.
>>
>> 2) It is not as optional as the header implies and should always be implemented
>>    if the rest of the clk framework is.
>>
>> 3) There should be some means of detecting its absense so that drivers can
>>    be dependant on its presene.
>>
>> Which is the correct one?
>
> The right answer is (2) now that we have things like the clk framework and
> soo many users.

Yes, we need to fix it. I'll handle it.

Regards
Haojian

Re: Arm sub architectures missing clk_round_rate()

[Haojian Zhuang]

On Sat, Jun 8, 2013 at 5:21 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 08, 2013 at 09:57:17AM +0100, Jonathan Cameron wrote:
>> At least one Arm subarch (pxa) does no provide an implementation of this
>> function.  As far as I can see there is no way for a driver wishing to use
>> it to detect it's absence.  This is marked in clk.h as being optional
>> for 'Machine Class support'. Obvious solutions to this are:
>>
>> 1) It is effectively only usable by platform specific drivers as no
>>    more generic driver can know it is available.  Perhaps even a stub that
>>    returns an appropriate error would be acceptable.
>>
>> 2) It is not as optional as the header implies and should always be implemented
>>    if the rest of the clk framework is.
>>
>> 3) There should be some means of detecting its absense so that drivers can
>>    be dependant on its presene.
>>
>> Which is the correct one?
>
> The right answer is (2) now that we have things like the clk framework and
> soo many users.

Yes, we need to fix it. I'll handle it.

Regards
Haojian