[PATCH 02/12] drm/ast: Handle configuration without P2A bridge

YC Chen yc_chen at aspeedtech.com
Fri Feb 24 18:06:15 AEDT 2017


Tested-by: Y.C. Chen <yc_chen at aspeedtech.com>

-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org] 
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel at lists.freedesktop.org
Cc: YC Chen <yc_chen at aspeedtech.com>; airlied at redhat.com; eich at suse.come; linuxppc-dev at ozlabs.org
Subject: [PATCH 02/12] drm/ast: Handle configuration without P2A bridge

From: Russell Currey <ruscur at russell.cc>

The ast driver configures a window to enable access into BMC memory space in order to read some configuration registers.

If this window is disabled, which it can be from the BMC side, the ast driver can't function.

Closing this window is a necessity for security if a machine's host side and BMC side are controlled by different parties; i.e. a cloud provider offering machines "bare metal".

A recent patch went in to try to check if that window is open but it does so by trying to access the registers in question and testing if the result is 0xffffffff.

This method will trigger a PCIe error when the window is closed which on some systems will be fatal (it will trigger an EEH for example on POWER which will take out the device).

This patch improves this in two ways:

 - First, if the firmware has put properties in the device-tree containing the relevant configuration information, we use these.

 - Otherwise, a bit in one of the SCU scratch registers (which are readable via the VGA register space and writeable by the BMC) will indicate if the BMC has closed the window. This bit has been defined by Y.C Chen from Aspeed.

If the window is closed and the configuration isn't available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server.

Signed-off-by: Russell Currey <ruscur at russell.cc>
Signed-off-by: Benjamin Herrenschmidt <benh at kernel.crashing.org>


More information about the Linuxppc-dev mailing list