Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [External] RE: [RFC] Documentation: Add documentation for new
 performance_profile sysfs class
To:     "Limonciello, Mario" <Mario.Limonciello@dell.com>,
        =?UTF-8?Q?Barnab=c3=a1s_P=c5=91cze?= <pobrn@protonmail.com>
CC:     Hans de Goede <hdegoede@redhat.com>,
        Darren Hart <dvhart@infradead.org>,
        Andy Shevchenko <andy@infradead.org>,
        Mark Gross <mgross@linux.intel.com>,
        Mark Pearson <mpearson@lenovo.com>,
        Elia Devito <eliadevito@gmail.com>,
        Bastien Nocera <hadess@hadess.net>,
        Benjamin Berg <bberg@redhat.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20201003131938.9426-1-hdegoede@redhat.com>
 <20201003131938.9426-2-hdegoede@redhat.com>
 <DM6PR19MB263669227D122BB7699951E6FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
 <Mz2G7glm3yMTniKA6SHM011dDkTFF4_otICrMQfVLheopX8JMGSupPleyjyK8OY0tyUazu09nX7XhleBVdl4ozTCWXCPGyvV58Qc-UUTvig=@protonmail.com>
 <DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
From:   Mark Pearson <markpearson@lenovo.com>
Message-ID: <91a9bb74-49e7-0a8d-cbc1-3f1907293fa4@lenovo.com>
Date:   Mon, 5 Oct 2020 12:47:56 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2020-10-05 12:11 p.m., Limonciello, Mario wrote:
>>
>> Excuse my ignorance, but I don't really see why this interface would be tied
>> to
>> ACPI devices? Why is it not possible to write a driver that implements this
>> interface
>> and directly modifies device registers? Am I missing something obvious here?
>>
> 
> When implemented for the two vendors mentioned here, it would be using a
> proprietary "firmware API" implemented by those two vendors.  For example write
> arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to coordinate
> using undisclosed protocol to affect the platform changes desirable.
> 
> This is different in my mind from "kernel writes to a specific register" to set
> power properties of a specific device.
> 

Just curious on this point - isn't that (mostly) what all hardware does? 
You write to it and the device does "stuff" to achieve the required 
effect. Yes this is in proprietary firmware, but from my experience with 
hardware devices that's not uncommon these days anyway.

Let me know if I'm misunderstanding something here. I couldn't see the 
difference between a register written to via ACPI and one written to via 
some other protocol (SMBUS? or whatever)

Mark