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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 69222C4320A for ; Wed, 4 Aug 2021 23:02:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A086610A0 for ; Wed, 4 Aug 2021 23:02:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230445AbhHDXC0 (ORCPT ); Wed, 4 Aug 2021 19:02:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229987AbhHDXCY (ORCPT ); Wed, 4 Aug 2021 19:02:24 -0400 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FDCDC061798 for ; Wed, 4 Aug 2021 16:02:11 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id o10so4511416ljp.0 for ; Wed, 04 Aug 2021 16:02:11 -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=SWwfAxfR7c4JrRsq35ex9D7DmgW1MFN8V1BR9OdGE3s=; b=Keuv9rmwBrPD0mImQNgZzTd90sUsS01XNQNiwlt6tUctK265kK/0g+VQw++Z0LJ8qV GA4DWAfZNHOkzruKioaUUOXybY/N3gQn6kkN3XLaOSBakIKXZndZXC2tiRDeFktVD7Nj U0Lm5nC5tMADC75PQ/9NHb8NooglHWqHmvM+OHuDYnUSML3W4AbM0TTOy2LNgvhKuSei lf/5OI2gFbsAb20Sh2cs5P7osRk0xkL/MEsxQKRh+GvSwbLa/5U+6VT+VQd2vAdi3xPY H4PSSHtVkLqf95+zWzC9dGeT086BV7ACrUGMssBe6ycVsdo1gmnobhnCi4EAlC7j/Kgp D28A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SWwfAxfR7c4JrRsq35ex9D7DmgW1MFN8V1BR9OdGE3s=; b=TAl69tt4H0SHmkOpp1IW+vvjti2T8h9ODXVhVFHqn5VQcJZbJW+rHEs1xDzRyl3SRd LqlUN1gyu4ZK1F37NvBpsBhf0Tqo8RkFx26n6feT2trsZChY7q/0DeImf6dodEs5QQrV Yuj4uJ8XZqLrMCV1/hmnqcCLmmXI5R4DYbm9x/HL1Hdmg6cwr5GuNF2s9fIILP0eShOR Avt+Hzt6MFI3B5w5kP8J9S1mCPvLkS2GlkCZBLlA1N/Zb/LJzzSAAcwGtGFycw797Bl4 6tr9wC2lLI25mwF39HIobrh/flYyh8Ds8BekKVITR5vTTwT6YGobcM0VeSzXiAqgSPIM nQ0w== X-Gm-Message-State: AOAM531fks40JNCt5QphXOJHCcpyyDYDVY4/JmCcUAMUeqzFZ9VDRuTw MGz+vW6246egDcsk//KQa9V+XTK1YyI62jk11HCqcQ== X-Google-Smtp-Source: ABdhPJz61O47mzHH9624bGfk/bfpBA1SJ3dnMpXd9CQG2hHPT+eKzKSoE6RiH7zQjaw6hJgUxRPNoePE54zpybhVLJI= X-Received: by 2002:a2e:7c04:: with SMTP id x4mr1038597ljc.273.1628118129818; Wed, 04 Aug 2021 16:02:09 -0700 (PDT) MIME-Version: 1.0 References: <20210710081722.1828-1-zhiyong.tao@mediatek.com> <20210710081722.1828-2-zhiyong.tao@mediatek.com> <1626940470.29611.9.camel@mhfsdcap03> <07388dac4e25e0f260725e8f80ba099d5aa80949.camel@mediatek.com> In-Reply-To: From: Linus Walleij Date: Thu, 5 Aug 2021 01:01:58 +0200 Message-ID: Subject: Re: [PATCH v10 1/2] dt-bindings: pinctrl: mt8195: add rsel define To: Chen-Yu Tsai Cc: "zhiyong.tao" , Rob Herring , Mark Rutland , Matthias Brugger , Sean Wang , srv_heupstream , hui.liu@mediatek.com, Eddie Huang , Light Hsieh , Biao Huang , Hongzhou Yang , Sean Wang , Seiya Wang , Devicetree List , LKML , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "moderated list:ARM/Mediatek SoC support" , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Jul 29, 2021 at 11:43 AM Chen-Yu Tsai wrote: > On Thu, Jul 29, 2021 at 4:23 PM zhiyong.tao wrote: > > The rsel actual bias resistance of each setting is different in > > different IC. we think that the define "MTK_PULL_SET_RSEL_000" is more > > common for all different IC. > > I see. I personally prefer having things clearly described. I can > understand this might be an extra burden to support different chips > with different parameters, though this should be fairly straightforward > with lookup tables tied to the compatible strings. > > Let's see if Rob and Linus have anything to add. Not much. We have "soft pushed" for this to be described as generic as possible, using SI units (ohms). But we also allow vendor-specific numbers in this attribute. Especially when reverse engineering SoCs that the contributor don't really have specs on (example M1 Mac). The intent with the SI units is especially for people like you folks working with Chromium to be able to use different SoCs and not feel lost to a forest of different ways of doing things and associated mistakes because vendors have hopelessly idiomatic pin configs. Yours, Linus Walleij