linux-kernel - Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property

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:   Tue, 25 Jul 2017 09:05:22 +0800
From:   Fenglin Wu <fenglinw@...eaurora.org>
To:     Rob Herring <robh@...nel.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        bjorn.andersson@...aro.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
        collinsd@...eaurora.org, aghayal@...eaurora.org,
        wruan@...eaurora.org, kgunda@...eaurora.org
Subject: Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for
 qcom,gpios-disallowed property

On 7/25/2017 3:09 AM, Rob Herring wrote:
>>   <prop-encoded-array>
>> +	Definition: Array of the GPIO hardware numbers corresponding to GPIOs
>> +		    which the APSS processor is not allowed to configure.
>> +		    The hardware numbers are indexed from 1.
>> +		    The interrupt resources for these GPIOs must not be defined
>> +		    in "interrupts" and "interrupt-names" properties.
>> +		    GPIOs defined in this array won't be registered as pins
>> +		    in the pinctrl device or gpios in the gpio chip.
> Isn't simply not assigning GPIOs to anything in the DT sufficient to not

Thanks for the question, Ron.
Previous implementation assumes all GPIOs are accessible from APSS
processor and it gets the total pin numbers by counting IRQs. It
registers pinctrl devices with the total pin numbers and assumes all the
pin are indexed continuously from hardware.
Current case is, some GPIOs' interrupt are not owned by APSS processor
and there would be errors when creating IRQ mapping for them. Yes, We
can exclude them from the "interrupts" property but the driver won't
shift the GPIO pad index automatically. Such as: PMI8998 has 14 GPIOs
from GPIO1 to GPIO14, and GPIO4/GPIO7/GPIO13 are not accessible from
APPS processor, we can excluded them from the interrupt assignment (in
following sample) and DON'T expect to register pins for them, but the
driver would count the IRQ numbers to 11 and register pins for
GPIO1 ~ GPIO11.
So I am adding this property "qcom,gpios-disallowed"  for these
inaccessible GPIOs then the driver would exclude them and register pins
for the right GPIO pads.

Samples:

interrupts = <0x2 0xc0 0 IRQ_TYPE_NONE>,
                 <0x2 0xc1 0 IRQ_TYPE_NONE>,
                 <0x2 0xc2 0 IRQ_TYPE_NONE>,
                 <0x2 0xc4 0 IRQ_TYPE_NONE>,
                 <0x2 0xc5 0 IRQ_TYPE_NONE>,
                 <0x2 0xc7 0 IRQ_TYPE_NONE>,
                 <0x2 0xc8 0 IRQ_TYPE_NONE>,
                 <0x2 0xc9 0 IRQ_TYPE_NONE>,
                 <0x2 0xca 0 IRQ_TYPE_NONE>,
                 <0x2 0xcb 0 IRQ_TYPE_NONE>,
                 <0x2 0xcd 0 IRQ_TYPE_NONE>;
interrupt-names = "pmi8998_gpio1", "pmi8998_gpio2",
                 "pmi8998_gpio3", "pmi8998_gpio5",
                 "pmi8998_gpio6", "pmi8998_gpio8",
                 "pmi8998_gpio9", "pmi8998_gpio10",
                 "pmi8998_gpio11", "pmi8998_gpio12",
                 "pmi8998_gpio14";
qcom,gpios-disallowed = <4 7 13>;

-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.