[PATCH v8 4/9] phy: fsl: Add Lynx 10G SerDes driver

[Sean Anderson]

On 12/12/22 18:37, Stephen Boyd wrote:
> Quoting Sean Anderson (2022-12-08 07:36:45)
>> On 12/6/22 21:17, Stephen Boyd wrote:
>> > Quoting Sean Anderson (2022-11-01 16:27:21)
>> >> On 11/1/22 16:10, Stephen Boyd wrote:
>> >> >> 
>> >> >> Oh, I remember why I did this. I need the reference clock for clk_hw_round_rate,
>> >> >> which is AFAICT the only correct way to implement round_rate.
>> >> >> 
>> >> > 
>> >> > Is the reference clk the parent of the clk implementing
>> >> > clk_ops::round_rate()?
>> >> 
>> >> Yes. We may be able to produce a given output with multiple reference
>> >> rates. However, the clock API provides no mechanism to say "Don't ask
>> >> for the parent clock to be rate X, you just tried it and the parent
>> >> clock can't support it." So instead, we loop over the possible reference
>> >> rates and pick the first one which the parent says it can round to.
>> >> 
>> > 
>> > Sorry, I'm lost. Why can't you loop over possible reference rates in
>> > determine_rate/round_rate clk op here?
>> 
>> This is what I do currently, but you need to have the parent clock to do
>> so. With your suggested method, we never actually get a struct clk(_hw)
>> which we can query for rate support.
> 
> The clk_hw for the parent is given to the determine_rate clk_op in the
> clk_rate_request structure. It's stored in the best_parent_hw pointer
> when the determine_rate function is called. Does that work for you?

Huh, I didn't realize that best_parent_hw was an input as well as an
output. The way it's documented, it makes it seem like this is set by
determine_rate.

I'm still not very happy with having to use an aux bus, as there are
plenty of other drivers which just register clocks with the top-level
device.

I will try and revisit this at some point, but the project has ended so
I'm not sure when I will find the time.

--Sean