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

[Guenter Roeck]

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.

[ ... ]

> > > +	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.

> > > +
> > > +	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 ?

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/