Re: [PATCH V11 4/6] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024

[Thierry Reding]

On Thu, Apr 28, 2016 at 06:52:26PM +0530, Laxman Dewangan wrote:
> Hi Lee,
> 
> On Thursday 28 April 2016 03:28 PM, Laxman Dewangan wrote:
> > MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins
> > which also act as the special function in alternate mode. Also
> > there is configuration like push-pull, open drain, FPS timing
> > etc for these pins.
> > 
> > Add pin control driver to configure these parameters through
> > pin control APIs.
> > 
> > Signed-off-by: Laxman Dewangan <ldewangan@xxxxxxxxxx>
> > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> 
> It seems there is some mismatches on kernel-next and the mfd/for-next for
> one of patch for generic function name.
> 
> /**
> 2016-04-01    pinctrl: Rename pinctrl_utils_dt_free_map to
> pinctrl_utils_free_map    Irina Tirdea    1    -1/+1
> 
> d32f7fd3bbc32732b094d938b95169521503a9fb (patch)
> 
> pinctrl: Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map
> 
> Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map, since
> it does not depend on device tree despite the current name. This
> will enforce a consistent naming in pinctr-utils.c and will make
> it clear it can be called from outside device tree (e.g. from
> ACPI handling code).
> **/
> 
> But this is not there in MFD sub system.
> 
> In mfd tree
> .dt_free_map = pinctrl_utils_dt_free_map,
> 
> In kernel next
> .dt_free_map = pinctrl_utils_free_map,
> 
> 
>  I used APIs from the kernel-next.
> > +static const struct pinctrl_ops max77620_pinctrl_ops = {
> > +	.get_groups_count = max77620_pinctrl_get_groups_count,
> > +	.get_group_name = max77620_pinctrl_get_group_name,
> > +	.get_group_pins = max77620_pinctrl_get_group_pins,
> > +	.dt_node_to_map = pinconf_generic_dt_node_to_map_pin,
> > +	.dt_free_map = pinctrl_utils_free_map,
> > +};
> 
> 
> If you see any issue on this patch, please drop this patch and we will fix
> this later once the renamed change available all the places.

To avoid this, it's usually best to base your patches on a recent
linux-next, which I suppose is what you did, since you picked up the
new symbol. The reason that this isn't in the MFD tree is most likely
because it's a new symbol being introduced in the next release cycle
and it's not relevant in pinctrl.

You patch series will most likely be applied via different trees. MFD
patches will go through Lee's MFD tree and pinctrl patches through
Linus' pinctrl tree. Your patches based on linux-next should then apply
cleanly and build correctly in the respective trees and everything will
come together in linux-next again.

Thierry

Attachment: signature.asc
Description: PGP signature