~canonical-kernel/ubuntu/+source/linux-oem-osp1/+git/bionic:oem-current

Last commit made on 2020-03-12
Get this branch:
git clone -b oem-current https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem-osp1/+git/bionic
Members of Canonical Kernel can upload to this branch. Log in for directions.

Branch merges

Branch information

Recent commits

a633f06... by Timo Aaltonen

UBUNTU: Ubuntu-oem-osp1-5.0.0-1043.48

Signed-off-by: Timo Aaltonen <email address hidden>

4f0774f... by Timo Aaltonen

UBUNTU: [Config] Bump the GCC version

Signed-off-by: Timo Aaltonen <email address hidden>

fae3ed5... by Timo Aaltonen

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1867111
Properties: no-test-build
Signed-off-by: Timo Aaltonen <email address hidden>

0aa61f1... by AceLan Kao

UBUNTU: SAUCE: Input: i8042 - Fix the selftest retry logic

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

It returns -NODEV at the first selftest timeout, so the retry logic
doesn't work. Move the return outside of the while loop to make it real
retry 5 times before returns -ENODEV.

BTW, the origin loop will retry 6 times, also fix this.

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

3c77b86... by You-Sheng Yang

UBUNTU SAUCE: r8151: check disconnect status after long sleep

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

Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:

  /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
      |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
          |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
          |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class,
              Driver=r8152, 5000M

where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.

When hotplugging such dock with additional usb devices already attached on
it, the probing process may reset usb 2.1 port, therefore r8152 ethernet
device is also reset. However, during r8152 device init there are several
for-loops that, when it's unable to retrieve hardware registers due to
being discconected from USB, may take up to 14 seconds each in practice,
and that has to be completed before USB may re-enumerate devices on the
bus. As a result, devices attached to the dock will only be available
after nearly 1 minute after the dock was plugged in:

  [ 216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
  [ 216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
  [ 258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY not ready
  [ 258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr
  [ 258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get ether addr fail

This can be reproduced on all kernel versions up to latest v5.6-rc2, but
after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or so
while it was around 1/2.

The time consuming for-loops are at:
https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

01b2670... by Timo Aaltonen

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Timo Aaltonen <email address hidden>

d218d43... by AceLan Kao

UBUNTU: Ubuntu-oem-osp1-5.0.0-1042.47

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

f190d5a... by AceLan Kao

UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command

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

ODM asks us to use get_display_mode command to confirm the scalar's
behavior, and Windows use this command, too.
To align the behavior with Windows, remove get_scalar_status command and
replace it with get_display_mode.

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

b25b177... by Lyude Paul <email address hidden>

drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels

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

According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls depending on whether or not the panel is in HDR or
SDR mode. Yikes.

Regardless, we need to add quirks for these so that DPCD backlight
controls get enabled by default, since without additional driver support
that's the only form of brightness control that will work. Hopefully in
the future we can remove these quirks once we have a better way of
probing for this.

Changes since v1:
* Add one more EDID per Dell's request
* Remove model number (which is possibly wrong) and replace with Dell
  CML 2020 systems

Signed-off-by: Lyude Paul <email address hidden>
Cc: Jani Nikula <email address hidden>
(backported from https://patchwork.kernel.org/patch/11376665/)
Signed-off-by: AceLan Kao <email address hidden>

7b9e372... by Lyude Paul <email address hidden>

drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

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

The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but we haven't gotten any more details on this from Lenovo
just yet. For the time being though, making sure the backlight 'just
works' is a bit more important.

So, add a quirk to force DPCD backlight controls on for these systems
based on EDID (since this panel doesn't appear to fill in the device ID).
Hopefully in the future we'll figure out a better way of probing this.

Signed-off-by: Lyude Paul <email address hidden>
Cc: Jani Nikula <email address hidden>
(backported from https://patchwork.kernel.org/patch/11376671/)
Signed-off-by: AceLan Kao <email address hidden>