This is the start of the stable review cycle for the 4.19.112 release.
There are 48 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.112-rc1
Matteo Croce <[email protected]>
ipv4: ensure rcu_read_lock() in cipso_v4_error()
Waiman Long <[email protected]>
efi: Fix debugobjects warning on 'efi_rts_work'
Chen-Tsung Hsieh <[email protected]>
HID: google: add moonball USB id
Jann Horn <[email protected]>
mm: slub: add missing TID bump in kmem_cache_alloc_bulk()
Kees Cook <[email protected]>
ARM: 8958/1: rename missed uaccess .fixup section
Florian Fainelli <[email protected]>
ARM: 8957/1: VDSO: Match ARMv8 timer in cntvct_functional()
Carl Huang <[email protected]>
net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
Rafael J. Wysocki <[email protected]>
driver core: Fix creation of device links with PM-runtime flags
Rafael J. Wysocki <[email protected]>
driver core: Remove device link creation limitation
Rafael J. Wysocki <[email protected]>
driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER
Rafael J. Wysocki <[email protected]>
driver core: Make driver core own stateful device links
Rafael J. Wysocki <[email protected]>
driver core: Fix adding device links to probing suppliers
Yong Wu <[email protected]>
driver core: Remove the link if there is no driver with AUTO flag
Faiz Abbas <[email protected]>
mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
Faiz Abbas <[email protected]>
mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
Navid Emamdoost <[email protected]>
wimax: i2400: Fix memory leak in i2400m_op_rfkill_sw_toggle
Navid Emamdoost <[email protected]>
wimax: i2400: fix memory leak
Qian Cai <[email protected]>
jbd2: fix data races at struct journal_head
Alex Maftei (amaftei) <[email protected]>
sfc: fix timestamp reconstruction at 16-bit rollover points
Taehee Yoo <[email protected]>
net: rmnet: fix packet forwarding in rmnet bridge mode
Taehee Yoo <[email protected]>
net: rmnet: fix bridge mode bugs
Taehee Yoo <[email protected]>
net: rmnet: use upper/lower device infrastructure
Taehee Yoo <[email protected]>
net: rmnet: do not allow to change mux id if mux id is duplicated
Taehee Yoo <[email protected]>
net: rmnet: remove rcu_read_lock in rmnet_force_unassociate_device()
Taehee Yoo <[email protected]>
net: rmnet: fix suspicious RCU usage
Taehee Yoo <[email protected]>
net: rmnet: fix NULL pointer dereference in rmnet_changelink()
Taehee Yoo <[email protected]>
net: rmnet: fix NULL pointer dereference in rmnet_newlink()
Luo bin <[email protected]>
hinic: fix a bug of setting hw_ioctxt
Luo bin <[email protected]>
hinic: fix a irq affinity bug
yangerkun <[email protected]>
slip: not call free_netdev before rtnl_unlock in slip_open
Linus Torvalds <[email protected]>
signal: avoid double atomic counter increments for user accounting
Madhuparna Bhowmik <[email protected]>
mac80211: rx: avoid RCU list traversal under mutex
Marek Vasut <[email protected]>
net: ks8851-ml: Fix IRQ handling and locking
Daniele Palmas <[email protected]>
net: usb: qmi_wwan: restore mtu min/max values after raw_ip switch
Igor Druzhinin <[email protected]>
scsi: libfc: free response frame from GPN_ID
Johannes Berg <[email protected]>
cfg80211: check reg_rule for NULL in handle_channel_custom()
Kai-Heng Feng <[email protected]>
HID: i2c-hid: add Trekstor Surfbook E11B to descriptor override
Mansour Behabadi <[email protected]>
HID: apple: Add support for recent firmware on Magic Keyboards
Jean Delvare <[email protected]>
ACPI: watchdog: Allow disabling WDAT at boot
Ulf Hansson <[email protected]>
mmc: core: Allow host controllers to require R1B for CMD6
Ulf Hansson <[email protected]>
mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
Ulf Hansson <[email protected]>
mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command
Ulf Hansson <[email protected]>
mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY
Faiz Abbas <[email protected]>
mmc: host: Fix Kconfig warnings on keystone_defconfig
Faiz Abbas <[email protected]>
mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
Faiz Abbas <[email protected]>
mmc: sdhci-omap: Add platform specific reset callback
Ulf Hansson <[email protected]>
mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
Kim Phillips <[email protected]>
perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT flag
-------------
Diffstat:
Documentation/admin-guide/kernel-parameters.txt | 4 +
Documentation/driver-api/device_link.rst | 63 +++--
Makefile | 4 +-
arch/arm/kernel/vdso.c | 2 +
arch/arm/lib/copy_from_user.S | 2 +-
arch/x86/events/amd/uncore.c | 14 +-
drivers/acpi/acpi_watchdog.c | 12 +-
drivers/base/core.c | 293 +++++++++++++++------
drivers/base/dd.c | 2 +-
drivers/base/power/runtime.c | 4 +-
drivers/firmware/efi/runtime-wrappers.c | 2 +-
drivers/hid/hid-apple.c | 3 +-
drivers/hid/hid-google-hammer.c | 2 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 8 +
drivers/mmc/core/core.c | 5 +-
drivers/mmc/core/mmc.c | 7 +-
drivers/mmc/core/mmc_ops.c | 27 +-
drivers/mmc/host/Kconfig | 2 +
drivers/mmc/host/sdhci-omap.c | 151 ++++++++++-
drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c | 1 +
drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 +-
drivers/net/ethernet/huawei/hinic/hinic_hw_if.h | 1 +
drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h | 1 +
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 5 +-
drivers/net/ethernet/micrel/ks8851_mll.c | 14 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 186 +++++++------
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 3 +-
.../net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 7 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 8 -
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.h | 1 -
drivers/net/ethernet/sfc/ptp.c | 38 ++-
drivers/net/slip/slip.c | 3 +
drivers/net/usb/qmi_wwan.c | 3 +
drivers/net/wimax/i2400m/op-rfkill.c | 1 +
drivers/scsi/libfc/fc_disc.c | 2 +
fs/jbd2/transaction.c | 8 +-
include/linux/device.h | 7 +-
include/linux/mmc/host.h | 1 +
kernel/signal.c | 23 +-
mm/slub.c | 9 +
net/ipv4/cipso_ipv4.c | 7 +-
net/mac80211/rx.c | 2 +-
net/qrtr/qrtr.c | 2 +-
net/wireless/reg.c | 2 +-
45 files changed, 672 insertions(+), 273 deletions(-)
From: Jean Delvare <[email protected]>
[ Upstream commit 3f9e12e0df012c4a9a7fd7eb0d3ae69b459d6b2c ]
In case the WDAT interface is broken, give the user an option to
ignore it to let a native driver bind to the watchdog device instead.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
drivers/acpi/acpi_watchdog.c | 12 +++++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 8bf0c0532046f..1a5101b7e853c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -136,6 +136,10 @@
dynamic table installation which will install SSDT
tables to /sys/firmware/acpi/tables/dynamic.
+ acpi_no_watchdog [HW,ACPI,WDT]
+ Ignore the ACPI-based watchdog interface (WDAT) and let
+ a native driver control the watchdog device instead.
+
acpi_rsdp= [ACPI,EFI,KEXEC]
Pass the RSDP address to the kernel, mostly used
on machines running EFI runtime service to boot the
diff --git a/drivers/acpi/acpi_watchdog.c b/drivers/acpi/acpi_watchdog.c
index 23cde3d8e8fbb..0bd1899a287f3 100644
--- a/drivers/acpi/acpi_watchdog.c
+++ b/drivers/acpi/acpi_watchdog.c
@@ -58,12 +58,14 @@ static bool acpi_watchdog_uses_rtc(const struct acpi_table_wdat *wdat)
}
#endif
+static bool acpi_no_watchdog;
+
static const struct acpi_table_wdat *acpi_watchdog_get_wdat(void)
{
const struct acpi_table_wdat *wdat = NULL;
acpi_status status;
- if (acpi_disabled)
+ if (acpi_disabled || acpi_no_watchdog)
return NULL;
status = acpi_get_table(ACPI_SIG_WDAT, 0,
@@ -91,6 +93,14 @@ bool acpi_has_watchdog(void)
}
EXPORT_SYMBOL_GPL(acpi_has_watchdog);
+/* ACPI watchdog can be disabled on boot command line */
+static int __init disable_acpi_watchdog(char *str)
+{
+ acpi_no_watchdog = true;
+ return 1;
+}
+__setup("acpi_no_watchdog", disable_acpi_watchdog);
+
void __init acpi_watchdog_init(void)
{
const struct acpi_wdat_entry *entries;
--
2.20.1
From: Marek Vasut <[email protected]>
[ Upstream commit 44343418d0f2f623cb9da6f5000df793131cbe3b ]
The KS8851 requires that packet RX and TX are mutually exclusive.
Currently, the driver hopes to achieve this by disabling interrupt
from the card by writing the card registers and by disabling the
interrupt on the interrupt controller. This however is racy on SMP.
Replace this approach by expanding the spinlock used around the
ks_start_xmit() TX path to ks_irq() RX path to assure true mutual
exclusion and remove the interrupt enabling/disabling, which is
now not needed anymore. Furthermore, disable interrupts also in
ks_net_stop(), which was missing before.
Note that a massive improvement here would be to re-use the KS8851
driver approach, which is to move the TX path into a worker thread,
interrupt handling to threaded interrupt, and synchronize everything
with mutexes, but that would be a much bigger rework, for a separate
patch.
Signed-off-by: Marek Vasut <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Lukas Wunner <[email protected]>
Cc: Petr Stetiar <[email protected]>
Cc: YueHaibing <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
index 9de59facec218..a5525bf977e2c 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -832,14 +832,17 @@ static irqreturn_t ks_irq(int irq, void *pw)
{
struct net_device *netdev = pw;
struct ks_net *ks = netdev_priv(netdev);
+ unsigned long flags;
u16 status;
+ spin_lock_irqsave(&ks->statelock, flags);
/*this should be the first in IRQ handler */
ks_save_cmd_reg(ks);
status = ks_rdreg16(ks, KS_ISR);
if (unlikely(!status)) {
ks_restore_cmd_reg(ks);
+ spin_unlock_irqrestore(&ks->statelock, flags);
return IRQ_NONE;
}
@@ -865,6 +868,7 @@ static irqreturn_t ks_irq(int irq, void *pw)
ks->netdev->stats.rx_over_errors++;
/* this should be the last in IRQ handler*/
ks_restore_cmd_reg(ks);
+ spin_unlock_irqrestore(&ks->statelock, flags);
return IRQ_HANDLED;
}
@@ -934,6 +938,7 @@ static int ks_net_stop(struct net_device *netdev)
/* shutdown RX/TX QMU */
ks_disable_qmu(ks);
+ ks_disable_int(ks);
/* set powermode to soft power down to save power */
ks_set_powermode(ks, PMECR_PM_SOFTDOWN);
@@ -990,10 +995,9 @@ static netdev_tx_t ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
{
netdev_tx_t retv = NETDEV_TX_OK;
struct ks_net *ks = netdev_priv(netdev);
+ unsigned long flags;
- disable_irq(netdev->irq);
- ks_disable_int(ks);
- spin_lock(&ks->statelock);
+ spin_lock_irqsave(&ks->statelock, flags);
/* Extra space are required:
* 4 byte for alignment, 4 for status/length, 4 for CRC
@@ -1007,9 +1011,7 @@ static netdev_tx_t ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
dev_kfree_skb(skb);
} else
retv = NETDEV_TX_BUSY;
- spin_unlock(&ks->statelock);
- ks_enable_int(ks);
- enable_irq(netdev->irq);
+ spin_unlock_irqrestore(&ks->statelock, flags);
return retv;
}
--
2.20.1
From: Linus Torvalds <[email protected]>
[ Upstream commit fda31c50292a5062332fa0343c084bd9f46604d9 ]
When queueing a signal, we increment both the users count of pending
signals (for RLIMIT_SIGPENDING tracking) and we increment the refcount
of the user struct itself (because we keep a reference to the user in
the signal structure in order to correctly account for it when freeing).
That turns out to be fairly expensive, because both of them are atomic
updates, and particularly under extreme signal handling pressure on big
machines, you can get a lot of cache contention on the user struct.
That can then cause horrid cacheline ping-pong when you do these
multiple accesses.
So change the reference counting to only pin the user for the _first_
pending signal, and to unpin it when the last pending signal is
dequeued. That means that when a user sees a lot of concurrent signal
queuing - which is the only situation when this matters - the only
atomic access needed is generally the 'sigpending' count update.
This was noticed because of a particularly odd timing artifact on a
dual-socket 96C/192T Cascade Lake platform: when you get into bad
contention, on that machine for some reason seems to be much worse when
the contention happens in the upper 32-byte half of the cacheline.
As a result, the kernel test robot will-it-scale 'signal1' benchmark had
an odd performance regression simply due to random alignment of the
'struct user_struct' (and pointed to a completely unrelated and
apparently nonsensical commit for the regression).
Avoiding the double increments (and decrements on the dequeueing side,
of course) makes for much less contention and hugely improved
performance on that will-it-scale microbenchmark.
Quoting Feng Tang:
"It makes a big difference, that the performance score is tripled! bump
from original 17000 to 54000. Also the gap between 5.0-rc6 and
5.0-rc6+Jiri's patch is reduced to around 2%"
[ The "2% gap" is the odd cacheline placement difference on that
platform: under the extreme contention case, the effect of which half
of the cacheline was hot was 5%, so with the reduced contention the
odd timing artifact is reduced too ]
It does help in the non-contended case too, but is not nearly as
noticeable.
Reported-and-tested-by: Feng Tang <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Huang, Ying <[email protected]>
Cc: Philip Li <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/signal.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 08911bb6fe9ab..c42eaf39b5729 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -407,27 +407,32 @@ __sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimi
{
struct sigqueue *q = NULL;
struct user_struct *user;
+ int sigpending;
/*
* Protect access to @t credentials. This can go away when all
* callers hold rcu read lock.
+ *
+ * NOTE! A pending signal will hold on to the user refcount,
+ * and we get/put the refcount only when the sigpending count
+ * changes from/to zero.
*/
rcu_read_lock();
- user = get_uid(__task_cred(t)->user);
- atomic_inc(&user->sigpending);
+ user = __task_cred(t)->user;
+ sigpending = atomic_inc_return(&user->sigpending);
+ if (sigpending == 1)
+ get_uid(user);
rcu_read_unlock();
- if (override_rlimit ||
- atomic_read(&user->sigpending) <=
- task_rlimit(t, RLIMIT_SIGPENDING)) {
+ if (override_rlimit || likely(sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
q = kmem_cache_alloc(sigqueue_cachep, flags);
} else {
print_dropped_signal(sig);
}
if (unlikely(q == NULL)) {
- atomic_dec(&user->sigpending);
- free_uid(user);
+ if (atomic_dec_and_test(&user->sigpending))
+ free_uid(user);
} else {
INIT_LIST_HEAD(&q->list);
q->flags = 0;
@@ -441,8 +446,8 @@ static void __sigqueue_free(struct sigqueue *q)
{
if (q->flags & SIGQUEUE_PREALLOC)
return;
- atomic_dec(&q->user->sigpending);
- free_uid(q->user);
+ if (atomic_dec_and_test(&q->user->sigpending))
+ free_uid(q->user);
kmem_cache_free(sigqueue_cachep, q);
}
--
2.20.1
On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.112 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
NOTE:
The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
and 5.5.11-rc2 kernel pops up the following messages on console log,
Is this a problem ?
[ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
[ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
[ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
...
[ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
[ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
Summary
------------------------------------------------------------------------
kernel: 4.19.112-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 8977fd00fd705a4e9273d09171ee66344cdc879e
git describe: v4.19.111-49-g8977fd00fd70
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.111-49-g8977fd00fd70
No regressions (compared to build v4.19.110-90-gad35ac79caef)
No fixes (compared to build v4.19.110-90-gad35ac79caef)
Ran 18421 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- nxp-ls2088- arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* linux-log-parser
* perf
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* v4l2-compliance
* ltp-cve-tests
* spectre-meltdown-checker-test
* ltp-open-posix-tests
ref:
https://lkft.validation.linaro.org/scheduler/job/1298207#L4037
https://lkft.validation.linaro.org/scheduler/job/1298945#L4132
https://lkft.validation.linaro.org/scheduler/job/1299973#L4232
--
Linaro LKFT
https://lkft.linaro.org
On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> <[email protected]> wrote:
> > This is the start of the stable review cycle for the 4.19.112 release.
> > There are 48 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > Faiz Abbas <[email protected]>
> > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> >
> > Faiz Abbas <[email protected]>
> > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
>
> NOTE:
> The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> and 5.5.11-rc2 kernel pops up the following messages on console log,
> Is this a problem ?
>
> [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> ...
> [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
[...]
This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
to generic_cmd6_time as timeout in __mmc_switch()". That should not be
applied to stable branches; it is not valid without (at least) these
preparatory changes:
0c204979c691 mmc: core: Cleanup BKOPS support
24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
On 3/19/20 6:03 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.112 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 418 pass: 418 fail: 0
Guenter
On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
> On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> > On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > > This is the start of the stable review cycle for the 4.19.112 release.
> > > There are 48 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > > Faiz Abbas <[email protected]>
> > > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> > >
> > > Faiz Abbas <[email protected]>
> > > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> >
> > Results from Linaro’s test farm.
> > No regressions on arm64, arm, x86_64, and i386.
> >
> > NOTE:
> > The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> > and 5.5.11-rc2 kernel pops up the following messages on console log,
> > Is this a problem ?
> >
> > [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> > [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> > [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> > ...
> > [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> > [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
> [...]
>
> This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
> to generic_cmd6_time as timeout in __mmc_switch()". That should not be
> applied to stable branches; it is not valid without (at least) these
> preparatory changes:
>
> 0c204979c691 mmc: core: Cleanup BKOPS support
> 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
> ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
Ok, I've now dropped that patch, which also required me to drop
1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
thanks,
greg k-h
On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
> > On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> > > On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> > > <[email protected]> wrote:
> > > > This is the start of the stable review cycle for the 4.19.112 release.
> > > > There are 48 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> > > > or in the git tree and branch at:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > > > Faiz Abbas <[email protected]>
> > > > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> > > >
> > > > Faiz Abbas <[email protected]>
> > > > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> > >
> > > Results from Linaro’s test farm.
> > > No regressions on arm64, arm, x86_64, and i386.
> > >
> > > NOTE:
> > > The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> > > and 5.5.11-rc2 kernel pops up the following messages on console log,
> > > Is this a problem ?
> > >
> > > [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> > > [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> > > [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> > > ...
> > > [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> > > [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
> > [...]
> >
> > This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
> > to generic_cmd6_time as timeout in __mmc_switch()". That should not be
> > applied to stable branches; it is not valid without (at least) these
> > preparatory changes:
> >
> > 0c204979c691 mmc: core: Cleanup BKOPS support
> > 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
> > ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
>
> Ok, I've now dropped that patch, which also required me to drop
> 1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
> CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
Ugh, I forgot, that broke other things. I'm going to go rip out a bunch
of mmc patches now...
On Fri, 20 Mar 2020 at 13:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
> > > On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> > > > On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> > > > <[email protected]> wrote:
> > > > > This is the start of the stable review cycle for the 4.19.112 release.
> > > > > There are 48 patches in this series, all will be posted as a response
> > > > > to this one. If anyone has any issues with these being applied, please
> > > > > let me know.
> > > > >
> > > > > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> > > > > Anything received after that time might be too late.
> > > > >
> > > > > The whole patch series can be found in one patch at:
> > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> > > > > or in the git tree and branch at:
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > > > and the diffstat can be found below.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > > >
> > > > > Faiz Abbas <[email protected]>
> > > > > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> > > > >
> > > > > Faiz Abbas <[email protected]>
> > > > > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> > > >
> > > > Results from Linaro’s test farm.
> > > > No regressions on arm64, arm, x86_64, and i386.
> > > >
> > > > NOTE:
> > > > The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> > > > and 5.5.11-rc2 kernel pops up the following messages on console log,
> > > > Is this a problem ?
> > > >
> > > > [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> > > > [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> > > > [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> > > > ...
> > > > [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> > > > [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
> > > [...]
> > >
> > > This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
> > > to generic_cmd6_time as timeout in __mmc_switch()". That should not be
> > > applied to stable branches; it is not valid without (at least) these
> > > preparatory changes:
> > >
> > > 0c204979c691 mmc: core: Cleanup BKOPS support
> > > 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
> > > ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
> >
> > Ok, I've now dropped that patch, which also required me to drop
> > 1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
> > CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
>
> Ugh, I forgot, that broke other things. I'm going to go rip out a bunch
> of mmc patches now...
[Am i missing rc2 tag ?]
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.19.112-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: d078cac7a42286ba7c97801a763fc42ad7baf5c1
git describe: v4.19.109-136-gd078cac7a422
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.109-136-gd078cac7a422
No regressions (compared to build v4.19.109)
No fixes (compared to build v4.19.109)
Ran 23963 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- x15
- x86_64
- x86-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
Test Suites
-----------
* install-android-platform-tools-r2800
* linux-log-parser
* ltp-ipc-tests
* v4l2-compliance
* kvm-unit-tests
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
--
Linaro LKFT
https://lkft.linaro.org
On 3/20/20 1:11 AM, Greg Kroah-Hartman wrote:
> On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
>> On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
>>> On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
>>>> On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
>>>> <[email protected]> wrote:
>>>>> This is the start of the stable review cycle for the 4.19.112 release.
>>>>> There are 48 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
>>>>> or in the git tree and branch at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>> Faiz Abbas <[email protected]>
>>>>> mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
>>>>>
>>>>> Faiz Abbas <[email protected]>
>>>>> mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
>>>>
>>>> Results from Linaro’s test farm.
>>>> No regressions on arm64, arm, x86_64, and i386.
>>>>
>>>> NOTE:
>>>> The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
>>>> and 5.5.11-rc2 kernel pops up the following messages on console log,
>>>> Is this a problem ?
>>>>
>>>> [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
>>>> [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
>>>> [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
>>>> ...
>>>> [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
>>>> [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
>>> [...]
>>>
>>> This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
>>> to generic_cmd6_time as timeout in __mmc_switch()". That should not be
>>> applied to stable branches; it is not valid without (at least) these
>>> preparatory changes:
>>>
>>> 0c204979c691 mmc: core: Cleanup BKOPS support
>>> 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
>>> ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
>>
>> Ok, I've now dropped that patch, which also required me to drop
>> 1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
>> CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
>
> Ugh, I forgot, that broke other things. I'm going to go rip out a bunch
> of mmc patches now...
>
For v4.19.111-44-gd078cac:
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 418 pass: 418 fail: 0
Guenter
Hello Greg,
> From: [email protected] <[email protected]> On
> Behalf Of Greg Kroah-Hartman
> Sent: 19 March 2020 13:04
>
> This is the start of the stable review cycle for the 4.19.112 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
No build/test issues seen for CIP configs for Linux 4.19.112-rc1 (d078cac7a422).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/128111695
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Kind regards, Chris
>
> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-
> 4.19.112-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.19.112-rc1
>
> Matteo Croce <[email protected]>
> ipv4: ensure rcu_read_lock() in cipso_v4_error()
>
> Waiman Long <[email protected]>
> efi: Fix debugobjects warning on 'efi_rts_work'
>
> Chen-Tsung Hsieh <[email protected]>
> HID: google: add moonball USB id
>
> Jann Horn <[email protected]>
> mm: slub: add missing TID bump in kmem_cache_alloc_bulk()
>
> Kees Cook <[email protected]>
> ARM: 8958/1: rename missed uaccess .fixup section
>
> Florian Fainelli <[email protected]>
> ARM: 8957/1: VDSO: Match ARMv8 timer in cntvct_functional()
>
> Carl Huang <[email protected]>
> net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
>
> Rafael J. Wysocki <[email protected]>
> driver core: Fix creation of device links with PM-runtime flags
>
> Rafael J. Wysocki <[email protected]>
> driver core: Remove device link creation limitation
>
> Rafael J. Wysocki <[email protected]>
> driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER
>
> Rafael J. Wysocki <[email protected]>
> driver core: Make driver core own stateful device links
>
> Rafael J. Wysocki <[email protected]>
> driver core: Fix adding device links to probing suppliers
>
> Yong Wu <[email protected]>
> driver core: Remove the link if there is no driver with AUTO flag
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
>
> Navid Emamdoost <[email protected]>
> wimax: i2400: Fix memory leak in i2400m_op_rfkill_sw_toggle
>
> Navid Emamdoost <[email protected]>
> wimax: i2400: fix memory leak
>
> Qian Cai <[email protected]>
> jbd2: fix data races at struct journal_head
>
> Alex Maftei (amaftei) <[email protected]>
> sfc: fix timestamp reconstruction at 16-bit rollover points
>
> Taehee Yoo <[email protected]>
> net: rmnet: fix packet forwarding in rmnet bridge mode
>
> Taehee Yoo <[email protected]>
> net: rmnet: fix bridge mode bugs
>
> Taehee Yoo <[email protected]>
> net: rmnet: use upper/lower device infrastructure
>
> Taehee Yoo <[email protected]>
> net: rmnet: do not allow to change mux id if mux id is duplicated
>
> Taehee Yoo <[email protected]>
> net: rmnet: remove rcu_read_lock in rmnet_force_unassociate_device()
>
> Taehee Yoo <[email protected]>
> net: rmnet: fix suspicious RCU usage
>
> Taehee Yoo <[email protected]>
> net: rmnet: fix NULL pointer dereference in rmnet_changelink()
>
> Taehee Yoo <[email protected]>
> net: rmnet: fix NULL pointer dereference in rmnet_newlink()
>
> Luo bin <[email protected]>
> hinic: fix a bug of setting hw_ioctxt
>
> Luo bin <[email protected]>
> hinic: fix a irq affinity bug
>
> yangerkun <[email protected]>
> slip: not call free_netdev before rtnl_unlock in slip_open
>
> Linus Torvalds <[email protected]>
> signal: avoid double atomic counter increments for user accounting
>
> Madhuparna Bhowmik <[email protected]>
> mac80211: rx: avoid RCU list traversal under mutex
>
> Marek Vasut <[email protected]>
> net: ks8851-ml: Fix IRQ handling and locking
>
> Daniele Palmas <[email protected]>
> net: usb: qmi_wwan: restore mtu min/max values after raw_ip switch
>
> Igor Druzhinin <[email protected]>
> scsi: libfc: free response frame from GPN_ID
>
> Johannes Berg <[email protected]>
> cfg80211: check reg_rule for NULL in handle_channel_custom()
>
> Kai-Heng Feng <[email protected]>
> HID: i2c-hid: add Trekstor Surfbook E11B to descriptor override
>
> Mansour Behabadi <[email protected]>
> HID: apple: Add support for recent firmware on Magic Keyboards
>
> Jean Delvare <[email protected]>
> ACPI: watchdog: Allow disabling WDAT at boot
>
> Ulf Hansson <[email protected]>
> mmc: core: Allow host controllers to require R1B for CMD6
>
> Ulf Hansson <[email protected]>
> mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
>
> Ulf Hansson <[email protected]>
> mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command
>
> Ulf Hansson <[email protected]>
> mmc: sdhci-omap: Fix busy detection by enabling
> MMC_CAP_NEED_RSP_BUSY
>
> Faiz Abbas <[email protected]>
> mmc: host: Fix Kconfig warnings on keystone_defconfig
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning
> failures (i929)
>
> Faiz Abbas <[email protected]>
> mmc: sdhci-omap: Add platform specific reset callback
>
> Ulf Hansson <[email protected]>
> mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
>
> Kim Phillips <[email protected]>
> perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT
> flag
>
>
> -------------
>
> Diffstat:
>
> Documentation/admin-guide/kernel-parameters.txt | 4 +
> Documentation/driver-api/device_link.rst | 63 +++--
> Makefile | 4 +-
> arch/arm/kernel/vdso.c | 2 +
> arch/arm/lib/copy_from_user.S | 2 +-
> arch/x86/events/amd/uncore.c | 14 +-
> drivers/acpi/acpi_watchdog.c | 12 +-
> drivers/base/core.c | 293 +++++++++++++++------
> drivers/base/dd.c | 2 +-
> drivers/base/power/runtime.c | 4 +-
> drivers/firmware/efi/runtime-wrappers.c | 2 +-
> drivers/hid/hid-apple.c | 3 +-
> drivers/hid/hid-google-hammer.c | 2 +
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 8 +
> drivers/mmc/core/core.c | 5 +-
> drivers/mmc/core/mmc.c | 7 +-
> drivers/mmc/core/mmc_ops.c | 27 +-
> drivers/mmc/host/Kconfig | 2 +
> drivers/mmc/host/sdhci-omap.c | 151 ++++++++++-
> drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c | 1 +
> drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 +-
> drivers/net/ethernet/huawei/hinic/hinic_hw_if.h | 1 +
> drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h | 1 +
> drivers/net/ethernet/huawei/hinic/hinic_rx.c | 5 +-
> drivers/net/ethernet/micrel/ks8851_mll.c | 14 +-
> drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 186 +++++++------
> drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 3 +-
> .../net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 7 +-
> drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 8 -
> drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.h | 1 -
> drivers/net/ethernet/sfc/ptp.c | 38 ++-
> drivers/net/slip/slip.c | 3 +
> drivers/net/usb/qmi_wwan.c | 3 +
> drivers/net/wimax/i2400m/op-rfkill.c | 1 +
> drivers/scsi/libfc/fc_disc.c | 2 +
> fs/jbd2/transaction.c | 8 +-
> include/linux/device.h | 7 +-
> include/linux/mmc/host.h | 1 +
> kernel/signal.c | 23 +-
> mm/slub.c | 9 +
> net/ipv4/cipso_ipv4.c | 7 +-
> net/mac80211/rx.c | 2 +-
> net/qrtr/qrtr.c | 2 +-
> net/wireless/reg.c | 2 +-
> 45 files changed, 672 insertions(+), 273 deletions(-)
>
On 3/19/20 7:03 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.112 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
On Fri, Mar 20, 2020 at 10:58:43AM -0700, Guenter Roeck wrote:
> On 3/20/20 1:11 AM, Greg Kroah-Hartman wrote:
> > On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
> >> On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
> >>> On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> >>>> On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> >>>> <[email protected]> wrote:
> >>>>> This is the start of the stable review cycle for the 4.19.112 release.
> >>>>> There are 48 patches in this series, all will be posted as a response
> >>>>> to this one. If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>>
> >>>>> Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> >>>>> Anything received after that time might be too late.
> >>>>>
> >>>>> The whole patch series can be found in one patch at:
> >>>>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> >>>>> or in the git tree and branch at:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> >>>>> and the diffstat can be found below.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>>
> >>>>> Faiz Abbas <[email protected]>
> >>>>> mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> >>>>>
> >>>>> Faiz Abbas <[email protected]>
> >>>>> mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> >>>>
> >>>> Results from Linaro’s test farm.
> >>>> No regressions on arm64, arm, x86_64, and i386.
> >>>>
> >>>> NOTE:
> >>>> The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> >>>> and 5.5.11-rc2 kernel pops up the following messages on console log,
> >>>> Is this a problem ?
> >>>>
> >>>> [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> >>>> [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> >>>> [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> >>>> ...
> >>>> [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> >>>> [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
> >>> [...]
> >>>
> >>> This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
> >>> to generic_cmd6_time as timeout in __mmc_switch()". That should not be
> >>> applied to stable branches; it is not valid without (at least) these
> >>> preparatory changes:
> >>>
> >>> 0c204979c691 mmc: core: Cleanup BKOPS support
> >>> 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
> >>> ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
> >>
> >> Ok, I've now dropped that patch, which also required me to drop
> >> 1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
> >> CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
> >
> > Ugh, I forgot, that broke other things. I'm going to go rip out a bunch
> > of mmc patches now...
> >
> For v4.19.111-44-gd078cac:
>
> Build results:
> total: 156 pass: 156 fail: 0
> Qemu test results:
> total: 418 pass: 418 fail: 0
Wonderful, thanks for testing.
greg k-h
On Fri, Mar 20, 2020 at 10:11:39PM +0530, Naresh Kamboju wrote:
> On Fri, 20 Mar 2020 at 13:41, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
> > > > On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
> > > > > On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
> > > > > <[email protected]> wrote:
> > > > > > This is the start of the stable review cycle for the 4.19.112 release.
> > > > > > There are 48 patches in this series, all will be posted as a response
> > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > >
> > > > > > The whole patch series can be found in one patch at:
> > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
> > > > > > or in the git tree and branch at:
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > > > > > and the diffstat can be found below.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > > >
> > > > > > Faiz Abbas <[email protected]>
> > > > > > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
> > > > > >
> > > > > > Faiz Abbas <[email protected]>
> > > > > > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> > > > >
> > > > > Results from Linaro’s test farm.
> > > > > No regressions on arm64, arm, x86_64, and i386.
> > > > >
> > > > > NOTE:
> > > > > The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
> > > > > and 5.5.11-rc2 kernel pops up the following messages on console log,
> > > > > Is this a problem ?
> > > > >
> > > > > [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
> > > > > [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
> > > > > [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
> > > > > ...
> > > > > [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
> > > > > [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
> > > > [...]
> > > >
> > > > This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
> > > > to generic_cmd6_time as timeout in __mmc_switch()". That should not be
> > > > applied to stable branches; it is not valid without (at least) these
> > > > preparatory changes:
> > > >
> > > > 0c204979c691 mmc: core: Cleanup BKOPS support
> > > > 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
> > > > ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
> > >
> > > Ok, I've now dropped that patch, which also required me to drop
> > > 1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
> > > CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
> >
> > Ugh, I forgot, that broke other things. I'm going to go rip out a bunch
> > of mmc patches now...
>
> [Am i missing rc2 tag ?]
Nope, didn't do one.
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Wonderful, thanks!
greg k-h
On Fri, Mar 20, 2020 at 09:01:22PM +0000, Chris Paterson wrote:
> Hello Greg,
>
> > From: [email protected] <[email protected]> On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 19 March 2020 13:04
> >
> > This is the start of the stable review cycle for the 4.19.112 release.
> > There are 48 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
>
> No build/test issues seen for CIP configs for Linux 4.19.112-rc1 (d078cac7a422).
>
> Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/128111695
> GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Great, thanks for testing two of these and letting me know.
greg k-h
On Fri, Mar 20, 2020 at 09:03:17AM +0100, Greg Kroah-Hartman wrote:
>On Thu, Mar 19, 2020 at 08:00:32PM +0000, Ben Hutchings wrote:
>> On Fri, 2020-03-20 at 01:12 +0530, Naresh Kamboju wrote:
>> > On Thu, 19 Mar 2020 at 18:50, Greg Kroah-Hartman
>> > <[email protected]> wrote:
>> > > This is the start of the stable review cycle for the 4.19.112 release.
>> > > There are 48 patches in this series, all will be posted as a response
>> > > to this one. If anyone has any issues with these being applied, please
>> > > let me know.
>> > >
>> > > Responses should be made by Sat, 21 Mar 2020 12:37:04 +0000.
>> > > Anything received after that time might be too late.
>> > >
>> > > The whole patch series can be found in one patch at:
>> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.112-rc1.gz
>> > > or in the git tree and branch at:
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
>> > > and the diffstat can be found below.
>> > >
>> > > thanks,
>> > >
>> > > greg k-h
>> > >
>> > > Faiz Abbas <[email protected]>
>> > > mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
>> > >
>> > > Faiz Abbas <[email protected]>
>> > > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
>> >
>> > Results from Linaro’s test farm.
>> > No regressions on arm64, arm, x86_64, and i386.
>> >
>> > NOTE:
>> > The arm beagleboard x15 device running stable rc 4.19.112-rc1, 5.4.27-rc1
>> > and 5.5.11-rc2 kernel pops up the following messages on console log,
>> > Is this a problem ?
>> >
>> > [ 15.737765] mmc1: unspecified timeout for CMD6 - use generic
>> > [ 16.754248] mmc1: unspecified timeout for CMD6 - use generic
>> > [ 16.842071] mmc1: unspecified timeout for CMD6 - use generic
>> > ...
>> > [ 977.126652] mmc1: unspecified timeout for CMD6 - use generic
>> > [ 985.449798] mmc1: unspecified timeout for CMD6 - use generic
>> [...]
>>
>> This warning was introduced by commit 533a6cfe08f9 "mmc: core: Default
>> to generic_cmd6_time as timeout in __mmc_switch()". That should not be
>> applied to stable branches; it is not valid without (at least) these
>> preparatory changes:
>>
>> 0c204979c691 mmc: core: Cleanup BKOPS support
>> 24ed3bd01d6a mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
>> ad91619aa9d7 mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
>
>Ok, I've now dropped that patch, which also required me to drop
>1292e3efb149 ("mmc: core: Allow host controllers to require R1B for
>CMD6"). I've done so for 5.5.y, 5.4.y, and 4.19.y.
Should we instead take those preparatory changes, and 1292e3efb149?
--
Thanks,
Sasha