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 04B05C25B0C for ; Mon, 8 Aug 2022 09:40:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242563AbiHHJk2 (ORCPT ); Mon, 8 Aug 2022 05:40:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242531AbiHHJkY (ORCPT ); Mon, 8 Aug 2022 05:40:24 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D1F310CE for ; Mon, 8 Aug 2022 02:40:20 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id s9so9205048ljs.6 for ; Mon, 08 Aug 2022 02:40:20 -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=jzQCeQzK/z2ziiZ85EHCo+LQwjQf8yM8fO70yS7S3mY=; b=aJ33SGVv3zJ5x6IbLuz/X8sbsCMX05NZMt/w+pQnD/9POpmCMCQzEJPLNyzriq2F/b HPzQQ8udkoR6ThjaeWhKAyxlKRe06XVz83s7q2wdaJ9Y3lA8+G93avNeygiLd3EK4sQJ AucIBWd/3zX1/ORNIitoV0gnbMlW115lMwc//a/yFNWJVis5tSrtysX6hmZZNJ13vk9e IhBJ50USTjo5BXJLgfck9tLWohBAhoDzAICXOok4hd86N3VgX238KHjTeq55yMxgx4nN 8yIvH9oDVKKx4m5fxxB6HtdJF6g4qzD42puzuFmOUhVn0/aWi0b0b7W8viOXgFoFktBf 1spw== 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=jzQCeQzK/z2ziiZ85EHCo+LQwjQf8yM8fO70yS7S3mY=; b=1xCIbdkpB3t8dDwiQJ8hTEDalXvxIHgcR4VXKfgg+lsUQC1RLPMyuSV76VM0wT6hxz 9L78mPBWECN18w5PqTvryuotOqB3Z1FiySF1w07Jk4099LGYntyg3vGbfqbfkt7VYxAB ccumX5tOldCYX3tQG/B6bOIu09lGqCrEDDmaGAWVwHK7B+BRBHThfzJqXuBogkGo10Hv EAyY0/X3OJS6/L1KBlo2TqKqUgs2j0sjE3OaMJuVC5nBqgxQDHucKNRpG7km+l2BNM1h RjV3571Q5v2v3pacHxFdKkFwM5EEB8xMbMaZEeBZcwAVnhoA5BymA+G21a4piWMtJDNG YVGw== X-Gm-Message-State: ACgBeo0VSXdl4C0wiGlPftvPl/sC3kYMRqQHg0vfLiykRNDfyi4AR2gH SvK4A32ccbnO4mem/hqzS+MLhQ== X-Google-Smtp-Source: AA6agR7WLbgFwVjA/ymihQczoZK2cQ5claVhqrToENvPaPxybFoFLHUGgAFZVtf8HXX0Mrfd6pqrBg== X-Received: by 2002:a2e:87cc:0:b0:25e:4425:54e2 with SMTP id v12-20020a2e87cc000000b0025e442554e2mr5731584ljj.72.1659951619216; Mon, 08 Aug 2022 02:40:19 -0700 (PDT) Received: from [192.168.1.39] ([83.146.140.105]) by smtp.gmail.com with ESMTPSA id be10-20020a056512250a00b0048af7e58c9dsm1363565lfb.278.2022.08.08.02.40.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Aug 2022 02:40:18 -0700 (PDT) Message-ID: Date: Mon, 8 Aug 2022 12:40:16 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and device ID check Content-Language: en-US To: Jonathan Cameron , Andy Shevchenko Cc: Patrick Williams , Potin Lai , Lars-Peter Clausen , Potin Lai , linux-iio , Linux Kernel Mailing List , Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org References: <20220728125435.3336618-1-potin.lai.pt@gmail.com> <20220728125435.3336618-3-potin.lai.pt@gmail.com> <20220731130959.50826fc4@jic23-huawei> <4ea235d1-46c1-87de-760f-dc4775007ae0@gmail.com> <20220806181252.7633f19d@jic23-huawei> From: Krzysztof Kozlowski In-Reply-To: <20220806181252.7633f19d@jic23-huawei> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 06/08/2022 20:12, Jonathan Cameron wrote: > On Mon, 1 Aug 2022 18:30:16 +0200 > Andy Shevchenko wrote: > >> On Mon, Aug 1, 2022 at 6:26 PM Andy Shevchenko >> wrote: >>> On Mon, Aug 1, 2022 at 6:12 PM Patrick Williams wrote: >>>> On Mon, Aug 01, 2022 at 10:22:16AM +0200, Andy Shevchenko wrote: >>>>> On Mon, Aug 1, 2022 at 3:52 AM Potin Lai wrote: >>>>>> On 7/31/22 20:09, Jonathan Cameron wrote: >>>>>> In our hardware board, we have "ti,hdc1080" as main source, and "silabs,si7020" >>>>>> for 2nd source. This two chip are locate at same bus and same slave address, >>>>>> and we want to use multiple compatibles to support both chips with single device >>>>>> node in device tree. >>>>>> >>>>>> Ex: >>>>>> compatible = "ti,hdc1099", "silabs,si7020"; >>>>> >>>>> This is simply broken DT, you must not put incompatible hardware on >>>>> the same compatible string. DT is by definition the description of a >>>>> certain platform. What you showed is a combination of incompatible >>>>> chips in a single DT. >>>> >>>> We were mistaken that this is the appropriate way to specify this >>>> behavior, partially because it works as long as the probe functions >>>> return an error the next matching driver from the compatible will probe. >>>> It does seem that specifying two different compatibles like this would >>>> violate the intention of the DT spec: >>>> >>>> The property value consists of a concatenated list of null terminated >>>> strings, from most specific to most general. They allow a device to >>>> express its compatibility with a family of similar devices, potentially >>>> allowing a single device driver to match against several devices. >>>> >>>>> >>>>>> In order to support this, I need to add ID checking mechanism into the current >>>>>> hdc100x driver, so the si7020 chip will fail to probe with hdc100x driver >>>>>> (because the ID checking is not failed), then success probe with si7020. >>>>>> >>>>>> Base on you explanation, it looks multiple compatibles is not suitable in this >>>>>> case? Would you mind advise us what would be the better approach for our case? >>>>> >>>>> If I may advise... fix your DT by dropping the wrong compatible item. >>>> >>>> This doesn't really give any helpful advice. >>> >>> Sorry to hear this, but it's the best and correct solution to your >>> problem. Believe me, many Linux people will tell you the same. >>> >>>> The reality is that these two chips are pin compatible and function >>>> compatible but not driver compatible. There is no such thing as driver compatible, in the terms of Devicetree. Implementation does not matter. The compatibles and binding should reflect the hardware (and its programming model). > Boards have been manufactured >>>> which are identical except for this chip replaced, due various to chip >>>> shortages. The question is - whether the programming model (e.g. all I2C registers) are similar or exactly the same? >>>> >>>> Making probe fail so that the next 'compatible' is chosen sounds like it >>>> isn't desired. Yes, it is not desired because any probe failure is indication of test failures in automated systems, so you do not develop a system which in normal conditions has a failure. I don't understand why you cannot include in this driver support for second device? Or if second device is so different, why you want to support different hardware with the same device node. This contradicts the very basic of Devicetree - description of hardware. Best regards, Krzysztof