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 ca
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."
> > > https://lkml.org/lkml/2016
-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 +++
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(+)
>
> diff --git
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
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,
t notification
> on backlight hotkey press as a result of evaluation of _BCL.
>
> Signed-off-by: Aaron Lu
> Tested-by: Igor Gnatenko
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 Mora
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
> Date: Mon Aug
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 non-triv
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
&
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 blackl
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
&
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 boar
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 blackl
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 boar
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 link
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
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 link
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
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. Thi
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. Thi
21 matches
Mail list logo