From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2D89C2BB48 for ; Thu, 17 Dec 2020 15:19:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9802D239A1 for ; Thu, 17 Dec 2020 15:19:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726291AbgLQPTD (ORCPT ); Thu, 17 Dec 2020 10:19:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgLQPTD (ORCPT ); Thu, 17 Dec 2020 10:19:03 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29290C061794; Thu, 17 Dec 2020 07:18:23 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id g20so38437373ejb.1; Thu, 17 Dec 2020 07:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mnERU2iVdKzX9RvnDhk1NZIz1JFzT1zaRxfnkrOcGto=; b=R1LEPagLOixZDyfDdu8KZryiHWwNFNsu1UYHnvzxJ0QynIuYO6kQGWnRq85pjTgx3e 64VqsHgvLOlbQC8UTrxS1qfaLDl+SaxU3eg1q61127HqXOJNf9bThkfWvCim4wWfaRZW m8WTewS0mo68/sAc0z7R+HXxRfCflK2Ov/1e4Kkj5nRC/mXdm82gAR5ET/ZJ2a8m/ZOS 52hWCeCaOqUExMLSwiHRDwWoKsL3WTICObqYTTJdDaLKDNl+7jjlMwZ7Fs33T3ZAat71 e4kgSqbtW2iIuqV549vUikxxIcBLuVnnYvajR4ds/QdgSOrbvWUeULr7iGvvGajkyrFQ Pzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mnERU2iVdKzX9RvnDhk1NZIz1JFzT1zaRxfnkrOcGto=; b=At7/2NGdxUGoObgJTtrBQrBb+VEh25ME4Mb9vz176vPTwnI7jJDO2b+CDpZ4Dh1e3O NNXKRG5v3EIuGOsQnBw44RHWetsj+hazIDFzObyHkD6Qh8cSzEp8i65hUQFeHzVzNhCq +WyrLtU26tBW4zOvEU9vTv3cqkTlUDoKmXg6rdm3nqMyBvGFWA4bJdVEPo3euxul+dpc H6LyJSSakz0v2swXw2sOCkAdPqQ1VYJ/H0RhAjMsUqt77dJDy5S/7EBHfp5nqSXV4I/d /P9Evr2mQNnSpY9NkCDlSPaV9bZkQ0pho74Mmg+x/txmdhEjQ9v7Mg54y77mY6BONK1j 9nSA== X-Gm-Message-State: AOAM531Dkr7KkXR1EA/BLDaEm1HtbJDi0pm9FaSWbDubjLUbM6USwAIb 2QQVQ/eE/+MjDw2+odb+oS8= X-Google-Smtp-Source: ABdhPJyh3vJiS+IMBB/ACL6va6jvpRnGNshpaQxGFQN6Zl8wMJLJPWvdHOQSEYYBTQGdAXOS1kIiUw== X-Received: by 2002:a17:906:a3c7:: with SMTP id ca7mr37006277ejb.523.1608218301848; Thu, 17 Dec 2020 07:18:21 -0800 (PST) Received: from [192.168.2.202] (pd9e5a339.dip0.t-ipconnect.de. [217.229.163.57]) by smtp.gmail.com with ESMTPSA id r24sm23805505edc.21.2020.12.17.07.18.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Dec 2020 07:18:21 -0800 (PST) Subject: Re: [External] Re: [PATCH v6 2/3] ACPI: platform-profile: Add platform profile support To: "Rafael J. Wysocki" , =?UTF-8?Q?Barnab=c3=a1s_P=c5=91cze?= Cc: Mark Pearson , Hans de Goede , Mark Gross , "Rafael J. Wysocki" , ACPI Devel Maling List , Platform Driver , Bastien Nocera , Mario Limonciello , Elia Devito , Benjamin Berg , Darren Hart , "njosh1@lenovo.com" References: <20201211020630.305905-1-markpearson@lenovo.com> <20201211020630.305905-2-markpearson@lenovo.com> <00993237-eb24-6038-3a85-bb76f96f679d@lenovo.com> From: Maximilian Luz Message-ID: Date: Thu, 17 Dec 2020 16:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 12/17/20 4:09 PM, Rafael J. Wysocki wrote: > On Thu, Dec 17, 2020 at 4:02 PM Barnabás Pőcze wrote: >> >> 2020. december 17., csütörtök 14:36 keltezéssel, Rafael J. Wysocki írta: >> >>> [...] >>>>>> My thinking here that I shouldn't make assumptions for future platform >>>>>> implementations - there may be valid cases in the future where being >>>>>> able to return an error condition if there was an error would be useful. >>>>>> >>>>>> Just trying to keep this somewhat future proof. Returning an error >>>>>> condition seemed a useful thing to have available. >>>>> >>>>> You can still return an error while returning a platform_profile_option value. >>>>> >>>>> Just add a special value representing an error to that set. >>>>> >>>> I'd like to understand what is better about that approach than having an >>>> error and a returnable parameter? >>>> >>>> I'm probably missing something obvious but if I add an extra >>>> platform_profile option (e.g PLATFORM_PROFILE_ERROR) to be used in an >>>> error case (and return just an enum platform_profile_option) it seems I >>>> lose the granularity of being able to return a specific error condition. >>>> It doesn't feel like an improvement. >>> >>> And what's the user expected to do about the different error codes >>> that can be returned? >> >> Even assuming the users of the API cannot or will not handle different errors >> differently, who would benefit from getting rid of this information which may be >> an aid in debugging for those who know what they're looking at? >> >> And if a new enum value is introduced to signal an error condition, how is that >> going to be communicated to the users? A magic string like "error" or "-1"? >> Or under a single errno like -EIO? > > Yes. > >> Personally, I believe neither of these two >> solutions are better than returning the actual errno which is deemed most >> appropriate by the platform profile handler. Or am I missing a third way? > > Can we please defer this until we actually have a driver needing to > return different error values from ->get_profile() (and I find it hard > to believe that there will be any drivers like that)? I can maybe give an example. On Microsoft Surface devices, the performance mode / platform profile is set via a request to the embedded controller and can be queried the same way. This request can fail (most notably with ETIMEDOUT and EREMOTEIO). I think at least being able to show users an error in this case would be helpful. A driver for that is currently at [1], but I haven't adapted that yet to the platform profile patchset. On the other hand, I can also query and store the profile when loading the driver and then update it when it's changed. That'd require that no one else changes the profile, but I think we can safely assume that. [1]: https://github.com/linux-surface/surface-aggregator-module/blob/master/module/src/clients/surface_perfmode.c, Regards, Max > > Let's do the simpler thing until we have a real need to do the more > complicated one. > > Otherwise we're preparing for things that may never happen. >