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 E42F7C433FE for ; Sat, 9 Apr 2022 13:44:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242222AbiDINql (ORCPT ); Sat, 9 Apr 2022 09:46:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242217AbiDINqk (ORCPT ); Sat, 9 Apr 2022 09:46:40 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B2CD98F7E for ; Sat, 9 Apr 2022 06:44:33 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id d10so13060029edj.0 for ; Sat, 09 Apr 2022 06:44:33 -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=9jXEm/llamwKFEyofVyK+nTUMIMtJh/N9Opoetbwiso=; b=H/Q1QSzzjh6u32GG8HINBQjg9TwglokvXK0o8iMSUEZ5LKCU4UGlvegrdfW19pX9Kw Jx+aCFxf4PgpI/i4Z7/SuesbDzwtYXu0IvwUXN7/x0Tv9d8YZkbdANXMLNK176OQ3U2v fESng/tSQPFwnXxO0JCD4Q1qGIrLJn58me1Zik5VgDzb+R2ISWMCDblWLUehEez3sfxN IViC67puHG0D/Afit76kZiOu6IBi1X4TvAwcA2tZlyHIyubhKx1x7vtHc8Qo5/d6weMl 9BPKxxjcv/pn0HXqhtmFhBkX+hrC3nvlLUYQ3HWBS/O4Bnb0ZQ+elH2rLCUs/8d2qG0W Vu4w== 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=9jXEm/llamwKFEyofVyK+nTUMIMtJh/N9Opoetbwiso=; b=ve3H/eMBZQLikCAaDdkMl0FKQcSOYdnDKMxOAsyUNDhscj8YfWxI2pPgZXlS/5T3Qe lWs78DXzHUmzWRgA/hp4w8F5w6NY8JLL8KdVXATAwcvS+OUbvz/dyNEOqQ+Z8bccYxaJ kMzN4NDpYaLmCjtveGjzvFldf3EkuMlZKpBeQOG+eqFXp+kJJEPR06fw8/W+qDbygn3n ukzAjyRWqmviSV+26sVzmhBNj1b4ciSN7ywLkzYnvGcVQsqwb7gTAjU6wi0GK5vyJ7s3 idGGAf/MCIAwn/HZRRi4WsHE6PoRKbDQwI3wz0uaPNd8zaYX3R4yqT4yLWXzPUOHt5rp wXxw== X-Gm-Message-State: AOAM533hSviLLYuLu3hDcDuCK9Xf3enmgCbCo7Cy5vFq895UwN/PM5mT GLDzYgGaYCHaAZU1ZRggNkfHaQ== X-Google-Smtp-Source: ABdhPJyBs5U8dR/fCs4H56/RwXNw6AtMq+4fIEZsHq+kAAZocRW7OIaEKiTQ3Rp7aeugGdG7Yb1n4A== X-Received: by 2002:a05:6402:3496:b0:419:82d5:f1d9 with SMTP id v22-20020a056402349600b0041982d5f1d9mr24186351edc.36.1649511871819; Sat, 09 Apr 2022 06:44:31 -0700 (PDT) Received: from [192.168.0.188] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.gmail.com with ESMTPSA id b17-20020aa7dc11000000b00412ae7fda95sm11514582edu.44.2022.04.09.06.44.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Apr 2022 06:44:31 -0700 (PDT) Message-ID: <3e95f567-03f5-bf9c-1856-9fe602e9b025@linaro.org> Date: Sat, 9 Apr 2022 15:44:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 07/18] MIPS: DTS: jz4780: fix otg node as reported by dtbscheck Content-Language: en-US To: "H. Nikolaus Schaller" Cc: Rob Herring , Paul Cercueil , Thomas Bogendoerfer , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mips@vger.kernel.org, letux-kernel@openphoenux.org References: <298162bfa2e7225ccc753865e1ffa39ce2722b2a.1649443080.git.hns@goldelico.com> <822182F3-5429-4731-9FA1-8F18C5D95DEC@goldelico.com> <535e3eab-a28e-46f3-2a7e-f1ffd1913470@linaro.org> <7B66AC66-EF73-4F75-A775-589A4F98BEFC@goldelico.com> From: Krzysztof Kozlowski In-Reply-To: <7B66AC66-EF73-4F75-A775-589A4F98BEFC@goldelico.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 09/04/2022 15:32, H. Nikolaus Schaller wrote: > > >> Am 09.04.2022 um 15:15 schrieb Krzysztof Kozlowski : >> >> On 09/04/2022 15:05, H. Nikolaus Schaller wrote: >>>> >>>> This looks wrong, the block usually should have a specific compatible. >>>> Please mention why it does not. >>> >>> Well, I did not even have that idea that it could need an explanation. >>> >>> There is no "ingenic,jz4780-otg" and none is needed here to make it work. >> >> Make it work in what terms? We talk about hardware description, right? > > Yes. > >> >>> >>> Therefore the generic "snps,dwc2" is sufficient. >> >> No, you are mixing now driver behavior (is sufficient) with hardware >> description. > > No. "snps,dwc2" is a hardware description for a licensed block. > Not a driver behavior. snps,dwc2 matches the original block, not necessarily this implementation. Unless you are sure? > >> Most of licensed blocks require the specific compatible to >> differentiate it. > > If there is a need to differentiate. No, regardless whether there is a need currently, most of them have specific compatibles, because there are some minor differences. Even if difference is not visible from programming model or wiring, it might justify it's own specific compatible. For example because maybe once that tiny difference will require some changes. Someone added the ingenic compatible, so why do you assume that one tool (bindings) is correct but other piece of code (using specific compatible) is not? You use the argument "bindings warning" which is not enough. Argument that blocks are 100% same, is good enough, if you are sure. Just use it in commit msg. But are you sure that these are the same? Same pins, same programming model (entire model, not used by Linux)? Best regards, Krzysztof