[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f524a2e5ddbec28dbbc0be4ef47a120b@manjaro.org>
Date: Wed, 07 Aug 2024 23:30:40 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Alexey Charkov <alchark@...il.com>
Cc: Florian Klink <flokli@...kli.de>, linux-rockchip@...ts.infradead.org,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
Sebastian Reichel <sebastian.reichel@...labora.com>, Kever Yang
<kever.yang@...k-chips.com>, Muhammed Efe Cetin <efectn@...tonmail.com>,
FUKAUMI Naoki <naoki@...xa.com>, Tamás Szűcs
<tszucs@...tonmail.ch>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: dts: rockchip: add rfkill node for M.2 E wifi
on orangepi-5-plus
Hello Alexey,
On 2024-08-07 23:12, Alexey Charkov wrote:
> On Wednesday, August 7, 2024 9:32:51 PM GMT+3 Dragan Simic wrote:
>> On 2024-08-07 20:14, Florian Klink wrote:
>> > On Wed, Aug 07, 2024 at 07:24:27PM GMT, Dragan Simic wrote:
>> >> On 2024-08-07 19:00, Florian Klink wrote:
>> >>> This follows the same logic as 82d40b141a4c ("arm64: dts: rockchip:
>> >>> add
>> >>> rfkill node for M.2 Key E WiFi on rock-5b").
>> >>>
>> >>> On the orangepi-5-plus, there's also a GPIO pin connecting the WiFi
>> >>> enable signal inside the M.2 Key E slot.
>> >>>
>> >>> The exact GPIO PIN can be validated in the Armbian rk-5.10-rkr4
>> >>> kernel
>> >>> rk3588-orangepi-5-plus.dtsi file [1], which contains a `wifi_disable`
>> >>> node referencing RK_PC4 on &gpio0.
>> >>>
>> >>> Signed-off-by: Florian Klink <flokli@...kli.de>
>> >>> Tested-by: Florian Klink <flokli@...kli.de>
>> >>
>> >> I forgot to mention that providing a Tested-by tag is redundant when
>> >> there's already a Signed-off-by tag, because the latter already
>> >> implies
>> >> the former.
>> >
>> > This came after I sent the v3. Generally I wish people would test
>> > things
>> > - though too often it's not. I explicitly tested this to work (with a
>> > wifi module added to that slot being unblock-able afterwards), and
>> > wanted to point that out, thus adding the Tested-by.
>>
>> In general, some time should be allowed between sending consecutive
>> versions of the same patch, so people can provide their feedback.
>>
>> When it comes to testing the submitted patches, please note that
>> signing
>> off a patch implies that the signer has already, to the best of their
>> abilities, made sure that the patch works as described and expected.
>>
>> With all that in mind, please allow me to repeat that a Tested-by tag
>> should not be provided from the same person that the Signed-off-by tag
>> is already coming from. It's simply redundant.
>
> Just two cents: perhaps dropping the tag and expanding the commit
> message a
> bit could be the best of both worlds. Just state that you tested it
> with such
> and such module, observing such and such results. That would also help
> if for
> example another user tries a different module and that fails due to
> some
> quirks: it's easier to debug a potential issue when one knows a working
> configuration to compare a non-working one against.
Totally agreed. Providing as much detail of the performed testing
as possible in the patch description is always a good thing.
Powered by blists - more mailing lists