On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote:
> I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> want.
That would be great, although given the potentially inconsistent
results we've been seeing so far it would be great if you could
additionally push a git
Hi Maxime,
On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so
> it
> seems that I fixed it along the way
Is your latest work available in a git branch anywhere that we could
test directly?
Thanks
Daniel
patches on top of Joerg's branch and confirmed that
they fix the issue discussed in the thread:
[PATCH v2] iommu/vt-d: consider real PCI device when checking if
mapping is needed
(the patch there is no longer needed)
Tested-by: Daniel Drake
Thanks!
p the device (in case that's necessary).
>
> Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of
> pci_set_power_state()")
> Reported-by: Daniel Drake
> Link:
> https://lore.kernel.org/linux-pm/cad8lp44tyxrmgplkhcqf9hv6sme
Hi Thomas,
On Fri, Aug 30, 2019 at 5:38 AM Thomas Gleixner wrote:
> So if we have to disable the HPET on Kaby Lake alltogether unless Intel
> comes up with the clever fix, i.e. poking at the right registers, then I
> think we should also lift the TSC watchdog restrictions on these machines
> if
On Fri, Aug 16, 2019 at 2:14 PM Daniel Drake wrote:
> Anyway, the system freeze occurs in parse_setup_data(), specifically:
>
> data = early_memremap(pa_data, sizeof(*data));
> data_len = data->len + sizeof(struct setup_data);
>
> Dereferencing data->len c
> 0011 -7.5dB
> 0100 -6dB
> 1000 -4.5dB
> 1001 -3dB
> 1010 -1.5dB
> 1011 0dB
>
> Signed-off-by: Katsuhiro Suzuki
Reviewed-by: Daniel Drake
On Mon, Aug 26, 2019 at 11:39 PM Katsuhiro Suzuki
wrote:
>
> This patch fixes inverted Left-Right channel of headphone mixer
> volume by wrong shift_left, shift_right values.
>
> Signed-off-by: Katsuhiro Suzuki
Agrees with the spec
Reviewed-by: Daniel Drake
On Mon, Aug 26, 2019 at 1:38 AM Hans de Goede wrote:
> On 24-08-19 23:04, Katsuhiro Suzuki wrote:
> > This patch limits Headphone mixer volume to 4 from 7.
> > Because output sound suddenly becomes very loudly with many noise if
> > set volume over 4.
That sounds like something that should be
On Fri, Aug 23, 2019 at 9:54 AM ndrw wrote:
> That's obviously a lot better than hard freezes but I wouldn't call such
> system lock-ups an excellent result. PSI-triggered OOM killer would have
> indeed been very useful as an emergency brake, and IMHO such mechanism
> should be built in the
Hi,
Artem S. Tashkinov wrote:
> Once you hit a situation when opening a new tab requires more RAM than
> is currently available, the system will stall hard. You will barely be
> able to move the mouse pointer. Your disk LED will be flashing
> incessantly (I'm not entirely sure why). You will not
On Mon, Aug 12, 2019 at 2:16 PM Daniel Drake wrote:
> I can do a bit of testing on other platforms too. Are there any
> specific tests I should run, other than checking that the system boots
> and doesn't have any timer watchdog complaints in the log?
Tested this on 2 AMD platforms
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote:
> On 8/12/19 10:32 AM, Kalle Valo wrote:
> > This is marked as RFC so I'm not sure what's the plan. Should I apply
> > this?
>
> I think it's at a point where it's worth applying - I kinda wish I had
> had time to test it, but I won't be near
On Fri, Aug 9, 2019 at 8:54 PM Thomas Gleixner wrote:
> Some newer machines do not advertise legacy timers. The kernel can handle
> that situation if the TSC and the CPU frequency are enumerated by CPUID or
> MSRs and the CPU supports TSC deadline timer. If the CPU does not support
> TSC deadline
On Thu, Aug 1, 2019 at 3:16 PM Aubrey Li wrote:
> No, the platform needs a global clock event, can you turn on some other
> clock source on your platform, like HPET?
Thanks Audrey and Thomas for the quick hints!
I double checked under Windows - it seems to be using a HPET there.
Also there is
Hi,
Working with a new consumer laptop based on AMD R7-3700U, we are
seeing a kernel panic during early boot (before the display
initializes). It's a new product and there is no previous known
working kernel version (tested 5.0, 5.2 and current linus master).
We may have also seen this problem
Hi,
On Mon, Jul 15, 2019 at 9:38 PM Sasha Levin wrote:
> From: Daniel Drake
>
> [ Upstream commit 604dc9170f2435d27da5039a3efd757dceadc684 ]
In my opinion this is not stable kernel material.
It alone does not solve a particular bug. It's part of a larger effort
to decrease usage of
On Fri, Jul 5, 2019 at 10:27 AM Chris Chiu wrote:
> Per the code before REG_S0S1_PATH_SWITCH setting, the driver has told
> the co-processor the antenna is inverse.
> memset(, 0, sizeof(struct h2c_cmd));
> h2c.ant_sel_rsv.cmd = H2C_8723B_ANT_SEL_RSV;
>
On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen wrote:
> My point is this seems to be very dongle dependent :( We have to be
> careful not breaking it for some users while fixing it for others.
Do you still have your device?
Once we get to the point when you are happy with Chris's two patches
here
On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due
On Tue, Jul 2, 2019 at 4:01 PM Chris Chiu wrote:
> When the vendor driver invokes rtw_btcoex_HAL_Initialize, which will then
> call halbtc8723b1ant_SetAntPath to configure the registers in this patch.
> From the code, the registers will have different register settings per the
> antenna position
On Tue, Jul 2, 2019 at 8:42 PM Jes Sorensen wrote:
> We definitely don't want to bring over the vendor code, since it's a
> pile of spaghetti, but we probably need to get something sorted. This
> went down the drain when the bluetooth driver was added without taking
> it into account - long after
Hi Chris,
On Thu, Jun 27, 2019 at 5:53 PM Chris Chiu wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to
watchdog as rtlwifi to improve from the
> driver side. Please leave precious comments for my commits and
> suggest what I can do better. Or suggest if there's any better idea
> to fix this. Thanks.
> Signed-off-by: Chris Chiu
Reviewed-by: Daniel Drake
> +* is supported
fix
> this issue.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
> Signed-off-by: Jian-Hong Pan
Reviewed-by: Daniel Drake
Oops, please also add a reference to the main thread:
On Fri, Jun 28, 2019 at 3:23 PM Daniel Drake wrote:
> Detect modern setups where we have no need for the PIT (e.g. where
> we already know the TSC and LAPIC timer frequencies, so no need
> to calibrate them against the PIT),
t against (this was causing the panic).
Tested-by: Daniel Drake
---
arch/x86/include/asm/apic.h| 2 ++
arch/x86/include/asm/time.h| 1 +
arch/x86/kernel/apic/apic.c| 27 +++
arch/x86/kernel/apic/io_apic.c | 4
arch/x86/kernel/i8253.c
On Thu, Jun 27, 2019 at 10:07 PM Thomas Gleixner wrote:
> Nah. That extra timer works thing is just another bandaid.
>
> What I had in mind is something like the below. That's on top of
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic
>
> Be warned. It's neither compiled
Hi Thomas,
Picking up this issue again after a break!
We made some progress last time on reducing PIT usage in the TSC
calibration code, but we still have the bigger issue to resolve:
IO-APIC code panicing when the PIT isn't ticking.
On Wed, Apr 3, 2019 at 7:21 PM Thomas Gleixner wrote:
> For
ink you can remove
"since kernel v3.7.1." from the comment.
After those changes you can add:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
Reviewed-by: Daniel Drake
> Signed-off-by: Jian-Hong Pan
> ---
> v2:
> - According to the vendor driver, it makes "
On Mon, Jun 24, 2019 at 2:16 PM Christoph Hellwig wrote:
> IFF we want to support it it has to be done at the PCIe layer. But
> even that will require actual documentation and support from Intel.
>
> If Intel still believes this scheme is their magic secret to control
> the NVMe market and give
Hi Jian-Hong,
On Fri, Jun 21, 2019 at 4:59 PM Jian-Hong Pan wrote:
> Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
> after on-off several times. Bluetooth daemon sets BT mode failed when
> this issue happens.
>
> bluetoothd[1576]: Failed to set mode: Failed (0x03)
>
>
On Thu, Jun 20, 2019 at 2:11 PM Christoph Hellwig wrote:
> The Linux NVMe driver will deal with NVMe as specified plus whatever
> minor tweaks we'll need for small bugs. Hiding it behind an AHCI
> device is completely out of scope and will not be accepted.
Do you have any new suggestions for
From: Dan Williams
A platform-driver for nvme resources needs access to struct nvme_dev and
other definitions that are currently local to pci.c.
Signed-off-by: Dan Williams
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c | 125 +---
drivers/nvme/host
ntel_ahci_nvme",
+ .pm = _remap_dev_pm_ops,
+ },
+ .id_table = ahci_remap_id_table,
+ .probe = ahci_remap_probe,
+ .remove = ahci_remap_remove,
+ .shutdown = ahci_remap_shutdown,
+};
+
+module_platform_driver(ahci_remap_drive
From: Dan Williams
In preparation for adding a platform_device nvme host, rename to a more
generic "mmio" prefix.
Signed-off-by: Dan Williams
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletion
he best
spec we have at the moment.
Based on earlier work by Dan Williams.
Signed-off-by: Daniel Drake
---
drivers/ata/Kconfig| 32 +++
drivers/ata/ahci.c | 173 -
drivers/ata/ahci.h | 14 +++
include/linux/ahci-remap.h | 140 +
In preparation for a platform device nvme driver, move the bus specific
portions of nvme to nvme_dev_ops, or otherwise rewrite routines to use a
generic 'struct device' instead of 'struct pci_dev'.
Based on earlier work by Dan Williams.
Signed-off-by: Daniel Drake
---
drivers/nvme/host/pci.c
focus on
compatibility with default configuration of common consumer products,
I'm hoping we could land an initial version without MSI support before
tending to those complications.
Dan Williams (2):
nvme: rename "pci" operations to "mmio"
nvme: move common definitions to pci
On Wed, May 29, 2019 at 10:52 PM Chris Chiu wrote:
> You mean moving the ratr_index to be the 4th function parameter of
> update_rate_mask which has 2 candidates rtl8xxxu_update_rate_mask
> and rtl8xxxu_gen2_update_rate_mask? I was planning to keep the
> rtl8xxxu_update_rate_mask the same because
Hi Chris,
On Tue, May 28, 2019 at 11:03 PM Chris Chiu wrote:
> + /*
> +* Single virtual interface permitted since the driver supports
> STATION
> +* mode only.
I think you can be a bit more explicit by saying e.g.:
Only one virtual interface permitted because only STA
On Mon, May 27, 2019 at 12:38 AM Chris Chiu wrote:
> The -EBUSY is returned by the ieee80211_check_combinations() in the
> ieee80211_check_concurrent_iface() function which is invoked each time
> doing ieee80211_open().
> The ieee80211_check_combinations() returns the -EBUSY because of
>
On Tue, May 14, 2019 at 12:59 PM Yurii Pavlovskyi
wrote:
>
> Add a new function to acpi.h / wmi.c that returns _UID of the ACPI WMI
> device. For example, it returns "ATK" for the following declaration in
> DSDT:
> Device (ATKD)
> {
> Name (_HID, "PNP0C14" /* Windows Management
egative consequences of this change
> are expected, as the input buffer size is not verified. The original
> function is replaced by a wrapper for a new method passing value 0 for the
> last parameter. The new function will be used to control RGB keyboard
> backlight.
>
> Signed-off-by: Yurii Pavlovskyi
Reviewed-by: Daniel Drake
using keyboard hotkey, the intensity will drop as a result. Correct the
> implementation.
>
> Signed-off-by: Yurii Pavlovskyi
Reviewed-by: Daniel Drake
for registering device with devm_* version that unregisters it
> automatically.
>
> Signed-off-by: Yurii Pavlovskyi
Reviewed-by: Daniel Drake
On Fri, May 10, 2019 at 2:37 AM Chris Chiu wrote:
> I've verified that multiple virtual interface can not work simultaneously in
> STA mode. I assigned different mac address for different vifs, I can only
> bring only one interface up. If I want to bring the second vif up, it always
> complains
On Thu, May 9, 2019 at 5:17 PM Chris Chiu wrote:
> I need the vif because there's seems no easy way to get RSSI. Please
> suggest if there's any better idea for this. I believe multiple vifs is for AP
> mode (with more than 1 virtual AP/SSIDs) and the Station+AP coexist
> mode. But the rtl8xxxu
Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work
Commit-ID: 604dc9170f2435d27da5039a3efd757dceadc684
Gitweb: https://git.kernel.org/tip/604dc9170f2435d27da5039a3efd757dceadc684
Author: Daniel Drake
AuthorDate: Thu, 9 May 2019 13:54:15 +0800
Committer: Ingo Molnar
CommitDate: Thu, 9 May 2019 11:06:48 +0200
x86/tsc: Use CPUID.0x16
Commit-ID: 52ae346bd26c7a8b17ea82e9a09671e98c5402b7
Gitweb: https://git.kernel.org/tip/52ae346bd26c7a8b17ea82e9a09671e98c5402b7
Author: Daniel Drake
AuthorDate: Thu, 9 May 2019 13:54:16 +0800
Committer: Ingo Molnar
CommitDate: Thu, 9 May 2019 11:06:49 +0200
x86/apic: Rename
Commit-ID: 2420a0b1798d7a78d1f9b395f09f3c80d92cc588
Gitweb: https://git.kernel.org/tip/2420a0b1798d7a78d1f9b395f09f3c80d92cc588
Author: Daniel Drake
AuthorDate: Thu, 9 May 2019 13:54:17 +0800
Committer: Ingo Molnar
CommitDate: Thu, 9 May 2019 11:06:49 +0200
x86/tsc: Set LAPIC timer
Hi Chris,
Thanks for this! Some suggestions below, although let me know if any
don't make sense.
On Fri, May 3, 2019 at 3:22 PM Chris Chiu wrote:
>
> Add wireless mode, signal strength level, and rate table index
> to tell the firmware that we need to adjust the tx rate bitmap
> accordingly.
>
> > -#define ASUS_WMI_METHODID_DSTS 0x53544344 /* Device STatuS */
> > -#define ASUS_WMI_METHODID_DSTS20x53545344 /* Device STatuS
> > #2*/
>
> > +#define ASUS_WMI_METHODID_DSTS 0x53544344 /* Device STatuS (DCTS)
> > */
>
> It's not clear from the description what
rnel.org/r/20190419083533.32388-1-dr...@endlessm.com
Suggested-by: Thomas Gleixner
Signed-off-by: Daniel Drake
---
Notes:
v2:
- Clarify the situation around Skylake X better.
- Enable TSC refinement when we had to calculate the crystal clock,
in case slight differences in the calculat
This variable is a period unit (number of clock cycles per jiffy),
not a frequency (which is number of cycles per second).
Give it a more appropriate name.
Suggested-by: Ingo Molnar
Signed-off-by: Daniel Drake
---
arch/x86/include/asm/apic.h| 2 +-
arch/x86/kernel/apic/apic.c| 20
/20190419083533.32388-1-dr...@endlessm.com
Link:
https://lkml.kernel.org/r/alpine.deb.2.21.1904031206440.1...@nanos.tec.linutronix.de
Suggested-by: Thomas Gleixner
Signed-off-by: Daniel Drake
---
Notes:
v2:
- remove unnecessary braces
- use newly renamed variable lapic_timer_period
On Wed, Apr 24, 2019 at 7:22 PM Jason Gunthorpe wrote:
> A driver that simply wants a SGL with a capped max size (ie 4k?)
> should use the dma_set_max_seg_size() API and just never get a SGE
> with a larger length.
That sounds like exactly what we want here. However I tried that
function and it
Hi,
In drivers/mmc/alcor.c we're working with a MMC controller which
supports DMA transfers split up into page-sized chunks. A DMA transfer
consists of multiple pages, after each page is transferred there is an
interrupt so that the driver can program the DMA address of the next
page in the
On Tue, Apr 23, 2019 at 5:08 PM Peter Zijlstra wrote:
> Well, SKX isn't exactly 'missing'; it would be very good if we can
> confirm the new code is still correct under the below mentioned
> conditions.
>
> commit b511203093489eb1829cb4de86e8214752205ac6
> Author: Len Brown
> Date: Fri Dec 22
ent source.
Signed-off-by: Daniel Drake
Link:
https://lkml.kernel.org/r/CAD8Lp45fedoPLnK=umuhhtkjy5u2h04sykrx3u+m04u6fpv...@mail.gmail.com
---
arch/x86/include/asm/time.h| 2 +
arch/x86/kernel/apic/io_apic.c | 101 ---
arch/x86/kernel/i8253.c| 6 ++
uffer is initialized).
Avoid the IO-APIC IRQ0 timer manipulation & verification on platforms
where the legacy IRQ0 timer has been determined as unavailable.
This fixes boot on Connex L1430 and Scope SN116PYA with default BIOS
settings.
Signed-off-by: Daniel Drake
Link:
https://lkml.kerne
On Mon, Apr 22, 2019 at 8:04 PM Ingo Molnar wrote:
> Minor style nit: the parentheses are unnecessary, integer expressions
> like this are evaluated left to right and multiplication and division has
> the same precedence.
Fair point, although the same could be said for cpu_khz_from_msr().
> But
/r/20190419083533.32388-1-dr...@endlessm.com
Link:
https://lkml.kernel.org/r/alpine.deb.2.21.1904031206440.1...@nanos.tec.linutronix.de
Suggested-by: Thomas Gleixner
Signed-off-by: Daniel Drake
---
arch/x86/kernel/tsc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86
Suggested-by: Thomas Gleixner
Signed-off-by: Daniel Drake
---
arch/x86/kernel/tsc.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 3fae23834069..3971c837584a 100644
--- a/arch/x86/kernel/tsc.c
gt; volume up/down, brightness up/down...etc, which were triggered
> by holding down Fn key and F-keys.
>
> Because there's no way to retrieve the fn-lock mode via existing
> WMI methods per ASUS spec, driver need to initialize and keep the
> fn-lock mode by itself.
>
> Signed-off-by: Chris Chiu
Reviewed-by: Daniel Drake
On Fri, Apr 19, 2019 at 6:30 AM Thomas Gleixner wrote:
>Time Stamp Counter/Core Crystal Clock Information (0x15):
> TSC/clock ratio = 168/2
> nominal core crystal clock = 0 Hz
>
>Processor Frequency Information (0x16):
> Core Base Frequency (MHz) = 0x834 (2100)
>
The CPUID.0x16 leaf provides "Bus (Reference) Frequency (in MHz)".
In the thread "No 8254 PIT & no HPET on new Intel N3350 platforms
causes kernel panic during early boot" we are exploring ways to have
the kernel avoid using the PIT/HPET IRQ0 timer in more cases, and
Thomas Gleixner suggested
On Wed, Apr 10, 2019 at 8:54 PM Thomas Gleixner wrote:
> On Tue, 9 Apr 2019, Daniel Drake wrote:
> > On Wed, Apr 3, 2019 at 7:21 PM Thomas Gleixner wrote:
> > > - Prevent the TSC calibration code from touching PIT/HPET. It
> > >should do that alr
On Thu, Apr 11, 2019 at 1:47 PM Yurii Pavlovskyi
wrote:
> * 0x00 - is normal,
> * 0x01 - is obviously turbo by the amount of noise, might be useful to
> avoid CPU frequency throttling on high load,
> * 0x02 - the meaning is unknown at the time as modes are not named
> in the vendor documentation,
On Thu, Apr 11, 2019 at 1:44 PM Yurii Pavlovskyi
wrote:
> Event codes are expected to be polled from a queue on at least some
> models.
Maybe avoid the word "poll" since it suggests something else (at least to me).
> The fix flushes the old key codes out of the queue on load and after
>
On Thu, Apr 11, 2019 at 4:28 AM Yurii Pavlovskyi
wrote:
> The DSTS method detection fails, as nothing is returned if method is not
> defined in WMNB. As a result the control of keyboard backlight is not
> functional for TUF Gaming series laptops (at the time the only
> functionality of the driver
On Thu, Apr 11, 2019 at 4:21 AM Yurii Pavlovskyi
wrote:
>
> The asus-wmi driver does not clean up the hwmon device on exit or error.
> To reproduce the bug, repeat rmmod, insmod to verify that device number
> /sys/devices/platform/asus-nb-wmi/hwmon/hwmon?? grows every time. Add
> pointer to the
On Wed, Apr 3, 2019 at 7:21 PM Thomas Gleixner wrote:
> Btw, one of those links you provided
>
> https://www.manualslib.com/manual/1316475/Ecs-Ed20pa2.html?page=23
>
> claims that you have to disable MWAIT as well. No idea why. Is MWAIT
> disabled on your platform?
I don't have that option in
Hi,
I already wrote about this problem in the thread "APIC timer checked
before it is set up, boot fails on Connex L1430"
https://lkml.org/lkml/2018/12/28/10
However my initial diagnosis was misguided, and I have some new
findings to share now, so I'm starting over in this new thread.
Also CCing
On Thu, Mar 28, 2019 at 5:17 PM Andy Shevchenko
wrote:
> Hmm... Can you confirm that laptop you declared as a fixed case and the
> mentioned here is the same one?
They are definitely not the same exact unit - originally we had a
pre-production sample, and now we briefly diagnosed a real
Hi Mika,
Digging up this old thread again...
On Tue, Nov 21, 2017 at 8:13 PM Mika Westerberg
wrote:
>
> On Tue, Nov 21, 2017 at 07:54:26PM +0800, Chris Chiu wrote:
> > Yup, I checked the value of the corresponded pin. It shows following before
> > suspend
> > pin 18 (GPIO_18) GPIO 0x40800102
On Thu, Jan 24, 2019 at 11:23 PM Kai-Heng Feng
wrote:
> Realtek bluetooth may not work after reboot:
> [ 12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e,
> hci rev 826c, hci ver 0008
>
> The power is not cut during system reboot, so the firmware is kept in
> Bluetooth
Commit-ID: 7e6fc2f50a3197d0e82d1c0e86282976c9e6c8a4
Gitweb: https://git.kernel.org/tip/7e6fc2f50a3197d0e82d1c0e86282976c9e6c8a4
Author: Daniel Drake
AuthorDate: Mon, 7 Jan 2019 11:40:24 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 11 Jan 2019 21:35:47 +0100
x86/kaslr: Fix
On Fri, Dec 28, 2018 at 2:11 PM Daniel Drake wrote:
> On the Connex L1430 laptop based on Intel Apollo Lake N3350, Linux
> doesn't boot. It hangs early on a blank screen. Reproduced with Linus
> git, 4.18 and 4.19 (there is no previous known working kernel
> version). EFI early
The outb call takes parameters value and port, in that order.
Fix the parameters used in the kalsr i8254 fallback code.
Signed-off-by: Daniel Drake
---
arch/x86/lib/kaslr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c
index
Hi,
On the Connex L1430 laptop based on Intel Apollo Lake N3350, Linux
doesn't boot. It hangs early on a blank screen. Reproduced with Linus
git, 4.18 and 4.19 (there is no previous known working kernel
version). EFI earlyprintk shows:
APIC: switch to symmetric I/O mode setup
x2apic: IRQ
On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek wrote:
> Plus, I don't think "100% charge" is right test for "battery full". At
> least on thinkpads, there's configuration option, and it is common
> _not_ to charge batterry above 95% or so (to increase its lifetime).
Hans also touched on this area
On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek wrote:
> Plus, I don't think "100% charge" is right test for "battery full". At
> least on thinkpads, there's configuration option, and it is common
> _not_ to charge batterry above 95% or so (to increase its lifetime).
Hans also touched on this area
Hi Suren
On Fri, Sep 7, 2018 at 11:58 PM, Suren Baghdasaryan wrote:
> Thanks for the new patchset! Backported to 4.9 and retested on ARMv8 8
> code system running Android. Signals behave as expected reacting to
> memory pressure, no jumps in "total" counters that would indicate an
>
Hi Suren
On Fri, Sep 7, 2018 at 11:58 PM, Suren Baghdasaryan wrote:
> Thanks for the new patchset! Backported to 4.9 and retested on ARMv8 8
> code system running Android. Signals behave as expected reacting to
> memory pressure, no jumps in "total" counters that would indicate an
>
On Thu, Sep 6, 2018 at 5:43 AM, Johannes Weiner wrote:
> Peter, do the changes from v3 look sane to you?
>
> If there aren't any further objections, I was hoping we could get this
> lined up for 4.20.
That would be excellent. I just retested the latest version at
On Thu, Sep 6, 2018 at 5:43 AM, Johannes Weiner wrote:
> Peter, do the changes from v3 look sane to you?
>
> If there aren't any further objections, I was hoping we could get this
> lined up for 4.20.
That would be excellent. I just retested the latest version at
On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote:
>> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
>> keyboard wake up the system as expected. We considered to work out a DMI
>> based quirk for this. But based on the information that EC would not signal
>>
On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote:
>> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
>> keyboard wake up the system as expected. We considered to work out a DMI
>> based quirk for this. But based on the information that EC would not signal
>>
Split from the thread
[PATCH 0/10] psi: pressure stall information for CPU, memory, and IO v2
where we were discussing if/how to make the direct reclaim codepath
fail if we're excessively thrashing, so that the OOM killer might
step in. This is potentially desirable when the thrashing is so bad
Split from the thread
[PATCH 0/10] psi: pressure stall information for CPU, memory, and IO v2
where we were discussing if/how to make the direct reclaim codepath
fail if we're excessively thrashing, so that the OOM killer might
step in. This is potentially desirable when the thrashing is so bad
On Fri, Jul 20, 2018 at 6:38 PM, Daniel Kurtz wrote:
> Sounds reasonable. How about:
>
> - /* Clear interrupt.
> -* We must read the pin register again, in case the
> -* value was changed while executing
> -
On Fri, Jul 20, 2018 at 6:38 PM, Daniel Kurtz wrote:
> Sounds reasonable. How about:
>
> - /* Clear interrupt.
> -* We must read the pin register again, in case the
> -* value was changed while executing
> -
On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz wrote:
> Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> changed to the clearing of interrupt status bits to a RMW in a critical
> section. This works, but is a bit overkill.
>
> The relevant interrupt/wake status bits are in
On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz wrote:
> Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> changed to the clearing of interrupt status bits to a RMW in a critical
> section. This works, but is a bit overkill.
>
> The relevant interrupt/wake status bits are in
Hi,
On Thu, Jun 14, 2018 at 1:58 AM, Chris Chiu wrote:
>
> On Wed, Jun 13, 2018 at 8:49 PM, Andy Shevchenko
> wrote:
> > On Mon, Jun 11, 2018 at 10:18 AM, Chris Chiu wrote:
> >> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> >> brightness events and update the brightness
Hi,
On Thu, Jun 14, 2018 at 1:58 AM, Chris Chiu wrote:
>
> On Wed, Jun 13, 2018 at 8:49 PM, Andy Shevchenko
> wrote:
> > On Mon, Jun 11, 2018 at 10:18 AM, Chris Chiu wrote:
> >> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> >> brightness events and update the brightness
On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
> Is this really a case of the hardware itself processing the
> keypress and then changing the brightness *itself* ?
>
> From the "[PATCH 2/2] platform/x86: asus-wmi: Add keyboard backlight
> toggle support" patch I get the impression that the
On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
> Is this really a case of the hardware itself processing the
> keypress and then changing the brightness *itself* ?
>
> From the "[PATCH 2/2] platform/x86: asus-wmi: Add keyboard backlight
> toggle support" patch I get the impression that the
1 - 100 of 540 matches
Mail list logo
