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 C6503C4332F for ; Tue, 12 Apr 2022 19:20:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345707AbiDLTWy (ORCPT ); Tue, 12 Apr 2022 15:22:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352457AbiDLTWx (ORCPT ); Tue, 12 Apr 2022 15:22:53 -0400 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C5F52229A for ; Tue, 12 Apr 2022 12:20:34 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id t2so19821413qtw.9 for ; Tue, 12 Apr 2022 12:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=chVyhFxixwoz7zNbu99F11TKHFQnl3/UVYBDPB80ZHY=; b=gXpCS89SV25uD/Y+1x2aHYvQ4vgt3R0Xu8swk6osxevhzyMgEDaPNW9ZP/NFJNuPHz 28TaViXb9L44buYRbeek8mPQATl09OQ79rU7Z3vikUf8fC9CMeEtxoBc20+ak86yhtyJ frFm6Pn3raz0+A/40BKzY3O7/vPlZktKTHmUJQDZM+eSJneDV8Q6568Y70BWO4GhTcgy eVEoeFmqKEpZc2RCRauAr7aKhDGpHi/ukxgVxu4alQ5aDJTSCJAJ/pdyygki/zCHbuN+ F1osIdGDrMeDJsLmaphrdl1NYjQqnyYcFDCrHCkgbVNURgnm8xNBbKuiqeudtRZSVYtY FakQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=chVyhFxixwoz7zNbu99F11TKHFQnl3/UVYBDPB80ZHY=; b=T3pUY/BoM6PYftFCtg1G66dyuXieL/30QpykH3K4yoVMemiMIDB4nyAvdObil14xJA KMU3NcaNO9EnGjh9sdDsVQJigl4hfUhHMmgjkBZqdtFgoVgCSkzqVVyv9z/9Kd9OFgEz QvDe+hDF9KHi4rGYYZ7WajXNcUcm1NP3Ar1K0EIH+6IAfUd0qPiqF+Zllkw/C6SB5Xwq G4zgy98Q6l87dMHdSCKF3A4Y+1rPy/C7RSiuitTwI3knndErE7IZ606iewq/vQfZ/DL/ X0I5XoCogUa15uQhybLRvcFRncAu5/9KAIzJs6UrvPZjnk7/ohS8D1Zzv7/+TDEAFeyG i3ZQ== X-Gm-Message-State: AOAM532mKAWEcsibO0mFmPaXSZAgayFfh2080WigINl3Xuwg9m4EXkc2 jgDV/Iark3XBbab+P/rurU+e982sgXoe/qoGR21lpw== X-Google-Smtp-Source: ABdhPJyLIBZR72VaDtuzWmfwbKyURkZFlbzUnKCwIee1kql6f59UqrnPndVBLSVdTBBd76Xhj9Y/B4Xwa0ph4v4E8kU= X-Received: by 2002:ac8:5a46:0:b0:2e2:2edd:374 with SMTP id o6-20020ac85a46000000b002e22edd0374mr4570468qta.295.1649791233793; Tue, 12 Apr 2022 12:20:33 -0700 (PDT) MIME-Version: 1.0 References: <20220406002648.393486-1-dmitry.baryshkov@linaro.org> <20220406154028.EC897C385A3@smtp.kernel.org> <20220412184304.79012C385A8@smtp.kernel.org> In-Reply-To: <20220412184304.79012C385A8@smtp.kernel.org> From: Dmitry Baryshkov Date: Tue, 12 Apr 2022 22:20:22 +0300 Message-ID: Subject: Re: [PATCH v2 0/4] arm: qcom: qcom-apq8064: add separate device node for tsens To: Stephen Boyd Cc: Amit Kucheria , Andy Gross , Bjorn Andersson , Krzysztof Kozlowski , Michael Turquette , Rob Herring , Thara Gopinath , linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, 12 Apr 2022 at 21:43, Stephen Boyd wrote: > > Quoting Dmitry Baryshkov (2022-04-06 12:57:30) > > On Wed, 6 Apr 2022 at 18:40, Stephen Boyd wrote: > > > > > > Quoting Dmitry Baryshkov (2022-04-05 17:26:44) > > > > Currently gcc-msm8960 driver manually creates tsens device. Instantiate > > > > the device using DT node instead. This follow the IPQ8064 device tree > > > > schema. > > > > > > Why can't the schema be changed? > > > > But these commits change the schema. They make apq8064 follow more > > logical scheme of ipq8064. > > > > Sounds like ipq8064 and apq8064 follow different schemas. Is there any > benefit to harmonizing the two vs. just leaving it as it is in the dts > and making the schema match whatever the dts has? I'd prefer to harmonize them. It makes no sense to have two different approaches for the single IP block (shared between ipq and apq/msm). And having a separate device tree node for the tsens removes a dependency from gcc on the nvmem/qfprom. Note, upstream qcom-msm8960.dtsi doesn't describe tsens at all, so we don't have to worry about it. -- With best wishes Dmitry