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 B8799C00140 for ; Tue, 2 Aug 2022 08:33:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235113AbiHBId4 (ORCPT ); Tue, 2 Aug 2022 04:33:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233814AbiHBIdz (ORCPT ); Tue, 2 Aug 2022 04:33:55 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 953EE237D1 for ; Tue, 2 Aug 2022 01:33:54 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id e15so10887905lfs.0 for ; Tue, 02 Aug 2022 01:33:54 -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=1ozmbsN2tgjXvPMdLMQFGo2ZV9fcaQMnF+02jQaScWo=; b=xiDFHToAk53VqqiejooYK/XgNB5mKuNz8WRx/QqME+8fOqnbf+fM8Vxd7FAAatCyJx hvU1TGDiOfHaUWhFP2YZApPg5ShXnWIAsahH5o+ul7zbNBW7rWJVihGhwjvE6teAvwdK wLsAJiemDPc68V7aQLFnMwgFh6kH3OyAVRyhk7UG5hqJ3fqzttbWyFfDezbMEdIxHz2X Hqo45gVcyArFQi+RpBv2sk8UlVcnIeNqwwgRqJDTw17K1rhw2xyHkrolTK0jzqqtk/Zc Cqz4bsnwSgM2QmwYMTVCaYGsJhGX1Gbiaz9dgELpIduIQq3AoBVrcYurKvBIRnTKBz+9 v/eQ== 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=1ozmbsN2tgjXvPMdLMQFGo2ZV9fcaQMnF+02jQaScWo=; b=7anV26W+ES17bWtcKOwMJd8EnH6jldKgqXyUmX8cL2Q1qYKCPFqLJlBr70gjJ1q2k/ APQCIJIt2BJxcOGoeFxC2EG6mgozrUU/hUsWLRYMtvIf71Pbh5vO6dP/fdYXhR4GdjKy KLOOICsb8E+f1qg8InM5OJXYLRjkwwt4uf5xQkLACZf33+nck2LHWDq3uUwwAAiD+V+S A0OUPnSny0kXnXX8Gk43juPIMmF8P/abkWmlW/1NCsRN00/Xa2zrqapea27AteIiPR+u /e3StwipVwCrSCef05JaRaou6OZ6BiCApGabY5jbBks+XTfAtvEPxf8tJ9fPqb4rNO/f HufQ== X-Gm-Message-State: AJIora/gwlZa+IgSmF3ymtBZa9HgXZ8PMMT+mqqroDgBgstnSpKK/Uc+ iida5wsKHlZIs1u6qT+lzLM8SqtnqmJwmI4L X-Google-Smtp-Source: AGRyM1sQl5cqH63HPgknS6/o1ykpwybk//qudzbfgglFjDL8qQJpX626a+cQNqh9Xlkj2+M40g0KWQ== X-Received: by 2002:a19:dc4d:0:b0:489:63cb:20c7 with SMTP id f13-20020a19dc4d000000b0048963cb20c7mr6494786lfj.101.1659429232964; Tue, 02 Aug 2022 01:33:52 -0700 (PDT) Received: from [192.168.1.6] ([213.161.169.44]) by smtp.gmail.com with ESMTPSA id t17-20020a2e4611000000b0025e1ec74e25sm869652lja.43.2022.08.02.01.33.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Aug 2022 01:33:52 -0700 (PDT) Message-ID: <64e3702b-f09b-5a2e-b6a5-4c8752fbad77@linaro.org> Date: Tue, 2 Aug 2022 10:33:50 +0200 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 9/9] ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from Pro5 pcie-ep node Content-Language: en-US To: Arnd Bergmann , Kunihiko Hayashi Cc: Rob Herring , Krzysztof Kozlowski , Masami Hiramatsu , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <1656894026-15707-1-git-send-email-hayashi.kunihiko@socionext.com> <1656894026-15707-10-git-send-email-hayashi.kunihiko@socionext.com> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 30/07/2022 13:58, Arnd Bergmann wrote: > On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi > wrote: >> >> UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" compatible, >> so this is no longer needed. Remove the compatible string from the pcie-ep >> node to fix the following warning. >> >> uniphier-pro5-epcore.dtb: pcie@66000000: compatible: ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long >> From schema: Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml >> > > This sounds like a problem with the binding rather than the dt file. Is this not > a designware pci endpoint? Should it be documented in that binding instead? Depends. We had one or two similar cases, where we dropped the snps/dw generic compatible, because device was actually quite different and could not match against snps/dw compatible. IOW, if device bound/matched via generic compatible it would be entirely non-operational. Logically I think it is okay to drop the generic compatible. Different question is any ABI break. Best regards, Krzysztof