coreboot-gerrit October 2014

coreboot-gerrit@coreboot.org

1 participants
1026 discussions

Patch set updated for coreboot: 655554b intel/fsp_baytrail: Clear the GNVS area prior to filling
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7040 -gerrit commit 655554b2fb926af93655d64f979a12d53e7413d0 Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:26:05 2014 -0400 intel/fsp_baytrail: Clear the GNVS area prior to filling Zero out the GNVS area so that uninitialized portions are defined. Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5 (ACPI_BIOS_ERROR) with the first parameter (0x00001000) (ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the GNVS area to define whether they're enabled and their MMIO regions. On my custom baytrail-based board and build, these devices were disabled but GNVS had uninitialized data indicating the devices were enabled with improper MMIO regions. Should investigate further to see where the GNVS device values are set if enabled and make sure they're set to valid values even when the devices are disabled via the mainboard/devicetree.cb. Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/acpi.c b/src/soc/intel/fsp_baytrail/acpi.c index dece178..fb0dc87 100644 --- a/src/soc/intel/fsp_baytrail/acpi.c +++ b/src/soc/intel/fsp_baytrail/acpi.c @@ -88,6 +88,9 @@ static acpi_cstate_t cstate_map[] = { void acpi_init_gnvs(global_nvs_t *gnvs) { + /* Clear gnvs area so uninitialized portions are defined */ + memset(gnvs, 0, sizeof(*gnvs)); + /* CPU core count */ gnvs->pcnt = dev_count_cpu();

1 0

Patch set updated for coreboot: a3c2f67 intel/fsp_baytrail: Clear the GNVS area prior to filling
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7040 -gerrit commit a3c2f67bb820b5d9d0ab2f858f21de7b0e114ba7 Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:26:05 2014 -0400 intel/fsp_baytrail: Clear the GNVS area prior to filling Zero out the GNVS area so that uninitialized portions are defined. Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5 (ACPI_BIOS_ERROR) with first parameter 0x00001000 (ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the GNVS area to define whether they're enabled and their MMIO regions. On my custom baytrail-based board and build, these devices are disabled but GNVS had uninitialized data indicating the devices were enabled with improper MMIO regions. Should investigate further to see where the GNVS device values are set if enabled and make sure they are set to valid values even when the devices are disabled via the mainboard/devicetree.cb. Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/acpi.c b/src/soc/intel/fsp_baytrail/acpi.c index dece178..fb0dc87 100644 --- a/src/soc/intel/fsp_baytrail/acpi.c +++ b/src/soc/intel/fsp_baytrail/acpi.c @@ -88,6 +88,9 @@ static acpi_cstate_t cstate_map[] = { void acpi_init_gnvs(global_nvs_t *gnvs) { + /* Clear gnvs area so uninitialized portions are defined */ + memset(gnvs, 0, sizeof(*gnvs)); + /* CPU core count */ gnvs->pcnt = dev_count_cpu();

1 0

Patch set updated for coreboot: 727e358 baytrail: Add padding to the end of device_nvs to match ACPI
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7039 -gerrit commit 727e3583553614c7c1d4860f34011d66905c2259 Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:15:01 2014 -0400 baytrail: Add padding to the end of device_nvs to match ACPI ACPI globalnvs.asl expects the gnvs memory area size to be 0x2000. Padding has been added to device_nvs struct to reserve the full 0x2000 bytes for gnvs usage. No known issues are caused by having the GNVS area shorter than what ACPI thinks. Since there's nothing defined in this area, O/S shouldn't try to access it. Only problem might be if O/S notices the SSDT is located within the GNVS defined area. I verified that the next table written to memory (SSDT) is 0x2000 past GNVS start using a custom-designed Baytrail-I motherboard based on the Intel Bayley Bay CRB. Change-Id: I9792954c7a3403eba6f37d7e53ea4a9ed3a2e4ac Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/baytrail/baytrail/device_nvs.h | 3 ++- src/soc/intel/fsp_baytrail/baytrail/device_nvs.h | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/soc/intel/baytrail/baytrail/device_nvs.h b/src/soc/intel/baytrail/baytrail/device_nvs.h index f8f831b..c7fbc45 100644 --- a/src/soc/intel/baytrail/baytrail/device_nvs.h +++ b/src/soc/intel/baytrail/baytrail/device_nvs.h @@ -55,13 +55,14 @@ typedef struct { u32 scc_bar0[3]; u32 lpe_bar0; - /* BAR 0 */ + /* BAR 1 */ u32 lpss_bar1[14]; u32 scc_bar1[3]; u32 lpe_bar1; /* Extra */ u32 lpe_fw; /* LPE Firmware */ + u8 rsvd1[3930]; /* Add padding so sizeof(device_nvs_t) == 0x1000 */ } __attribute__((packed)) device_nvs_t; #endif diff --git a/src/soc/intel/fsp_baytrail/baytrail/device_nvs.h b/src/soc/intel/fsp_baytrail/baytrail/device_nvs.h index a06ca70..1ed897f 100644 --- a/src/soc/intel/fsp_baytrail/baytrail/device_nvs.h +++ b/src/soc/intel/fsp_baytrail/baytrail/device_nvs.h @@ -55,13 +55,14 @@ typedef struct { u32 scc_bar0[3]; u32 lpe_bar0; - /* BAR 1 */ + /* BAR 0 */ u32 lpss_bar1[14]; u32 scc_bar1[3]; u32 lpe_bar1; /* Extra */ u32 lpe_fw; /* LPE Firmware */ + u8 rsvd1[3930]; /* Add padding so sizeof(device_nvs_t) == 0x1000 */ } __attribute__((packed)) device_nvs_t; #endif

1 0

Patch set updated for coreboot: d72a6ed intel/fsp_baytrail: Clear the GNVS area prior to filling
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7040 -gerrit commit d72a6ed2caf4ae94a19ab5153283cbf4eab484f6 Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:26:05 2014 -0400 intel/fsp_baytrail: Clear the GNVS area prior to filling Zero out the GNVS area so that uninitialized portions are defined. Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/acpi.c b/src/soc/intel/fsp_baytrail/acpi.c index dece178..fb0dc87 100644 --- a/src/soc/intel/fsp_baytrail/acpi.c +++ b/src/soc/intel/fsp_baytrail/acpi.c @@ -88,6 +88,9 @@ static acpi_cstate_t cstate_map[] = { void acpi_init_gnvs(global_nvs_t *gnvs) { + /* Clear gnvs area so uninitialized portions are defined */ + memset(gnvs, 0, sizeof(*gnvs)); + /* CPU core count */ gnvs->pcnt = dev_count_cpu();

1 0

Patch set updated for coreboot: a9fcd41 intel/fsp_baytrail: Add padding so device_nvs location matches ACPI
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7038 -gerrit commit a9fcd4167cac99412ec9c373f29ddf6b648a7e9b Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:09:52 2014 -0400 intel/fsp_baytrail: Add padding so device_nvs location matches ACPI The offset of the device_nvs in the gnvs struct is expected to be 0x1000. It is actually 0x100 so padding is needed to move device_nvs to the expected location. ACPI references to device_nvs objects will be correct with the padding. This was tested using a Micro Industries customized Baytrail-I board based on the Intel Bayley Bay CRB. In intel/baytrail/nvs.h, there's a Google customized structure located at 0x0100-0x0FFF that is removed from the fsp_baytrail/nvs.h which explains the mismatch here. Change-Id: I4721a79b53b5b3345ff9b0c053bdd31d2cf9cb61 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/baytrail/nvs.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/baytrail/nvs.h b/src/soc/intel/fsp_baytrail/baytrail/nvs.h index 53c4a64..242f6d3 100644 --- a/src/soc/intel/fsp_baytrail/baytrail/nvs.h +++ b/src/soc/intel/fsp_baytrail/baytrail/nvs.h @@ -61,6 +61,9 @@ typedef struct { u32 cbmc; /* 0x38 - coreboot memconsole */ u8 rsvd3[196]; + /* Pad 0x0100-0x0fff */ + u8 rsvd4[3840]; + /* Baytrail LPSS (0x1000) */ device_nvs_t dev; } __attribute__((packed)) global_nvs_t;

1 0

Patch set updated for coreboot: b4925b7 intel/fsp_baytrail: Clear the GNVS area prior to filling
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7040 -gerrit commit b4925b77c0cde5ffb671dfef7448dbcc0c12e42c Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:26:05 2014 -0400 intel/fsp_baytrail: Clear the GNVS area prior to filling Zero out the GNVS area so that uninitialized portions are defined. Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5 (ACPI_BIOS_ERROR) with first parameter 0x00001000 (ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the GNVS area to define whether they're enabled and their MMIO regions. On my custom baytrail-based board and build, these devices are disabled but GNVS had uninitialized data indicating the devices were enabled with improper MMIO regions. Should investigate further to see where the GNVS device values are set if enabled and make sure they are set to valid values even when the devices are disabled via the mainboard/devicetree.cb. Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/acpi.c b/src/soc/intel/fsp_baytrail/acpi.c index dece178..fb0dc87 100644 --- a/src/soc/intel/fsp_baytrail/acpi.c +++ b/src/soc/intel/fsp_baytrail/acpi.c @@ -88,6 +88,9 @@ static acpi_cstate_t cstate_map[] = { void acpi_init_gnvs(global_nvs_t *gnvs) { + /* Clear gnvs area so uninitialized portions are defined */ + memset(gnvs, 0, sizeof(*gnvs)); + /* CPU core count */ gnvs->pcnt = dev_count_cpu();

1 0

Patch set updated for coreboot: c1a65db intel/fsp_baytrail: Clear the GNVS area prior to filling
by Scott Radcliffe 13 Oct '14

13 Oct '14

Scott Radcliffe (sradcliffe(a)microind.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7040 -gerrit commit c1a65db524a5b0b352bce3013b56cf6239c3313a Author: Scott Radcliffe <sradcliffe(a)microind.com> Date: Fri Oct 10 16:26:05 2014 -0400 intel/fsp_baytrail: Clear the GNVS area prior to filling Zero out the GNVS area so that uninitialized portions are defined. Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5 (ACPI_BIOS_ERROR) with first parameter 0x00001000 (ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the GNVS area to define whether they're enabled and their MMIO regions. On my custom baytrail-based board and build, these devices are disabled but GNVS had uninitialized data indicating the devices were enabled with improper MMIO regions. Should investigate further to see where the GNVS device values are set if enabled and make sure they are set to valid values even when the devices are disabled via the mainboard/devicetree.cb. Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97 Signed-off-by: Scott Radcliffe <sradcliffe(a)microind.com> --- src/soc/intel/fsp_baytrail/acpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/soc/intel/fsp_baytrail/acpi.c b/src/soc/intel/fsp_baytrail/acpi.c index dece178..fb0dc87 100644 --- a/src/soc/intel/fsp_baytrail/acpi.c +++ b/src/soc/intel/fsp_baytrail/acpi.c @@ -88,6 +88,9 @@ static acpi_cstate_t cstate_map[] = { void acpi_init_gnvs(global_nvs_t *gnvs) { + /* Clear gnvs area so uninitialized portions are defined */ + memset(gnvs, 0, sizeof(*gnvs)); + /* CPU core count */ gnvs->pcnt = dev_count_cpu();

1 0

Patch set updated for coreboot: 594eef3 AMD Trinity and Kabini: fix fan control
by WANG Siyuan 13 Oct '14

13 Oct '14

WANG Siyuan (wangsiyuanbuaa(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/6981 -gerrit commit 594eef33dc8e03a154dea776c8b155e41b2d5505 Author: WANG Siyuan <wangsiyuanbuaa(a)gmail.com> Date: Fri Oct 10 14:37:02 2014 +0800 AMD Trinity and Kabini: fix fan control The fan can stop but can't run again. "AGESA hudson yangtze: Move IMC firmware init out of get_bus_conf()" (Change-Id: I5b3cbc4d2) result to this problem. This patch can resolve this problem. Change-Id: I1b5bf3f6f7a66c60743f78918dc5442cdfc8b6e4 Signed-off-by: WANG Siyuan <SiYuan.Wang(a)amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa(a)gmail.com> --- src/cpu/amd/agesa/amd_late_init.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/cpu/amd/agesa/amd_late_init.c b/src/cpu/amd/agesa/amd_late_init.c index c7927dc..37d36b1 100644 --- a/src/cpu/amd/agesa/amd_late_init.c +++ b/src/cpu/amd/agesa/amd_late_init.c @@ -58,11 +58,6 @@ static void agesawrapper_post_device(void *unused) pci_write_config32(dev, 0x60, value); #endif -#if IS_ENABLED(CONFIG_HUDSON_IMC_FWM) - /* AMD AGESA does not enable thermal zone, so we enable it here. */ - enable_imc_thermal_zone(); -#endif - #if CONFIG_AMD_SB_CIMX sb_Late_Post(); #endif @@ -70,6 +65,12 @@ static void agesawrapper_post_device(void *unused) return; AGESAWRAPPER(amdS3Save); + +#if IS_ENABLED(CONFIG_HUDSON_IMC_FWM) + /* AMD AGESA does not enable thermal zone, so we enable it here. */ + printk(BIOS_DEBUG, "enable_imc_thermal_zone\n"); + enable_imc_thermal_zone(); +#endif } BOOT_STATE_INIT_ENTRIES(agesa_bscb) = {

1 0

Patch set updated for coreboot: f44e531 NOTFORMERGE: ec/lenovo/h8: permanently enable wifi/trackpoint/touchpad/bluetooth/wwan
by Francis Rowe 13 Oct '14

13 Oct '14

Francis Rowe (info(a)gluglug.org.uk) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7058 -gerrit commit f44e531919c64c13654ad38700a9fdf2840fc8f1 Author: Francis Rowe <info(a)gluglug.org.uk> Date: Mon Oct 13 00:14:53 2014 +0100 NOTFORMERGE: ec/lenovo/h8: permanently enable wifi/trackpoint/touchpad/bluetooth/wwan Wifi is enabled by default: most users will want wifi. Intel wifi chipsets might be a security risk due to non-free firmware (these chipsets have DMA access) and could leak data over a side-channel. Switching to a non-intel wifi chipset (without firmware, or with free firmware) is recommended. Enable bluetooth and wwan. Note, these are both security risks. WWAN cards also have proprietary firmware in them. That, plus DMA access means you should physically remove it. It's possible to replace the wwan card with something else, for example an SD card reader. Enable trackpoint and touchpad. There is no reason to disable these. Change-Id: Ic76ab9ab9c865f30312378e18af58bece6c3260a Signed-off-by: Francis Rowe <info(a)gluglug.org.uk> --- src/ec/lenovo/h8/h8.c | 21 +++++++++++---------- src/ec/lenovo/pmh7/pmh7.c | 11 ++++------- 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/src/ec/lenovo/h8/h8.c b/src/ec/lenovo/h8/h8.c index 79ef3cd..186ae6a 100644 --- a/src/ec/lenovo/h8/h8.c +++ b/src/ec/lenovo/h8/h8.c @@ -245,9 +245,11 @@ static void h8_enable(device_t dev) ec_write(H8_FAN_CONTROL, H8_FAN_CONTROL_AUTO); - if (get_option(&val, "wlan") != CB_SUCCESS) - val = 1; - h8_wlan_enable(val); + // Permanently enable wifi + // Intel wifi could be a security risk because it uses firmware. Wlan chip has DMA + // and could leak data over a side-channel. Using another manufacturer is recommended. + // see http://libreboot.org/docs/index.html#recommended_wifi + h8_wlan_enable(1); h8_trackpoint_enable(1); h8_usb_power_enable(1); @@ -255,14 +257,13 @@ static void h8_enable(device_t dev) if (get_option(&val, "volume") == CB_SUCCESS) ec_write(H8_VOLUME_CONTROL, val); - if (get_option(&val, "bluetooth") != CB_SUCCESS) - val = 1; - h8_bluetooth_enable(val); - - if (get_option(&val, "wwan") != CB_SUCCESS) - val = 1; + // Permanently enable bluetooth. + // NOTE: bluetooth is a potential security risk. Physical removal of the bluetooth module is recommended. + h8_bluetooth_enable(1); - h8_wwan_enable(val); + // Permanently enable wwan. + // NOTE: wwan is a security risk (remove access plus DMA). Physical removal of both the wwan and sim card is recommended. + h8_wwan_enable(1); if (conf->has_uwb) { if (get_option(&val, "uwb") != CB_SUCCESS) diff --git a/src/ec/lenovo/pmh7/pmh7.c b/src/ec/lenovo/pmh7/pmh7.c index cb0e27b..38ca77a 100644 --- a/src/ec/lenovo/pmh7/pmh7.c +++ b/src/ec/lenovo/pmh7/pmh7.c @@ -106,7 +106,6 @@ static void enable_dev(device_t dev) { struct ec_lenovo_pmh7_config *conf = dev->chip_info; struct resource *resource; - u8 val; resource = new_resource(dev, EC_LENOVO_PMH7_INDEX); resource->flags = IORESOURCE_IO | IORESOURCE_FIXED; @@ -118,13 +117,11 @@ static void enable_dev(device_t dev) pmh7_backlight_enable(conf->backlight_enable); pmh7_dock_event_enable(conf->dock_event_enable); - if (get_option(&val, "touchpad") != CB_SUCCESS) - val = 1; - pmh7_touchpad_enable(val); + // Permanently enable touchpad + pmh7_touchpad_enable(1); - if (get_option(&val, "trackpoint") != CB_SUCCESS) - val = 1; - pmh7_trackpoint_enable(val); + // Permanently enable trackpoint + pmh7_trackpoint_enable(1); } struct chip_operations ec_lenovo_pmh7_ops = {

1 0

Patch set updated for coreboot: cb882f1 NOTFORMERGE: ec/lenovo/h8: permanently enable wifi/trackpoint/touchpad, disable bluetooth/wwan
by Francis Rowe 12 Oct '14

12 Oct '14

Francis Rowe (info(a)gluglug.org.uk) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7058 -gerrit commit cb882f1bb75aa2ccc5fa62284eacf5ee59029348 Author: Francis Rowe <info(a)gluglug.org.uk> Date: Mon Oct 13 00:14:53 2014 +0100 NOTFORMERGE: ec/lenovo/h8: permanently enable wifi/trackpoint/touchpad, disable bluetooth/wwan Wifi is enabled by default: most users will want wifi. Intel wifi chipsets might be a security risk due to non-free firmware (these chipsets have DMA access) and could leak data over a side-channel. Switching to a non-intel wifi chipset (without firmware, or with free firmware) is recommended. Disable wwan. These chipsets have non-free firmware in them and direct memory access. Disable bluetooth (potential security risk). Enable trackpoint and touchpad. There is no reason to disable these. Change-Id: Ic76ab9ab9c865f30312378e18af58bece6c3260a Signed-off-by: Francis Rowe <info(a)gluglug.org.uk> --- src/ec/lenovo/h8/h8.c | 22 ++++++++++++---------- src/ec/lenovo/pmh7/pmh7.c | 11 ++++------- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/ec/lenovo/h8/h8.c b/src/ec/lenovo/h8/h8.c index 79ef3cd..dd6f73c 100644 --- a/src/ec/lenovo/h8/h8.c +++ b/src/ec/lenovo/h8/h8.c @@ -245,9 +245,11 @@ static void h8_enable(device_t dev) ec_write(H8_FAN_CONTROL, H8_FAN_CONTROL_AUTO); - if (get_option(&val, "wlan") != CB_SUCCESS) - val = 1; - h8_wlan_enable(val); + // Permanently enable wifi + // Intel wifi could be a security risk because it uses firmware. Wlan chip has DMA + // and could leak data over a side-channel. Using another manufacturer is recommended. + // see http://libreboot.org/docs/index.html#recommended_wifi + h8_wlan_enable(1); h8_trackpoint_enable(1); h8_usb_power_enable(1); @@ -255,14 +257,14 @@ static void h8_enable(device_t dev) if (get_option(&val, "volume") == CB_SUCCESS) ec_write(H8_VOLUME_CONTROL, val); - if (get_option(&val, "bluetooth") != CB_SUCCESS) - val = 1; - h8_bluetooth_enable(val); - - if (get_option(&val, "wwan") != CB_SUCCESS) - val = 1; + // Permanently disable bluetooth (potential remote security risk) + h8_bluetooth_enable(0); - h8_wwan_enable(val); + // Permanently disable wwan + // These wwan chips have firmware in them - they have to. It's a small OS that handles communication + // with a telecoms provider. The issue is that this could allow remote access to the machine, + // and the cards have direct memory access. It could potentially leak data. + h8_wwan_enable(0); if (conf->has_uwb) { if (get_option(&val, "uwb") != CB_SUCCESS) diff --git a/src/ec/lenovo/pmh7/pmh7.c b/src/ec/lenovo/pmh7/pmh7.c index cb0e27b..38ca77a 100644 --- a/src/ec/lenovo/pmh7/pmh7.c +++ b/src/ec/lenovo/pmh7/pmh7.c @@ -106,7 +106,6 @@ static void enable_dev(device_t dev) { struct ec_lenovo_pmh7_config *conf = dev->chip_info; struct resource *resource; - u8 val; resource = new_resource(dev, EC_LENOVO_PMH7_INDEX); resource->flags = IORESOURCE_IO | IORESOURCE_FIXED; @@ -118,13 +117,11 @@ static void enable_dev(device_t dev) pmh7_backlight_enable(conf->backlight_enable); pmh7_dock_event_enable(conf->dock_event_enable); - if (get_option(&val, "touchpad") != CB_SUCCESS) - val = 1; - pmh7_touchpad_enable(val); + // Permanently enable touchpad + pmh7_touchpad_enable(1); - if (get_option(&val, "trackpoint") != CB_SUCCESS) - val = 1; - pmh7_trackpoint_enable(val); + // Permanently enable trackpoint + pmh7_trackpoint_enable(1); } struct chip_operations ec_lenovo_pmh7_ops = {

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit October 2014