On Wed, 06 Jan 2021, Joe Perches wrote:
> On Wed, 2021-01-06 at 14:36 +0800, YANG LI wrote:
> > The snprintf() function returns the number of characters which would
> > have been printed if there were enough space, but the scnprintf()
> > returns the number of characters which were actually printed
On Mon, 27 Jul 2020, Andy Shevchenko wrote:
> On Mon, Jul 27, 2020 at 10:49 AM Andy Shevchenko
> wrote:
> > On Mon, Jul 27, 2020 at 10:45 AM Hans de Goede wrote:
> > >
> > > Hi,
> > >
> > > On 7/27/20 2:50 AM, Henrique de Moraes Holschuh wrote:
&g
On Tue, 21 Jul 2020, Dmitry Torokhov wrote:
> On Sun, Jul 19, 2020 at 07:56:49PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 17 Jul 2020, Hans de Goede wrote:
> > > This is a simple patch-series adding support for 3 new hotkeys found
> > > on various
On Fri, 17 Jul 2020, Hans de Goede wrote:
> This is a simple patch-series adding support for 3 new hotkeys found
> on various new Lenovo Thinkpad models.
For all three patches, pending an ack for the new keycodes by the input
maintainers:
Acked-by: Henrique de Moraes Holschuh
--
He
On Tue, 30 Jun 2020, Ming Lei wrote:
> On Wed, Jun 24, 2020 at 5:01 AM Henrique de Moraes Holschuh
> wrote:
> > Cache flushes do not matter that much when SSDs and sudden power cuts
> > are involved. Power cuts at the wrong time harm the FLASH itself, it is
> > not ab
On Thu, 18 Jun 2020, Christoph Hellwig wrote:
> > For SSDs, I don't think an extra stop should ever be an issue.
>
> Extra shutdowns will usually cause additional P/E cycles.
I am not so sure. We're talking about enforcing clean shutdowns here
(from the SSD PoV).
A system reboot takes enough ti
On Sun, 28 Jun 2020, Simon Arlott wrote:
> On 23/06/2020 21:42, Henrique de Moraes Holschuh wrote:
> > [1] I have long lost the will and energy to pursue this, so *this* is a
> > throw-away anecdote for anyone that cares: I reported here a few years
> > ago that many models
On Thu, 18 Jun 2020, Damien Le Moal wrote:
> Are you experiencing data loss or corruption ? If yes, since a clean reboot or
> shutdown issues a synchronize cache to all devices, a corruption would mean
> that
> your SSD is probably not correctly processing flush cache commands.
Cache flushes do n
On Wed, 10 Oct 2018, Andi Kleen wrote:
> v2:
> Remove all CPU match, only check boot cpu
IMHO, since it looks like a v3 will be necessary anyway, it could
benefit from a comment reminding people about how to use it on older
systems where "mixed CPU stepping" configurations were common.
This is *n
On Tue, 26 Jun 2018, Jan Beulich wrote:
> >>> On 25.06.18 at 18:33, wrote:
> > On 06/25/2018 03:25 AM, Jan Beulich wrote:
> >> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
> >> 32-bit ones instead.
> >
> > Hmph. Is that considered a bug (errata)?
>
> No.
>
> > URL/refere
On Fri, 15 Jun 2018, Pali Rohár wrote:
> Henrique, any idea why there are no exported led classes for mute and
> micmute? And how are suppose to be controlled?
I have to look into the code, it was contributed by someone who had
access to the proper hardware to test it.
But the way *I* would like
On Wed, 30 May 2018, Ivan Ivanov wrote:
> This is still not addressing the outdated 15h microcode version issue
> that Rudolf Marek has pointed out. Also, we still hope to see an
> updated microcode for 16h architecture as well - it has not received
> any updates for two years already
True, but no
igned-off-by: Alexander Kappner
I assume you tested this on real hardware? If so:
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/dri
On Thu, 15 Mar 2018, Borislav Petkov wrote:
> it is injecting faults and attempting to manipulate some size field -
> I'm guessing the encrypted data size. And I'm also guessing that if you
> manipulate that size, it would simply take a lot longer to attempt to
> decrypt and verify that it is broke
On Thu, 15 Mar 2018, Borislav Petkov wrote:
> On Wed, Mar 14, 2018 at 10:00:14PM -0300, Henrique de Moraes Holschuh wrote:
> > Intel takes anything from twenty thousand cycles to several *million*
> > cycles per core, proportional to microcode update size.
>
> Got any hard da
On Wed, 14 Mar 2018, Borislav Petkov wrote:
> Also, since the update is serialized and it also takes a couple of
> thousand cycles per microcode engine, increase the exit timeout by the
> number of CPUs on the system.
Maybe on AMD it is that fast ;-)
Intel takes anything from twenty thousand cycl
On Wed, 28 Feb 2018, Raj, Ashok wrote:
> On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh wrote:
> > > Avoid loading microcode if any of the CPUs are offline, and issue a
> > > warning. Having different microcode revisions on the system at any time
> &
On Wed, 28 Feb 2018, Borislav Petkov wrote:
> On Wed, Feb 28, 2018 at 10:59:31AM -0300, Henrique de Moraes Holschuh wrote:
> > Eek! If I read that right, this effectively halts the entire box until
> > every core is updated, with one core entering deep-coma at a time (the
> >
On Wed, 28 Feb 2018, Borislav Petkov wrote:
> + * Late loading dance. Why the heavy-handed stomp_machine effort?
> + *
> + * - HT siblings must be idle and not execute other code while the other
> sibling
> + * is loading microcode in order to avoid any negative interactions caused
> by
> + *
On Wed, 28 Feb 2018, Borislav Petkov wrote:
> Avoid loading microcode if any of the CPUs are offline, and issue a
> warning. Having different microcode revisions on the system at any time
> is outright dangerous.
Even if we update that microcode during CPU early bring-up, before we
mark it on-line
On Thu, 22 Feb 2018, Van De Ven, Arjan wrote:
> > > In the past the only guidance was to not load microcode at the same time
> > > to
> > the
> > > thread siblings of a core. We now have new guidance that the sibling must
> > > be
> > > spinning and not doing other things that can introduce insta
On Thu, 22 Feb 2018, Raj, Ashok wrote:
> On Thu, Feb 22, 2018 at 01:15:06PM +0100, Borislav Petkov wrote:
> > On Thu, Feb 22, 2018 at 03:55:54AM -0800, Raj, Ashok wrote:
> > > The current code wasn't trying to enforce checking the loaded microcode
> > > revision on a thread
> > > before attempting
On Sat, 17 Feb 2018, Borislav Petkov wrote:
> On Sat, Feb 17, 2018 at 11:42:48AM -0200, Henrique de Moraes Holschuh wrote:
> > I wonder when this broke,
>
> It didn't break - we're just printing the update only once.
It was before that change, when the microcode subsyste
On Fri, 16 Feb 2018, Ashok Raj wrote:
> After updating microcode on one of the threads in the core, the
> thread sibling automatically gets the update since the microcode
> resources are shared. Check the ucode revision on the cpu before
> performing a ucode update.
I wonder when this broke, becau
> > I'm fine with a signed-off-by or tested-by or suggested-by. There is a
> > spelling mistake though, 'hoveres' should be hovers.
>
> Is there anything else I can do here? I'm not sure any of us have the
> ability to find out what lenovo actualy wants this for.
I have already acked the patch,
On Tue, 30 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
> > So much for the theory. That's not going to work. If the boot cpu has the
> > feature then the alternatives will have been applied. So even if the flag
> > mismatch can be observed whe
On Fri, 26 Jan 2018, Victor Kamensky wrote:
> On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote:
> > On Thu, 25 Jan 2018, Rob Landley wrote:
> > > That said, I don't think -h newcx should emit (or recognize) the
> > > "TRAILER!!!1!" entry. Tha
On Thu, 25 Jan 2018, Rob Landley wrote:
> That said, I don't think -h newcx should emit (or recognize) the
> "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
> files have a length, pipes provide EOF, and each cpiox entry starts with
> 6 bytes of c_magic anyway. (I stopped toybox
On Wed, 24 Jan 2018, David Woodhouse wrote:
> I'm kind of tempted to turn it into a whitelist just by adding 1 to the
> microcode revision in each table entry. Sure, that N+1 might be another
> microcode build that also has issues but never saw the light of day...
Watch out for the (AFAIK) still n
On Thu, 18 Jan 2018, Dmitry Vyukov wrote:
> I've made a bunch of changes yesterday and today. This includes
...
> and even per crash/tree. To alleviate this, syzbot will now say e.g.
> "So far this crash happened 185 times on linux-next, mmots, net-next,
> upstream". So that you can see that it's
On Wed, 17 Jan 2018, Dmitry Vyukov wrote:
> On Wed, Jan 17, 2018 at 10:32 AM, Pavel Machek wrote:
> > On Fri 2018-01-12 17:58:01, syzbot wrote:
> >> syzkaller hit the following crash on
> >> 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> >
> > What an useful way to describe kernel version.
> >
> > Cou
On Mon, 15 Jan 2018, Jia Zhang wrote:
> For more details, see erratum BDF90 in document #334165 (Intel Xeon
> Processor E7-8800/4800 v4 Product Family Specification Update) from
> September 2017.
For the record, this erratum may well affect some E5v4 as well.
Anything with a LLC/core ratio >= 2.5
On Fri, 12 Jan 2018, Andi Kleen wrote:
> > Skylake still loses if it takes an SMI, right?
>
> SMMs are usually rare, especially on servers, and are usually
> not very predictible, and even if you have
FWIW, a data point: SMIs can be generated on demand by userspace on
thinkpad laptops, but they
not ABI in any way, so we can
change that at any time if we find out it should be named differently).
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/platform/x
On Tue, 19 Dec 2017, SF Markus Elfring wrote:
> >> Delete an error message for a failed memory allocation in three functions
> >
> > This one is questionable since it prints error messages at ->init() stage.
> > I would rather not touch this.
>
> Do you find the Linux allocation failure report
On Tue, 19 Dec 2017, Andy Shevchenko wrote:
> On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring
> wrote:
> > From: Markus Elfring
> > Date: Mon, 18 Dec 2017 22:23:45 +0100
> >
> > Two update suggestions were taken into account
> > from static source code analysis.
> >
> > Markus Elfring (2):
>
On Sat, 16 Sep 2017, Rob Landley wrote:
> So, I added a workaround with a printk in hopes of embarassing them into
> someday fixing it.
Oh, it will be fixed in Debian alright. I am just waiting the issue to
settle a bit to file the bug reports, or maybe even send in the Debian
patches myself (not
rk in other cases.
>
> Thanks to Peter Zhang of Lenovo for providing information on how to use the
> GMMS method to query the tablet mode.
>
> Signed-off-by: Benjamin Berg
> Cc: Peter FP1 Zhang
> Cc: Lyude Paul
Looks good.
Acked-by: Henrique de Moraes Holschuh
---
PS: p
On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word
> > > > > 48 of
> > > > > the IDENTIFY DEVICE
On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> > On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > > ---
> > > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > > From: Christoph Hellwig
> > > Date: Tue, 29 Aug 2017 14
On Fri, 11 Aug 2017, Michal Suchánek wrote:
> On 2017-08-10 18:30, Jason Gunthorpe wrote:
> > On Thu, Aug 10, 2017 at 12:18:11PM +0200, Michal Suchánek wrote:
> > > > Existing bus implementations do properly chain to driver shutdown (eg
> > > > look at mmc_bus_shutdown) and it appears to have been
On Tue, 25 Jul 2017, Prarit Bhargava wrote:
> A common way of determining if the system is a virtual machine is to
> search /proc/cpuinfo flags entry for "hypervisor". turbostat must output
> a proper error message when found.
Maybe you could output that message only if it fails to both use
/dev/
On Mon, 12 Jun 2017, Henrique de Moraes Holschuh wrote:
> So, you can just have /kernel/x86/microcode/.bin
> (without leading /kernel, /kernel/x86, /kernel/x86/microcode) in an
> early initramfs, and it will *work* for early microcode update purposes.
...
> So, if the early initramfs
On Mon, 12 Jun 2017, Marcin Szewczyk wrote:
> during my experiments with initramfs I have noticed there is something
> that looks like a bug in the 9-year old code[1] of the clean_rootfs()
> function in init/initramfs.c. An inconsistent behaviour appears when
> I have both the built-in initramfs
On Mon, 12 Jun 2017, Borislav Petkov wrote:
> I think I've dreamt of a simple solution to the early microcode
> application deal with suspend-to-RAM. The commit message of patch 2
> should explain it in more detail. Patch 1 is a fix for 32-bit when the
> ramdisk is being relocated.
>
> I'm still t
On Sat, 10 Jun 2017, Jason A. Donenfeld wrote:
> That's fine. As I mentioned, I really have no clue what this code's
> trying to do. If this is just part of some test that doesn't deal with
> actual messages that could be forged, then of course there's nothing
> that needs to be done and this can b
On Fri, 09 Jun 2017, Greg Kroah-Hartman wrote:
> We are trying to get rid of DRIVER_ATTR(), and the thinkpad_acpi
> driver's attributes can be trivially changed to use DRIVER_ATTR_RO() and
> DRIVER_ATTR_RW().
>
> Cc: Henrique de Moraes Holschuh
> Cc: Darren Hart
>
On Fri, 09 Jun 2017, NeilBrown wrote:
> Or maybe it could be discarded - the md_check_recovery() thing.
> The idea was that if you alt-sysrq-K to kill all processes, md arrays
> would go into immediate-safe-mode where the metadata is marked clean
> immediately after writes finish, rather than waiti
On Wed, 07 Jun 2017, Stephan Müller wrote:
> Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh:
> > On that same idea, one could add an early_initramfs handler for entropy
> > data.
>
> Any data that comes from outside during the boot proc
On Tue, 06 Jun 2017, Theodore Ts'o wrote:
> It might be possible, for example, to store a cryptographic key in a
> UEFI boot-services variable, where the key becomes inaccessible after
> the boot-time services terminate. But you also need either a reliable
> time-of-day clock, or a reliable counte
On Thu, 01 Jun 2017, Peter Zijlstra wrote:
> On Wed, May 31, 2017 at 06:58:55PM -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 31 May 2017, Peter Zijlstra wrote:
> > > + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X,0x0214),
> > ...
> >
On Wed, 31 May 2017, Peter Zijlstra wrote:
> + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X,0x0214),
...
> + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_MOBILE, 0xb2),
> + DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_DESKTOP, 0xb2),
...
> + DEADLINE_MODEL_MATCH_
On Wed, 31 May 2017, Peter Zijlstra wrote:
> These patches rely on the latest microcode data files from Intel [*]
>
> Without this microcode loaded, we'll print a FW_BUG informing the user to
> update their microcode image and disable TSC_DEADLINE support.
>
> This in turn allows us to remove the
On Fri, 12 May 2017, Pavel Machek wrote:
> On Sun 2017-05-07 20:49:03, Henrique de Moraes Holschuh wrote:
> > On Sun, 07 May 2017, Pavel Machek wrote:
> > > On Thu 2017-01-19 12:21:32, Adam Goode wrote:
> > > > This allows the control of the red status LED, which
On Wed, 10 May 2017, Andy Shevchenko wrote:
> Okay, what I'm going to do is:
> 1) drop patch 1 for now;
> 2) split patch 2 into two patches (and append your Ack on both);
> 3) push to our testing branch (I can send v2 if we need one more round
> of review).
>
> Tell me if there is any objection.
On Tue, May 9, 2017, at 14:33, Andy Shevchenko wrote:
> On Tue, 2017-05-09 at 14:10 -0300, Henrique de Moraes Holschuh wrote:
> > > While here, print negative error without changing a sign as it is a
> > > common pattern in the kernel.
> >
> > A separate patch f
bove there were no functional changes intended.
>
> Signed-off-by: Andy Shevchenko
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 182
> +--
> 1 file changed, 65 insertions(+), 117 deletions(-)
&g
hy 0 is used as permissions in
> module_param_call().
>
> [1]: https://patchwork.ozlabs.org/patch/713245/
>
> Cc: Richard Weinberger
> Signed-off-by: Andy Shevchenko
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 1 +
> 1 file
On Tue, 09 May 2017, Andy Shevchenko wrote:
> The commit 4be73005e4dc
>
> ("thinkpad-acpi: remove uneeded tp_features.hotkey tests in
> hotkey_exit")
>
> adds a complex logic behind hotkey status check in a way
> it started mixing logical operations with bitwise ones.
>
> Refactor the cod
On Sun, 07 May 2017, Pavel Machek wrote:
> On Thu 2017-01-19 12:21:32, Adam Goode wrote:
> > This allows the control of the red status LED, which is the dot of the "i"
> > in the word "ThinkPad" on the outside cover of newer models.
> >
> > In the manual, both this LED and the power LED are referr
On Thu, 20 Apr 2017, Mehmet Kayaalp wrote:
> > On Apr 20, 2017, at 7:13 PM, Henrique de Moraes Holschuh
> > wrote:
> > On Thu, 20 Apr 2017, Mehmet Kayaalp wrote:
> >> Include a random filled binary in vmlinux at the space reserved with
> >> CONFIG_SYSTEM_E
On Thu, 20 Apr 2017, Mehmet Kayaalp wrote:
> Include a random filled binary in vmlinux at the space reserved with
> CONFIG_SYSTEM_EXTRA_CERTIFICATE. This results in an uncompressed reserved
Random data is not always going to be completely incompressible. And
just how much it could be compressed a
On Tue, 11 Apr 2017, Martin Steigerwald wrote:
> I do have a Crucial M500 and I do have an increase of that counter:
>
> martin@merkaba:~[…]/Crucial-M500> grep "^174" smartctl-a-201*
> smartctl-a-2014-03-05.txt:174 Unexpect_Power_Loss_Ct 0x0032 100 100
> 000
> Old_age Always
On Mon, 10 Apr 2017, James Bottomley wrote:
> On Tue, 2017-04-11 at 08:52 +0900, Tejun Heo wrote:
> [...]
> > > Any comments? Any clues on how to make the delay "smarter" to
> > > trigger only once during platform shutdown, but still trigger per
> > > -device when doing per-device hotswapping ?
>
On Tue, 11 Apr 2017, Tejun Heo wrote:
> > The kernel then continues the shutdown path while the SSD is still
> > preparing itself to be powered off, and it becomes a race. When the
> > kernel + firmware wins, platform power is cut before the SSD has
> > finished (i.e. the SSD is subject to an uncl
On Mon, 10 Apr 2017, Bart Van Assche wrote:
> On Mon, 2017-04-10 at 20:21 -0300, Henrique de Moraes Holschuh wrote:
> > A proof of concept patch is attached
>
> Thank you for the very detailed write-up. Sorry but no patch was attached
> to the e-mail I received from you ...
Author: Henrique de Moraes Holschuh
Date: Wed Feb 1 20:42:02 2017 -0200
sd: wait for slow devices on shutdown path
Wait 1s during suspend/shutdown for the device to settle after
we issue the STOP command.
Otherwise we race ATA SSDs to powerdown, possibly causing
Summary:
Linux properly issues the SSD prepare-to-poweroff command to SATA SSDs,
but it does not wait for long enough to ensure the SSD has carried it
through.
This causes a race between the platform power-off path, and the SSD
device. When the SSD loses the race, its power is cut while it is st
On Tue, 28 Mar 2017, Wols Lists wrote:
> What Arnd is doing is commonly called "defensive programming", and
> unfortunately reality shows us that it is usually worth its weight in
> gold. That's why you put ASSERTs in code - so that if somebody does
> something stupid by accident, it blows up. This
On Sun, 05 Mar 2017, Måns Rullgård wrote:
> Tomas Winkler writes:
> > Sparse complains for arrays declared with variable length
> >
> > 'warning: Variable length array is used'
> >
> > Prior to c99 this was not allowed but lgcc (c99) doesn't have problem
> > with that https://gcc.gnu.org/onlinedo
Hello Adam,
I apologise for the delay on answering you.
On Tue, 31 Jan 2017, Adam Goode wrote:
> On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode wrote:
> > This allows the control of the red status LED, which is the dot of the "i"
> > in the word "ThinkPad" on the outside cover of newer models.
> >
On Fri, 16 Dec 2016, Borislav Petkov wrote:
> What for? We don't want to run the microcode loader on xen at all.
Or under KVM, or any other hypervisor, really.
--
Henrique Holschuh
0 and type to "".
>
> Signed-off-by: Darren Hart
> Cc: Lyude
> Cc: Henrique de Moraes Holschuh
> Cc: Andy Shevchenko
Acked-by: Henrique de Moraes Holschuh
> ---
> Since v1: Initialize type also.
>
> drivers/platform/x86/thinkpad_acpi.c | 4 ++--
>
On Wed, 23 Nov 2016, Tony Luck wrote:
> IMHO people who really care should find the BIOS option and disable it
> there.
That can also be said about *enabling* it, I think (see below).
> Having Linux take responsibility seems a little weird. If we do go
Not really. The currently proposed patch
On Wed, 23 Nov 2016, Borislav Petkov wrote:
> On Wed, Nov 23, 2016 at 11:29:51AM -0200, Henrique de Moraes Holschuh wrote:
> > 1. Assuming we can do it, always lock it when it is found to be unlocked
> >at kernel boot.
>
> Because...?
Privacy, and the fact that /dev/
On Wed, 23 Nov 2016, Borislav Petkov wrote:
> + /* if PPIN is disabled, but not locked, try to enable: */
> + if (!(val & 3ul)) {
> + wrmsrl_safe(MSR_PPIN_CTL, val | 2ul);
> + rdmsrl_safe(MSR_PPIN_CTL, &val);
> + }
Actual
On Sun, 20 Nov 2016, Borislav Petkov wrote:
> We will have set (or not) the X86_FEATURE_CPUID bit at
> early_identify_cpu() time. Looking at the code, we do call sync_core()
> pretty early. :-\
Hmm, watch out for the early microcode update driver for Intel
processors should something get changed i
On Mon, 07 Nov 2016, Lyude wrote:
> There's no need to have multiple copies of the logic we use for checking
> whether or not we're in tablet mode, so just use
> hotkey_get_tablet_mode() when checking the initial state in
> hotkey_init_tablet_mode().
...
> @@ -3130,13 +3130,16 @@ hotkey_init_tabl
On Mon, 07 Nov 2016, Lyude wrote:
> For whatever reason, the X1 Yoga doesn't support the normal method of
> querying for tablet mode. Instead of providing the MHKG method under the
> hotkey handle, we're instead given the CMMD method under the EC handle.
> Values on this handle are either 0x1, lapt
init_tablet_mode(void)
> +{
Function definiton all in one line, please.
Provided that you fix that minor nit,
Acked-by: Henrique de Moraes Holschuh
--
Henrique Holschuh
On Sat, 05 Nov 2016, Pavel Machek wrote:
> On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote:
> > On Sat, 05 Nov 2016, Pavel Machek wrote:
> > > Hmm, thanks for the pointer. But it seems like I'll have to build my
> > > own, as /proc/acpi/ibm does not
On Sat, 05 Nov 2016, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote:
> > Suggested by Daniel Martin
> >
> > Lenovo's having a bit of fun randomly changing what hotkey events and
> > acpi handles they use for reporting tablet mode, so unfortunately this
> > means we're
On Sat, 05 Nov 2016, Darren Hart wrote:
> On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote:
> > For whatever reason, the X1 Yoga doesn't support the normal method of
> > querying for tablet mode. Instead of providing the MHKG method under the
> > hotkey handle, we're instead given the CMMD met
On Fri, 04 Nov 2016, Viresh Kumar wrote:
> On 04-11-16, 10:26, Pavel Machek wrote:
> > How would I know if it is thermal capping? There's nothing in dmesg.
>
> I am not sure what code is responsible for doing that in case of x86, maybe
> Rafael and Rui can explain it that better.
>
> But surely i
On Sat, 05 Nov 2016, Pavel Machek wrote:
> [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something
> is extremely hot!
> [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 33
> N/A 47 50 N/A N/A N/A N/A N/A N/A
Oh boy, that must be the second time in a
On Sat, 05 Nov 2016, Pavel Machek wrote:
> Hmm, thanks for the pointer. But it seems like I'll have to build my
> own, as /proc/acpi/ibm does not follow the usual infrastructure...
/proc/acpi/ibm has been deprecated for years. 99% of the functionality
is available through more modern, standard in
On Thu, 27 Oct 2016, Lyude Paul wrote:
> as well, can someone confirm this patch made it to the ibm-acpi-devel
> list? When I originally sent this I realized I wasn't subscribed to the
> list, so I'm guessing I might need to resend.
I received it. I just didn't have the time to go over it in deta
On Thu, 29 Sep 2016, t...@kernel.org wrote:
> On Wed, Sep 28, 2016 at 05:45:08AM +, Shah, Nehal-bakulchandra wrote:
> > Can someone please help me to debug this issue?
>
> The only thing I can do from libata side is disbling msi on the
> affected platform, but the problem doesn't seem confined
On Wed, 21 Sep 2016, David Madore wrote:
> On Tue, Sep 20, 2016 at 03:50:09PM +0300, Mika Westerberg wrote:
> > Does the machine have WDAT ACPI table (see /sys/firmware/acpi/tables/*)?
> > If it does, you can try the new WDAT watchdog driver instead [1]. It
> > still uses the same hardware, though
On Mon, 12 Sep 2016, Jason A. Donenfeld wrote:
> I was wondering if it'd be possible to have the uas driver -- or
> perhaps somewhere else in the stack -- fall back to using
> ATA-passthrough-TRIM for UNMAP, so that discard can work properly.
> AFAIK, the Windows drivers do exactly this.
>
> If th
On Mon, 12 Sep 2016, Andi Kleen wrote:
> The cpuid char driver does this, other code may too.
Such as anything that calls sync_core().
That includes processor hotplug paths, and who knows what else...
> You probably would need to protect these CPUIDs with an exception
> handler that temporarily
On Tue, 16 Aug 2016, Kees Cook wrote:
> This adds a CONFIG to trigger BUG()s when the kernel encounters
> unexpected data structure integrity as currently detected with
> CONFIG_DEBUG_LIST.
>
> Specifically list operations have been a target for widening flaws to gain
> "write anywhere" primitives
On Tue, 09 Aug 2016, Jason Cooper wrote:
> Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
IMHO, this is mightly annoying to use from ins
On Wed, 03 Aug 2016, Michael S. Tsirkin wrote:
> Are any of these used in kernel though?
These specific errata were not the point of my post, rather, it was the
fact that errata related to *FENCE and LOCKed instructions exists.
I didn't verify whether something attempts to use non-temporal loads
On Wed, 03 Aug 2016, Michael S. Tsirkin wrote:
> > And I'm still discussing this with the hardware people. It seems we
> > can do this for *most* things, but not all; the question is where
> > exactly we need to do something different.
Let's hope the "hardware guys" get back to you soon :(
(cc list trimmed)
On Tue, 02 Aug 2016, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the
> corresponding macro,
>
On Wed, 13 Jul 2016, Joerg Roedel wrote:
> On Wed, Jul 13, 2016 at 11:31:02AM +0300, Meelis Roos wrote:
> > > > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> > > > activated, there is high probability of NMI-s in random places.
> > >
> > > Hmm, strange. But nothing could reall
On Wed, 13 Jul 2016, Ingo Molnar wrote:
> > The ordering Paul has, namely 0,1 for core0,smt{0,1} is not something
> > I've ever seen on an Intel part. AMD otoh does enumerate their CMT stuff
> > like what Paul has.
>
> That's more the natural 'direct' mapping from CPU internal topology to CPU
> i
On Tue, Jun 21, 2016, at 13:05, Andi Kleen wrote:
> Andi Kleen writes:
>
> Ping! Any comments on this patch?
Well, FWIW, it looks good enough to me.
--
"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
whe
On Wed, 15 Jun 2016, Toralf Förster wrote:
> This diff is reliable depending whether the T440s is docked (right) or not
> (left) :
>
> Linux t44 4.5.7-hardened-r2 #1 SMP Wed Jun 15 23:39:10 CEST 2016 x86_64
> Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux
>
> 215c215
>
1 - 100 of 652 matches
Mail list logo