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]
Date:   Thu, 3 May 2018 13:25:39 -0500
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Tony Lindgren <tony@...mide.com>
CC:     Christina Quast <cquast@...libre.com>,
        <linux-omap@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <narmstrong@...libre.com>,
        Oleg Kokorin <ole2mail@...l.com>
Subject: Re: [PATCH 1/2] ARM: dts: am335x: Replace numeric pinmux address with
 macro defines



On 05/03/2018 11:19 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@...com> [180503 15:54]:
>>
>>
>> On 04/30/2018 12:31 PM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Christina Quast <cquast@...libre.com> [180430 11:23]:
>>>> The values are extraced from the "AM335x SitaraTM Processors Technical
>>>> Reference Manual", Section 9.3.1 CONTROL_MODULE Registers, based on the
>>>> file autogenerated by TI PinMux.
>>>
>>> This certainly makes things easier to mux :)
>>>
>>> Have you verified that the registers are the same across all am335x
>>> models and different revisions?
>>>
>>> It used to be that different SoC revisions could have different
>>> amount of registers and also different options in some cases.
>>>
>>>> +#define AM335X_CONTROL_REVISION			0x0
>>>> +#define AM335X_CONTROL_HWINFO			0x4
>>>> +#define AM335X_CONTROL_SYSCONFIG		0x10
>>>> +#define AM335X_CONTROL_STATUS			0x40
>>>
>>> You should only list the padconf mux registers here, no need to
>>> list any of the controller registers.
>>>
>>
>> To be honest, I do think it's right thing to do - DT by itself is
>> documentation and previously DT maintainers were not very happy regarding
>> introducing more defines instead of const.
> 
> Sounds like you mean "I don't think" above instead of "I do think"?
> Care to clarify..

i don't.. sry

> 
>> Adding such defines will introduce big headers in Linux common or
>> platform folders again which we've just got rid of.
>>
>> If smth is unclear - comments can be used in DT.
>>
>> Just my 5c.
> 
> The problem earlier was that we had just too many variants as
> the padconf registers got changed even between SoC revisions.
> Not always and not for many registers but still. The padconf
> register range seems to stay the same for a SoC though.
> 
> I do see value at being able to mux the registers easier though.



-- 
regards,
-grygorii

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ