Received: by 2002:a05:7412:8d11:b0:fa:4934:9f with SMTP id bj17csp656024rdb; Mon, 15 Jan 2024 09:10:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IHWq/K/T+QhLHyWxNE4qqoWud/VlsUOVMsmLODDrWL74MVkS7PAR12BrFQcRJhnSyZVmmHj X-Received: by 2002:a17:90a:1284:b0:28b:7563:a6cd with SMTP id g4-20020a17090a128400b0028b7563a6cdmr2652244pja.83.1705338613124; Mon, 15 Jan 2024 09:10:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705338613; cv=none; d=google.com; s=arc-20160816; b=Bm1HU1pysceMaUvbGb5NRO9s6Bm8uviL+cQYjKwr6qL8eQyWI/VF1Q7A9ruprllccy zZqqBpd6W4n3nuddSR3DF1ZcqcgQhOZ4Bdhi3qQ340uWX4JrZ1Vzo233uIF7WiZTdzAl oYVVfBfhyDqShhx1knSfhvetENlO3J69gw3CTAQ3uJyzkM86O0Vf3ivYmJWD7AnS+5MH l15/e6ZCXykfevZqFcJ3Mw0BM8XG5YI3GcEWHfK1GFOrkbvDoaP2jmm8/ohRoAnx8loL uSKPK04CROvnHuGjPO8G75XUJ1LpuOmROfczOQgklqUkQHHzrScc0nyuqX9poBA5fnHy s5yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence; bh=6AuNqPEQ6+Di1qW9NRwRXKxlP0o+roEfzht1wXg9bXQ=; fh=kbREOHOL9/np6HO+zAUU1nVRaCrLK5RUZOkhXwJZ3hE=; b=jhCWa23EyIFL5Gd6gR069hd/82Ssgk7uN+yg4duZxQekY2ulGC6rS8RsL5oGvbb6qD kLpOyYBiE4JUGo8DZEevMlN3vSBKAdnVDFRwxAu9kD8riY3SbHsC80CNvMhpWaCB2lFp c6AdnaQeIimm2Awp7CLcaSo9me60uZ3JeI+Ho/s+n/djn0fOpNjFRW61P6bNqNMuYSJW CfEImW9HC/0ECX24/q516YVquF0aciBeybbxml2EzAp3JAiNfD4AO0snzz0TJ21W/GdR jG5z/dfe9g2cLwpZd41EHJTPqX5leX6NJ4QyF02M+gpPyPQHT6uHSwg9ETqIFRuRy7gZ deBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26296-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26296-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id k59-20020a17090a3ec100b0028c3ae07ce8si11798619pjc.184.2024.01.15.09.10.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 09:10:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-26296-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26296-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26296-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 6591A2832CF for ; Mon, 15 Jan 2024 17:10:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D4F5D18045; Mon, 15 Jan 2024 17:09:20 +0000 (UTC) Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1853F18041; Mon, 15 Jan 2024 17:09:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-2057f388b2dso1805451fac.1; Mon, 15 Jan 2024 09:09:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705338558; x=1705943358; 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=6AuNqPEQ6+Di1qW9NRwRXKxlP0o+roEfzht1wXg9bXQ=; b=P9Ygee4ZoLHkGWZnLlBDjbXsEA7h6ZmC0RW7X7ffUEqucQB7YywJJgQcgFzTD29E2A OuY+88Dp2ljo+ixaJOPyFOpzM3mmXAAmjGUhO8oqYXW4BPOIp8oQSw7GKyqWiI+fp6OO i4TaTdlertJ2zU0SM45/4Qnbx09/tF0v16tPr31OQ0tDR5reI7WPJ3hysp9E+11klHPt cMbiPVaeDJh1Wc2bwg2Z0hXEmTaQ3pEwY2yZSmPYJzTLV+ju8ZWuAeVO3vPpM2fZzb9w jWgQDGHnpf52JC/Cx7y5RR1q3DUtTqEAM3Owv6sYGrvA20fvqMVdB9IFXHFD0FmUfUfs 41zw== X-Gm-Message-State: AOJu0Yw81AO/myI9we7p6cDRllDWULIjpFivKAAMSOOIX2zUo+ar3FBA oNnb1KYgTggydZ4mTrixfoBx+jDfoi7Uc9twGNM= X-Received: by 2002:a05:6820:510:b0:598:c118:30d1 with SMTP id m16-20020a056820051000b00598c11830d1mr11628098ooj.0.1705338558095; Mon, 15 Jan 2024 09:09:18 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240115082507.29651-1-duminjie@vivo.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Mon, 15 Jan 2024 18:09:06 +0100 Message-ID: Subject: Re: [PATCH v1] thermal/debugfs: Remove unnecessary debugfs_create_dir() error check in thermal_debug_init() To: Daniel Lezcano Cc: "Rafael J. Wysocki" , Minjie Du , Zhang Rui , Lukasz Luba , "open list:THERMAL" , open list , opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2024 at 5:55=E2=80=AFPM Daniel Lezcano wrote: > > On 15/01/2024 16:52, Rafael J. Wysocki wrote: > > On Mon, Jan 15, 2024 at 9:25=E2=80=AFAM Minjie Du w= rote: > >> > >> This patch removes the debugfs_create_dir() error checking in > >> thermal_debug_init(). Because the debugfs_create_dir() is developed > >> in a way that the caller can safely handle the errors that > >> occur during the creation of DebugFS nodes. > > > > I honestly don't see what the purpose of this patch is. > > I think it is because the recent debugfs changes were about to reduce as > much as possible the code related to the error handling as the debugfs > is not supposed to go in production system. > > So for instance debugfs_create_dir() will not fail if the parent is NULL > and will create the entry in the debugfs topdir. Which would be confusing IMO. > At the end we are ending up with: > > d_root =3D debugfs_create_dir("thermal", NULL); > d_cdev =3D debugfs_create_dir("cooling_devices", d_root); > d_tz =3D debugfs_create_dir("thermal_zones", d_root); > > The current code will avoid creating lost entries in /sys/kernel/debug Right, and IMO it is the right thing to do, and I would even go a bit further and roll back the thermal debugfs initialization if any of the above is NULL. Note that currently d_tz can be NULL and it will work in the sort of degraded mode with the other two, but it is not a big deal IMV. It would just be more consistent to clean up everything then, but that can be done later.