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: <2a1ccecd-f81f-4de3-a4f8-c056496802b1@ti.com>
Date: Mon, 15 Jul 2024 09:12:16 -0500
From: Logan Bristol <l-bristol@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Bryan Brattlof <bb@...com>,
        Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>
CC: Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree

On 7/10/24 01:52, Krzysztof Kozlowski wrote:
> On 09/07/2024 18:20, Logan Bristol wrote:
>>
>> Hi all,
>>
>> On 3/22/22 13:14, Krzysztof Kozlowski wrote:
>>> On 21/03/2022 16:54, Bryan Brattlof wrote:
>>>> Texas Instrument's am642 is one of many k3 based, low cost, low power,
>>>> chips designed to work in a wide range of applications spanning an even
>>>> wider range of industries that TI is actively developing
>>>>
>>>> With its pin-mux and peripheral rich designs, these chips will likely
>>>> have a multitude of custom device trees that range wildly from one
>>>> another and (hopefully) guarantee an influx of variants into the kernel
>>>> in the coming years
>>>>
>>>> With overlays no longer a thing, I wanted to ask for opinions on how
>>>> we can best help integrate these dt files as they begin to be developed
>>>>
>>>> I also wanted to introduce a skeletonized (nothing but uart) device tree
>>>> to give others a good starting point while developing their projects.
>>>
>>> Real hardware as DTS please. There is no need to add some skeleton for
>>> specific SoC. What if every SoC goes that way?
>>>
>>> Feel free to create re-usable components in DTSI ways, still reflecting
>>> some hardware parts.
>>>
>>
>> I am working on a project for the AM62 and came across this email thread.
>>
>> Following Krzysztof's direction, I am wanting to submit a DTSI to serve
>> as a minimal configuration for the existing boards based on the AM62
>> SoC, which are currently defined by bloated DTS files.
>>
>> This DTSI file can be consumed by other board DTS files to reduce the
>> configuration. Krzysztof, could this be merged upstream?
> 
> Aren't you writing something contradictory to what I wrote above? I do
> not see your description matching my earlier guideline.
> 
> Best regards,
> Krzysztof
> 

I understand your statement now. Are there any other paths you can
suggest for a minimal configuration to be accepted?

Thanks,
Logan Bristol

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ