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: <da7b815c-149c-6baf-6691-a038d3fe54bf@nvidia.com>
Date:   Fri, 25 Nov 2016 17:29:31 +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 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

-- 
nvpublic

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ