From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Frank Wunderlich <linux@fw-web.de>,
Frank Wunderlich <frank-w@public-files.de>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Lee Jones <lee@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Eric Woudstra <ericwouds@gmail.com>,
Tianling Shen <cnsztl@immortalwrt.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-leds@vger.kernel.org,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Tianling Shen <cnsztl@gmail.com>
Subject: Re: Aw: Re: [RFC v1 5/5] arm64: dts: mediatek: Add mt7986 based Bananapi R3 Mini
Date: Thu, 9 May 2024 12:35:37 +0200 [thread overview]
Message-ID: <708ed735-1666-4da3-8d8f-d0ba073f6360@collabora.com> (raw)
In-Reply-To: <7859DAB9-107F-432D-AA3D-0F54AE0E30D5@fw-web.de>
Il 09/05/24 12:30, Frank Wunderlich ha scritto:
> Am 9. Mai 2024 12:10:59 MESZ schrieb AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
>> Il 08/05/24 20:25, Frank Wunderlich ha scritto:
>>> Hi
>>>
>>>> Gesendet: Dienstag, 07. Mai 2024 um 15:35 Uhr
>>>> Von: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
>>>>
>>>> Il 06/05/24 18:00, Frank Wunderlich ha scritto:
>>>
>>>>>>> + fan: pwm-fan {
>>>>>>> + compatible = "pwm-fan";
>>>>>>> + #cooling-cells = <2>;
>>>>>>> + /* cooling level (0, 1, 2) - pwm inverted */
>>>>>>> + cooling-levels = <255 96 0>;
>>>>>>
>>>>>> Did you try to actually invert the PWM?
>>>>>>
>>>>>> Look for PWM_POLARITY_INVERTED ;-)
>>>>>
>>>>> Mtk pwm driver does not support it
>>>>>
>>>>> https://elixir.bootlin.com/linux/latest/source/drivers/pwm/pwm-mediatek.c#L211
>>>>>
>>>>
>>>> You're right, sorry - I confused the general purpose PWM controller with the
>>>> rather specific DISP_PWM controller (which does support polarity inversion).
>>>>
>>>> It's good - but I'd appreciate if you can please add a comment stating that
>>>> the PWM values are inverted in SW because the controller does *not* support
>>>> polarity inversion... so that next time someone looks at this will immediately
>>>> understand what's going on and why :-)
>>>
>>> so i would change comment like this:
>>>
>>> /* cooling level (0, 1, 2)
>>> * signal is inverted on board
>>> * mtk pwm driver does not support
>>> * PWM_POLARITY_INVERTED */
>>>
>>
>> There you go:
>>
>> /*
>> * The signal is inverted on this board and the general purpose
>> * PWM HW IP in this SoC does not support polarity inversion.
>> */
>> /* Cooling level < 0 1 2> */
>> cooling-levels = <255 96 0>;
>
> Thanks for clearing structure of the comment,but imho actually it is a driver issue (for all mtk SoC). Not sure it is really a hardware limitation. So i would change this to "... and the PWM driver does not support polarity inversion."
>
>>>>>>> + pwms = <&pwm 0 10000>;
>>>>>>> + status = "okay";
>>>>>>> + };
>>>>>>> +
>>>>>>> + phy14: ethernet-phy@14 {
>>> ...
>>>>>>> + interrupts-extended = <&pio 48 IRQ_TYPE_EDGE_FALLING>;
>>>>>>> + reset-gpios = <&pio 49 GPIO_ACTIVE_LOW>;
>>>>>>> + reset-assert-us = <10000>;
>>>>>>> + reset-deassert-us = <20000>;
>>>>>>> + phy-mode = "2500base-x";
>>>>>>> + full-duplex;
>>>>>>> + pause;
>>>>>>> + airoha,pnswap-rx;
>>>>>>> +
>>>>>>> + leds {
>>>>>>> + #address-cells = <1>;
>>>>>>> + #size-cells = <0>;
>>>>>>> +
>>>>>>> + led@0 { /* en8811_a_gpio5 */
>>>>>>> + reg = <0>;
>>>>>>> + color = <LED_COLOR_ID_YELLOW>;
>>>>>>> + function = LED_FUNCTION_LAN;
>>>>>>> + function-enumerator = <1>;
>>>>>>
>>>>>> Why aren't you simply using a label?
>>>>>
>>>>> You mean the comment? I can add it of course like for regulators.
>>>>>
>>>>
>>>> I mean in place of the function-enumerator... that's practically used to
>>>> distinguish between instances, it's not too common to see it, and usually
>>>> "label" replaces exactly that - just that, instead of a different number,
>>>> it gets a different name with no (usually) meaningless numbers :-)
>>>
>>> as far as i understand using label also makes "function" property useless, after discussing
>>> this with eric i would drop both on all 4 places by labels like these:
>>>
>>> label = "yellow-lan";
>>> label = "green-lan";
>>> ...
>>>
>>> not sure if we should drop color property too...
>>>
>>
>> I'm looking at the leds binding (leds/common.yaml) right now.
>>
>> My suggestion of using 'label' was actually wrong - and your devicetree was
>> actually right!!! (apart from the default-trigger that may not work)
>>
>> Infact, the documentation says, in brief:
>>
>> - function-enumerator is ignored if label is present
>> - function doesn't say that gets ignored
>> - color doesn't say that gets ignored
>> - label says:
>> - If not present -> get string from node name
>> - function-enumerator ignored
>> - This property is deprecated
>>
>> ...but the 'label' binding does not say 'deprecated: true', which is something
>> that must be fixed!
>
> Ok,i can try to add the property to binding (independ of this series). Imho label was cleaner than function and function-enumerator...
>
Oh I sort of agree with you, I liked the label more, as it's more consistent with
everything else... but oh well. :-)
>> So, I'm sorry for the confusion, the noise and the useless loss of time around
>> this - you can keep the LED nodes as they are, and that's a lesson for the future
>> me reviewing another node like this one.
>
> Don't worry, we are all humas...i missed looking in linux-next for the other binding-patches.
>
>> P.S.: This shouldn't have been a RFC, as the patches are more than RFC quality!!!
>
> I sent it as RFC because i had not expected to be merged before next is closed.
>
Ah at least from my side, no worries... when I see RFC I generally expect to see
"dubious/head-scratching stuff", not "sub-optimal timing to send a patch" :-P
Cheers!
Angelo
>>
>>>>>>> + default-state = "keep";
>>>>>>> + linux,default-trigger = "netdev";
>>>>>>> + };
>>>>>>> + led@1 { /* en8811_a_gpio4 */
>>>>>>> + reg = <1>;
>>>>>>> + color = <LED_COLOR_ID_GREEN>;
>>>>>>> + function = LED_FUNCTION_LAN;
>>>>>>> + function-enumerator = <2>;
>>>>>>> + default-state = "keep";
>>>>>>> + linux,default-trigger = "netdev";
>>>>>>> + };
>>>>>>> + };
>>>>>>> + };
>>>>>>> +
>>>>>>> + phy15: ethernet-phy@15 {
>>>>>>> + reg = <15>;
>
>
> regards Frank
next prev parent reply other threads:[~2024-05-09 10:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-05 16:45 [RFC v1 0/5] Add Bananapi R3 Mini Frank Wunderlich
2024-05-05 16:45 ` [RFC v1 1/5] dt-bindings: leds: add led trigger netdev Frank Wunderlich
2024-05-06 8:18 ` Krzysztof Kozlowski
2024-05-06 8:59 ` Daniel Golle
2024-05-06 17:10 ` Aw: " Frank Wunderlich
2024-05-07 6:10 ` Krzysztof Kozlowski
2024-05-05 16:45 ` [RFC v1 2/5] dt-bindings: clock: mediatek: add address-cells and size-cells to ethsys Frank Wunderlich
2024-05-06 8:18 ` Krzysztof Kozlowski
2024-05-06 16:51 ` Aw: " Frank Wunderlich
2024-05-07 19:35 ` Rob Herring
2024-05-07 21:22 ` Aw: " Frank Wunderlich
2024-05-06 12:48 ` AngeloGioacchino Del Regno
2024-05-06 16:01 ` Frank Wunderlich
2024-05-07 13:36 ` AngeloGioacchino Del Regno
2024-05-05 16:45 ` [RFC v1 3/5] dt-bindings: net: mediatek,net: add reset-cells Frank Wunderlich
2024-05-06 8:19 ` Krzysztof Kozlowski
2024-05-07 19:37 ` Rob Herring
2024-05-05 16:45 ` [RFC v1 4/5] dt-bindings: arm64: dts: mediatek: add BananaPi R3 Mini Frank Wunderlich
2024-05-05 16:45 ` [RFC v1 5/5] arm64: dts: mediatek: Add mt7986 based Bananapi " Frank Wunderlich
2024-05-06 8:20 ` Krzysztof Kozlowski
2024-05-06 16:40 ` Aw: " Frank Wunderlich
2024-05-06 12:48 ` AngeloGioacchino Del Regno
2024-05-06 16:00 ` Frank Wunderlich
2024-05-06 16:12 ` Daniel Golle
2024-05-07 13:35 ` AngeloGioacchino Del Regno
2024-05-08 18:25 ` Aw: " Frank Wunderlich
2024-05-09 10:10 ` AngeloGioacchino Del Regno
2024-05-09 10:30 ` Frank Wunderlich
2024-05-09 10:35 ` AngeloGioacchino Del Regno [this message]
2024-05-06 20:40 ` [RFC v1 0/5] Add " Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=708ed735-1666-4da3-8d8f-d0ba073f6360@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=cnsztl@gmail.com \
--cc=cnsztl@immortalwrt.org \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=ericwouds@gmail.com \
--cc=frank-w@public-files.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@fw-web.de \
--cc=matthias.bgg@gmail.com \
--cc=mturquette@baylibre.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavel@ucw.cz \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).