From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78750C433DF for ; Tue, 13 Oct 2020 15:20:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B09424922 for ; Tue, 13 Oct 2020 15:20:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZDCLkG1B" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731122AbgJMPUt (ORCPT ); Tue, 13 Oct 2020 11:20:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbgJMPUs (ORCPT ); Tue, 13 Oct 2020 11:20:48 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AAFEC0613D0 for ; Tue, 13 Oct 2020 08:20:48 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id z22so199690wmi.0 for ; Tue, 13 Oct 2020 08:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9em53n7IKEDSCEYZtHmPvDvhhD75e1+tqMf+AhUYcN4=; b=ZDCLkG1BSn4yzX28Cam+G3NZDw5dwK3VT+N15YmgrZRxnTZz5mmxDJB3t6EfNUCMl/ yNGO9IODIqe/eLuAnfoWNqKtwCZl8rNrECPyV2pTlupb/h85FtJXxbw3xfM94sx3KhG1 qEPQMjSJtYQdBoDUTK2FzVJcB0wCk8AwMuBHCcsjj7eK8k9D4JSgVc4dhwMze67FeZQR h7JQC6aDdElSxxKMQ9L3mfMHw+o91FAERtM3VHKddlOz7ZMtb/KwWHtboYrpUbzVwVUj LN6h8JXHnArz0bMnef6KX1XdLKOmnh7o+rEJN3W2QJTQgEEi/UKPZvtlT6YCuR7MFdJb FP9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9em53n7IKEDSCEYZtHmPvDvhhD75e1+tqMf+AhUYcN4=; b=SoahAG+dTWYzmK2RNnRWcxXxlX/QPq31w4gTwQa6iX08Vblf76dWdxigf6ib2otVY0 nsCvGTrSKx2uVKRsR0uB/oMLTGz/H9+QcJ3RxQwJoV8gtRWC2UtCvSKRzRlqW7l2gjaA CKDcFeGQJbmS1O8sU/cQonx3GLQ+6VYLhkQn9XkwjFV3Hyap8Aqs38Rif+XZ5HJiyDlc O+INFSQzhs3XbEKyJ9tjlxx9TFvEmHiDDDid2cqM4tG6l4VeBrvnWgJScgb6CsK7n8/N R7H/kTcreVNAOLfI2h2w9/mAIMygd0mEXtEyahgDCjBMmM4sQI6fjwCbqHuCqrHGJ1Al XcZA== X-Gm-Message-State: AOAM532CosPlgCmJLKlAx0xjwfAT8PItF3suimHFkWtFNuD3Ciex5L0Z RcziCZQGXFSx/69TnOHbpcbwtA== X-Google-Smtp-Source: ABdhPJyFnJ/cKfn28zIhHhYwEBDs6pJv0b6Na5kylov1gHy9GGl7+H6NbRMIp3c0Rb4SEoNUMB8oAw== X-Received: by 2002:a1c:495:: with SMTP id 143mr337585wme.63.1602602446108; Tue, 13 Oct 2020 08:20:46 -0700 (PDT) Received: from google.com ([2a00:79e0:d:110:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id i10sm11441211wrq.27.2020.10.13.08.20.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 08:20:45 -0700 (PDT) Date: Tue, 13 Oct 2020 16:20:42 +0100 From: Quentin Perret To: "zhuguangqing83" Cc: , , , , , , "'zhuguangqing'" Subject: Re: [PATCH] PM / EM: consult something about cpumask in em_dev_register_perf_domain Message-ID: <20201013152042.GA183119@google.com> References: <098a01d6a112$9cd7f410$d687dc30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <098a01d6a112$9cd7f410$d687dc30$@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 13 Oct 2020 at 11:40:31 (+0800), zhuguangqing83 wrote: > I did not observe anything wrong for my use-case. But I think it's possible > in > theory that cpu_dev maybe NULL. I observe that in the function > scmi_cpufreq_init(), before calling em_dev_register_perf_domain(), > 'policy->cpus' can be ensure that all the cpu_dev in CPU mask are not NULL. > But maybe we can not ensure all the clients do the check. This could happen > if the arch did not set up cpu_dev since this CPU is not in cpu_present mask > and the driver did not send a correct CPU mask during registration. Admittedly this has only been tested on Arm64 where I think we can safely assume that all possible CPUs have been registered at once -- see topology_init(). And for allowing to register CPUs late in a perf domain, I'm not opposed to it in principle but that has deep implications as the existing EM users (e.g. EAS) currently hard rely on it being static after registration. If you have a real need for it and a patch that adds the feature and fixes all the users I'll be happy to look at it :) Thanks, Quentin