linux-kernel - RE: [PATCH V1] regulator: pv88080: Update regulator for PV88080 BB silicon 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8FA4409277D6E54680546B8811D85410029DF8071C@NB-EX-MBX01.diasemi.com>
Date:   Mon, 26 Sep 2016 03:03:51 +0000
From:   Eric Hyeung Dong Jeong <eric.jeong.opensource@...semi.com>
To:     Mark Brown <broonie@...nel.org>,
        Eric Hyeung Dong Jeong <eric.jeong.opensource@...semi.com>
CC:     LINUXKERNEL <linux-kernel@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Support Opensource <Support.Opensource@...semi.com>
Subject: RE: [PATCH V1] regulator: pv88080: Update regulator for PV88080 BB
 silicon support

On September 25, 2016 3:23 AM, Mark Brown wrote:

> On Wed, Sep 21, 2016 at 01:44:39PM +0900, Eric Jeong wrote:
> 
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id pv88080_dt_ids[] = {
> > +	{ .compatible = "pvs,pv88080-aa", .data = (void *)TYPE_PV88080_AA },
> > +	{ .compatible = "pvs,pv88080-ba", .data = (void *)TYPE_PV88080_BA },
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(of, pv88080_dt_ids); #endif
> 
> This doesn't list the old compatible string and therefore ends up breaking
> since the code defaults to assuming something it hasn't heard of is BB when
> it seems more likely that old DTs using the old compatible string will be for
> boards that also use the old silicon.  It would be much better practice to
> explicitly list the old compatible string and how we handle it, that won't break
> in future and avoids this kind of error.
> 
> Is it really not possible to read the chip revision from the device using ID
> registers?  That'd be even better.

The address of ID register is different between each chip revision.
So, It is difficult to read the chip revision from the device using ID register.
And, I will send a patch with old compatible.