On Wed, Apr 05, 2017 at 04:02:01PM +0530, Amit Pundir wrote: > From: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> > > Some peripheral clocks, like the VEC (Video EnCoder) clock need to be set > to a precise rate (in our case 108MHz). With the current implementation, > where peripheral clocks are not allowed to forward rate change requests > to their parents, it is impossible to match this requirement unless the > bootloader has configured things correctly, or a specific rate has been > assigned through the DT (with the assigned-clk-rates property). > > Add a new field to struct bcm2835_clock_data to specify which parent > clocks accept rate change propagation, and support set rate propagation > in bcm2835_clock_determine_rate(). > > Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Eric Anholt <eric@xxxxxxxxxx> > Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> > (cherry picked from commit 155e8b3b0ee320ae866b97dd31eba8a1f080a772) > Signed-off-by: Amit Pundir <amit.pundir@xxxxxxxxxx> > --- > drivers/clk/bcm/clk-bcm2835.c | 67 ++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 63 insertions(+), 4 deletions(-) How does this match the stable kernel rules? I'm confused. Just because a distro/product includes patches in their tree, does not mean they are all applicable for stable kernel releases. Adding new device support in ways that is not just a simple quirk or other table addition, isn't ok. So this clk series isn't ok. I'm going to drop this whole patch series now. Can you please review it, and resend any that you think are applicable? thanks, greg k-h