On Tue, Jun 27, 2017 at 01:08:12PM +0200, Stefan Roese wrote: > Hi Andy, > > On 27.06.2017 10:31, Andy Shevchenko wrote: > >On Thu, 2017-06-22 at 21:00 +0530, Vinod Koul wrote: > >>On Thu, Jun 22, 2017 at 04:50:57PM +0200, Stefan Roese wrote: > >>>On 22.06.2017 15:00, Vinod Koul wrote: > >>>>On Tue, Jun 20, 2017 at 02:20:49PM +0200, Stefan Roese wrote: > >>>>>On 14.06.2017 10:25, Vinod Koul wrote: > >>>>>>On Wed, May 24, 2017 at 09:00:48AM +0200, Stefan Roese wrote: > >>>>>> > >>>>>>>+#define MSGDMA_MAX_TRANS_LEN 0xffffffff > >>>>>> > >>>>>>GENAMSK? > >>>>> > >>>>>I'm personally not a big fan of GENMASK. BIT(x) is good for > >>>>>single > >>>>>bits, but GENMASK usually looks lees clear - at least to me. So > >>>>>if > >>>>>you do not insist in this change, I would like to keep the > >>>>>masks. > >>>> > >>>>Well GENMASK(14, 11) tell me that it means mask of bit 14 thru 11, > >>>>which is > >>>>way clear than 0x7800 :) > >>> > >>>In this specific case, I see your point and would be willing to make > >>>this change gladly. But in the case above, its a the largest number > >>>of a u32 variable. I find it more confusing using GENMASK here. > >>>Probably there is a macro already for this u32(-1) value, that I > >>>should use instead. > >> > >>I think there is something, but can't recall which one. Andy? > > > >Since it's a maximum length of transfer on the one hand and in the > >hardware is actually a mask (bits are used for transfer length) you may > >choose one of > > > >U32_MAX > >GENMASK(31, 0) > > > >My personal preference is GENMASK(), since it's slightly closer to what > >hardware does inside. > > My personal preference would be U32_MAX in this case. > > Vinod, do you want me to send a v3 of the mSGDMA patch with one of > those defines used? Which one do you prefer, I really have no strong > feelings here. That can be sent as an update afterwards or if we have comments then in next iternation :) -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
