Re: New sysfs interface for privacy screens

2019-10-06 Thread Henrique de Moraes Holschuh
On Thu, 03 Oct 2019, Daniel Thompson wrote: > I guess... although the Thinkpad code hasn't added any standard > interfaces (no other laptop should be placing controls for a privacy > screen in /proc/acpi/ibm/... ). Maybe its not too late. As far as I am concerned, it is *not* too late. And you

[PATCH] fbcon: warn on invalid cursor blink intervals

2016-05-28 Thread Henrique de Moraes Holschuh
On Fri, 20 May 2016, Scot Doyle wrote: > On Fri, 20 May 2016, Jeremy Kerr wrote: > > >Then looks there are two fix patches acked & tested: > > > > > > - the patch in this thread > > > - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor > > >blink timer." > > >

[PATCH] fbcon: warn on invalid cursor blink intervals

2016-05-28 Thread Henrique de Moraes Holschuh
-by: David Daney > Signed-off-by: Scot Doyle > Cc: [v4.2] FWIW: Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. And nothing caused it to issue warnings here, so far (with the other recommended patch applied first). > --- > drivers/video/console/fbcon.c | 14 +++

[PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

2016-05-28 Thread Henrique de Moraes Holschuh
to initialize vc_cur_blink_ms before calling the con_init() > function. > > Signed-off-by: David Daney > Cc: stable at vger.kernel.org Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. > --- > drivers/tty/vt/vt.c | 1 + > 1 file changed, 1 insertion(+) > > di

[PATCH 29/32] thinkpad-acpi: Port to new backlight interface selection API

2015-06-10 Thread Henrique de Moraes Holschuh
On Wed, Jun 10, 2015, at 10:01, Hans de Goede wrote: > Port the backlight selection logic to the new backlight interface > selection API. > > Signed-off-by: Hans de Goede Acked-by: Henrique de Moraes Holschuh > --- > drivers/platform/x86/thinkpad_acpi.c | 5 +++-- &g

Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh
On Thu, 26 Sep 2013, Aaron Lu wrote: I checked the git log for the commit to use tpacpi_acpi_handle_locate to locate video controller's ACPI handle, it's: commit 122f26726b5e16174bf8a707df14be1d93c49d62 Author: Henrique de Moraes Holschuh h...@hmh.eng.br Date: Mon Aug 9 23:48:18 2010

Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh
of evaluation of _BCL. Signed-off-by: Aaron Lu aaron...@intel.com Tested-by: Igor Gnatenko i.gnatenko.br...@gmail.com Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: Acked-by: Henrique de Moraes Holschuh h...@hmh.eng.br

Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-27 Thread Henrique de Moraes Holschuh
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote: On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote: Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: I can test on T61, would that help? I

Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL

2013-09-25 Thread Henrique de Moraes Holschuh
On Tue, 24 Sep 2013, Aaron Lu wrote: locate handle for ACPI video by HID, the problem is, ACPI video node doesn't really have HID defined(i.e. no _HID control method is defined ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI video devices so as to keep the

MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote: > > > > And as far as I could find from Intel's not-that-complete public > > "specification updates", we are applying the errata workaround to a few more > &

MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote: > > On Sun, 23 Jun 2013, H. Peter Anvin wrote: > >> Why do you care about performance when PAT is disabled? > > > > It will regress already slow boxes. We bl

MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody ever took the pain to track down which ones of those actually have PAT+MTRR aliasing bugs. These boxes have

Re: MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody ever took the pain to track down which ones of those actually have PAT+MTRR aliasing bugs. These boxes have

Re: MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote: On Sun, 23 Jun 2013, H. Peter Anvin wrote: Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody

Re: MTRR use in drivers

2013-06-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Jun 2013, H. Peter Anvin wrote: On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote: And as far as I could find from Intel's not-that-complete public specification updates, we are applying the errata workaround to a few more processors than strictly required, but since I

Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-30 Thread Henrique de Moraes Holschuh
On Tue, 30 Aug 2011, Peter Zijlstra wrote: > On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over the l

Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-30 Thread Henrique de Moraes Holschuh
On Tue, 30 Aug 2011, Borislav Petkov wrote: > On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over

Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-30 Thread Henrique de Moraes Holschuh
On Mon, 29 Aug 2011, Borislav Petkov wrote: > So, hypothetically speaking, hpa suggested then that we could pass > firmware blobs over the linked list setup_data thing in the real-mode > kernel header and parse_setup_data() can look at them and map them > somewhere later for the driver to find.

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-30 Thread Henrique de Moraes Holschuh
On Tue, 30 Aug 2011, Borislav Petkov wrote: On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-30 Thread Henrique de Moraes Holschuh
On Tue, 30 Aug 2011, Peter Zijlstra wrote: On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

2011-08-29 Thread Henrique de Moraes Holschuh
On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This