Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2411987pxb; Sun, 30 Jan 2022 15:41:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJzAMSN6hAFj8dRNFjF8Ae+mQg5TN47eIOvl+xBC0s6KO9kohSK1xfaDUdyUTcDYyfjfKpzb X-Received: by 2002:a17:906:ae8a:: with SMTP id md10mr15421659ejb.726.1643586080419; Sun, 30 Jan 2022 15:41:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643586080; cv=none; d=google.com; s=arc-20160816; b=SFcuejPjni66elYG0bvBuSJKjnvX+eMwoNVuE2v5ibQvBEDKOnaHqrzG5dW1yuObvd hTJ1TCQ1hSDncEjQkQM9/tpR5elRyeZEdDm4PPTrkrWOwWhen4r7l5mq35YV7DgwCEYH ZxUCfDLSceWl9DkQKFHNb0fpDk3X8P+o/Vxy3gc+fqccMlnIba6DFZQR76EfAZgSthjL 0uda7VDel6H1+5zVzkUXom+42SY//bIfUTa1fRoDFUutHLmsj36LLJFF9S48rzVHegwF JiwTITN1ekHibytwkZF70M89bVm2zOvZNp5d1DeEo2quHmw/9Xt1ZluojyjP/Y8WilwZ GIUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=eLTKyyTk86fw8+vZ3HGXFL99c3hJSRNtS/XfXWZ0v/w=; b=EYYHEgChQdpwF5+31UwaWSI3dw6AwXCnscPPLfLZ/d/AjtIpgCR+0NJ0LNQ7Qghgcn 3NgoHmZsuL+Wl3fIjXaJheu/1bj29KW+M40jn1WyoV0210L5WkVAgSDHlskj3M/0Uci6 l+sMuX5Ex9cZsdPWA/UqPCGK6s6ihGkieQO1y8v3hCpCbHx7GTOMCeaGXK9eAmrngdi8 vMBPQP1ZNKcyzWBGdJinutIrjqNApolammqfUezm2rXpdL7EHlZvBwRBRsFRCtoO/3sd sY1AfdME9/JQWMtav2NT9DSCddIfOsuM4evBYC8ewa5e7QYgxYEMqP2TUeMi6Wr1N4OI dpMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u8si6289052eju.571.2022.01.30.15.40.56; Sun, 30 Jan 2022 15:41:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236360AbiA1Kjo (ORCPT + 99 others); Fri, 28 Jan 2022 05:39:44 -0500 Received: from foss.arm.com ([217.140.110.172]:35540 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiA1Kjo (ORCPT ); Fri, 28 Jan 2022 05:39:44 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB643113E; Fri, 28 Jan 2022 02:39:43 -0800 (PST) Received: from [10.57.12.131] (unknown [10.57.12.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 59F8E3F766; Fri, 28 Jan 2022 02:39:42 -0800 (PST) Subject: Re: [PATCH v2 2/2] cpufreq: qcom-hw: Delay enabling throttle_irq To: Bjorn Andersson Cc: Jonathan Corbet , linux-pm@vger.kernel.org, "Rafael J. Wysocki" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Viresh Kumar References: <20220128032554.155132-1-bjorn.andersson@linaro.org> <20220128032554.155132-2-bjorn.andersson@linaro.org> From: Lukasz Luba Message-ID: <5433250b-ee51-06e0-3ef8-ab287a112611@arm.com> Date: Fri, 28 Jan 2022 10:39:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220128032554.155132-2-bjorn.andersson@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/28/22 3:25 AM, Bjorn Andersson wrote: > In the event that the SoC is under thermal pressure while booting it's > possible for the dcvs notification to happen inbetween the cpufreq > framework calling init and it actually updating the policy's > related_cpus cpumask. > > Prior to the introduction of the thermal pressure update helper an empty > cpumask would simply result in the thermal pressure of no cpus being > updated, but the new code will attempt to dereference an invalid per_cpu > variable. Just to confirm, is that per-cpu var the 'policy->related_cpus' in this driver? > > Avoid this problem by using the newly reintroduced "ready" callback, to > postpone enabling the IRQ until the related_cpus cpumask is filled in. > > Fixes: 0258cb19c77d ("cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function") You have 'Fixes' tagging here, which might be picked by the stable tree. The code uses the reverted callback .ready(), which might be missing there (since patch 1/2 doesn't have tagging). This patch looks like a proper fix for the root cause. Anyway, I'm going to send a patch, which adds a check for null cpumask in the topology_update_thermal_pressure() It was removed after the review comments: https://lore.kernel.org/linux-pm/20211028054459.dve6s2my2tq7odem@vireshk-i7/ I'll also push that change for the stable tree. Regards, Lukasz