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 B6481C352A1 for ; Tue, 6 Dec 2022 08:39:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231425AbiLFIjQ (ORCPT ); Tue, 6 Dec 2022 03:39:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232490AbiLFIiq (ORCPT ); Tue, 6 Dec 2022 03:38:46 -0500 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABC2FE78 for ; Tue, 6 Dec 2022 00:38:44 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id cf42so16773818lfb.1 for ; Tue, 06 Dec 2022 00:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ANyVsngf65a+eFmtwb0iMJHr0EeOJEcLYKSjm4qNpxI=; b=NJMk55P+sC/tqvVTE5YgKq8nQusWlrdEnAyJYx0CsOvhX9rLKLkm4pnwSIvQk6SAZm ONCSQRQ1JXQIeAKiPGbM848T1ZIW2d7l+/tP6GaB06wKMQ1zq7TJupMR4/QJbvZ5AYzA KApImDchL4woQ6iEfLs7s0HrjmzKegSkNkD2M+/HxZDyfrsw9Jx1zbwGJH/Kk9Uly+lq zNtBHZXfMM1sNaFXNCHVqjnEJoph6+nUF/9/bZ9T+GjzR2z+j2IPdhMflij5zxKIwQwL FHdA+RgpZ0/9YNbYpGoZ2PzHSdM6qC735HYmAsZ2Ow4Ex7LA2iZ7foVSmULQ6AB52RdM W3Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ANyVsngf65a+eFmtwb0iMJHr0EeOJEcLYKSjm4qNpxI=; b=ZgSDFXZZIZYGYkQ4DFiM5cPLqDbFKHlgpzEEPbdakYCzcn4+0oq//vMT5JxzR0qYNy xjDo79Oz5yyak9QuXVeJYU8OXKOhs33iYL7usc11c0zpBeE6DfimluVR3E0uC3EoKEfa g6Bdvu2RMamMzlm8gp3hI+7CWxhqImp8S94GoFlBDD2PgRkllgsBHF4X7PTKGsb0OehN sYbnwJhE9fDDzczJnj68pjGnTfSb9ZLtuU+ghICcmrNN6FEG3BmtFQLCm+HGnpaDe26g +iOS7sNMQlVAobcIeOVYLYz63IxzJl9UOBV5Uly9zqDudZOQAEvt89ZG/cCJ2+sRMA6q aNQw== X-Gm-Message-State: ANoB5pncS+FyRzdsqAPqsdwMpSW1mQaeQirpUBzrKawLMF1hP2lUFMsW lHs7f8ukaVcreqd4AQ9aXUy0kw== X-Google-Smtp-Source: AA0mqf64avDHaRy5jJ5LqrBrk9vceu4eOGM5kyWEz2n90p+ntO8hFrEe7y5FzENUFnVh7tv2lJ+tuA== X-Received: by 2002:a05:6512:445:b0:4b5:8d2c:fc36 with SMTP id y5-20020a056512044500b004b58d2cfc36mr31490lfk.505.1670315922955; Tue, 06 Dec 2022 00:38:42 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id bi20-20020a05651c231400b002773ac59697sm1599383ljb.0.2022.12.06.00.38.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Dec 2022 00:38:42 -0800 (PST) Message-ID: <2597b9e5-7c61-e91c-741c-3fe18247e27c@linaro.org> Date: Tue, 6 Dec 2022 09:38:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH net-next v1 3/4] dt-bindings: net: phy: add MaxLinear GPY2xx bindings Content-Language: en-US To: Michael Walle , Rob Herring Cc: Xu Liang , Andrew Lunn , Heiner Kallweit , Russell King , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org References: <20221202151204.3318592-1-michael@walle.cc> <20221202151204.3318592-4-michael@walle.cc> <20221205212924.GA2638223-robh@kernel.org> <99d4f476d4e0ce5945fa7e1823d9824a@walle.cc> <9c0506a6f654f72ea62fed864c1b2a26@walle.cc> From: Krzysztof Kozlowski In-Reply-To: <9c0506a6f654f72ea62fed864c1b2a26@walle.cc> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 06/12/2022 09:29, Michael Walle wrote: > Am 2022-12-05 22:53, schrieb Michael Walle: >> Am 2022-12-05 22:29, schrieb Rob Herring: >>> On Fri, Dec 02, 2022 at 04:12:03PM +0100, Michael Walle wrote: >>>> Add the device tree bindings for the MaxLinear GPY2xx PHYs. >>>> >>>> Signed-off-by: Michael Walle >>>> --- >>>> >>>> Is the filename ok? I was unsure because that flag is only for the >>>> GPY215 >>>> for now. But it might also apply to others. Also there is no >>>> compatible >>>> string, so.. >>>> >>>> .../bindings/net/maxlinear,gpy2xx.yaml | 47 >>>> +++++++++++++++++++ >>>> 1 file changed, 47 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml >>>> b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml >>>> new file mode 100644 >>>> index 000000000000..d71fa9de2b64 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml >>>> @@ -0,0 +1,47 @@ >>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/net/maxlinear,gpy2xx.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: MaxLinear GPY2xx PHY >>>> + >>>> +maintainers: >>>> + - Andrew Lunn >>>> + - Michael Walle >>>> + >>>> +allOf: >>>> + - $ref: ethernet-phy.yaml# >>>> + >>>> +properties: >>>> + maxlinear,use-broken-interrupts: >>>> + description: | >>>> + Interrupts are broken on some GPY2xx PHYs in that they keep >>>> the >>>> + interrupt line asserted even after the interrupt status >>>> register is >>>> + cleared. Thus it is blocking the interrupt line which is >>>> usually bad >>>> + for shared lines. By default interrupts are disabled for this >>>> PHY and >>>> + polling mode is used. If one can live with the consequences, >>>> this >>>> + property can be used to enable interrupt handling. >>> >>> Just omit the interrupt property if you don't want interrupts and add >>> it >>> if you do. >> >> How does that work together with "the device tree describes >> the hardware and not the configuration". The interrupt line >> is there, its just broken sometimes and thus it's disabled >> by default for these PHY revisions/firmwares. With this >> flag the user can say, "hey on this hardware it is not >> relevant because we don't have shared interrupts or because >> I know what I'm doing". Yeah, that's a good question. In your case broken interrupts could be understood the same as "not connected", so property not present. When things are broken, you do not describe them fully in DTS for the completeness of hardware description, right? > > Specifically you can't do the following: Have the same device > tree and still being able to use it with a future PHY firmware > update/revision. Because according to your suggestion, this > won't have the interrupt property set. With this flag you can > have the following cases: > (1) the interrupt information is there and can be used in the > future by non-broken PHY revisions, > (2) broken PHYs will ignore the interrupt line > (3) except the system designer opts-in with this flag (because > maybe this is the only PHY on the interrupt line etc). I am not sure if I understand the case. You want to have a DTS with interrupts and "maxlinear,use-broken-interrupts", where the latter will be ignored by some future firmware? Isn't then the property not really correct? Broken for one firmware on the same device, working for other firmware on the same device? I would assume that in such cases you (or bootloader or overlay) should patch the DTS... Best regards, Krzysztof