~kamalmostafa/ubuntu/+source/linux/+git/disco:disco-stable

Last commit made on 2020-04-30
Get this branch:
git clone -b disco-stable https://git.launchpad.net/~kamalmostafa/ubuntu/+source/linux/+git/disco
Only Kamal Mostafa can upload to this branch. If you are Kamal Mostafa please log in for upload directions.

Branch merges

Branch information

Name:
disco-stable
Repository:
lp:~kamalmostafa/ubuntu/+source/linux/+git/disco

Recent commits

db95fb1... by Kamal Mostafa

UBUNTU: upstream stable to v4.19.117, v5.4.34

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

Ignore: yes
Signed-off-by: Kamal Mostafa <email address hidden>

90fc881... by Hans de Goede <email address hidden>

i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT

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

commit d79294d0de12ddd1420110813626d691f440b86f upstream.

We already set DPM_FLAG_SMART_PREPARE, so we completely skip all
callbacks (other then prepare) where possible, quoting from
dw_i2c_plat_prepare():

        /*
         * If the ACPI companion device object is present for this device, it
         * may be accessed during suspend and resume of other devices via I2C
         * operation regions, so tell the PM core and middle layers to avoid
         * skipping system suspend/resume callbacks for it in that case.
         */
        return !has_acpi_companion(dev);

Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend()
to leave the controller runtime-suspended even if dw_i2c_plat_prepare()
returned 0.

Leaving the controller runtime-suspended normally, when the I2C controller
is suspended during the suspend_late phase, is not an issue because
the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it.

But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c
leaves the controller alive until the suspend_noirq phase, because it may
be used by the _PS3 ACPI methods of PCI devices and PCI devices are left
powered on until the suspend_noirq phase.

Between the suspend_late and resume_early phases runtime-pm is disabled.
So for any ACPI I2C OPRegion accesses done after the suspend_late phase,
the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the
controller is left runtime-suspended.

i2c_dw_xfer() has a check to catch this condition (rather then waiting
for the I2C transfer to timeout because the controller is suspended).
acpi_subsys_suspend() leaving the controller runtime-suspended in
combination with an ACPI I2C OPRegion access done after the suspend_late
phase triggers this check, leading to the following error being logged
on a Bay Trail based Lenovo Thinkpad 8 tablet:

[ 93.275882] i2c_designware 80860F41:00: Transfer while suspended
[ 93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280
...
[ 93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred
[ 93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280
...
[ 93.276340] Call Trace:
[ 93.276366] __i2c_transfer+0x121/0x520
[ 93.276379] i2c_transfer+0x4c/0x100
[ 93.276392] i2c_acpi_space_handler+0x219/0x510
[ 93.276408] ? up+0x40/0x60
[ 93.276419] ? i2c_acpi_notify+0x130/0x130
[ 93.276433] acpi_ev_address_space_dispatch+0x1e1/0x252
...

So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses
to work until the suspend_noirq phase, we need the controller to be
runtime-resumed during the suspend phase if it is runtime-suspended
suspended at that time. This means that we must not set the
DPM_FLAG_SMART_SUSPEND on these platforms.

On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag
to make sure the controller stays functional until the suspend_noirq
phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND
flag when that flag is set.

Cc: <email address hidden>
Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers")
Signed-off-by: Hans de Goede <email address hidden>
Reviewed-by: Andy Shevchenko <email address hidden>
Acked-by: Rafael J. Wysocki <email address hidden>
Acked-by: Jarkko Nikula <email address hidden>
Signed-off-by: Wolfram Sang <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

1417c39... by Prike Liang <email address hidden>

drm/amdgpu: fix the hw hang during perform system reboot and reset

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

commit b2a7e9735ab2864330be9d00d7f38c961c28de5d upstream.

The system reboot failed as some IP blocks enter power gate before perform
hw resource destory. Meanwhile use unify interface to set device CGPG to ungate
state can simplify the amdgpu poweroff or reset ungate guard.

Fixes: 487eca11a321ef ("drm/amdgpu: fix gfx hang during suspend with video playback (v2)")
Signed-off-by: Prike Liang <email address hidden>
Tested-by: Mengbing Wang <email address hidden>
Tested-by: Paul Menzel <email address hidden>
Acked-by: Alex Deucher <email address hidden>
Signed-off-by: Alex Deucher <email address hidden>
Cc: <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

8969215... by Sumit Garg <email address hidden>

mac80211: fix race in ieee80211_register_hw()

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

commit 52e04b4ce5d03775b6a78f3ed1097480faacc9fd upstream.

A race condition leading to a kernel crash is observed during invocation
of ieee80211_register_hw() on a dragonboard410c device having wcn36xx
driver built as a loadable module along with a wifi manager in user-space
waiting for a wifi device (wlanX) to be active.

Sequence diagram for a particular kernel crash scenario:

    user-space ieee80211_register_hw() ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       | | |
       |<---phy0----wiphy_register() |
       |-----iwd if_add---->| |
       | |<---IRQ----(RX packet)
       | Kernel crash |
       | due to unallocated |
       | workqueue. |
       | | |
       | alloc_ordered_workqueue() |
       | | |
       | Misc wiphy init. |
       | | |
       | ieee80211_if_add() |
       | | |

As evident from above sequence diagram, this race condition isn't specific
to a particular wifi driver but rather the initialization sequence in
ieee80211_register_hw() needs to be fixed. So re-order the initialization
sequence and the updated sequence diagram would look like:

    user-space ieee80211_register_hw() ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       | | |
       | alloc_ordered_workqueue() |
       | | |
       | Misc wiphy init. |
       | | |
       |<---phy0----wiphy_register() |
       |-----iwd if_add---->| |
       | |<---IRQ----(RX packet)
       | | |
       | ieee80211_if_add() |
       | | |

Cc: <email address hidden>
Signed-off-by: Sumit Garg <email address hidden>
Link: https://<email address hidden>
[Johannes: fix rtnl imbalances]
Signed-off-by: Johannes Berg <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

dd20399... by Adam Barber <email address hidden>

ALSA: hda/realtek - Enable the headset mic on Asus FX505DT

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

commit 4963d66b8a26c489958063abb6900ea6ed8e4836 upstream.

On Asus FX505DT with Realtek ALC233, the headset mic is connected
to pin 0x19, with default 0x411111f0.

Enable headset mic by reconfiguring the pin to an external mic
associated with the headphone on 0x21. Mic jack detection was also
found to be working.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207131
Signed-off-by: Adam Barber <email address hidden>
Cc: <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Takashi Iwai <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

56a234d... by Jin Yao <email address hidden>

perf report: Fix no branch type statistics report issue

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

commit c3b10649a80e9da2892c1fd3038c53abd57588f6 upstream.

Previously we could get the report of branch type statistics.

For example:

  # perf record -j any,save_type ...
  # t perf report --stdio

  #
  # Branch Statistics:
  #
  COND_FWD: 40.6%
  COND_BWD: 4.1%
  CROSS_4K: 24.7%
  CROSS_2M: 12.3%
      COND: 44.7%
    UNCOND: 0.0%
       IND: 6.1%
      CALL: 24.5%
       RET: 24.7%

But now for the recent perf, it can't report the branch type statistics.

It's a regression issue caused by commit 40c39e304641 ("perf report: Fix
a no annotate browser displayed issue"), which only counts the branch
type statistics for browser mode.

This patch moves the branch_type_count() outside of ui__has_annotation()
checking, then branch type statistics can work for stdio mode.

Fixes: 40c39e304641 ("perf report: Fix a no annotate browser displayed issue")
Signed-off-by: Jin Yao <email address hidden>
Cc: Alexander Shishkin <email address hidden>
Cc: Andi Kleen <email address hidden>
Cc: Jiri Olsa <email address hidden>
Cc: Kan Liang <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Link: http://<email address hidden>
Signed-off-by: Arnaldo Carvalho de Melo <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

3752fde... by Dan Carpenter <email address hidden>

acpi/nfit: improve bounds checking for 'func'

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

commit 01091c496f920e634ea84b689f480c39016752a8 upstream.

The 'func' variable can come from the user in the __nd_ioctl(). If it's
too high then the (1 << func) shift in acpi_nfit_clear_to_send() is
undefined. In acpi_nfit_ctl() we pass 'func' to test_bit(func, &dsm_mask)
which could result in an out of bounds access.

To fix these issues, I introduced the NVDIMM_CMD_MAX (31) define and
updated nfit_dsm_revid() to use that define as well instead of magic
numbers.

Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
Signed-off-by: Dan Carpenter <email address hidden>
Reviewed-by: Dan Williams <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

799f881... by Gilberto Bertin <email address hidden>

net: tun: record RX queue in skb before do_xdp_generic()

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

[ Upstream commit 3fe260e00cd0bf0be853c48fcc1e19853df615bb ]

This allows netif_receive_generic_xdp() to correctly determine the RX
queue from which the skb is coming, so that the context passed to the
XDP program will contain the correct RX queue index.

Signed-off-by: Gilberto Bertin <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

2d5dee1... by Atsushi Nemoto <email address hidden>

net: phy: micrel: use genphy_read_status for KSZ9131

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

[ Upstream commit 68dac3eb50be32957ae6e1e6da9281a3b7c6658b ]

KSZ9131 will not work with some switches due to workaround for KSZ9031
introduced in commit d2fd719bcb0e83cb39cfee22ee800f98a56eceb3
("net/phy: micrel: Add workaround for bad autoneg").
Use genphy_read_status instead of dedicated ksz9031_read_status.

Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
Signed-off-by: Atsushi Nemoto <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

ff6be45... by =?utf-8?q?Michael_Wei=C3=9F?= <email address hidden>

l2tp: Allow management of tunnels and session in user namespace

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

[ Upstream commit 2abe05234f2e892728c388169631e4b99f354c86 ]

Creation and management of L2TPv3 tunnels and session through netlink
requires CAP_NET_ADMIN. However, a process with CAP_NET_ADMIN in a
non-initial user namespace gets an EPERM due to the use of the
genetlink GENL_ADMIN_PERM flag. Thus, management of L2TP VPNs inside
an unprivileged container won't work.

We replaced the GENL_ADMIN_PERM by the GENL_UNS_ADMIN_PERM flag
similar to other network modules which also had this problem, e.g.,
openvswitch (commit 4a92602aa1cd "openvswitch: allow management from
inside user namespaces") and nl80211 (commit 5617c6cd6f844 "nl80211:
Allow privileged operations from user namespaces").

I tested this in the container runtime trustm3 (trustm3.github.io)
and was able to create l2tp tunnels and sessions in unpriviliged
(user namespaced) containers using a private network namespace.
For other runtimes such as docker or lxc this should work, too.

Signed-off-by: Michael Weiß <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>