linux-kernel - Re: [PATCH v4 1/3] dt-bindings: mfd: Add Realtek switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bc1355d0-c516-4a5a-9a8e-d4bd46343e1c@kernel.org>
Date: Wed, 25 Sep 2024 10:08:34 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "lee@...nel.org" <lee@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
 "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>
Subject: Re: [PATCH v4 1/3] dt-bindings: mfd: Add Realtek switch

On 24/09/2024 22:56, Chris Packham wrote:
> Hi Krzysztof,
> 
> On 24/09/24 20:51, Krzysztof Kozlowski wrote:
>> On 24/09/2024 10:39, Krzysztof Kozlowski wrote:
>>> On Tue, Sep 24, 2024 at 10:57:17AM +1200, Chris Packham wrote:
>>>> Add device tree schema for the Realtek switch. Currently the only
>>>> supported feature is the syscon-reboot which is needed to be able to
>>>> reboot the board.
>>>>
>>>> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
>>>> ---
>>> Reviewed-by: Krzysztof Kozlowski <krzk@...nel.org>
>>>
>> Unreviewed - it is incomplete!
>>
>> No, we said multiple times, you must send complete binding. Sending
>> pieces for review does not give us full picture and hides parts of the
>> controversial decisions. If you want to go this way, next time you will
>> get NAK when adding i2c@0-7 to parent binding.
>>
> Fair enough.
> 
> I did already get myself tied in knots trying to juggle two dependent 
> series. I thought I was making things easier to review by sending them 
> in smaller chunks but obviously I'm holding things back that are 
> relevant for context.

Pieces of chunks works fine for drivers, but bindings is an exception
here: if possible, we want to see entire hardware description.

> 
> So just to be clear, one binding in mfd that covers the reboot and i2c 
> for the 4 variants? That's about as much as I can actually test driver wise.

This can be multiple binding files, multiple patches (organized in
bisectable way)... Not sure about what you ask here.

> 
> I could add the mdio and switch ports but I'm not at a point where I 
> could really test them properly. I know the binding doesn't necessarily 
> need code to be able to describe the hardware but it does run the risk 
> that I might miss something in the binding that I need when I do get to 
> the driver code.

OK, MDIO/switch ports can be skipped. Skip anything which you do not
know how it looks or works yet. But in the case of MFD and I2C, you
already had everything available.

> 
> I also did want to say thanks for your patience. It may not seem like it 
> but I really do appreciate your feedback and I do try to take it all on 
> board.

No worries, you are doing a great job, I appreciate it. I probably sound
harsher than intended.


Best regards,
Krzysztof