linux-kernel - Re: [PATCH v4 4/5] mikrobus: Add mikroBUS driver

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]

Date: Tue, 19 Mar 2024 13:30:07 +0530
From: Vaishnav Achath <vaishnav.a@...com>
To: Ayush Singh <ayushdevel1325@...il.com>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski@...aro.org>,
        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>,
        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 4/5] mikrobus: Add mikroBUS driver

Hi Ayush,

On 19/03/24 12:17, Ayush Singh wrote:
> On 3/19/24 11:34, Krzysztof Kozlowski wrote:
> 
>> On 17/03/2024 20:37, Ayush Singh wrote:
>>> DONOTMERGE
>>>
>>> this patch depends on Patch 1, 2, 3
>> So none of your work should be reviewed? I don't understand this, but in
>> such case I am not going to review it.
>>
>> Best regards,
>> Krzysztof
>>
> I am a bit lost here. It was mentioned in the patch v3 that I should 
> specify the interdependence of patches in v3. And now you are saying I 
> should not?
> 

It was mentioned in v3 that patches that are independent should be sent 
separately to the particular subsytem list and the dependencies should 
be mentioned in this series, still in this series you have combined SPI 
patches/platform DT changes along with the mikroBUS driver patches which 
creates confusion.

This is what I mentioned as a response to your v3 series regarding 
adding the patches

"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."

My suggestion was to get your series with the bindings and the base 
driver support accepted/ready first and the send the platform specific 
DT changes later. The rationale behind pointing to your fork with all 
changes is to have all the changes (w1 EEPROM, instantiating remote 
mikrobus ports over greybus .etc) together and ensure there are no 
conflicts with the base series.

It looks like you have put DONOTMERGE on random patches (why is patch 3 
and 4 marked as do not merge?)

Thanks and Regards,
Vaishnav

> Here is the rationale for the dependence:
> 
> 1. Any changes to the property names in dt-bindings patch 1 will need an 
> appropriate change here.
> 
> 2. This patch will fail to build without patch 2.
> 
> 3. This patch will fail to build without patch 3.
> 
> 
> Ayush Singh
>