linux-kernel - Re: [PATCH] ASoC: rt5677: Reintroduce I2C device IDs

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 25 Aug 2017 18:09:13 +0100
From:   John Keeping <john@...anate.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Tom Rini <trini@...sulko.com>, linux-kernel@...r.kernel.org,
        Bard Liao <bardliao@...ltek.com>,
        Oder Chiou <oder_chiou@...ltek.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        Mark Brown <broonie@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] ASoC: rt5677: Reintroduce I2C device IDs

On Fri, 25 Aug 2017 19:42:51 +0300, Andy Shevchenko wrote:

> On Fri, 2017-08-25 at 17:05 +0100, John Keeping wrote:
> > On Fri, 25 Aug 2017 10:24:26 -0400, Tom Rini wrote:  
> > > On Fri, Aug 25, 2017 at 04:56:47PM +0300, Andy Shevchenko wrote:  
> 
> > > > Apparently you are the one who tested the commit
> > > > 	89128534f925 ("ASoC: rt5677: Add ACPI support")
> > > > year ago.    
> > > 
> > > Yes.
> > >   
> > > > The commit states that ACPI properties that are used in Chromebook
> > > > Pixel
> > > > 2015 is non-standard (not the same as for DT).
> > > > 
> > > > However, DSDT shows the opposite!    
> > > 
> > > Interesting.  I'm not an ACPI person, I just tested what John came
> > > up
> > > with.  
> > 
> > And the patch adding this was the first (and still only) time I've
> > really looked at ACPI, so it's quite possible that I misunderstood
> > something at the time.  
> 
> Maybe.
> 
> > From memory, I think the particular problem I was referring to in the
> > commit message was that certain GPIOs were only defined by index and
> > not
> > by property name (specifically "plug-det-gpios", "mic-present-gpios"
> > and
> > "headphone-enable-gpios"), and having dumped DSDT just now I do not
> > see
> > those strings appearing anywhere.  
> 
> Exactly, and this part of the patch I'm _not_ talking about (it's pretty
> much good and working).
> 
> What I'm talking about is a specific function called
> 
> rt5677_read_acpi_properties()
> 
> in the rt5677.c codec driver.

Right, I don't see any reason why it shouldn't be possible to replace
that with rt5677_read_device_properties() given the DSDT I have.

I expect that exists because I was using the chromeos-3.14 tree as a
reference (which was the supported kernel on this hardware at the time),
but it looks like the unified device property API was added in 3.18 so
of course was not used there, and I did not realise that the device
property versions could be used here.

I'll try to find time to test this change over the weekend, if Tom
doesn't beat me to it!