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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ