Michael, On (09/27/17 15:01), Michael Ellerman wrote: > Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> writes: > > > On (09/22/17 16:48), Luck, Tony wrote: > > [..] > >> Tested patch series on ia64 successfully. > >> > >> Tested-by: Tony Luck <tony.luck@xxxxxxxxx> > > > > thanks! > > > >> After this goes upstream, you should submit a patch to get rid of > >> all uses of %pF (70 instances in 35 files) and %pf (63 in 34) > >> > >> Perhaps break the patch by top-level directory (e.g. get all the %pF > >> and %pF in the 17 files under drivers/ in one patch). > > > > frankly, I was going to have some sort of a lazy deprecation process: > > didn't plan to send out a patch set that would hunt down all pf/pF-s. > > hm... > > That never works though, we have lots of cruft left over from times when > that's happened and the conversion never quite got finished. this time around it's different, I promise! :) well... I guess I can send out a tree wide pf/pF removal patch set. later. when we will see that .opd based dereference does not make anyone unhappy. and I think we can't remove pf/pF from the kernel completely. it will stay in vscnprintf() for some time. old habits die hard, I suppose, there might be people using it for debugging/etc. > At least if you send out the patches to do the removal they might > eventually get merged. > > > speaking of upstream, any objections if this patch set will go through > > the printk tree, in one piece? > > Do you mind putting it in a topic branch (based on rc2) and then merge > that into the printk tree? That way I can merge the topic branch iff > there are conflicts later down the line towards 4.15. ok, let me re-spin the series. there are some changes here and there, so I'll drop Tested-by/Reviewed-by tags and will ask platforms' maintainers to re-test the patch set :( if everything goes OK, then we can ask Petr to do the topic branch (I don't have a kernel.org account). -ss -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html