From: David Hildenbrand <david@redhat.com>
To: Shiju Jose <shiju.jose@huawei.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "rafael@kernel.org" <rafael@kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"jiaqiyan@google.com" <jiaqiyan@google.com>,
"jthoughton@google.com" <jthoughton@google.com>,
"somasundaram.a@hpe.com" <somasundaram.a@hpe.com>,
"erdemaktas@google.com" <erdemaktas@google.com>,
"pgonda@google.com" <pgonda@google.com>,
"rientjes@google.com" <rientjes@google.com>,
"duenwen@google.com" <duenwen@google.com>,
"Vilas.Sridharan@amd.com" <Vilas.Sridharan@amd.com>,
"mike.malvestuto@intel.com" <mike.malvestuto@intel.com>,
"gthelen@google.com" <gthelen@google.com>,
Linuxarm <linuxarm@huawei.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
tanxiaofei <tanxiaofei@huawei.com>,
"Zengtao (B)" <prime.zeng@hisilicon.com>
Subject: Re: [RFC PATCH 3/9] Documentation/scrub-configure.rst: Add documentation for scrub driver
Date: Mon, 18 Sep 2023 14:15:33 +0200 [thread overview]
Message-ID: <7282d074-15ba-4fe7-bf62-6a4dd6089817@redhat.com> (raw)
In-Reply-To: <946f29d2370c41deb7a7c5a6f2bff0f3@huawei.com>
On 18.09.23 12:25, Shiju Jose wrote:
> Hi David,
>
> Thanks for looking into this.
>
>> -----Original Message-----
>> From: David Hildenbrand <david@redhat.com>
>> Sent: 18 September 2023 08:24
>> To: Shiju Jose <shiju.jose@huawei.com>; linux-acpi@vger.kernel.org; linux-
>> mm@kvack.org; linux-kernel@vger.kernel.org
>> Cc: rafael@kernel.org; lenb@kernel.org; naoya.horiguchi@nec.com;
>> tony.luck@intel.com; james.morse@arm.com; dave.hansen@linux.intel.com;
>> jiaqiyan@google.com; jthoughton@google.com; somasundaram.a@hpe.com;
>> erdemaktas@google.com; pgonda@google.com; rientjes@google.com;
>> duenwen@google.com; Vilas.Sridharan@amd.com; mike.malvestuto@intel.com;
>> gthelen@google.com; Linuxarm <linuxarm@huawei.com>; Jonathan Cameron
>> <jonathan.cameron@huawei.com>; tanxiaofei <tanxiaofei@huawei.com>;
>> Zengtao (B) <prime.zeng@hisilicon.com>
>> Subject: Re: [RFC PATCH 3/9] Documentation/scrub-configure.rst: Add
>> documentation for scrub driver
>>
>> On 15.09.23 19:28, shiju.jose@huawei.com wrote:
>>> From: Shiju Jose <shiju.jose@huawei.com>
>>>
>>> Add documentation for scrub driver, supports configure scrub
>>> parameters, in Documentation/scrub-configure.rst
>>>
>>> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
>>> ---
>>> Documentation/scrub-configure.rst | 55
>> +++++++++++++++++++++++++++++++
>>> 1 file changed, 55 insertions(+)
>>> create mode 100644 Documentation/scrub-configure.rst
>>>
>>> diff --git a/Documentation/scrub-configure.rst
>>> b/Documentation/scrub-configure.rst
>>> new file mode 100644
>>> index 000000000000..9f8581b88788
>>> --- /dev/null
>>> +++ b/Documentation/scrub-configure.rst
>>> @@ -0,0 +1,55 @@
>>> +==========================
>>> +Scrub subsystem driver
>>> +==========================
>>> +
>>> +Copyright (c) 2023 HiSilicon Limited.
>>> +
>>> +:Author: Shiju Jose <shiju.jose@huawei.com>
>>> +:License: The GNU Free Documentation License, Version 1.2
>>> + (dual licensed under the GPL v2) :Original Reviewers:
>>> +
>>> +- Written for: 6.7
>>> +- Updated for:
>>> +
>>> +Introduction
>>> +------------
>>> +The scrub subsystem driver provides the interface for configure the
>>
>> "... interface for configuring memory scrubbers in the system."
>>
>> are we only configuring firmware/hw-based memory scrubbing? I assume so.
> The scrub control could be used for the SW based memory scrubbing too.
Okay, looks like there is not too much hw/firmware specific in there
(besides these weird range changes).
[...]
>>> +-------
>>> +
>>> + The usage takes the form shown in this example::
>>> +
>>> + # echo 0x300000 > /sys/class/scrub/scrub0/region0/addr_base
>>> + # echo 0x100000 > /sys/class/scrub/scrub0/region0/addr_size
>>> + # cat /sys/class/scrub/scrub0/region0/speed_available
>>> + # 1-60
>>> + # echo 25 > /sys/class/scrub/scrub0/region0/speed
>>> + # echo 1 > /sys/class/scrub/scrub0/region0/enable
>>> +
>>> + # cat /sys/class/scrub/scrub0/region0/speed
>>> + # 0x19
>>
>> Is it reasonable to return the speed as hex? You set it as dec.
> Presently return speed as hex to reduce the number of callback function needed
> for reading the hex/dec data because the values for the address range
> need to be in hex.
If speed_available returns dec, speed better also return dec IMHO.
>
>>
>>> + # cat /sys/class/scrub/scrub0/region0/addr_base
>>> + # 0x100000
>>
>> But didn't we set it to 0x300000 ...
> This is an emulated example for testing the RASF/RAS2 definition.
> According to the RASF & RAS2 definition, the actual address range in the
> platform could vary from the requested address range for the patrol scrubbing.
> "The platform calculates the nearest patrol scrub boundary address
> from where it can start". The platform returns the actual address range
> in response to GET_PATROL_PARAMETERS command to the firmware.
> Please see section 5.2.21.2.1 Hardware-based Memory Scrubbing ,
> Table 5.87: Parameter Block Structure for PATROL_SCRUB in the
> ACPI 6.5 specification.
>
So you configure [0x300000 - 0x400000] and you get [0x100000 - 0x300000]
How does that make any sense? :)
Shouldn't we rather return an error when setting a range that is
impossible, instead of the hardware deciding to scrub something
completely different (as can be seen in the example)?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-09-18 12:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 17:28 [RFC PATCH 0/9] ACPI:RASF: Add support for ACPI RASF, ACPI RAS2 and configure scrubbers shiju.jose
2023-09-15 17:28 ` [RFC PATCH 1/9] memory: scrub: Add scrub driver supports configuring memory scrubbers in the system shiju.jose
2023-09-15 17:28 ` [RFC PATCH 2/9] memory: scrub: sysfs: Add Documentation entries for set of scrub attributes shiju.jose
2023-09-22 0:07 ` Jiaqi Yan
2023-09-22 10:20 ` Jonathan Cameron
2023-09-28 5:25 ` Jiaqi Yan
2023-09-28 13:14 ` Jonathan Cameron
2023-10-05 3:18 ` David Rientjes
2023-10-06 13:02 ` Jonathan Cameron
2023-10-06 13:06 ` Sridharan, Vilas
2023-10-11 16:35 ` Jonathan Cameron
2023-10-12 13:41 ` Sridharan, Vilas
2023-10-12 15:02 ` Jonathan Cameron
2023-10-12 15:44 ` Sridharan, Vilas
2023-10-13 9:07 ` Jonathan Cameron
2023-09-15 17:28 ` [RFC PATCH 3/9] Documentation/scrub-configure.rst: Add documentation for scrub driver shiju.jose
2023-09-18 7:23 ` David Hildenbrand
2023-09-18 10:25 ` Shiju Jose
2023-09-18 12:15 ` David Hildenbrand [this message]
2023-09-18 12:28 ` Jonathan Cameron
2023-09-18 12:34 ` David Hildenbrand
2023-09-18 15:03 ` Shiju Jose
2023-09-15 17:28 ` [RFC PATCH 4/9] ACPI:RASF: Add extract RASF table to register RASF platform devices shiju.jose
2023-09-15 17:28 ` [RFC PATCH 5/9] ACPI:RASF: Add common library for RASF and RAS2 PCC interfaces shiju.jose
2023-09-15 17:28 ` [RFC PATCH 6/9] memory: RASF: Add memory RASF driver shiju.jose
2023-09-15 17:28 ` [RFC PATCH 7/9] ACPICA: ACPI 6.5: Add support for RAS2 table shiju.jose
2023-09-15 17:28 ` [RFC PATCH 8/9] ACPI:RAS2: Add driver for ACPI RAS2 feature table (RAS2) shiju.jose
2023-09-15 17:28 ` [RFC PATCH 9/9] memory: RAS2: Add memory RAS2 driver shiju.jose
2023-09-17 21:14 ` [RFC PATCH 0/9] ACPI:RASF: Add support for ACPI RASF, ACPI RAS2 and configure scrubbers Jiaqi Yan
2023-09-18 10:19 ` Shiju Jose
2023-09-18 17:47 ` Jiaqi Yan
2023-09-19 8:28 ` Shiju Jose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7282d074-15ba-4fe7-bf62-6a4dd6089817@redhat.com \
--to=david@redhat.com \
--cc=Vilas.Sridharan@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=duenwen@google.com \
--cc=erdemaktas@google.com \
--cc=gthelen@google.com \
--cc=james.morse@arm.com \
--cc=jiaqiyan@google.com \
--cc=jonathan.cameron@huawei.com \
--cc=jthoughton@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=mike.malvestuto@intel.com \
--cc=naoya.horiguchi@nec.com \
--cc=pgonda@google.com \
--cc=prime.zeng@hisilicon.com \
--cc=rafael@kernel.org \
--cc=rientjes@google.com \
--cc=shiju.jose@huawei.com \
--cc=somasundaram.a@hpe.com \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).