Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1169913pxk; Fri, 18 Sep 2020 05:48:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAK7fr6zMC2biY2RdHjxeQkVQ3c+bSXm6Af1zx1JSiq/L6x97RvyR2s5o2zbv83tuKbXy1 X-Received: by 2002:aa7:dbcb:: with SMTP id v11mr38472137edt.351.1600433305839; Fri, 18 Sep 2020 05:48:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600433305; cv=none; d=google.com; s=arc-20160816; b=J+jIifH2LSz6GAOtaSPjr3LkulIHTZmUqgUHw0pCXPTJ5+6FB/Ttn+rSDHvL/OpK7Q 0POMfSmUkGAalPZQncDBPQqfed/taNgmbQmfzFwtmQSGGR3H+/CdYat16Zcqhth61aFM Ld0JuHtFbavgnmELDm4yM4HngHDPfTI36ueprVL6dwiTc142d8sYuVfoSIKBoqT8GKwz KFeiJ5LemAfgmJmMbjgm2ut8WHe1N8swY8kOeY7eSw0liPZRB8Kw4vh9XbRiShabyjZk Qk0L47booCOOOrjgKwEJjZJArThFuc/mPliGGwW1eS5tak1l+eoKKa8VVtRX/syyr2JD 5Qyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=gzxdocuvlTq5PvxpHV1LCFElPLeEAvL4iTAIyd54CUs=; b=raKpOd/FVCIPhYlmihdLzZ4SUUtMpSG+K9/OdxxmBHrKEcFpKzJfN6yHn1IyxyOkBH pZWPXH7sm0V5JuB20pxS5vRU+B/mJZXusPQBSs3vu8ND3sTLoB/cCJ3M1k3iuEff/4ko Hi62XbQmr6DYdTUqa9yoQU0lsZhW5oY8fmAaYk5XCBiGmuHJMdF1nWQSK+VhQa6hXxrc IDMUqNgM5goP4/RL8lN6rLOuE5S2TUQigMOKnW4G6hSUAmVlo5yKHA0/Alw1MOpZ0cTF GlES4wAraWjEcuHQaWb0vbyBwWHJVqXD+qjtv4B3/2+tN9qiPCzyraDpYcI/HvomLHf5 lbsw== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay3si2131910ejb.174.2020.09.18.05.48.02; Fri, 18 Sep 2020 05:48:25 -0700 (PDT) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726831AbgIRMqS (ORCPT + 99 others); Fri, 18 Sep 2020 08:46:18 -0400 Received: from mga02.intel.com ([134.134.136.20]:59770 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726757AbgIRMp6 (ORCPT ); Fri, 18 Sep 2020 08:45:58 -0400 IronPort-SDR: yPryd+gVYnOgcW9uqXKhir4xp6UT5/4gOmgH3P/LXPaAFRRvjqP5jGWKfhe198fakJJiYzsrUP GfXFV3UGb2yA== X-IronPort-AV: E=McAfee;i="6000,8403,9747"; a="147606658" X-IronPort-AV: E=Sophos;i="5.77,274,1596524400"; d="scan'208";a="147606658" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2020 05:45:57 -0700 IronPort-SDR: g8txEcJO0ulTSqG4U6y6lFjZr6I732JoqmIF3ujvyzswstXN00cJme4NYMxtnUgUWBa5X9TZtz nX66g3jf6GSw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,274,1596524400"; d="scan'208";a="332595129" Received: from um.fi.intel.com (HELO um) ([10.237.72.57]) by fmsmga004.fm.intel.com with ESMTP; 18 Sep 2020 05:45:53 -0700 From: Alexander Shishkin To: Tingwei Zhang , Steven Rostedt , Ingo Molnar , Maxime Coquelin , Alexandre Torgue Cc: Tingwei Zhang , Mathieu Poirier , Suzuki K Poulose , tsoni@codeaurora.org, Sai Prakash Ranjan , Mao Jinlong , linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, alexander.shishkin@linux.intel.com Subject: Re: [PATCH v3 6/6] stm class: ftrace: use different channel accroding to CPU In-Reply-To: <20200903001706.28147-7-tingwei@codeaurora.org> References: <20200903001706.28147-1-tingwei@codeaurora.org> <20200903001706.28147-7-tingwei@codeaurora.org> Date: Fri, 18 Sep 2020 15:45:52 +0300 Message-ID: <87zh5nw8vz.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tingwei Zhang writes: > @@ -63,6 +65,7 @@ static int __init stm_ftrace_init(void) > { > int ret; > > + stm_ftrace.data.nr_chans = num_possible_cpus(); Not a problem with this patch necesarily, but this made me realize that .nr_chans may be larger than: (1) what the policy permits, (2) what the stm device can handle. While (1) the user can fix in the policy, they won't be able to fix (2), in which case they won't be able to use stm_ftrace at all. I'm thinking if a link-time callback would be good enough. Another thing is that .nr_chans needs to be a power of 2 at the moment. Regards, -- Alex