linux-kernel - Re: [PATCH V4 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads

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]

Date:   Mon, 28 Nov 2016 09:26:32 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Laxman Dewangan <ldewangan@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>
CC:     <linus.walleij@...aro.org>, <robh+dt@...nel.org>,
        <mark.rutland@....com>, <swarren@...dotorg.org>,
        <gnurou@...il.com>, <joe@...ches.com>,
        <yamada.masahiro@...ionext.com>, <linux-gpio@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V4 2/2] pinctrl: tegra: Add driver to configure voltage
 and power of io pads


On 25/11/16 17:49, Laxman Dewangan wrote:
> 
> On Friday 25 November 2016 10:59 PM, Jon Hunter wrote:
>> On 25/11/16 12:04, Laxman Dewangan wrote:
>>> Thanks Thierry for review.
>>>
>>> On Friday 25 November 2016 03:27 PM, Thierry Reding wrote:
>>>> * PGP Signed by an unknown key
>>>>
>>>> On Thu, Nov 24, 2016 at 02:08:54PM +0530, Laxman Dewangan wrote:
>>>>> +      NVIDIA Tegra124/210 SoC has IO pads which supports
>>>>> multi-voltage
>>>>> +      level of interfacing and deep power down mode of IO pads. The
>>>>> +      voltage of IO pads are SW configurable based on IO rail of that
>>>>> +      pads on T210. This driver provides the interface to change
>>>>> IO pad
>>>>> +      voltage and power state via pincontrol interface.
>>>> This has a lot of chip-specific text. Will all of that have to be
>>>> updated if support for new chips is added?
>>> Then saying that Tegra124 and later..
>>> Hoping, people know our chip releasing sequence as numbering are not in
>>> sequence.
>>>
>>>>> +#include <linux/regulator/consumer.h>
>>>>> +#include <soc/tegra/pmc.h>
>>>> Have you considered moving this code into the PMC driver? It seems a
>>>> little over the top to go through all of the platform device creation
>>>> and driver registration dance only to call into a public API later on.
>>> Yes, we had discussion on this and suggestion came to use the pinctrl
>>> framework.
>>> If we do in the pmc driver then we will need lots of DT processing for
>>> getting information from DT which we can directly get from the pinctrl
>>> core framework.
>>> Also client driver may need to have the control dynamically and get the
>>> IO pads from DT. So implementing all in pmc will be huge duplication
>>> over already existing framework.
>> I don't follow. We already did something similar for the Tegra DPAUX
>> driver [0].
>>
>> Cheers
>> Jon
>>
>> [0]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/tegra/dpaux.c?id=0751bb5c44fe1aa9494ce259d974c3d249b73a84
>>
> 
> In the above dpaux driver,  you used the pinctrl framework and its core
> functionality for the device tree interfacing and client interfacing.
> 
> The same thing I am saying here, we should not avoid the pinctrl
> framework. The client driver will use the pinctrl framework for the IO
> pad configurations, not direct PMC APIs.

Exactly, so why are you saying that by moving the code into the PMC
driver this will "need lots of DT processing for getting information
from DT"? By moving the code, we are not suggesting we don't use the
pinctrl framework, we are just suggesting we move the code. That's all.

Jon

-- 
nvpublic