svn commit: r314186 - head/sys/arm/at91

[Olivier Houchard]

On Thu, Feb 23, 2017 at 07:23:36PM -0500, Pedro Giffuni wrote:
> Hi;
> 
> > Il giorno 23 feb 2017, alle ore 19:05, Ian Lepore <ian at freebsd.org> ha scritto:
> > 
> > On Thu, 2017-02-23 at 23:48 +0000, Pedro F. Giffuni wrote:
> >> Author: pfg
> >> Date: Thu Feb 23 23:48:44 2017
> >> New Revision: 314186
> >> URL: https://svnweb.freebsd.org/changeset/base/314186
> >> 
> >> Log:
> >>   at91: double assignment.
> >>   
> >>   Found with:	coccinelle (da.cocci)
> >>   Suggested by:	cognet
> >> 
> >> Modified:
> >>   head/sys/arm/at91/at91sam9260.c
> >> 
> >> Modified: head/sys/arm/at91/at91sam9260.c
> >> =====================================================================
> >> =========
> >> --- head/sys/arm/at91/at91sam9260.c	Thu Feb 23 22:46:01 2017	
> >> (r314185)
> >> +++ head/sys/arm/at91/at91sam9260.c	Thu Feb 23 23:48:44 2017	
> >> (r314186)
> >> @@ -193,7 +193,6 @@ at91_clock_init(void)
> >>  	 */
> >>  	clk = at91_pmc_clock_ref("pllb");
> >>  	clk->pll_min_in    = SAM9260_PLL_B_MIN_IN_FREQ;		
> >> /*   1 MHz */
> >> -	clk->pll_max_in    = SAM9260_PLL_B_MAX_IN_FREQ;		
> >> /*   5 MHz */
> >>  	clk->pll_max_in    = 2999999;				
> >> /*  ~3 MHz */
> >>  	clk->pll_min_out   = SAM9260_PLL_B_MIN_OUT_FREQ;	/*  
> >> 70 MHz */
> >>  	clk->pll_max_out   = SAM9260_PLL_B_MAX_OUT_FREQ;	/*
> >> 130 MHz */
> >> 
> > 
> > Just looking at this by eye (but without digging out the at91 manuals)
> > I'd say this looks like fallout from a mismerge and the correct line to
> > keep would be the named constant.  Keeping the one that has actually
> > been in effect all this time isn't the same as keeping the right one,
> > and this deletion may remove the only clue someone might find when they
> > eventually get around to debugging this (if ever, the sam9260 is a
> > pretty old chip).
> > 
> > -- ian
> > 
> > 
> 
> According to SVN annotations it is not a mismerge:. The first line looks more technical but cognet@ stated from the second one is correct and matches the (long) initial comment.
> 
> It???s also what is in effective use now, so I wouldn???t change it unless someone with the hardware confirms first.
> 

As Pedro says, there's a large comment that says :
 * Fudge MAX pll in frequence down below 3.0 MHz to ensure
 * PMC alogrithm choose the divisor that causes the input clock
 * to be near the optimal 2 MHz per datasheet.  We know
 * we are going to be using this for the USB
 * clock at 96 MHz.
 * Causes no extra frequency deviation  for all recommended crystal
 * values.  See Note 1, table 40-16 SAM9260 doc.
 

So I just assumed it was OK. (And it's been that way since the code was
first submitted).

Olivier