On Fri, 09 Mar 2018, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Mar 08, 2018 at 09:07:36AM -0800, Tony Lindgren wrote:
> > * Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx> [180308 09:47]:
> > > Hi Lee,
> > >
> > > On Wed, Mar 07, 2018 at 04:32:11PM +0000, Lee Jones wrote:
> > > > On Fri, 23 Feb 2018, Sebastian Reichel wrote:
> > > > > +static const struct mfd_cell cpcap_mfd_devices[] = {
> > >
> > > [...]
> > >
> > > > > + }, {
> > > > > + .name = "cpcap-led",
> > > > > + .id = 4,
> > > > > + .of_compatible = "motorola,cpcap-led-cp",
> > > > > + }, {
> > > > > + .name = "cpcap-codec",
> > > > > + }
> > > > > +};
> > > >
> > > > With none of the entries containing platform_data /me wonders why you
> > > > can't still use devm_of_platform_populate()?
> > >
> > > Because devm_of_platform_populate works with compatible properties and
> > > cpcap-codec does not have one after I removed it for Mark.
> >
> > How about keep devm_of_platform_populate() for the ones that
> > already have compatible. Then add a table entry for cpcap-codec
> > only and call devm_mfd_add_devices()?
>
> This should work. I think it makes sense to wait for Rob Herring's
> feedback on the binding. My understanding is, that he has the last
> word on binding questions and I would like to avoid changing this
> back and forth.
I've been avoiding mix-and-matching mfd_*() and of_platform_*() APIs,
else it gets too confusing for new developers.
*If* you make the switch to mfd_*() APIs (not preferable), then I
would like to see of_platform_*() removed.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
