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: <39f5e726-8542-b650-3bdb-7542e8fab8ac@ti.com>
Date:   Fri, 28 Jun 2019 09:08:37 +0530
From:   Keerthy <j-keerthy@...com>
To:     Nishanth Menon <nm@...com>
CC:     <t-kristo@...com>, <will.deacon@....com>,
        <catalin.marinas@....com>, <shawnguo@...nel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <lokeshvutla@...com>
Subject: Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for
 ARCH_K3



On 27/06/19 8:02 PM, Nishanth Menon wrote:
> On 16:39-20190627, Keerthy wrote:
>> Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms.
>>
>> Signed-off-by: Keerthy <j-keerthy@...com>
>> ---
>>
>> Changes in v2:
>>
>>    * Enabling configs in Kconfig.platforms file instead of defconfig.
>>    * Removed GPIO_DEBUG config.
>>
>>   arch/arm64/Kconfig.platforms | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 4778c775de1b..6e43a0995ed4 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -97,6 +97,8 @@ config ARCH_K3
>>   	select TI_SCI_PROTOCOL
>>   	select TI_SCI_INTR_IRQCHIP
>>   	select TI_SCI_INTA_IRQCHIP
>> +	select GPIO_SYSFS
>> +	select GPIO_DAVINCI
> 
> 
> Could you help explain the logic of doing this? commit message is
> basically the diff in English. To me, this does NOT make sense.
> 
> I understand GPIO_DAVINCI is the driver compatible, but we cant do this for
> every single SoC driver that is NOT absolutely mandatory for basic
> functionality.

In case of ARM64 could you help me find the right place to enable
such SoC specific configs?

> 
> Also keep in mind the impact to arm64/configs/defconfig -> every single
> SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force
> that?

This was the practice in arm32 soc specific configs like 
omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i 
totally understand your concern about every single SoC rebuilding but 
now where do we need to enable the bare minimal GPIO_DAVINCI config?

v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i 
shifted to this approach.

> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ