[PATCH v2] arm64: dts: rockchip: add rfkill node for M.2 E wifi on orangepi-5-plus

[Dragan Simic]

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 at flokli.de>
>> >>> Tested-by: Florian Klink <flokli at flokli.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.