[PATCH] clk: si570: Add a driver for SI570 oscillators
Sören Brinkmann
soren.brinkmann at xilinx.com
Fri Sep 13 17:05:49 EDT 2013
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 at roeck-us.net>
> > > > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > > > ---
> [ ... ]
>
> > > > + /* 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.
Sören
More information about the linux-arm-kernel
mailing list