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: <62c22a98-76cc-44e7-b759-2dfcc5d692a1@kernel.org>
Date: Thu, 19 Dec 2024 13:44:39 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: 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>, linux-clk@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, upstream@...oha.com
Subject: Re: [PATCH v3 2/4] dt-bindings: clock: drop NUM_CLOCKS define for
 EN7581

On 19/12/2024 13:30, Christian Marangi wrote:
> On Thu, Dec 19, 2024 at 01:28:59PM +0100, Krzysztof Kozlowski wrote:
>> On 19/12/2024 13:18, Christian Marangi wrote:
>>> Drop NUM_CLOCKS define for EN7581 include. This is not a binding and
>>> should not be placed here. Value is derived internally in the user
>>> driver.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
>>> ---
>>> Changes v3:
>>> - Add this patch
>>>
>>>  include/dt-bindings/clock/en7523-clk.h | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/include/dt-bindings/clock/en7523-clk.h b/include/dt-bindings/clock/en7523-clk.h
>>> index c4f8a161b981..edfa64045f52 100644
>>> --- a/include/dt-bindings/clock/en7523-clk.h
>>> +++ b/include/dt-bindings/clock/en7523-clk.h
>>> @@ -14,6 +14,4 @@
>>>  
>>>  #define EN7581_CLK_EMMC		8
>>>  
>>> -#define EN7523_NUM_CLOCKS	8
>> Are you sure your patchset bisects?
>>
> 
> Well bisectability is a problem. Either this can't be dropped or the
> change must be shipped with the driver change.

No, you need to fix order of patches and maybe driver as well. There is
never a problem, if done correctly (which was happening multiple times).

Please do not send non-bisectable changes, especially in hidden way we
need to discover.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ