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: <7cc4d012-1382-204c-5ba5-73bdf6dae2d5@amazon.com>
Date:   Tue, 3 Jan 2023 16:34:02 +0200
From:   "Shenhar, Talel" <talel@...zon.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        <bp@...en8.de>
CC:     <talelshenhar@...il.com>, <shellykz@...zon.com>,
        <linux-edac@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller


On 1/3/2023 4:24 PM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 03/01/2023 14:47, Shenhar, Talel wrote:
>> So how would you have the DT described and how would driver/s look like
>> for cases that the unit registers are split interchangeably?
>>
>>> You did not Cc relevant here mailing addresses (DT and Rob), so this
>>> discussion might miss their feedback.
>>>
>>> How the drivers map IO address space is independent question and should
>>> not determine the hardware description. You want to say that hardware
>>> changes depending on OS? One OS means hardware is like that and on other
>>> OS it's different?
> BTW, you nicely skipped points of my email which are a bit
> inconvenient,e.g. how you want to tie DTS and bindings to one specific
> driver implementation and ignore the rest...

Sorry missed that.

Rob would probably be relevant for this topic as well, however, I didn't 
want to focus on DT for this topic.

Seems your question is what I am actually asking...

However your answer keep getting back to do "full hardware description 
in dt and that it doesn't relate to driver" but does not give concrete 
response hence I fail to get the answer or direction I am looking for.

The solution I previously gave show different possibility for describing 
the HW and the impact on the drivers and wonder what is the best path.


For now I think this is the path I shall take which is option 1:

"1) map more specific region to avoid conflict (we don't need the same 
registers on both entity so if we do very specific multiple mapping this 
shall be resolved)"

Which seems to be what you are trying to say by give more complete HW 
description.


>
> Best regards,
> Krzysztof
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ