linux-kernel - Re: [PATCH 0/2] clk: qcom: Add support for GCC on QCS8300

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: <c6t35o5pnqw25x6gho725qvpgyr6bl2xkpsurq4jtjgii2v5mq@mvdl64azwpz4>
Date: Tue, 20 Aug 2024 13:02:59 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Imran Shaik <quic_imrashai@...cinc.com>
Cc: Bjorn Andersson <andersson@...nel.org>, 
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Richard Cochran <richardcochran@...il.com>, Ajit Pandey <quic_ajipan@...cinc.com>, 
	Taniya Das <quic_tdas@...cinc.com>, Jagadeesh Kona <quic_jkona@...cinc.com>, 
	Satya Priya Kakitapalli <quic_skakitap@...cinc.com>, linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 0/2] clk: qcom: Add support for GCC on QCS8300

On Tue, Aug 20, 2024 at 03:38:39PM +0530, Imran Shaik wrote:
> 
> 
> On 8/20/2024 3:27 PM, Krzysztof Kozlowski wrote:
> > On 20/08/2024 11:36, Imran Shaik wrote:
> > > This series adds the dt-bindings and driver support for GCC on QCS8300 platform.
> > > 
> > > Please note that this series is dependent on [1] which adds support
> > > for QCS8275/QCS8300 SoC ID.
> > > 
> > > [1] https://lore.kernel.org/all/20240814072806.4107079-1-quic_jingyw@quicinc.com/
> > 
> > How do the depend? What is exactly the dependency?
> > 
> > If so this cannot be merged...
> > 
> 
> They are not functionally dependent, but we want to ensure the base QCS8300
> changes to merge first and then our GCC changes. Hence added the dependency.

This does not work like that, these are different trees, even if they go
via Bjorn.

Why do you insist on some specific workflow, different than every
upstreaming process? What is so special here?

If you keep insisting, I will keep disagreeing, because it is not
justified and just complicates things unnecessarily.