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]
Date:   Tue, 13 Jun 2023 14:12:57 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Georgi Djakov <djakov@...nel.org>,
        Leo Yan <leo.yan@...aro.org>,
        Evan Green <evgreen@...omium.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 07/23] interconnect: qcom: icc-rpm: Allow negative QoS
 offset



On 12.06.2023 22:27, Stephan Gerhold wrote:
> On Mon, Jun 12, 2023 at 08:24:24PM +0200, Konrad Dybcio wrote:
>> In some very very very very unfortunate cases, the correct offset of
>> the QoS registers will be.. negative. One such case is MSM8998, where
>> The DDR BWMON occupies what-would-be-the-BIMC-base which we usually
>> take into account with the register calculation, making the actual
>> BIMC node start at what-would-be-the-BIMC-base+0x300.
>>
>> In order to keep the calculation code sane, the simplest - however
>> ugly it may be - solution is to allow the offset to be negative.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> 
> I'm a bit confused why this patch is part of this series. It doesn't
> seem to be directly related.
> 
> Can you send it as part of the series that adds the MSM8998 interconnect
> driver?
Ack

Konrad
> 
> Thanks,
> Stephan
> 
>> ---
>>  drivers/interconnect/qcom/icc-rpm.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
>> index d2c04c400cad..ba840a436cc0 100644
>> --- a/drivers/interconnect/qcom/icc-rpm.h
>> +++ b/drivers/interconnect/qcom/icc-rpm.h
>> @@ -29,10 +29,10 @@ enum qcom_icc_type {
>>   * @num_intf_clks: the total number of intf_clks clk_bulk_data entries
>>   * @type: the ICC provider type
>>   * @regmap: regmap for QoS registers read/write access
>> - * @qos_offset: offset to QoS registers
>>   * @bus_clk_rate: bus clock rate in Hz
>>   * @bus_clks: the clk_bulk_data table of bus clocks
>>   * @intf_clks: a clk_bulk_data array of interface clocks
>> + * @qos_offset: offset to QoS registers
>>   * @keep_alive: whether to always keep a minimum vote on the bus clocks
>>   * @is_on: whether the bus is powered on
>>   */
>> @@ -42,7 +42,7 @@ struct qcom_icc_provider {
>>  	int num_intf_clks;
>>  	enum qcom_icc_type type;
>>  	struct regmap *regmap;
>> -	unsigned int qos_offset;
>> +	int qos_offset;
>>  	u64 bus_clk_rate[NUM_BUS_CLKS];
>>  	struct clk_bulk_data bus_clks[NUM_BUS_CLKS];
>>  	struct clk_bulk_data *intf_clks;
>> @@ -108,7 +108,7 @@ struct qcom_icc_desc {
>>  	bool no_clk_scaling;
>>  	enum qcom_icc_type type;
>>  	const struct regmap_config *regmap_cfg;
>> -	unsigned int qos_offset;
>> +	int qos_offset;
>>  };
>>  
>>  /* Valid for all bus types */
>>
>> -- 
>> 2.41.0
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ