On 12 April 2017 at 18:47, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > 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? Ack. I'll review the series and resend the relevant patches. Regards, Amit Pundir > > thanks, > > greg k-h