linux-kernel - Re: RFC on drivers/memory vs drivers/edac memory mapping for DDR Controller

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:   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
>