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
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
