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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

	Sören


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux