linux-kernel - RE: [PATCH V2 1/2] mfd: da9063: Add device tree support

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] [day] [month] [year] [list]

Date:	Tue, 20 Jan 2015 13:23:23 +0000
From:	"Opensource [Steve Twiss]" <stwiss.opensource@...semi.com>
To:	Lee Jones <lee.jones@...aro.org>
CC:	Grant Likely <grant.likely@...aro.org>,
	Mark Brown <broonie@...aro.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Rob Herring <robh+dt@...nel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	DT <devicetree@...r.kernel.org>,
	"David Dajun Chen" <david.chen@...semi.com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Mark Rutland <mark.rutland@....com>,
	"Pawel Moll" <pawel.moll@....com>,
	Support Opensource <Support.Opensource@...semi.com>
Subject: RE: [PATCH V2 1/2] mfd: da9063: Add device tree support

On 20 January 2015 10:46 Lee Jones wrote:

[...]

> >  static const struct regmap_range da9063_ad_readable_ranges[] = {
> >  	{
> >  		.range_min = DA9063_REG_PAGE_CON,
> > @@ -203,6 +206,13 @@ static struct regmap_config da9063_regmap_config
> = {
> >  	.cache_type = REGCACHE_RBTREE,
> >  };
> >
> > +static const struct of_device_id da9063_dt_ids[] = {
> > +	{ .compatible = "dlg,da9063-ad", },
> > +	{ .compatible = "dlg,da9063-bb", },
> > +	{ .compatible = "dlg,da9063-ca", },
> 
> I'm still a bit bemused as to why these require their own compatible
> strings?  They are never matched (of_match_device()) on and it appears
> they can be dynamically told apart by poking.
> 

Yes: like you said. Why bother with a 2-letter variant code in the DT if the
driver's behaviour is automatic?

It was a design style decision on my side. I was being explicit in my definitions 
and I added the 2-letter code to handle (potential) differences in the way
platform data can be handled in the driver. There is nothing right now, I was just
considering the future and the ABI.

However, I've talked myself round this argument several times -- I guess the
explicit compatibility letters in the devices tree are jarring against the automatic
detection inside the driver.

I will remove the 2-letter extensions from the next submission.

Regards,
Steve