Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp949695rwe; Fri, 14 Apr 2023 11:55:15 -0700 (PDT) X-Google-Smtp-Source: AKy350aTo+Lg9u3ElKfh5Xgk34eXmmqi2jY7g10NM2FDbriWLU/XQKhrVd1nHDVV8Zx4LOShtyDn X-Received: by 2002:a17:902:c155:b0:1a6:51a6:ca76 with SMTP id 21-20020a170902c15500b001a651a6ca76mr3639187plj.11.1681498514921; Fri, 14 Apr 2023 11:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681498514; cv=none; d=google.com; s=arc-20160816; b=Xz0V4XFpkbfrPVEmDYXcxHS6Mn05YSOZ/IvtJwVk/lR//bz/4d48o2xgObgUsYzZ7u SjanAaW3G0QN63gTGUGLaEQaMEQOcRC4wr0iimHfAm4851uiEEU072pvcNhZvuXuN9u1 kxUJPPwBD3IOoAAbs8zAvSmJiISv241wXMcfQ4irxGhpx5iomqLdnQjHz24Thcqgee5F i8rajxqRYCAoQ23xhu8/sHZyVmz6X4mvLDy7MaEalofwx0dbGQrlDc7+4aeT5FwaoPJ8 scVrGVXxI0mYEXJLrV5FYIFvsxrJzUJXSbPqB+PPZ15CV7k9w9rkMXc2ZA0azJJvIxeS Xg8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=IDxXa1MT9BcKygGHONc0obRyG+X/gVfjd8/c/OkPBso=; b=liwPhHqdmZieSmas2hSzFijHsVjWQ15gDCeHhElR2v1VeBZJbFFSDDA3HK1SKNISdB 7rwjZb4fPiF80+p70RL1OQ2ctHUI6Efh4IFVkYyL/a1swrjmoSX2N1tAb6y00guN9PqO n1LzXZtMvU/NbqGIFDhQgOE7Xj2mFVSLM7IR+yihb1DI1ckWtZxkaQzsISKVjZxzeV23 3LIZKhUyDLLwF8ZbidqfcV7j1dWbPqGsAViSWC9ani6J9Y4Y7qdvjMXbXcGunCEI9Xj6 rq4EVFpFtXxOyLnENnabglU240NkHrulgsEAc3b9dLA3776umvdBU6jt/zJIUQYiAetX m+JA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u16-20020a170902e81000b001a5783b9d5asi5536860plg.221.2023.04.14.11.55.03; Fri, 14 Apr 2023 11:55:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229774AbjDNSn6 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 14 Apr 2023 14:43:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbjDNSn4 (ORCPT ); Fri, 14 Apr 2023 14:43:56 -0400 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 801FB8A74; Fri, 14 Apr 2023 11:43:55 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id c9so9059067ejz.1; Fri, 14 Apr 2023 11:43:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681497834; x=1684089834; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=McbEA2OpJ6jOUiDyogw43V66/S8Du0pTDcqQpetxNCk=; b=DijGJVUPdXnOAuxmFyIkmYlvbANbgCrsoMEmeD1hLCp/WwyZBHamiyKpZc7m3xXRei P0/Lkgsb1UCRT7/WMWS+tM842Uj7ynrBe7MG4yB2eqoJVQUSk9lPewtFq12bVUn8dck+ vDHnUjuhl0TmfRSmAiGsDd8cAoIOEsIFcqzQ6Ph2cNIF7aLNDKzQBCgOOBGNX6kZRByH Xs4gTjfdabxTGa+IacW8lmZVFwWzHv20/SoJ29l2SfeNfzbfRwMcJxhz9A2C77mQvaQV 2Exzvn7v0qn0whv2zKshBoNxpJdKnrj+bOMKNMyG3JC7QS7rPmUz1JkMWsnEvHIPmfvq y5dQ== X-Gm-Message-State: AAQBX9eI/6YVpx3C67iB00086+zedBi2VuEqIzyZA5lF4xFstK83ZMTd UEi8qmVeLmX5hLUHQ39QoRbRoUucDrWCfOeaD7+SUfGC X-Received: by 2002:a17:906:f290:b0:94d:cf8c:1542 with SMTP id gu16-20020a170906f29000b0094dcf8c1542mr71781ejb.2.1681497833847; Fri, 14 Apr 2023 11:43:53 -0700 (PDT) MIME-Version: 1.0 References: <20230307133735.90772-1-daniel.lezcano@linaro.org> <20230307133735.90772-10-daniel.lezcano@linaro.org> In-Reply-To: From: "Rafael J. Wysocki" Date: Fri, 14 Apr 2023 20:43:42 +0200 Message-ID: Subject: Re: [PATCH v1 09/11] thermal/core: Add a linked device parameter To: Daniel Lezcano Cc: "Rafael J. Wysocki" , amitk@kernel.org, "open list:THERMAL" , open list , rui.zhang@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 4, 2023 at 9:01 PM Daniel Lezcano wrote: > > On 27/03/2023 18:16, Rafael J. Wysocki wrote: > > On Tue, Mar 7, 2023 at 2:38 PM Daniel Lezcano wrote: > >> > >> Some drivers want to create a link from the thermal zone to the device > >> sysfs entry and vice versa. > > > > Which device is this, exactly? > > ls -alh /sys/bus/acpi/drivers/thermal/LNXTHERM:00/ > > [ ... ] > > lrwxrwxrwx 1 0 thermal_zone -> > ../../../virtual/thermal/thermal_zone0 > > [ ... ] > > The ACPI driver is the only one doing this AFAICT. > > > >> That is the case of the APCI driver. > >> > >> Having a backpointer from the device to the thermal zone sounds akward > >> as we can have the same device instantiating multiple thermal zones so > >> there will be a conflict while creating the second link with the same > >> name. Moreover, the userspace has enough information to build the > >> dependency from the thermal zone device link without having this cyclic > >> link from the device to thermal zone. > >> > >> Anyway, everything in its time. > >> > >> This change allows to create a these cyclic links tz <-> device as > >> ACPI does and will allow to remove the code in the ACPI driver. > > > > Well, I'd rather have it in the driver than in the core TBH. > > > > If ACPI is the only user of this, let it do the dirty thing by itself. > > > > There are two cases which would justify making this change: > > 1. There will be more users of it going forward (seems unlikely from > > the description). > > 2. It gets in the way of some other changes somehow. > > > > I kind of expect 2. to be the case, so how does it get in the way? > > Shall we do the same approach than 'Menlow' and add an option to remove > the thermal zone link in the acpi sysfs directory ? That depends on the answer to the question above.