linux-kernel - Re: [PATCH 4/4] mfd: tps65217: Instantiate sub-devices from device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFqH_50MDAAMcj0RW8Vzu71n=vAHAukpGw--mn3+PZBfj+m88w@mail.gmail.com>
Date:   Fri, 9 Jun 2017 11:55:05 +0200
From:   Enric Balletbo Serra <eballetbo@...il.com>
To:     Javier Martinez Canillas <javier@...hile0.org>
Cc:     Grygorii Strashko <grygorii.strashko@...com>,
        Mark Brown <broonie@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-leds@...r.kernel.org, linux-input@...r.kernel.org,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH 4/4] mfd: tps65217: Instantiate sub-devices from device tree

Hello Grygorii, Javier,

2017-06-09 2:00 GMT+02:00 Javier Martinez Canillas <javier@...hile0.org>:
> Hello Grygorii,
>
> [snip]
>
>>>
>>> For tps65218 couldn't instead of using mfd_add_devices() for all the
>>> sub-devs, had used of_platform_populate() for the ones that have
>>> device nodes and mfd_add_devices() only for the "tps65218-regulator"?
>>>
>>> The commit talks about nodes without compatibles but's actually about
>>> sub-devices without an associated device node. For me it makes sense
>>> to use of_platform_populate() when the MFD has device nodes for their
>>> sub-devices and mfd_add_devices() when DT knows nothing about the
>>> sub-devices.
>>
>> FYI. Below is link discussion I'm referring to between Mark Brown and Andrew F. Davis
>> https://lkml.org/lkml/2015/10/22/823
>> the same - https://groups.google.com/forum/#!topic/linux.kernel/wQsdSpPMroQ
>>
>
> Thanks a lot for the pointer. There's a subtle difference between the
> argument you made and the one that Mark is making in this thread
> though.
>
> Because you said (sorry if I misunderstood) that mfd_add_devices()
> should be used instead of of_device_populate() even when sub-devices
> are described as DT nodes (as is the case in the commit you shared)
> while Mark is saying that if the sub-devs IP blocks are part of the
> MFD, then it shouldn't be exposed in the DT and be instantiated via
> mfd_add_devices() and I absolutely agree with that.
>
> So I was arguing for using of_device_populate() if the sub-devices are
> described in the DT. If that makes sense or not to expose the
> sub-devices in the DT for this particular driver is a different
> discussion and I can't comment on that since I'm not familiar with the
> HW.
>

I'm agree with Grygorii here that has no sense describe the static
interrupts resources in the DT here unless DT maintainers prefer have
them (dunno their preferences). OTOH, for the charger we need a way to
disable (or having a mfd propriety or having a DT subnode with the
status). I have a new idea that might be acceptable by Grygorii and
also solve my use case. Let me prepare a second patchset and lets
continue the discussion there?

Best regards,
 Enric

> Best regards,
> Javier