On Wed, Feb 1, 2017 at 2:22 PM, Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, 1 Feb 2017 14:05:43 +0100 > Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> > Linus, is this something you really care about? If that's the case, can >> > you step in? >> >> I can only throw up my hands... > > Sorry for forcing your hand like this, but this is the kind of > discussion I'm not comfortable with (when I need to argue on something > I'm not completely convinced of, or I don't have opinion on). Sorry, I'm just too stressed by all patches. I now read back on the context below. >> The way I percieved it, a new function >> was added, but I guess it could be that the diffstat was so >> convoluted in the other patch (by the way that diff sometimes give >> very confusing stuff unless you use the right fuzz) so I misunderstood >> some other renaming as introducing a new function. > > Indeed, a new function is added (see patch 2), and this new function is > taking an additional 'index' parameter. If that's a problem, I can also > change the prototype of devm_get_gpiod_from_child() and patch all > existing users of this function, but I fear we'll end up with pretty > much the same discussion :-/. Yeah. >> Please drop the patch if it is controversial. >> >> The name of the function *is* confusing though but maybe it's not >> the biggest problem in the world. > > I can still name the new function as you suggested > (devm_fwnode_get_index_gpiod_from_child()), and keep the existing one > unchanged if you want. But that is just insane. Then it is just better to apply this and the other patch making the situation manageable. This is a good time to do it too since I'm anyways patching around in all the consumers this merge window. Dmitry: is this such a big deal to you? commit 40b7318319281b1bdec804f6435f26cadd329c13 "gpio: Support for unified device properties interface" by Mika Westerberg introduced fwnode_get_named_gpiod() devm_get_gpiod_from_child() Both are taking a fwnode as argument and the naming is as inconsistent as it can be. Some more churn should be expected as a side effect of naming this function wrong in the first place. The fwnode API change was on fast-forward and mistakes were made, also by me, mea culpa. When I write kernel code, I usually intuitively look for a function doing what I want, this naming is unintuitive, and it has confused me so it will confuse others. Can I please apply these two patches? Yours, Linus Walleij