Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp724717pxb; Fri, 14 Jan 2022 15:04:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzbzqFo5UNUnpI7OW6YjLZzkjjKFx6q62XCHS9WmHE+OxxaqxJoeNedC1yEUwqDn3kChJ9H X-Received: by 2002:a63:b341:: with SMTP id x1mr9983211pgt.185.1642201489720; Fri, 14 Jan 2022 15:04:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642201489; cv=none; d=google.com; s=arc-20160816; b=xxdY/LEk0yStRITz4RnUQrL1MCbis8CB7q4jlP29M+lfzyePeTb1EVG4QEWxJNs8kd qwbR20pk+70Bl7VPitqkLy07vbIES3ArpO3bDiOx9IgRaJaV6fsIgVOnpt8HdVDLRR9b GfOEFzI369rTmloW4S0ILj7ztYpXRUiN5/df+8Oc7nAtQcw0wq9JX9hy0zgYEwsWIMHx eY53jv8VSbnhlXk81BWBtApLXPKTHLDrVlVMR7b0tP2T2/e792Chduzc24wsDEA+VLm0 jiFszaYa312Xu6nuRgi2UBPYYYS7jYKiiAb62KLB4mfldKaUTG4hYeMqvXXpipEdDy2T EkVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=Qdn/VSBgWsg66OG0unhwyC/L4RktepqcOC0tWwqS/+g=; b=PhiuPp9xgqHUN67C0k7a8BOmDIw42MQtrxCC07esigkzvnlX3CUSOP6hOUKwQWoPJb uB41OVdmbsesKQ8noSoHWYjfBeNchD1M+wZ5K3w5wBUHwTTYrZAJOkavJJba4cykzOy0 P86OZ2TlqztW9hXYKyrA71I41IHQL71rEPMrErzuDxr7hffeIgMIzdv5ch1FtgODXWyT vB49HvCu8orCgM95p9OlNxX4/ni/Gud9SYazFmenYOCHadsLLWyMHg4SJnT9qB7hWqOr bVNk8+Fj64NEiGGufHp5dSE4FxYfNWDP8Zve5Bc/D/8DHAvPq9Av6cOnhqIG+DM6naR4 tkJw== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f13si11321206pjp.45.2022.01.14.15.04.38; Fri, 14 Jan 2022 15:04:49 -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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244120AbiANTfx (ORCPT + 99 others); Fri, 14 Jan 2022 14:35:53 -0500 Received: from mail-qt1-f174.google.com ([209.85.160.174]:45979 "EHLO mail-qt1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232351AbiANTfw (ORCPT ); Fri, 14 Jan 2022 14:35:52 -0500 Received: by mail-qt1-f174.google.com with SMTP id x8so5723892qta.12; Fri, 14 Jan 2022 11:35:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qdn/VSBgWsg66OG0unhwyC/L4RktepqcOC0tWwqS/+g=; b=rTMIr/x019cswQjd01qjASHKx0vrs4bGIL342Qg3cZNMdd2mSGha50DlNMUjMDYpMt RYXhmAu9hV3BR49affhGjgyPqwXH2OWF6MZU9DQW3CrBEXez189LnXQn9EdhKOhQCCKX Iyx3G5yq8Ff8dlArlSMAUIextzmVqaIRwZ0eSC91v2tLF2wae6veuGgdcbbLyy43pVye k6E6VqHbHDUvMySEnot+J+QyJg66H1SAchU5XDlaYGbpNxQ9FCM0CUUzVptIaSO69Xaf rka0G4AImd1MT5Zx/5HM3mVOwoVQFrlm94YelPUKH6aP5GemK5dSujo2pn6ku72WCkKP tCwQ== X-Gm-Message-State: AOAM533+43rQ4oT9HkWlGsjlLyHNXTib+Fo1EjBaShgMnlndB9l0QxZg iyeuOQ61EIR8WlqQM7ooMDhUoUhtCCLvgssd4/A= X-Received: by 2002:ac8:5991:: with SMTP id e17mr9096424qte.344.1642188951451; Fri, 14 Jan 2022 11:35:51 -0800 (PST) MIME-Version: 1.0 References: <20220106025059.25847-1-ricardo.neri-calderon@linux.intel.com> <20220106025059.25847-7-ricardo.neri-calderon@linux.intel.com> <7dde8e84961e09066c6bf02198e429d3a702a496.camel@linux.intel.com> In-Reply-To: <7dde8e84961e09066c6bf02198e429d3a702a496.camel@linux.intel.com> From: "Rafael J. Wysocki" Date: Fri, 14 Jan 2022 20:35:40 +0100 Message-ID: Subject: Re: [PATCH v3 6/7] thermal: netlink: Add a new event to notify CPU capabilities change To: Srinivas Pandruvada Cc: "Rafael J. Wysocki" , Ricardo Neri , "Rafael J. Wysocki" , Daniel Lezcano , Linux PM , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , Len Brown , Aubrey Li , Amit Kucheria , Andi Kleen , Tim Chen , Lukasz Luba , "Ravi V. Shankar" , Ricardo Neri , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 12, 2022 at 10:32 PM Srinivas Pandruvada wrote: > > On Wed, 2022-01-12 at 20:25 +0100, Rafael J. Wysocki wrote: > > On Thu, Jan 6, 2022 at 3:49 AM Ricardo Neri > > wrote: > > > From: Srinivas Pandruvada > > > > > > Add a new netlink event to notify change in CPU capabilities in > > > terms of > > > performance and efficiency. > > > > > > Firmware may change CPU capabilities as a result of thermal events > > > in the > > > system or to account for changes in the TDP (thermal design power) > > > level. > > > > > > This notification type will allow user space to avoid running > > > workloads > > > on certain CPUs or proactively adjust power limits to avoid future > > > events. > > > > > > The netlink message consists of a nested attribute > > > (THERMAL_GENL_ATTR_CPU_CAPABILITY) with three attributes: > > > > > > * THERMAL_GENL_ATTR_CPU_CAPABILITY_ID (type u32): > > > -- logical CPU number > > > * THERMAL_GENL_ATTR_CPU_CAPABILITY_PERFORMANCE (type u32): > > > -- Scaled performance from 0-1023 > > > * THERMAL_GENL_ATTR_CPU_CAPABILITY_EFFICIENCY (type u32): > > > -- Scaled efficiency from 0-1023 > > > > > > Cc: Andi Kleen > > > Cc: Aubrey Li > > > Cc: Lukasz Luba > > > Cc: Tim Chen > > > Cc: "Ravi V. Shankar" > > > Reviewed-by: Len Brown > > > Signed-off-by: Srinivas Pandruvada < > > > srinivas.pandruvada@linux.intel.com> > > > > Of course, I need to know if Daniel and Lukasz agree with this patch. > > > I pinged Daniel offline. I accommodated comments from Lukasz. > > > > --- > > > > > [...] > > > > +static int thermal_genl_event_cpu_capability_change(struct param > > > *p) > > > +{ > > > + struct cpu_capability *cpu_cap = p->cpu_capabilities; > > > + struct sk_buff *msg = p->msg; > > > + struct nlattr *start_cap; > > > + int i, ret; > > > + > > > + start_cap = nla_nest_start(msg, > > > THERMAL_GENL_ATTR_CPU_CAPABILITY); > > > + if (!start_cap) > > > + return -EMSGSIZE; > > > + > > > + for (i = 0; i < p->cpu_capabilities_count; ++i) { > > > + if (nla_put_u32(msg, > > > THERMAL_GENL_ATTR_CPU_CAPABILITY_ID, > > > + cpu_cap->cpu)) { > > > + ret = -EMSGSIZE; > > > + goto out_cancel_nest; > > > + } > > > + if (nla_put_u32(msg, > > > THERMAL_GENL_ATTR_CPU_CAPABILITY_PERFORMANCE, > > > + cpu_cap->performance)) { > > > + ret = -EMSGSIZE; > > > + goto out_cancel_nest; > > > + } > > > + if (nla_put_u32(msg, > > > THERMAL_GENL_ATTR_CPU_CAPABILITY_EFFICIENCY, > > > + cpu_cap->efficiency)) { > > > + ret = -EMSGSIZE; > > > + goto out_cancel_nest; > > > + } > > > + ++cpu_cap; > > > + } > > > + > > > + nla_nest_end(msg, start_cap); > > > + > > > + return 0; > > > +out_cancel_nest: > > > + nla_nest_cancel(msg, start_cap); > > > + > > > + return ret; > > > > It looks like ret is never different from -EMSGSIZE here, so I'd just > > return that error and drop the ret variable. > > > ret is initialized for every case when it will be returned. Right, but it is redundant. > But agree > that we can just return -EMSGSIZE as there is no other return value > here. > > > > +} > > > + > > > > > [...] > > > > +struct cpu_capability { > > > > I'm wondering if the struct name is not too generic as the purpose it > > is used for is rather narrow and specific. > > > This was named something else before. What about cpu_energy_perf_cap? Because it is only used in the thermal_genl_cpu_capability_event() interface, it would be good to make the name reflect that IMO. Something like thermal_genl_cpu_caps would work in this regard.