On Wed, Feb 8, 2017 at 2:00 PM, Greg KH <greg@xxxxxxxxx> wrote:
>> - gpiod = devm_get_gpiod_from_child(port->dev, "rts",
>> - &np->fwnode);
>> - if (!IS_ERR(gpiod)) {
>> - gpiod_direction_output(gpiod, 0);
>> + gpiod = devm_fwnode_get_gpiod_from_child(port->dev,
>> + "rts",
>> + &np->fwnode,
>> + GPIOD_OUT_LOW,
>> + np->name);
>
> I can't apply this :(
>
> Usually, when you move apis around, you add it, then convert it, wait a
> kernel release, then remove the old one. That allows for issues like
> this when new code is added in one maintainer's branch but not yours.
Sorry about this, I guess I got a bit stressed too recently so I was not
able to solve this in the ultimate way.
We converted over all existing users of the APIs but I guess I optimistically
assumed no new users would be added in this
kernel cycle, but of course they did.... this new driver was using it, Stephen
fixed that up in next and now a patch to that driver arrived on top, ouch.
> So how about reverting your "drop the function" patch and then wait for
> -rc2 to really remove it?
I never did a thing like this before, hm sorry for the inexperience. :(
I did make an immutable branch like Andy suggested but didn't advertise
it well enough. But as stated that approach sucks anyways.
Typically I saw this suggestion right after sending the pull request to
Torvalds (yeah I should have seen it first, my inbox is chaotic too, mea
culpa).
I'll follow up on it asking him not to pull that and look for a resolution like
you suggest instead. Since it is three patches that then have users on
top I guess it is best to add back the old prototype helper for this driver
exclusively then fix it for -rc2.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
