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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130913194822.GA12117@roeck-us.net>
Date:	Fri, 13 Sep 2013 12:48:22 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Sören Brinkmann <soren.brinkmann@...inx.com>
Cc:	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	Mike Turquette <mturquette@...aro.org>,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Hyun Kwon <hyunk@...inx.com>
Subject: Re: [PATCH] clk: si570: Add a driver for SI570 oscillators

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@...ck-us.net>
> > > Signed-off-by: Soren Brinkmann <soren.brinkmann@...inx.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.

[ ... ]

> > > +	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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/