Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2944980pxb; Fri, 8 Oct 2021 20:12:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1c0cub3cnwWHOJ9yejx0/kG+9LxS9iCE1qKthfFM9y6NpjmKADPSekiOVCQs+Wf52kvmn X-Received: by 2002:a05:6402:34d1:: with SMTP id w17mr2404889edc.340.1633749136314; Fri, 08 Oct 2021 20:12:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633749136; cv=none; d=google.com; s=arc-20160816; b=ueAaNTodtj2wvk3Bh50daNzLPvedyu8J8NFElTDNtQWvEUyHHgbi0A0fsA6zWIJ2bE swTG3dafOaTtY1AkycW9jJymrvaytXwRhvfgktUHP+S2vVHhTfkiTqKYCmMwycunMz2h cEd23xkBPuY8QY48YB3B0VHpyEkd6m1ppJ7ARnN70jj9jEPUCK8+cWPoIRs+jf9m5P/N lwcrmK/2m9zHM8ZpNzsDAaT3kp2uLHNTIp5FXdVFsL5jdQu8fxmbPFm2MQ3QL4T97BRk 9IXFpJ+1b/cjXPv5fM+aK5jm+ssmC27ka4kgImhAUHWjd5BtDCUwehvQPJjAgxBGTuVT K+sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=5iBW8enG5P/ibkm90qNSFxEoHvUjFVD81D0eZ92k/AY=; b=zHBIVrrQWRKSsXDCGAtuKwbGb7yUZ7wSYMrxZo4i1IbcQTI/OB0eixfww3V/aFNBaM XduDhMaCdAZr49dalCCxIhuwr193RmZ2f2rd6jKyT6V8U36on5IYyK7uONfg1dfdhRpt 21huF1n2ooV6Hn7QhJdTWlJ3XBmwkwqPlZKRB6dl3PMucN1oPFmB9gBSGFDZ0++UK7e2 kc3UXQv3FwJt23PyfAwhaesohg6mgUWucwo03k3gAOoFNLp2lm/Wlvcdiv79Q54w+Uw2 imJWKZPmcNu12GxW+Pn/XaUQMNxj4hzB/mjOaiT+TqE7lkG4167jSaJfBrvU4R1fEayK jgjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb8si2640662edb.154.2021.10.08.20.11.51; Fri, 08 Oct 2021 20:12:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244140AbhJIDKo (ORCPT + 99 others); Fri, 8 Oct 2021 23:10:44 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]:35451 "EHLO mail-qt1-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244114AbhJIDKn (ORCPT ); Fri, 8 Oct 2021 23:10:43 -0400 Received: by mail-qt1-f171.google.com with SMTP id c20so11406180qtb.2; Fri, 08 Oct 2021 20:08:47 -0700 (PDT) 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=5iBW8enG5P/ibkm90qNSFxEoHvUjFVD81D0eZ92k/AY=; b=OTa82kit4DXanlZKYJ/G8KZp7blCgk7qWf8sJBSxOeRiOKitxrPTaffigcQhNjLvz5 fwFCTw3AGqTx2/IyaXFqYrBQarQPaGz0ObZE+RoWlNAd3dx52l31J4s5SW1WM9heEBaU HLVF3mS57OuUtxuX++R+d0CydZzHFxPK9K1r56ROQBMCD351iSkYYZCgkQsY3u9XSvwY IHp04H57DsM/JggwjZjUxlaxVnT59kD5o455sh9WXg7tvjQLKulxm+/nU7ZMqT5OvG6x NmbKl+9Fo3L4OHH/Lyh6eXD54831celn0SrabYtaKTRBg1CrSHb8Q1rSNFSmNSYVUNmL Oi2w== X-Gm-Message-State: AOAM532Ug473DbINgBH+kJVJO9MbbbC+qKusoH8xVi9+MD7cVPS6SZD5 Valb+Pbb3zVacnVUHacIBaQ8brrOcxw= X-Received: by 2002:ac8:5755:: with SMTP id 21mr1969626qtx.353.1633748926416; Fri, 08 Oct 2021 20:08:46 -0700 (PDT) Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com. [209.85.160.177]) by smtp.gmail.com with ESMTPSA id h8sm902367qkk.11.2021.10.08.20.08.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 20:08:46 -0700 (PDT) Received: by mail-qt1-f177.google.com with SMTP id b12so3332335qtq.3; Fri, 08 Oct 2021 20:08:45 -0700 (PDT) X-Received: by 2002:a05:622a:209:: with SMTP id b9mr2044865qtx.28.1633748925581; Fri, 08 Oct 2021 20:08:45 -0700 (PDT) MIME-Version: 1.0 References: <20211001000417.15334-1-leoyang.li@nxp.com> <20211001000417.15334-3-leoyang.li@nxp.com> In-Reply-To: From: Li Yang Date: Fri, 8 Oct 2021 22:08:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 02/16] dt-bindings: i2c: imx: update schema to align with original txt binding To: Rob Herring Cc: Shawn Guo , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Oleksij Rempel , linux-arm-kernel , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 8, 2021 at 5:20 PM Rob Herring wrote: > > On Fri, Oct 01, 2021 at 12:37:54PM -0500, Li Yang wrote: > > On Fri, Oct 1, 2021 at 8:24 AM Rob Herring wrote: > > > > > > On Thu, Sep 30, 2021 at 7:04 PM Li Yang wrote: > > > > > > > > When the binding was converted from txt to yaml, it actually added more > > > > constrains than the original txt binding which was already used in many > > > > in-tree DTSes. Some of the newly added constrains are either not valid > > > > or not neccessary. > > > > > > IMO, both of these should be fixed in the dts files. > > > > > > > Not all SoCs use ipg as the clock name for i2c. There is no point in > > > > having SoC integration information defined in i2c binding. Remove the > > > > clock name requirement in the schema. > > > > > > Any name you want is not fine. Your choices are remove clock-names, > > > add all the names used, or change everyone to use 'ipg'. > > > > I understand that the name should be important as clocks are > > referenced by name. But since the i2c controller only has one clock , > > the name is never referenced in the driver. > > Then just remove 'clock-names' from the dts file. Had thought the clock-names are mandatory, but it turns out not. Removing it should be great. > > > If we really want to define the name, IMO, it should be from the > > perspective of the i2c controller like "clkin" or "i2c" instead of the > > "ipg" from the perspective of SoC integration which could be changing > > with a different integration. I can list both "i2c" and "ipg" for now > > as a workaround though. > > $modulename for $foo-names always looks made up and pointless to me. > > > > > > > > > > The original txt binding didn't require the order of tx and rx for > > > > dmas/dma-names. Many in tree DTSes are already using the other order. > > > > Both orders should just work fine. Update the schema to allow both. > > > > > > Doesn't sound like a case where defining the order is challenging. > > > > No, it is not challenging. But as dma channel is only referenced by > > name instead of index. I don't see too much benefit in enforcing the > > order other than easier to create the schema. > > Easier is nice, and that's the 'DT way' is the other reason. Ok. Regards, Leo