linux-kernel - Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

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: <32803199-239f-821c-7942-748436d53261@siemens.com>
Date:   Tue, 25 Apr 2017 18:12:12 +0200
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sascha Weisenberger <sascha.weisenberger@...mens.com>
Subject: Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

On 2017-04-25 15:47, Jan Kiszka wrote:
> On 2017-04-25 14:30, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>>> I'm not ACPI guru: How do we come from a SSDT to information that is
>>> carried in the DSDT so far? How can we overload wrong information in the
>>> built in DSDT this way? I'm all ears if we could fix our (and also the
>>> Galileo) quirks like that!
>>
>> SSDT stands for Secondary System Description table which basically adds
>> stuff to DSDT (the main table). Main use for SSDTs is to add devices but
>> you can also amend an existing device in DSDT by adding methods and so
>> forth.
>>
>> In case of Galileo the SPI1 host controller happens to miss _CRS method
>> so we can use SSDT like below to add that method there:
>>
>> Scope (\_SB.PCI0.SPI1)
>> {
>>     Name (_CRS, ResourceTemplate () {
>>         GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
>>                 "\\_SB.PCI0.GIP0.GPO", 0) {2} // MUX6_IO
>>     })
>>
>>     Name (_DSD, Package () {
>>         ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>         Package () {
>>             Package () {
>>                 "cs-gpios", Package () {^SPI1, 0, 0, 0},
>>             },
>>         }
>>     })
>> }
>>
>> This effectively means that once the table is parsed we find the SPI1
>> device with two new methods, _CRS and _DSD and the kernel is happy to
>> handle the rest.
>>
>> Important thing here is the
>>
>> 	Scope (\_SB.PCI0.SPI1)
>>
>> which allows us to reference an object in DSDT.
>>
> 
> Ah, now I recall: I think we discussed this before, but for a case were
> we would need to patch an existing element that contains one wrong value
> - that won't work. This case should, though. I'll give that a try.
> 

Works fine via an SSDT overlay - perfect!

Now, do you also a suggestion where to put that 5 V reference voltage
value that is hard-coded (via wiring) on the target boards for the ADC?
That is now device-specific, not a controller parameter. Is there an
ACPI-way to express such a parameter?

How would that be done for DTs?

Plan B would be hard-coding in the code for now, waiting for a second,
non-ACPI user to address it.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux