* [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() [not found] <20150531010132.289674310@telegraphics.com.au> @ 2015-05-31 1:01 ` Finn Thain 2015-05-31 4:11 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 9+ messages in thread From: Finn Thain @ 2015-05-31 1:01 UTC (permalink / raw) To: linux-kernel, linux-m68k, linuxppc-dev, Henrique de Moraes Holschuh, Darren Hart, ibm-acpi-devel, platform-driver-x86 [-- Attachment #1: pc-rtc-replace-exported-nvram-functions --] [-- Type: text/plain, Size: 3833 bytes --] Make use of arch_nvram_ops in the thinkpad_acpi driver so that the nvram_* function exports can be removed. This patch series was tested on a ThinkPad T43. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> --- drivers/platform/x86/thinkpad_acpi.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) Index: linux/drivers/platform/x86/thinkpad_acpi.c =================================================================== --- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:00:59.000000000 +1000 +++ linux/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:01:07.000000000 +1000 @@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_ u8 d; if (m & TP_NVRAM_HKEY_GROUP_HK2) { - d = nvram_read_byte(TP_NVRAM_ADDR_HK2); + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2); n->thinkpad_toggle = !!(d & TP_NVRAM_MASK_HKT_THINKPAD); n->zoom_toggle = !!(d & TP_NVRAM_MASK_HKT_ZOOM); n->display_toggle = !!(d & TP_NVRAM_MASK_HKT_DISPLAY); n->hibernate_toggle = !!(d & TP_NVRAM_MASK_HKT_HIBERNATE); } if (m & TP_ACPI_HKEY_THNKLGHT_MASK) { - d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT); + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT); n->thinklight_toggle = !!(d & TP_NVRAM_MASK_THINKLIGHT); } if (m & TP_ACPI_HKEY_DISPXPAND_MASK) { - d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO); + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO); n->displayexp_toggle = !!(d & TP_NVRAM_MASK_HKT_DISPEXPND); } if (m & TP_NVRAM_HKEY_GROUP_BRIGHTNESS) { - d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); n->brightness_level = (d & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; n->brightness_toggle = !!(d & TP_NVRAM_MASK_HKT_BRIGHTNESS); } if (m & TP_NVRAM_HKEY_GROUP_VOLUME) { - d = nvram_read_byte(TP_NVRAM_ADDR_MIXER); + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); n->volume_level = (d & TP_NVRAM_MASK_LEVEL_VOLUME) >> TP_NVRAM_POS_LEVEL_VOLUME; n->mute = !!(d & TP_NVRAM_MASK_MUTE); @@ -6153,7 +6153,7 @@ static unsigned int tpacpi_brightness_nv { u8 lnvram; - lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS) + lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS) & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; lnvram &= bright_maxlvl; @@ -6178,7 +6178,7 @@ static void tpacpi_brightness_checkpoint if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, &lec))) goto unlock; lec &= TP_EC_BACKLIGHT_LVLMSK; - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); if (lec != ((b_nvram & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) >> TP_NVRAM_POS_LEVEL_BRIGHTNESS)) { @@ -6186,7 +6186,7 @@ static void tpacpi_brightness_checkpoint b_nvram &= ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS << TP_NVRAM_POS_LEVEL_BRIGHTNESS); b_nvram |= lec; - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); dbg_printk(TPACPI_DBG_BRGHT, "updated NVRAM backlight level to %u (0x%02x)\n", (unsigned int) lec, (unsigned int) b_nvram); @@ -6794,13 +6794,13 @@ static void tpacpi_volume_checkpoint_nvr if (unlikely(!acpi_ec_read(TP_EC_AUDIO, &lec))) goto unlock; lec &= ec_mask; - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER); + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); if (lec != (b_nvram & ec_mask)) { /* NVRAM needs update */ b_nvram &= ~ec_mask; b_nvram |= lec; - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); dbg_printk(TPACPI_DBG_MIXER, "updated NVRAM mixer status to 0x%02x (0x%02x)\n", (unsigned int) lec, (unsigned int) b_nvram); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-05-31 1:01 ` [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain @ 2015-05-31 4:11 ` Henrique de Moraes Holschuh 2015-05-31 6:15 ` Finn Thain 0 siblings, 1 reply; 9+ messages in thread From: Henrique de Moraes Holschuh @ 2015-05-31 4:11 UTC (permalink / raw) To: Finn Thain Cc: linux-kernel, linux-m68k, linuxppc-dev, Darren Hart, ibm-acpi-devel, platform-driver-x86 On Sun, 31 May 2015, Finn Thain wrote: > Make use of arch_nvram_ops in the thinkpad_acpi driver so that the > nvram_* function exports can be removed. > > This patch series was tested on a ThinkPad T43. Can you describe how you did the testing? A specific procedure is required to test the hotkey NVRAM polling codepaths (which will read several NVRAM bytes @10Hz by default) in a T43... > Signed-off-by: Finn Thain <fthain@telegraphics.com.au> The patch looks correct, so I don't expect any problems. Provided that your test procedure did enable hotkey NVRAM polling in the T43 and your hotkeys all still worked fine, you have my Acked-by. > --- > drivers/platform/x86/thinkpad_acpi.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > Index: linux/drivers/platform/x86/thinkpad_acpi.c > =================================================================== > --- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:00:59.000000000 +1000 > +++ linux/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:01:07.000000000 +1000 > @@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_ > u8 d; > > if (m & TP_NVRAM_HKEY_GROUP_HK2) { > - d = nvram_read_byte(TP_NVRAM_ADDR_HK2); > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2); > n->thinkpad_toggle = !!(d & TP_NVRAM_MASK_HKT_THINKPAD); > n->zoom_toggle = !!(d & TP_NVRAM_MASK_HKT_ZOOM); > n->display_toggle = !!(d & TP_NVRAM_MASK_HKT_DISPLAY); > n->hibernate_toggle = !!(d & TP_NVRAM_MASK_HKT_HIBERNATE); > } > if (m & TP_ACPI_HKEY_THNKLGHT_MASK) { > - d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT); > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT); > n->thinklight_toggle = !!(d & TP_NVRAM_MASK_THINKLIGHT); > } > if (m & TP_ACPI_HKEY_DISPXPAND_MASK) { > - d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO); > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO); > n->displayexp_toggle = > !!(d & TP_NVRAM_MASK_HKT_DISPEXPND); > } > if (m & TP_NVRAM_HKEY_GROUP_BRIGHTNESS) { > - d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > n->brightness_level = (d & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; > n->brightness_toggle = > !!(d & TP_NVRAM_MASK_HKT_BRIGHTNESS); > } > if (m & TP_NVRAM_HKEY_GROUP_VOLUME) { > - d = nvram_read_byte(TP_NVRAM_ADDR_MIXER); > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); > n->volume_level = (d & TP_NVRAM_MASK_LEVEL_VOLUME) > >> TP_NVRAM_POS_LEVEL_VOLUME; > n->mute = !!(d & TP_NVRAM_MASK_MUTE); > @@ -6153,7 +6153,7 @@ static unsigned int tpacpi_brightness_nv > { > u8 lnvram; > > - lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS) > + lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS) > & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; > lnvram &= bright_maxlvl; > @@ -6178,7 +6178,7 @@ static void tpacpi_brightness_checkpoint > if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, &lec))) > goto unlock; > lec &= TP_EC_BACKLIGHT_LVLMSK; > - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > > if (lec != ((b_nvram & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS)) { > @@ -6186,7 +6186,7 @@ static void tpacpi_brightness_checkpoint > b_nvram &= ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS << > TP_NVRAM_POS_LEVEL_BRIGHTNESS); > b_nvram |= lec; > - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); > + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); > dbg_printk(TPACPI_DBG_BRGHT, > "updated NVRAM backlight level to %u (0x%02x)\n", > (unsigned int) lec, (unsigned int) b_nvram); > @@ -6794,13 +6794,13 @@ static void tpacpi_volume_checkpoint_nvr > if (unlikely(!acpi_ec_read(TP_EC_AUDIO, &lec))) > goto unlock; > lec &= ec_mask; > - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER); > + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); > > if (lec != (b_nvram & ec_mask)) { > /* NVRAM needs update */ > b_nvram &= ~ec_mask; > b_nvram |= lec; > - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); > + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); > dbg_printk(TPACPI_DBG_MIXER, > "updated NVRAM mixer status to 0x%02x (0x%02x)\n", > (unsigned int) lec, (unsigned int) b_nvram); > > -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-05-31 4:11 ` Henrique de Moraes Holschuh @ 2015-05-31 6:15 ` Finn Thain 2015-05-31 14:34 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 9+ messages in thread From: Finn Thain @ 2015-05-31 6:15 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: linux-kernel, linux-m68k, linuxppc-dev, Darren Hart, ibm-acpi-devel, platform-driver-x86 On Sun, 31 May 2015, Henrique de Moraes Holschuh wrote: > On Sun, 31 May 2015, Finn Thain wrote: > > Make use of arch_nvram_ops in the thinkpad_acpi driver so that the > > nvram_* function exports can be removed. > > > > This patch series was tested on a ThinkPad T43. > > Can you describe how you did the testing? A specific procedure is > required to test the hotkey NVRAM polling codepaths (which will read > several NVRAM bytes @10Hz by default) in a T43... > > > Signed-off-by: Finn Thain <fthain@telegraphics.com.au> > > The patch looks correct, so I don't expect any problems. > > Provided that your test procedure did enable hotkey NVRAM polling in the > T43 and your hotkeys all still worked fine, you have my Acked-by. The procedure I used was this, 1. $ xev 2. # rmmod thinkpad_acpi 3. Press <Access IBM> key and confirm that xev does not report any events. 4. # modprobe thinkpad_acpi 5. Press <Access IBM> key and confirm that xev now reports the key press events. Is this sufficient? Regards, Finn > > > --- > > drivers/platform/x86/thinkpad_acpi.c | 20 ++++++++++---------- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > Index: linux/drivers/platform/x86/thinkpad_acpi.c > > =================================================================== > > --- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:00:59.000000000 +1000 > > +++ linux/drivers/platform/x86/thinkpad_acpi.c 2015-05-31 11:01:07.000000000 +1000 > > @@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_ > > u8 d; > > > > if (m & TP_NVRAM_HKEY_GROUP_HK2) { > > - d = nvram_read_byte(TP_NVRAM_ADDR_HK2); > > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2); > > n->thinkpad_toggle = !!(d & TP_NVRAM_MASK_HKT_THINKPAD); > > n->zoom_toggle = !!(d & TP_NVRAM_MASK_HKT_ZOOM); > > n->display_toggle = !!(d & TP_NVRAM_MASK_HKT_DISPLAY); > > n->hibernate_toggle = !!(d & TP_NVRAM_MASK_HKT_HIBERNATE); > > } > > if (m & TP_ACPI_HKEY_THNKLGHT_MASK) { > > - d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT); > > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT); > > n->thinklight_toggle = !!(d & TP_NVRAM_MASK_THINKLIGHT); > > } > > if (m & TP_ACPI_HKEY_DISPXPAND_MASK) { > > - d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO); > > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO); > > n->displayexp_toggle = > > !!(d & TP_NVRAM_MASK_HKT_DISPEXPND); > > } > > if (m & TP_NVRAM_HKEY_GROUP_BRIGHTNESS) { > > - d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > > n->brightness_level = (d & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; > > n->brightness_toggle = > > !!(d & TP_NVRAM_MASK_HKT_BRIGHTNESS); > > } > > if (m & TP_NVRAM_HKEY_GROUP_VOLUME) { > > - d = nvram_read_byte(TP_NVRAM_ADDR_MIXER); > > + d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); > > n->volume_level = (d & TP_NVRAM_MASK_LEVEL_VOLUME) > > >> TP_NVRAM_POS_LEVEL_VOLUME; > > n->mute = !!(d & TP_NVRAM_MASK_MUTE); > > @@ -6153,7 +6153,7 @@ static unsigned int tpacpi_brightness_nv > > { > > u8 lnvram; > > > > - lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS) > > + lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS) > > & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS; > > lnvram &= bright_maxlvl; > > @@ -6178,7 +6178,7 @@ static void tpacpi_brightness_checkpoint > > if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, &lec))) > > goto unlock; > > lec &= TP_EC_BACKLIGHT_LVLMSK; > > - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > > + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS); > > > > if (lec != ((b_nvram & TP_NVRAM_MASK_LEVEL_BRIGHTNESS) > > >> TP_NVRAM_POS_LEVEL_BRIGHTNESS)) { > > @@ -6186,7 +6186,7 @@ static void tpacpi_brightness_checkpoint > > b_nvram &= ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS << > > TP_NVRAM_POS_LEVEL_BRIGHTNESS); > > b_nvram |= lec; > > - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); > > + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS); > > dbg_printk(TPACPI_DBG_BRGHT, > > "updated NVRAM backlight level to %u (0x%02x)\n", > > (unsigned int) lec, (unsigned int) b_nvram); > > @@ -6794,13 +6794,13 @@ static void tpacpi_volume_checkpoint_nvr > > if (unlikely(!acpi_ec_read(TP_EC_AUDIO, &lec))) > > goto unlock; > > lec &= ec_mask; > > - b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER); > > + b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER); > > > > if (lec != (b_nvram & ec_mask)) { > > /* NVRAM needs update */ > > b_nvram &= ~ec_mask; > > b_nvram |= lec; > > - nvram_write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); > > + arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_MIXER); > > dbg_printk(TPACPI_DBG_MIXER, > > "updated NVRAM mixer status to 0x%02x (0x%02x)\n", > > (unsigned int) lec, (unsigned int) b_nvram); > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-05-31 6:15 ` Finn Thain @ 2015-05-31 14:34 ` Henrique de Moraes Holschuh [not found] ` <20150531143422.GA12337-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Henrique de Moraes Holschuh @ 2015-05-31 14:34 UTC (permalink / raw) To: Finn Thain Cc: linux-kernel, linux-m68k, linuxppc-dev, Darren Hart, ibm-acpi-devel, platform-driver-x86 On Sun, 31 May 2015, Finn Thain wrote: > On Sun, 31 May 2015, Henrique de Moraes Holschuh wrote: > > On Sun, 31 May 2015, Finn Thain wrote: > > > Make use of arch_nvram_ops in the thinkpad_acpi driver so that the > > > nvram_* function exports can be removed. > > > > > > This patch series was tested on a ThinkPad T43. > > > > Can you describe how you did the testing? A specific procedure is > > required to test the hotkey NVRAM polling codepaths (which will read > > several NVRAM bytes @10Hz by default) in a T43... > > > > > Signed-off-by: Finn Thain <fthain@telegraphics.com.au> > > > > The patch looks correct, so I don't expect any problems. > > > > Provided that your test procedure did enable hotkey NVRAM polling in the > > T43 and your hotkeys all still worked fine, you have my Acked-by. > > The procedure I used was this, > > 1. $ xev > 2. # rmmod thinkpad_acpi > 3. Press <Access IBM> key and confirm that xev does not report any > events. > 4. # modprobe thinkpad_acpi > 5. Press <Access IBM> key and confirm that xev now reports the key press > events. > > Is this sufficient? No. Please try: modprobe thinkpad_acpi echo 0xfb88c0 > /sys/devices/platform/thinkpad_acpi/hotkey_source_mask test the hotkeys. Please test several of them, as not all of them are available through NVRAM polling... at least Fn+SPACE, Fn+F1..FN+F12 Please test the brightness keys. In the T43 we use "direct EC mode", which depends on the NVRAM to sync with the SMBIOS firmware. to reset the driver to normal mode, it is enough to do this: echo 0 > /sys/devices/platform/thinkpad_acpi/hotkey_source_mask -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20150531143422.GA12337-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>]
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() [not found] ` <20150531143422.GA12337-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> @ 2015-06-02 10:09 ` Henrique de Moraes Holschuh 2015-06-03 3:34 ` Darren Hart 0 siblings, 1 reply; 9+ messages in thread From: Henrique de Moraes Holschuh @ 2015-06-02 10:09 UTC (permalink / raw) To: Finn Thain Cc: linux-m68k-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Darren Hart, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ Test results were sent to me privately, and they are correct, so... Acked-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> On Sun, May 31, 2015, at 11:34, Henrique de Moraes Holschuh wrote: > On Sun, 31 May 2015, Finn Thain wrote: > > On Sun, 31 May 2015, Henrique de Moraes Holschuh wrote: > > > On Sun, 31 May 2015, Finn Thain wrote: > > > > Make use of arch_nvram_ops in the thinkpad_acpi driver so that the > > > > nvram_* function exports can be removed. > > > > > > > > This patch series was tested on a ThinkPad T43. > > > > > > Can you describe how you did the testing? A specific procedure is > > > required to test the hotkey NVRAM polling codepaths (which will read > > > several NVRAM bytes @10Hz by default) in a T43... > > > > > > > Signed-off-by: Finn Thain <fthain-PnMVE5gNl/W9dxLkCovUHLpzq4S04n8Q@public.gmane.org> > > > > > > The patch looks correct, so I don't expect any problems. > > > > > > Provided that your test procedure did enable hotkey NVRAM polling in the > > > T43 and your hotkeys all still worked fine, you have my Acked-by. > > > > The procedure I used was this, > > > > 1. $ xev > > 2. # rmmod thinkpad_acpi > > 3. Press <Access IBM> key and confirm that xev does not report any > > events. > > 4. # modprobe thinkpad_acpi > > 5. Press <Access IBM> key and confirm that xev now reports the key press > > events. > > > > Is this sufficient? > > No. Please try: > > modprobe thinkpad_acpi > echo 0xfb88c0 > /sys/devices/platform/thinkpad_acpi/hotkey_source_mask > > test the hotkeys. Please test several of them, as not all of them are > available through NVRAM polling... at least Fn+SPACE, Fn+F1..FN+F12 > > Please test the brightness keys. In the T43 we use "direct EC mode", > which > depends on the NVRAM to sync with the SMBIOS firmware. > > to reset the driver to normal mode, it is enough to do this: > echo 0 > /sys/devices/platform/thinkpad_acpi/hotkey_source_mask -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-06-02 10:09 ` Henrique de Moraes Holschuh @ 2015-06-03 3:34 ` Darren Hart 2015-06-03 7:38 ` Finn Thain 2015-06-03 10:37 ` Henrique de Moraes Holschuh 0 siblings, 2 replies; 9+ messages in thread From: Darren Hart @ 2015-06-03 3:34 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Finn Thain, linux-kernel, linux-m68k, linuxppc-dev, ibm-acpi-devel, platform-driver-x86 On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh wrote: > Test results were sent to me privately, and they are correct, so... > Finn, unless there is some compelling reason not to - like they are MBs worth of data, please submit these to the list in the future so we have them for reference. > Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> I'm fine with the changes, but they need to be submitted with the other changes as this one change cannot compile independently in my tree. Finn, please work with whomever is pulling the series to include this in their pull request. Reviewed-by: Darren Hart <dvhart@linux.intel.com> -- Darren Hart Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-06-03 3:34 ` Darren Hart @ 2015-06-03 7:38 ` Finn Thain 2015-06-03 10:37 ` Henrique de Moraes Holschuh 1 sibling, 0 replies; 9+ messages in thread From: Finn Thain @ 2015-06-03 7:38 UTC (permalink / raw) To: Darren Hart Cc: Henrique de Moraes Holschuh, linux-kernel, linux-m68k, linuxppc-dev, ibm-acpi-devel, platform-driver-x86 On Tue, 2 Jun 2015, Darren Hart wrote: > On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh > wrote: > > Test results were sent to me privately, and they are correct, so... > > > > Finn, unless there is some compelling reason not to - like they are MBs > worth of data, please submit these to the list in the future so we have > them for reference. Sure. Those results were just confirmation that this patch series doesn't affect input events read directly from /dev/input/by-path/platform-thinkpad_acpi-event given the the hotkey_source_mask settings discussed in this thread. > > > Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> > > I'm fine with the changes, but they need to be submitted with the other > changes as this one change cannot compile independently in my tree. > > Finn, please work with whomever is pulling the series to include this in > their pull request. Right. > > Reviewed-by: Darren Hart <dvhart@linux.intel.com> Thanks for your review. -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-06-03 3:34 ` Darren Hart 2015-06-03 7:38 ` Finn Thain @ 2015-06-03 10:37 ` Henrique de Moraes Holschuh 2015-06-04 5:14 ` Darren Hart 1 sibling, 1 reply; 9+ messages in thread From: Henrique de Moraes Holschuh @ 2015-06-03 10:37 UTC (permalink / raw) To: Darren Hart Cc: Finn Thain, linux-kernel, linux-m68k, linuxppc-dev, ibm-acpi-devel, platform-driver-x86 On Wed, Jun 3, 2015, at 00:34, Darren Hart wrote: > On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh > wrote: > > Test results were sent to me privately, and they are correct, so... > > Finn, unless there is some compelling reason not to - like they are MBs > worth of > data, please submit these to the list in the future so we have them for > reference. After I told him which exact bitmask to use on a T43 to test hotkey_source_mask, his test results can be summarized as "I could see no difference in behavior", which is *exactly* what I expected to happen. If anything went wrong with the thinkpad-acpi NVRAM code, you'd notice a very large change in behavior (typical: hotkeys don't work, less typical: random hotkey keypresses, hotkey press bursts, low responsivity of hotkeys). > > Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> > > I'm fine with the changes, but they need to be submitted with the other > changes > as this one change cannot compile independently in my tree. > > Finn, please work with whomever is pulling the series to include this in > their > pull request. > > Reviewed-by: Darren Hart <dvhart@linux.intel.com> -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() 2015-06-03 10:37 ` Henrique de Moraes Holschuh @ 2015-06-04 5:14 ` Darren Hart 0 siblings, 0 replies; 9+ messages in thread From: Darren Hart @ 2015-06-04 5:14 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Finn Thain, linux-kernel, linux-m68k, linuxppc-dev, ibm-acpi-devel, platform-driver-x86 On Wed, Jun 03, 2015 at 07:37:13AM -0300, Henrique de Moraes Holschuh wrote: > On Wed, Jun 3, 2015, at 00:34, Darren Hart wrote: > > On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh > > wrote: > > > Test results were sent to me privately, and they are correct, so... > > > > Finn, unless there is some compelling reason not to - like they are MBs > > worth of > > data, please submit these to the list in the future so we have them for > > reference. > > After I told him which exact bitmask to use on a T43 to test > hotkey_source_mask, his test results can be summarized as "I could see > no difference in behavior", which is *exactly* what I expected to > happen. > > If anything went wrong with the thinkpad-acpi NVRAM code, you'd notice a > very large change in behavior (typical: hotkeys don't work, less > typical: random hotkey keypresses, hotkey press bursts, low responsivity > of hotkeys). Perfect, thanks for the update so we have it recorded here on the list. -- Darren Hart Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-06-04 5:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20150531010132.289674310@telegraphics.com.au>
2015-05-31 1:01 ` [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-05-31 4:11 ` Henrique de Moraes Holschuh
2015-05-31 6:15 ` Finn Thain
2015-05-31 14:34 ` Henrique de Moraes Holschuh
[not found] ` <20150531143422.GA12337-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2015-06-02 10:09 ` Henrique de Moraes Holschuh
2015-06-03 3:34 ` Darren Hart
2015-06-03 7:38 ` Finn Thain
2015-06-03 10:37 ` Henrique de Moraes Holschuh
2015-06-04 5:14 ` Darren Hart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox