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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1F7CC433EF for ; Sat, 18 Jun 2022 01:02:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383799AbiFRBCq (ORCPT ); Fri, 17 Jun 2022 21:02:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233738AbiFRBCo (ORCPT ); Fri, 17 Jun 2022 21:02:44 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8976A2DDE for ; Fri, 17 Jun 2022 18:02:43 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id t2so5172410pld.4 for ; Fri, 17 Jun 2022 18:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=0DQDSG7vpMhAghxTWTUioir0FFHVEEY00Bb6PEI7mmA=; b=VZ9hmLoIfZy3Gv2bUDe1d7P5vdzrlmwX+NQy3m99tg79e0urCWEGw6Nb90Q+ysZ5Yv 1sUTQqlVo2dAKBDnpKuEn/VH0lzk9WUkbmaz9XlVigQjn0H4x1P3V2GBPRddB0Zfagwv K+RK3mh4MqMk7h7lyV+JK5CphtV8ecMhkGmO6fGoRs91jK+hpDDRPwlaR6OXlEHrzgGL Ho9MpaVHzm3VNJADWD7wKr/lkZRzUowMMQsX+95C9Wf7XrYdjx/0APy4WKhOxIiiL5sA 8v/gUQUYVdttl0azzvip7rzLpISsEdtFXOAZ7tCpNnLYHa+EKdhLp1K4z/dHMqWntN+D iOHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0DQDSG7vpMhAghxTWTUioir0FFHVEEY00Bb6PEI7mmA=; b=TID3zhNys/VFfE+3Mnp61+b8nWzFQFKkF9u1MxC/a0MdtNzra1UjUAnOAYK2cmQK57 iyAgdPpqu+GTtacw/MXSTJD+KX4ABmsFq8ctTTraM9QdSwr/ZIG2uN3thnTk6iTqr1dB 6goPznSx/uEBG1pc3uA92AuVUQN1UtpKud6hAFInbkUQnbqXw5BmgesRfSv0EBdb2//H X2VgSbuhatHax1QNtFw8PubRg3Ah/9aVnmTYqlVfZfiM0BhyvshY7ygvLURFMPa+37NF GlAAyaXhRXORcaLawQrdA1AAVNGTlkEql+GxOBoRSBQvMWDcIpqHHkZY8VlIO/f5TJ76 pbcg== X-Gm-Message-State: AJIora8coftO+4ukmQILvLwIWLE4Jn8g5s8MfyHrwhfepYqU9Lx9BLdU xLfWTvZLJp9Pv4qRHa/evNCyug== X-Google-Smtp-Source: AGRyM1uaYDSo4SeaMwOX4NuS5P558iYahkc4hsUv8eFKbvNiaUT+2mdq7FveVa0/03GkLts7bHgLnA== X-Received: by 2002:a17:90b:3904:b0:1ea:d976:aff7 with SMTP id ob4-20020a17090b390400b001ead976aff7mr13658747pjb.4.1655514163076; Fri, 17 Jun 2022 18:02:43 -0700 (PDT) Received: from [172.31.235.92] ([216.9.110.6]) by smtp.gmail.com with ESMTPSA id q2-20020a639802000000b003fc4894c270sm4311961pgd.69.2022.06.17.18.02.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jun 2022 18:02:42 -0700 (PDT) Message-ID: Date: Fri, 17 Jun 2022 18:02:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v2 1/9] dt-bindings: thermal: Define trips node in $defs Content-Language: en-US To: Francesco Dolcini , Daniel Lezcano , Rob Herring , "Rafael J. Wysocki" , Krzysztof Kozlowski , Shawn Guo , Marco Felsch , Anson Huang Cc: Amit Kucheria , Zhang Rui , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, Pengutronix Kernel Team , Sascha Hauer , Fabio Estevam , NXP Linux Team , linux-arm-kernel@lists.infradead.org References: <20220617070847.186876-1-francesco.dolcini@toradex.com> <20220617070847.186876-2-francesco.dolcini@toradex.com> From: Krzysztof Kozlowski In-Reply-To: <20220617070847.186876-2-francesco.dolcini@toradex.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 17/06/2022 00:08, Francesco Dolcini wrote: > Move `trips` definition to `#/$defs/trips-base` and just reference it > from the trips node. This allows to easily re-use this binding from > another binding file. > > No functional changes expected. If you want to re-use trips, they should be rather moved to separate YAML file... but anyway this should not be done per-driver bindings, but in more general way. Either the problem - using one DTS for different temperature grades - looks generic or is wrong at the core. In the first option, the generic bindings should be fixed. In the second case - using same DTS for different HW is not correct approach and why only thermal should be specific? I can imagine that cooling devices might have different settings, regulator voltages for DVFS could be a bit different... Best regards, Krzysztof