[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 06/24] x86: refactor psr: implement get hw info flow.
>>> On 14.12.16 at 05:07, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -115,6 +115,9 @@ struct feat_ops { > struct psr_socket_info *info); > /* get_max_cos_max is used to get feature's cos_max. */ > unsigned int (*get_max_cos_max)(const struct feat_node *feat); > + /* get_feat_info is used to get feature HW info. */ > + bool (*get_feat_info)(const struct feat_node *feat, enum cbm_type type, > + uint32_t dat[], uint32_t array_len); data, value, or val would all seem okay, but dat suggests an acronym of other than data (which I think it is meant to be). > @@ -220,9 +223,24 @@ static unsigned int l3_cat_get_max_cos_max(const struct > feat_node *feat) > return feat->info.l3_cat_info.cos_max; > } > > +static bool l3_cat_get_feat_info(const struct feat_node *feat, > + enum cbm_type type, > + uint32_t dat[], uint32_t array_len) array_len wants to be size_t or unsigned int. And more generally, please avoid fixed width types when you don't really mean such. > +int psr_get_info(unsigned int socket, enum cbm_type type, > + uint32_t dat[], uint32_t array_len) > +{ > + struct psr_socket_info *info = get_socket_info(socket); > + struct feat_node *feat_tmp; With the hook function taking a pointer to const I don#t see why this one can't be const, too. > + if ( IS_ERR(info) ) > + return PTR_ERR(info); > + > + list_for_each_entry(feat_tmp, &info->feat_list, list) > + if ( feat_tmp->ops.get_feat_info(feat_tmp, type, dat, array_len) ) Wouldn't the type check better be done here than inside each function? That would then also allow for terminating the loop earlier (when the type was found, instead of when a function returns success). > --- a/xen/include/asm-x86/psr.h > +++ b/xen/include/asm-x86/psr.h > @@ -33,6 +33,11 @@ > /* L3 CDP Enable bit*/ > #define PSR_L3_QOS_CDP_ENABLE_BIT 0x0 > > +/* Used by psr_get_info() */ > +#define CBM_LEN 0 > +#define COS_MAX 1 > +#define CDP_FLAG 2 These needing putting in a header means that you want to prefix them, e.g. by PSR_. Also with the next value used e.g. as array dimension, I think you also want to name that value (currently 3) and use it instead of a plain number which would need to be adjusted everywhere once a value gets added here. Also - is CDP_FLAG really a suitable name for flags? Wouldn't PSR_FLAGS be better (as being more general)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |