Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support

Sebastian Reichel
2018-03-08T12:54:08Z

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

Hi,

On Thu, Mar 08, 2018 at 10:48:31AM +0000, Lee Jones wrote:
> On Thu, 08 Mar 2018, Sebastian Reichel wrote:
> > On Thu, Mar 08, 2018 at 09:53:15AM +0000, Lee Jones wrote:
> > > On Thu, 08 Mar 2018, Sebastian Reichel wrote:
> > > > 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.
> > >
> > > Sorry, I missed that conversation. Why was it removed?
> >
> > I had it in PATCHv1-PATCHv4. It was removed, since Mark didn't want
> > to have it in the DT ABI.
>
> Right, but why? Is it not a hardware device? I think converting from
> devm_of_platform_populate() for one sub-device is a bit drastic.

This must be answered by Mark. Personally I think it makes more sense
to have the compatible, since all other cpcap sub-devices have them
and it should be consistent IMHO. I changed it to avoid bikeshedding.

The previous discussion was here: https://patchwork.kernel.org/patch/10220035/

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]