~vicamo/+git/ubuntu-kernel:bug-1860940/fix-hp-wmi-feature2-query/oem-bionic

Last commit made on 2020-01-27
Get this branch:
git clone -b bug-1860940/fix-hp-wmi-feature2-query/oem-bionic https://git.launchpad.net/~vicamo/+git/ubuntu-kernel
Only You-Sheng Yang can upload to this branch. If you are You-Sheng Yang please log in for upload directions.

Branch merges

Branch information

Name:
bug-1860940/fix-hp-wmi-feature2-query/oem-bionic
Repository:
lp:~vicamo/+git/ubuntu-kernel

Recent commits

c2c36a9... by You-Sheng Yang

Bug 1860940: platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes

058cf68... by Hans de Goede <email address hidden>

platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes

At least on the HP Envy x360 15-cp0xxx model the WMI interface
for HPWMI_FEATURE2_QUERY requires an outsize of at least 128 bytes,
otherwise it fails with an error code 5 (HPWMI_RET_INVALID_PARAMETERS):

Dec 06 00:59:38 kernel: hp_wmi: query 0xd returned error 0x5

We do not care about the contents of the buffer, we just want to know
if the HPWMI_FEATURE2_QUERY command is supported.

This commits bumps the buffer size, fixing the error.

Fixes: 8a1513b4932 ("hp-wmi: limit hotkey enable")
Cc: <email address hidden>
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Andy Shevchenko <email address hidden>
(cherry picked from commit 133b2acee3871ae6bf123b8fe34be14464aa3d2c)
Signed-off-by: You-Sheng Yang <email address hidden>

076272b... by Kelsey Steele

UBUNTU: Ubuntu-oem-4.15.0-1067.77

Signed-off-by: Kelsey Skunberg <email address hidden>

2eeddce... by Kelsey Steele

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1859702
Properties: no-test-build
Signed-off-by: Kelsey Skunberg <email address hidden>

1f2c410... by Kelsey Steele

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Kelsey Skunberg <email address hidden>

3f1d50a... by AceLan Kao

UBUNTU: Ubuntu-oem-4.15.0-1066.76

Signed-off-by: AceLan Kao <email address hidden>

2d09145... by AceLan Kao

UBUNTU: [Config] updateconfigs for DIMLIB

Ignore: yes
Signed-off-by: AceLan Kao <email address hidden>

55c7f41... by AceLan Kao

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1854797
Properties: no-test-build
Signed-off-by: AceLan Kao <email address hidden>

e94e936... by Kai-Heng Feng

UBUNTU: SAUCE: USB: core: Attempt power cycle port when it's in eSS.Disabled state

BugLink: https://bugs.launchpad.net/bugs/1855312

On Dell TB16, Realtek USB ethernet (r8152) connects to an SMSC hub which
then connects to ASMedia xHCI's root hub:

/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 5000M
            |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 0424:5537 Standard Microsystems Corp. USB5537B
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

The SMSC hub may disconnect after system resume from suspend. When this
happens, the reset resume attempt fails, and the last resort to disable
the port and see something comes up later, also fails.

When the issue occurs, the link state stays in eSS.Disabled state
despite the warm reset attempts. Accoding to spec this can be caused by
invalid VBus, after some expiremets, the SMSC hub can be brought back
after a powercycle.

So let's power cycle the port at the end of reset resume attempt, if
it's in eSS.Disabled state.

Signed-off-by: Kai-Heng Feng <email address hidden>
Signed-off-by: AceLan Kao <email address hidden>

46b863e... by Kai-Heng Feng

UBUNTU: SAUCE: USB: core: Make port power cycle a seperate helper function

BugLink: https://bugs.launchpad.net/bugs/1855312

Add a new function, hub_port_power_cycle() to power cycle port's power.
It'll be used by a following patch.

In addition to that, check the return value of usb_hub_set_port_power(),
so we don't need to wait if the set power operation fails.

Furthermore, remove parameter *hdev from usb_hub_set_port_power(), since
we can get *hdev from *hub directly.

Signed-off-by: Kai-Heng Feng <email address hidden>
Signed-off-by: AceLan Kao <email address hidden>