[PATCH v3 12/23] staging/rdma/hfi1: Macro code clean up
Greg KH
gregkh at linuxfoundation.org
Tue Oct 27 21:14:04 UTC 2015
On Tue, Oct 27, 2015 at 04:51:15PM -0400, ira.weiny wrote:
> On Tue, Oct 27, 2015 at 05:19:10PM +0900, Greg KH wrote:
> > On Mon, Oct 26, 2015 at 10:28:38AM -0400, ira.weiny at intel.com wrote:
> > > From: Mitko Haralanov <mitko.haralanov at intel.com>
> > >
> > > Clean up the context and sdma macros and move them to a more logical place in
> > > hfi.h
> > >
> > > Signed-off-by: Mitko Haralanov <mitko.haralanov at intel.com>
> > > Signed-off-by: Ira Weiny <ira.weiny at intel.com>
> > > ---
> > > drivers/staging/rdma/hfi1/hfi.h | 22 ++++++++++------------
> > > 1 file changed, 10 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/staging/rdma/hfi1/hfi.h b/drivers/staging/rdma/hfi1/hfi.h
> > > index a35213e9b500..41ad9a30149b 100644
> > > --- a/drivers/staging/rdma/hfi1/hfi.h
> > > +++ b/drivers/staging/rdma/hfi1/hfi.h
> > > @@ -1104,6 +1104,16 @@ struct hfi1_filedata {
> > > int rec_cpu_num;
> > > };
> > >
> > > +/* for use in system calls, where we want to know device type, etc. */
> > > +#define fp_to_fd(fp) ((struct hfi1_filedata *)(fp)->private_data)
> > > +#define ctxt_fp(fp) (fp_to_fd((fp))->uctxt)
> > > +#define subctxt_fp(fp) (fp_to_fd((fp))->subctxt)
> > > +#define tidcursor_fp(fp) (fp_to_fd((fp))->tidcursor)
> > > +#define user_sdma_pkt_fp(fp) (fp_to_fd((fp))->pq)
> > > +#define user_sdma_comp_fp(fp) (fp_to_fd((fp))->cq)
> > > +#define notifier_fp(fp) (fp_to_fd((fp))->mn)
> > > +#define rb_fp(fp) (fp_to_fd((fp))->tid_rb_root)
> >
> > Ick, no, don't do this, just spell it all out (odds are you will see tht
> > you can make the code simpler...) If you don't know what "cq" or "pq"
> > are, then name them properly.
> >
> > These need to be all removed.
>
> Ok.
>
> Can I add the removal of these macros to the TODO list and get this patch
> accepted in the interm?
Nope, sorry, why would I accept a known-problem patch? Would you do
such a thing?
> Many of the patches I am queueing up to submit as well as one in this series do
> not apply cleanly without this change. It will be much easier if I can get
> everything applied and then do a global clean up of these macros after the
> fact.
But you would have no incentive to do that if I take this patch now :)
thanks,
greg k-h
More information about the devel
mailing list