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] [day] [month] [year] [list]
Message-ID: <CACRpkdY_-fN3oxXwghR=iC7_K-xF7_-HRtBKDnGbckEsYKA+pw@mail.gmail.com>
Date:	Thu, 10 Apr 2014 18:22:36 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Bjorn Andersson <bjorn@...o.se>
Cc:	Timur Tabi <timur@...eaurora.org>,
	"Ivan T. Ivanov" <iivanov@...sol.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 2/2] ARM: dts: MSM8974: Add pinctrl node

On Tue, Apr 8, 2014 at 8:39 PM, Bjorn Andersson <bjorn@...o.se> wrote:
> On Tue, Apr 8, 2014 at 7:18 AM, Timur Tabi <timur@...eaurora.org> wrote:

>> Back in July, Qualcomm submitted a patch that added this information into
>> the device tree:
>>
>> http://marc.info/?t=137185166100003&r=1&w=2
>>
>> However, this was rejected.  Now it appears that this information is again
>> being added to the device tree, but it's being accepted.  What's different
>> now?
>
> The difference is that in the first proposal pins, groups and
> functions where defined in DT, in the accepted proposal the devicetree
> merely selects pins, functions and their configuration.

Yes and I point this out in this reply:
http://marc.info/?l=linux-kernel&m=137650778624988&w=2

>> Another problem is that these device tree changes makes it difficult to
>> support ACPI.  It's easy to move information between the drivers and the
>> device tree, because they're kept together.  It's not so easy with ACPI.
>> I'm trying to add ACPI support to the 8x74 pinctrl driver, but it's a moving
>> target.
>
> The DT bindings for 8x74 is all standard pinctrl, so I presume that
> what you should be looking at is how pinctrl and acpi is interacting,
> not the specific case of 8x74...
>
> Maybe Linus have some input on this?

AFAIK ACPI has nothing like official pin control support, last time I
checked it was limited to some custom information that could be
tagged onto GPIO pins (REALLY a bad idea, we don't shoehorn
pin control into the concept of GPIO).

If you are adding this then tell me which ACPI standard document
you're using for it, so I can read and criticize it.

I was under the impression that the ambition of ACPI was to hide
away all "complex stuff" such as pin control in the firmware
and just e.g. call the devices into some D-state and the
pin business happens in the firmware.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ