Arm sub architectures missing clk_round_rate()
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
Quoted 9 lines · 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.has 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.
Quoted 7 lines
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.
cc'd Eric and Haojian, sorry should have done that in the first place.
Quoted 19 lines · Russell King - ARM Linux
Quoted 9 lines · 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.has 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.
Quoted 7 lines
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.
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · 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.has 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.
Quoted 7 lines
Quoted 4 lines
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