Michael Ellerman writes:
> Nathan Lynch writes:
>> Nathan Lynch writes:
>>>
>>> aside: does anyone know if the display_status() code is worth keeping?
>>> It looks like it is used to drive the 16-character wide physical LCD I
>>> remember seeing on P4-era and older machines. Is it a vestige of
Nathan Lynch writes:
> Nathan Lynch writes:
>>
>> aside: does anyone know if the display_status() code is worth keeping?
>> It looks like it is used to drive the 16-character wide physical LCD I
>> remember seeing on P4-era and older machines. Is it a vestige of
>> non-LPAR pseries that should
Nathan Lynch writes:
>
> aside: does anyone know if the display_status() code is worth keeping?
> It looks like it is used to drive the 16-character wide physical LCD I
> remember seeing on P4-era and older machines. Is it a vestige of
> non-LPAR pseries that should be dropped, or is it perhaps
Andrew Donnellan writes:
> On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
>> From: Nathan Lynch
>>
>> Any caller of rtas_call_unlocked() must provide an rtas_args
>> parameter
>> block distinct from the core rtas_args buffer used by the rtas_call()
>> path. It's an
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Any caller of rtas_call_unlocked() must provide an rtas_args
> parameter
> block distinct from the core rtas_args buffer used by the rtas_call()
> path. It's an unlikely error to make, but the potential
From: Nathan Lynch
Any caller of rtas_call_unlocked() must provide an rtas_args parameter
block distinct from the core rtas_args buffer used by the rtas_call()
path. It's an unlikely error to make, but the potential consequences
are grim, and it's trivial to check.
Signed-off-by: Nathan Lynch
