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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 28 May 2020 10:44:01 -0700
From:   Jolly Shah <>
To:     Stephen Boyd <>,
        Jolly Shah <>,,,,,
Cc:,,, Tejas Patel <>,
        Rajan Vaja <>
Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check
 from custom type flags

Hi Stephan,

Thanks for the review.

 > ------Original Message------
 > From: Stephen Boyd <>
 > Sent:  Tuesday, May 26, 2020 6:08PM
 > To: Jolly Shah <>, Arm <>, 
Linux-clk <>, Michal Simek 
<>, Mturquette <>, Olof 
 > Cc: Rajan Vaja <>, 
<>, Tejas Patel <>, 
Rajan Vaja <>, Jolly Shah <>
 > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction 
clock check from custom type flags
> Quoting Jolly Shah (2020-03-12 14:31:39)
>> From: Tejas Patel <>
>> Older firmware version sets BIT(13) in clkflag to mark a
>> divider as fractional divider. Updated firmware version sets BIT(4)
>> in type flags to mark a divider as fractional divider since
>> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
>> framework flags.
>> To support both old and new firmware version, consider BIT(13) from
>> clkflag and BIT(4) from type_flag to check if divider is fractional
>> or not.
>> To maintain compatibility BIT(13) of clkflag in firmware will not be
>> used in future for any purpose and will be marked as unused.
> Why are we mixing the firmware flags with the ccf flags? They shouldn't
> be the same. The firmware should have its own 'flag numberspace' that is
> distinct from the common clk framework's 'flag numberspace'. Please fix
> the code.

Yes firmware flags are using separate numberspace now. Firmware 
maintains CCF and firmware specific flags separately but earlier 
CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here 
for backward compatibility. Driver takes care of not registering same 
with CCF. Let me know if I misunderstood.

Jolly Shah

Powered by blists - more mailing lists