aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/vt.h
diff options
context:
space:
mode:
authorLen Brown <len.brown@intel.com>2007-12-27 23:55:13 -0500
committerLen Brown <len.brown@intel.com>2007-12-27 23:55:13 -0500
commit2c838197751db19d08a00e633e33dce23a69fb0c (patch)
treea7a6a4a59656cd52a9c814defbf34ea6b29774f3 /include/linux/vt.h
parentc68cb23dde29fb107575656effa46f7b9440ac04 (diff)
downloadkernel_samsung_smdk4412-2c838197751db19d08a00e633e33dce23a69fb0c.zip
kernel_samsung_smdk4412-2c838197751db19d08a00e633e33dce23a69fb0c.tar.gz
kernel_samsung_smdk4412-2c838197751db19d08a00e633e33dce23a69fb0c.tar.bz2
increase PNP_MAX_PORT to 40 from 24
a7839e960675b549f06209d18283d5cee2ce9261 (PNP: increase the maximum number of resources) increased PNP_MAX_PORT to 24 from 8. It also added a test and a complaint when a machine exceeded the limit, causing: pnpacpi: exceeded the max number of IO resources: 24 http://bugzilla.kernel.org/show_bug.cgi?id=9535 We should have been squawking about this all along, as this is a potentially serious issue. For now, simply burn some dynamic bytes and increase the limit by another 16 to 40. There is no guarantee that this will satisfy every system on Earth. It probably will not, but it should be an improvement. In the future, PNPACPI should allocate resource structures as needed, rather than max-sized arrays. Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'include/linux/vt.h')
0 files changed, 0 insertions, 0 deletions