On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <[email protected]> wrote: > On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <[email protected]> wrote: >> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <[email protected]> wrote: >>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote: >>>> From: Leon Romanovsky <[email protected]> > >>>> Modify enum ib_device_cap_flags such that other patches which add new >>>> enum values pass strict checkpatch.pl checks. > >>>> - IB_DEVICE_RESERVED = (1<<16), /* old SEND_W_INV */ >>>> - IB_DEVICE_MEM_WINDOW = (1<<17), >>>> + IB_DEVICE_RESIZE_MAX_WR = (1 << 0), > >> 2. Change the whole file => the work with "git blame" will be less >> straightforward. > > Agree. > > Leon, I don't think we need to take checkpatch-ing of things to that level. > > Indeed, we should make sure that whole new enums and such are done right -- > but avoid touching core structs/enums in a manner that disallows > simple git blaming of things, which is very useful for new comers and > old suffers. There are no doubts that standalone fixing checkpatch errors is more suitable to staging subsystem. In our case, it is part of coming changes in that structure. such change serves specific goal to minimize the possibility of error by seeing clean output from static analyser tool.
For the new comers and old suffers checkpatch tool is extremely useful too. > >> I will do the change across whole file, If Doug accepts such change. > > Please don't... simple git blame is very powerful tool for kernel > developers everyday work. It is an open question what we prefer more: history with chance to sneak a mistake or less history with less chances to make a mistake. > > Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
