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] [thread-next>] [day] [month] [year] [list]
Message-ID: <13ced390-71a0-4edf-b2f0-19195ec30c22@linaro.org>
Date: Wed, 20 Mar 2024 08:31:11 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Ayush Singh <ayushdevel1325@...il.com>,
 open list <linux-kernel@...r.kernel.org>
Cc: jkridner@...gleboard.org, robertcnelson@...gleboard.org,
 lorforlinux@...gleboard.org, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
 Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>,
 Derek Kiernan <derek.kiernan@....com>, Dragan Cvetic
 <dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Vaishnav M A <vaishnav.a@...com>, Mark Brown <broonie@...nel.org>,
 Johan Hovold <johan@...nel.org>, Alex Elder <elder@...nel.org>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>,
 "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE"
 <linux-arm-kernel@...ts.infradead.org>,
 "open list:SPI SUBSYSTEM" <linux-spi@...r.kernel.org>,
 "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@...ts.linaro.org>,
 Vaishnav M A <vaishnav@...gleboard.org>
Subject: Re: [PATCH v4 5/5] dts: ti: k3-am625-beagleplay: Add mikroBUS

On 19/03/2024 07:34, Ayush Singh wrote:
> 
> On 3/19/24 11:29, Krzysztof Kozlowski wrote:
>> On 17/03/2024 20:37, Ayush Singh wrote:
>>> DONOTMERGE
>> Why? Explain then the purpose of this patch.
> 
> Well, it was suggested to have DONOTMERGE by Vaishnav in the patches 
> until dt bindings have been approved, since this patch touches different 
> subsystems. Here is the full context from v3:
> 
>> The reasoning behind this is that these patches go in to separate  maintainer trees and without the bindings merged first the device tree changes cannot be validated, thus it is a usual practice to get the bindings and driver merged first and the device tree changes to go in the next cycle. Another alternative is you can point to your fork with  all the changes together.

This is some odd style of work. Please don't follow such advise.

> 
>>> this patch depends on patch 1
>> How? I don't see any dependency.
> 
> I think it is not allowed to have code in device tree unless a 
> corresponding dt-binding exists for the device. And thus every time the 

And you provided the binding.

> dt-binding changes, this patch also needs to change.So I thought it is 
> dependent on patch 1.

But it is not a dependency. Dependency means something does not work
without another. Or something must be applied in the same branch as
another. None of the cases are here. Drop the statements.

This is no different than all of our regular works. Do you see any of
such comments ("dont merge", "dependency")? No.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ