On 08/05/14 01:16, Paul Walmsley wrote: >> It's true that the original patch changes the dpll behavior when an >> exact match is not found. However, I think our drivers always request an >> exact match, and in that case the original patch doesn't change the >> behavior in practice. >> >> In theory it's possible that a driver requests a non-exact clock from >> the dpll, and when it gets an error, it does something else. > > The path that worries me at the moment is the set-rate path. That calls > __clk_round_rate() (if the user hasn't called it already) and silently > tries to set the clock to the altered rate. Hmm, so you mean a driver could call set_rate, and presume it only uses exact rates the dpll can produce, and presumes that set_rate returns an error if the dpll cannot produce the requested rate? Isn't that what I said? If a driver has such behavior, I think it still doesn't work, as (correct me if I'm wrong) we always have the clk-divider after a dpll. And the clk-divider doesn't handle the error, so neither can the driver. Or what kind of scenario do you have in mind? Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
