Re: [PATCH] clk: si570: Add a driver for SI570 oscillators

[Guenter Roeck]

On Fri, Sep 13, 2013 at 02:05:49PM -0700, Sören Brinkmann wrote:
> On Fri, Sep 13, 2013 at 12:48:22PM -0700, Guenter Roeck wrote:
> > On Fri, Sep 13, 2013 at 10:26:04AM -0700, Sören Brinkmann wrote:
> > > On Fri, Sep 13, 2013 at 10:00:05AM -0700, Guenter Roeck wrote:
> > > > On Thu, Sep 12, 2013 at 05:55:37PM -0700, Soren Brinkmann wrote:
> > > > > Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> > > > > The devices generate low-jitter clock signals and are reprogrammable via
> > > > > an I2C interface.
> > > > > 
> > > > > Cc: Guenter Roeck <linux@xxxxxxxxxxxx>
> > > > > Signed-off-by: Soren Brinkmann <soren.brinkmann@xxxxxxxxxx>
> > > > > ---
> > [ ... ]
> > 
> > > > > +	/* Applying a new frequency can take up to 10ms */
> > > > > +	usleep_range(10000, 10001);
> > > > 
> > > > One microsecond range doesn't really buy anything besides forcing the compiler
> > > > to generate extra code. Why not just use 10000 ?
> > > That's due to checkpatch. I originally had 'msleep(10)' and checkpatch
> > > suggested to use 'usleep_range()'. Then I put
> > > 'usleep_range(10000, 10000)' and checkpatch suggested to not use the
> > > same values for MIN and MAX, so I added the 1 to the MAX value.
> > > If it is considered to be safe and okay to put in MIN=MAX=10000, I'll
> > > change it accordingly.
> > > 
> > Guess what checkpatch means is to put in something resonable,
> > such as maybe (10000, 12000). (10000, 10001) just defeats checkpatch
> > which doesn't really provide any value. So either provide a reasonable
> > and acceptable range or use a single value.
> All right. I'll make it 10000 then, for MIN and MAX.
> 
> > 
> > [ ... ]
> > 
> > > > > +	match = of_match_node(clk_si570_of_match, client->dev.of_node);
> > > > > +	if (!match)
> > > > > +		return -EINVAL;
> > > > 
> > > > Seems unusual. Is this really needed ? It precludes the driver from being used
> > > > in a non-devicetree environment, for example. I would guess that there is a match
> > > > if client->dev.of_node is set. Otherwise, this code would be needed in every
> > > > driver supporting devicetree, and I don't recall seeing that.
> > > > 
> > > > > +	ddata = match->data;
> > > > > +
> > > > You should be able to get this information (ie the pointer to si570_device_data)
> > > > from id->driver_data. That would be more consistent with other i2c devices.
> > > I think I copied this approach from the other clk-si... driver. I'll
> > > do some research on your suggestion and change it. Could you point me to
> > > an example for your proposal?
> > > 
> > drivers/hwmon/lm90.c or drivers/hwmon/max6697.c.
> Thanks.
> 
> > 
> > > > > +
> > > > > +	if (of_property_read_u32(client->dev.of_node, "factory-fout",
> > > > > +				&factory_fout)) {
> > > > > +		dev_warn(&client->dev,
> > > > > +			"DTS does not contain factory-fout, using default\n");
> > > > 
> > > > Is that really worth a warning ?
> > > My understanding is, that the default output frequency is part-specific
> > > and required to calculate the frequency of the internal crystal. Hence,
> > > if you do not provide the correct default output frequency for your part, all
> > > frequencies generated by this driver will be off, unless the here used
> > > default matches your part. Please correct me if I'm wrong, otherwise, I
> > > think it's worth a warning.
> > > 
> > Maybe the property should be mandatory ?
> It's actually listed as required property in the documentation. I'll
> make it mandatory in the code as well and let probe() fail if it's not
> provided.
> 
Ok.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/