Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5143465pxj; Wed, 9 Jun 2021 10:06:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyp1ZOtOw4YV6pUItS3KDmESizDd79S2kH6WTcz4JLL6OWf6DMRAiQNYTd9N4voFoFPm1AS X-Received: by 2002:a17:906:1c49:: with SMTP id l9mr841139ejg.39.1623258371162; Wed, 09 Jun 2021 10:06:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623258371; cv=none; d=google.com; s=arc-20160816; b=akEfQDfe/uOWlZRrRSQJvGxttrHbVXAL/d8ZyqnktKusPcIbvqS7XBvif8PAOSne9r 13FpOALJ502xhLGHcipiK5A4F0w1L36nXaVYqbeMu0iUCEzW6C41Hm6TUqI9GeoXZcZt 35i/YHBdbSm9P1OgDAbg+xZi/Iy/Jn+IEZrZTC5UV2VPdZlycdtbJsvJ7ybgIfTgLOUA M2u2/M0FyWeZk/86djXGbFs+HXb+Zm+d2RJoMFehttbPKvapcYKmEoxFRMtB8v8vcXHK N66OXs++mYcGxXE/+8bRZ3+m9FNudMzH106eoh1mjJcOHSTZR+7BUiAo8eTIjuQMYIxx Iptg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=Lbw60RyOEdMwPU3WsJgz73gTQVkRLzJD8D5zTg5fONk=; b=QAbFwy0kyQYIsTqLcEr315Si3ez98YdmV3598EvfTlZjhmmBr7NTPEna2+AbHNzAyf Adxeg9ID3/c/txsRpJROBHLWhOmyEue3MpFzWKuX9yVRwW9h2FgV7GVwNgjjH7zHlSWW 2zl8RNJ7JLKCaIEUbc2H9dadjQGPSEIGmkXc9dD/5pjv3P3V+xMfS+dL/kn3PWAh7gJ3 Da9SBXKNEvBNYV4w9nGWrQJVv3IK6LsaSz++6TIhEIAoSI9nsH+sMBt4hZCBe1v4LD8H rFMeseq0QHZ9q6LFmLQhlR4lGlL7jZoouh2jF+WvAWrRq9Iofh6MmNoFVINqB3I8p/37 9r0A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h18si185278eds.410.2021.06.09.10.05.47; Wed, 09 Jun 2021 10:06:11 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235902AbhFICt5 (ORCPT + 99 others); Tue, 8 Jun 2021 22:49:57 -0400 Received: from regular1.263xmail.com ([211.150.70.196]:54620 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235876AbhFICt4 (ORCPT ); Tue, 8 Jun 2021 22:49:56 -0400 X-Greylist: delayed 416 seconds by postgrey-1.27 at vger.kernel.org; Tue, 08 Jun 2021 22:49:55 EDT Received: from localhost (unknown [192.168.167.235]) by regular1.263xmail.com (Postfix) with ESMTP id 164081F5D; Wed, 9 Jun 2021 10:40:41 +0800 (CST) X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ADDR-CHECKED4: 1 X-ANTISPAM-LEVEL: 2 X-SKE-CHECKED: 1 X-ABS-CHECKED: 1 Received: from [172.16.12.120] (unknown [58.22.7.114]) by smtp.263.net (postfix) whith ESMTP id P31748T140095126476544S1623206439537590_; Wed, 09 Jun 2021 10:40:40 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <109c2c5a014b780e9cd049b63178e813> X-RL-SENDER: kever.yang@rock-chips.com X-SENDER: yk@rock-chips.com X-LOGIN-NAME: kever.yang@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-RCPT-COUNT: 10 X-SENDER-IP: 58.22.7.114 X-ATTACHMENT-NUM: 0 X-System-Flag: 0 Subject: Re: [PATCH v4 1/6] dt-bindings: spi: spi-rockchip: add description for rv1126 and rk3568 To: =?UTF-8?Q?Heiko_St=c3=bcbner?= , Jon Lin , broonie@kernel.org, Johan Jonker Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, linux-rockchip@lists.infradead.org, Rob Herring , linux-arm-kernel@lists.infradead.org References: <20210607063448.29589-1-jon.lin@rock-chips.com> <20210607063448.29589-2-jon.lin@rock-chips.com> <3681106.bcXerOTE6V@diego> From: Kever Yang Message-ID: Date: Wed, 9 Jun 2021 10:40:39 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <3681106.bcXerOTE6V@diego> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Heiko, Johan, On 2021/6/7 下午5:04, Heiko Stübner wrote: > Your comment in [PATCH v3 3/8]: >>>> Adding "rockchip,rv1126-spi" to rockchip_spi_dt_match[] is strictly not >>>> needed when using "rockchip,rk3066-spi" as fall back string. >>>> Could a maintainer advise? >>>> >>>> Maybe this bug of mine should revert too?? Or is it legacy? >>>> spi: rockchip: add compatible string for px30 rk3308 rk3328 >>>> https://lore.kernel.org/r/20200309151004.7780-1-jbx6244@gmail.com >>> I agree with you. If the maintainer doesn't have any comments, I will use >>> "rockchip,spi" as compatible names for the subsequent rk platform. >> Compatibility strings are supposed to be SoC orientated. >> So generic ones like in the manufacturer tree can't be used here. > Johan ist right :-) . > > rockchip,spi won't work at all, especially as these controllers always change > over time. [0] > > Best example is the iommu. We started with "rockchip,iommu" thinking this > won't change over time, but with the rk3568 we get a new slightly different > iommu. Rockchip SPI and SFC controller can use a generic compatible string, because there is a version register inside the IP, and all the feature update will have a new IP version, so the driver is used for the SPI/SFC IP  in all SoCs, we don't need to care which SoC is using this driver. If we have to use the compatible string "rockchip,rk3066-spi" and each for a new soc, then we have to update the driver compatible id list and document for each soc which is totally not need and not correct  to do it. The example "iommu" is different, because there is no version register inside the IP and the IP can not identify itself, which need a software define "-vX". Thanks, - Kever > The vendor-kernel then introduces somewhat random "-vX" additions to > distinguish them, but often they do seem to be very software-centric. > > Meaning, hardware-designers moved stuff around and software-developers > then invented the versioning to differentiate between versions. > > The devicetree is supposed to describe the hardware though, so going with > the relevant soc-specific compatible gives us the necessary hardware-centric > differentiation. > > Also this allows to catch later issues with specific soc implementations ;-) > Like 6 monts down the road we discover some special behaviour on the > rk3568 and devicetree is supposed to be stable. > > So having the relevant compatibles in place allows us to just add driver > fixes and have those apply on the rk3568 if that is need at some point. > > Heiko > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > >