On 22.01.21 07:04, Anshuman Khandual wrote:
>
> On 1/20/21 2:07 PM, Anshuman Khandual wrote:
>>
>>
>> On 1/19/21 7:10 PM, Oscar Salvador wrote:
>>> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote:
Minor thing, we should make up our mind if we want to call stuff
internal
On 1/20/21 2:07 PM, Anshuman Khandual wrote:
>
>
> On 1/19/21 7:10 PM, Oscar Salvador wrote:
>> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote:
>>> Minor thing, we should make up our mind if we want to call stuff
>>> internally "memhp_" or "mhp". I prefer the latter, because
On 1/19/21 7:10 PM, Oscar Salvador wrote:
> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote:
>> Minor thing, we should make up our mind if we want to call stuff
>> internally "memhp_" or "mhp". I prefer the latter, because it is shorter.
>
> I would rather use the latter as we
On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote:
> Minor thing, we should make up our mind if we want to call stuff
> internally "memhp_" or "mhp". I prefer the latter, because it is shorter.
I would rather use the latter as well. I used that in [1].
MEMHP_MERGE_RESOURCE should b
On 18.01.21 14:12, Anshuman Khandual wrote:
> This series adds a mechanism allowing platforms to weigh in and prevalidate
> incoming address range before proceeding further with the memory hotplug.
> This helps prevent potential platform errors for the given address range,
> down the hotplug call c
This series adds a mechanism allowing platforms to weigh in and prevalidate
incoming address range before proceeding further with the memory hotplug.
This helps prevent potential platform errors for the given address range,
down the hotplug call chain, which inevitably fails the hotplug itself.
Th
6 matches
Mail list logo
