On the System76 Oryx Pro (oryp5), there is a headset microphone input
attached to 0x19 that does not have a jack detect. In order to get it
working, the pin configuration needs to be set correctly, and the
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is
similar to the MIC_NO_PRESENCE fixups for some Dell laptops, except we
have a separate microphone jack that is already configured correctly.
Since the ALC1220 does not have a fixup similar to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, I have exposed the fixup from the
ALC269 in a way that it can be accessed from the
alc1220_fixup_system76_oryp5 function. In addition, the
alc1220_fixup_clevo_p950 needs to be applied to gain speaker output.
Signed-off-by: Jeremy Soller <email address hidden>
Cc: <email address hidden>
Signed-off-by: Takashi Iwai <email address hidden>
(cherry picked from commit 7f665b1c3283aae5b61843136d0a8ee808ba3199
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git)
Signed-off-by: Seth Forshee <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
On the System76 Darter Pro (darp5), there is a headset microphone
input attached to 0x1a that does not have a jack detect. In order to
get it working, the pin configuration needs to be set correctly, and
the ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied.
This is similar to the MIC_NO_PRESENCE fixups for some Dell laptops,
except we have a separate microphone jack that is already configured
correctly.
Signed-off-by: Jeremy Soller <email address hidden>
Cc: <email address hidden>
Signed-off-by: Takashi Iwai <email address hidden>
(backported from commit 89e3a5682edaa4e5bb334719afb180256ac7bf78)
[ saf: adjust context ]
Signed-off-by: Seth Forshee <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
It is reported that there's a constant background "hum/whitenoise"
in the headset on the Lenovo X1 machines with the codec alc285, and it
is confirmed that if we run the command below, the noise will stop.
sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0
Then I consulted this issue with Kailang, he told me the pin 0x1d on
this codec is used for PC beep in, the noise probably comes from this
pin and we can also disable the PC beep in passthrough, then the PC
beep in will not affect other sound playback.
Fixes: c4cfcf6f4297 ("ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1660581
Cc: <email address hidden>
Signed-off-by: Kailang Yang <email address hidden>
Signed-off-by: Hui Wang <email address hidden>
Signed-off-by: Takashi Iwai <email address hidden>
(backported from commit c8c6ee611926685a7d753409e0a6e48b9e1b8748
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git)
Signed-off-by: Hui Wang <email address hidden>
Acked-by: You-Sheng Yang <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
94b8907...
by
Hans de Goede <email address hidden>
ACPI / battery: Ignore AC state in handle_discharging on systems where it is broken
On some devices the "AC" interface ACPI AML code uses the exact same broken
logic which is causing the battery code to wrongly report discharging to
determine the "AC" state. Specifically the ACPI AML code is checking the
charging status bits of the charger-IC rather then the vbus present or
power-good status bits.
This makes our workaround for devices which wrongly report discharging when
plugged into AC while the charge is above the start charging threshold not
work on these devices.
This commit adds a battery_ac_is_broken flag and when that is set it skips
the power_supply_is_system_supplied() check in the workaround fixing this.
This flag gets set by a DMI quirk selected by systems where we know the AC
AML code is broken in this way *and* the rate_now value can be trusted.
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 1b799c5cf031c2b615f4b21150eafde3ff227788)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
1163d08...
by
Hans de Goede <email address hidden>
ACPI / battery: Add handling for devices which wrongly report discharging state
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.
This causes the wrong status to be reported for the battery in the
following quite common scenario:
1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok
2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok
3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.
Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.
This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".
This replaces commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.
Signed-off-by: Hans de Goede <email address hidden>
Reviewed-by: Daniel Drake <email address hidden>
Reviewed-by: Sebastian Reichel <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(backported from commit 19fffc8450d4378580a8f019b195c4617083176f)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
585cf03...
by
Hans de Goede <email address hidden>
ACPI / battery: Remove initializer for unused ident dmi_system_id
The battery code does not use the dmi_system_id ident member, so there is
no need to initialize it. This saves us storing the unused strings as
as const data.
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 91afa07664a8d26f51fb59b13fd5fa3592b728bc)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
d6e5d91...
by
Hans de Goede <email address hidden>
ACPI / AC: Remove initializer for unused ident dmi_system_id
The ac.c code does not use the dmi_system_id ident member, so there is
no need to initialize it. This saves us storing the unused "thinkpad e530"
string as const data.
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 6605e3423f37ba4d24771a65b850d8a900830610)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Revert commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA") and commit 4446823e2573 ("ACPI / battery: Add
quirk for Asus UX360UA and UX410UAK").
On many many Asus products, the battery is sometimes reported as
charging or discharging even when it is full and you are on AC power.
This change quirked the kernel to avoid advertising the discharging
state when this happens on 4 laptop models, under the belief that
this was incorrect information. I presume it originates from user
reports who are confused that their battery status icon says that it
is discharging.
However, the reported information is indeed correct, and the quirk
approach taken is inadequate and more thought is needed first.
Specifically:
1. It only quirks discharging state, not charging
2. There are so many different Asus products and DMI naming variants
within those product families that behave this way; Linux could
grow to quirk hundreds of products and still not even be close at
"winning" this battle.
3. Asus previously clarified that this behaviour is intentional. The
platform will periodically do a partial discharge/charge cycle
when the battery is full, because this is one way to extend the
lifetime of the battery (leaving a battery at 100% charge and
unused will decrease its usable capacity over time).
My understanding is that any decent consumer product will have
this behaviour, but it appears that Asus is different in that
they expose this info through ACPI.
However, the behaviour seems correct. The ACPI spec does not
suggest in that the platform should hide the truth. It lets you
report that the battery is full of charge, and discharging, and
with external power connected; and Asus does this.
4. In terms of not confusing the user, this seems like something that
could/should be handled by userspace, which can also detect these
same (accurate) conditions in the general case.
Revert this quirk before it gets included in a release, while we look
for better approaches.
Signed-off-by: Daniel Drake <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 82bf43b291888599b4079244d12195d214086fa4)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
e208bce...
by
James Bottomley <email address hidden>
My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background). There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.
There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them. It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command. So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on. In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.
Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.
[<email address hidden>: cleaned up some klog messages and
dropped tpm_transmit_check() helper function from James' original
commit.]
Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: <email address hidden>
Signed-off-by: James Bottomley <email address hidden>
Reviewed-by: Jarkko Sakkinen <email address hidden>
Tested-by: Jarkko Sakkinen <email address hidden>
Signed-off-by: Jarkko Sakkinen <email address hidden>
(backported from commit 2be8ffed093b91536d52b5cd2c99b52f605c9ba6)
[tyhicks: Backport to Bionic:
- Bionic is missing upstream commit 0b66f2a05a80 which modified the
self test retry loop in tpm2_do_selftest() but the entirety of that
loop is rewritten by this patch, anyways.]
Signed-off-by: Tyler Hicks <email address hidden>
Acked-by: Marcelo Henrique Cerri <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
