[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] platform/cpufreq: add public defines for CPUFREQ_SHARED_TYPE_


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 7 Apr 2022 11:22:35 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BoEkVdeuF0017vsm02abjyJ5Ut7M4pi8LJ13OXWTqw4=; b=RtZlUTkM77KA8Cr89u8IShDW43oTm8aNH6Sp6vIQS+f+3GCaw3mzJLTkYfCjSiFCZBHC3c71y3mYN++oYKtHu+TB1LZgSSInOXhUcsKi4zoLmqHxAGVy65bP++b18BffiXrs7Uklk4ux/0y4/r9Wx54Jdn+1tXwOL0mV7wJ8NVoM8129lqM88Q7QG6VxMWFhfTcqpIFoexwG+hT/1oqXBTJyaYxVOP10JTKnpDcr1d15cvajofdozYHXri9igZyIOZK1Y+LzLtl4OQVUnI7qvRudn+AUrKawEWLf0Bxmwol/SA64z/snpa7bxNQXGnr7e9hfKMKGRGT8xYLOkj7NlQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gK+wLqufx9d11XaZyCef/kIqG/wr7ZymJNr2g0HwnfdyKGmWTEzsy8IgaE82ezHfrBSj1TrCdnO4OxV+Yae4eRT/gQEuKatj4HEWVAGKvNL1cjTWLBPG9VSmRuqUAfQ4mKNRIkPH+B9SscTOzxi8eiGDYjZgtcft8kEbMBYlU4DV26WuXbYoR+NANEcnBR52Fj/0Mw9maQ1uvSzNKjqEb0H1d61NeEUMdQ2ylL41oQ8reBUkqTE6KtFenxzHoZp9XvtV6/wgy/FffkZohIFsnjfRG4MgTbl/Tq9vzzwxZ7uie4P1MVMHtliKMoP4TTfJo6NA0RzzVphJW/CCexPuzw==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 07 Apr 2022 09:23:06 +0000
  • Ironport-data: A9a23:6i099q5ewlVx5CsW7XXAGAxRtATHchMFZxGqfqrLsTDasY5as4F+v jcaUD2OPv6CYmrxLdlyYYS1pElV65SAzNdkTQM/qy03Hi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yE6j8lkf5KkYAL+EnkZqTRMFWFw0XqPp8Zj2tQy2YThXFvU0 T/Pi5a31GGNimYc3l08s8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vNvy7X 47+IISRpQs1yfuP5uSNyd4XemVSKlLb0JPnZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSvch8mI4nyh98YSihWDDl+OpNa1K/IdC3XXcy7lyUqclPpyvRqSko3IZcZ6qB8BmQmG f4wcW5XKErZ3qTvnez9GrIEascLdaEHOKsFvX5t13fBBOsOSpHfWaTao9Rf2V/cg+gQQqiAP ZpHOFKDajzgUyNCBGtMDa4Us8aKu3WlXANB8W6s8P9fD2/7k1UqjemF3MDuUsOObdVYmACfv G2u13T0BFQWOcKSzRKB82mwnanfkCXjQoUQGbaksPlwjzW73XcPARcbUV+6p/iRiUOkXd9bb UsO9UIGr6I/6UiqRdnVRACjrTiPuRt0c9hNF+w37imdx6yS5ByWblXoVRYYNoZg7pVvA2V3i BnZxLsFGACDrpWKcmqS65Oqsgi3IBkbMncCYhEYYRsKtoyLTJ4IsjrDSdNqEaiQh9LzGC3tz z3ikBXSl4n/nuZQifzloAmvbyaE48GQE1Vrvlm/sneNtFsRWWKzW2C/BbE3B95kJZ3RcFSOt WNsdyO2vLFXVsHleMBgrYww8FCVCxStbWW0bb1HRcBJG9GRF5iLJ904DNZWfhoBDyr8UWW1C HI/QCsIjHOpAFOkbLVsf6W6ANkwwK7rGLzND66IP4AeP8UhK1DepUmCgHJ8OUi3zSDAdollZ /+mnTuEVy5GWcyLMhLoLwvi7VPb7n9nnj6CLXwK5x+mzaCfdBaopUQtazOzghQCxPrc+m39q o8HX+PTkkk3eLCuM0H/rN9IRXhXfCdTOHwDg5EOHgJ1ClE9Qz9J5j646e5JRrGJaIwJzryYo SznAhYwJZiWrSSvFDhmo0tLMdvHdZ1+sWg6LWorO1Op0GIkeoGh8OEUcJ5fQFXt3LYLISJcJ xXdR/i9Pw==
  • Ironport-hdrordr: A9a23:w060o6GwZZPNpmZ/pLqFCpHXdLJyesId70hD6qkvc3Nom52j+/ xGws536faVslcssHFJo6HmBEClewKnyXcT2/htAV7CZnichILMFu9fBOTZsl/d8kHFh4tgPO JbAtRD4b7LfClHZKTBkXCF+r8bqbHtmsDY5ts2jU0dNT2CA5sQkTuRYTzrdHGeKjM2YabQQ/ Gnl7V6TnebCDwqR/X+IkNAc/nIptXNmp6jSRkaByQ/4A3LqT+z8rb1HzWRwx9bClp0sP0f2F mAtza8yrSosvm9xBOZ/2jP765OkN+k7tdYHsSDhuUcNz2poAe1Y4ZKXaGEoVkO0aqSwWdvtO OJjwYrPsx15X+UVmapoSH10w2l6zoq42+K8y7uvVLT5ejCAB4qActIgoxUNjHD7VA7gd162K VXm0qEqpt+F3r77WvAzumNcysvulu/oHIkn+JWpWdYS5EiZLhYqpFa1F9JEa0HADnx5OkcYa VT5fnnlbdrmG6hHjDkVjEF+q3uYp1zJGbKfqE6gL3a79AM90oJjXfxx6Qk7wM9HdwGOtx5Dt //Q9dVfYF1P78rhJ1GdZU8qOuMexrwqEH3QSuvyWqOLtBzB5uKke+y3IkI
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 07, 2022 at 10:48:50AM +0200, Jan Beulich wrote:
> On 07.04.2022 10:18, Roger Pau Monne wrote:
> > The values set in the shared_type field of xen_processor_performance
> > have so far relied on Xen and Linux having the same
> > CPUFREQ_SHARED_TYPE_ defines, as those have never been part of the
> > public interface.
> > 
> > Formalize by adding the defines for the allowed values in the public
> > header, while renaming them to use the XEN_CPUPERF_SHARED_TYPE_ prefix
> > for clarity.
> > 
> > Set the Xen internal defines for CPUFREQ_SHARED_TYPE_ using the newly
> > introduced XEN_CPUPERF_SHARED_TYPE_ public defines in order to avoid
> > unnecessary code churn.  While there also drop
> > CPUFREQ_SHARED_TYPE_NONE as it's unused.
> > 
> > Fixes: 2fa7bee0a0 ('Get ACPI Px from dom0 and choose Px controller')
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> with one remark:
> 
> > --- a/xen/include/acpi/cpufreq/cpufreq.h
> > +++ b/xen/include/acpi/cpufreq/cpufreq.h
> > @@ -78,10 +78,9 @@ DECLARE_PER_CPU(struct cpufreq_policy *, 
> > cpufreq_cpu_policy);
> >  extern int __cpufreq_set_policy(struct cpufreq_policy *data,
> >                                  struct cpufreq_policy *policy);
> >  
> > -#define CPUFREQ_SHARED_TYPE_NONE (0) /* None */
> 
> I realize this is unused, but do we really want/need to drop this?
> I think it is used implicitly right now by assuming the value would
> be zero; this could do with making explicit, in which case we'd
> need the #define.

I don't think Xen uses it explicitly, all checks of shared_type are
always against a specific CPUFREQ_SHARED_TYPE_{HW,ALL,ANY}.

I don't have a strong opinion about keeping it however, I've just
removed as a cleanup, if you don't think it's helpful I can resubmit
keeping the define.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.