[PATCH 6/9] staging: greybus: loopback: Fix up some alignment checkpatch issues
Some function prototypes do not match the expected alignment formatting
so fix that up so that checkpatch is happy.
Cc: "Bryan O'Donoghue"
Cc: Johan Hovold
Cc: Alex Elder
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/loopback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 48d85ebe404a..b0ab0eed5c18 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -882,7 +882,7 @@ static int gb_loopback_fn(void *data)
gb->type = 0;
gb->send_count = 0;
sysfs_notify(>dev->kobj, NULL,
- "iteration_count");
+"iteration_count");
dev_dbg(>dev, "load test complete\n");
} else {
dev_dbg(>dev,
@@ -1054,7 +1054,7 @@ static int gb_loopback_probe(struct gb_bundle *bundle,
/* Allocate kfifo */
if (kfifo_alloc(>kfifo_lat, kfifo_depth * sizeof(u32),
- GFP_KERNEL)) {
+ GFP_KERNEL)) {
retval = -ENOMEM;
goto out_conn;
}
--
2.23.0
[PATCH 5/9] staging: greybus: log: Fix up some alignment checkpatch issues
Some function prototypes do not match the expected alignment formatting
so fix that up so that checkpatch is happy.
Cc: David Lin
Cc: Johan Hovold
Cc: Alex Elder
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/log.c b/drivers/staging/greybus/log.c
index 15a88574dbb0..4f1f161ff11c 100644
--- a/drivers/staging/greybus/log.c
+++ b/drivers/staging/greybus/log.c
@@ -31,14 +31,14 @@ static int gb_log_request_handler(struct gb_operation *op)
/* Verify size of payload */
if (op->request->payload_size < sizeof(*receive)) {
dev_err(dev, "log request too small (%zu < %zu)\n",
- op->request->payload_size, sizeof(*receive));
+ op->request->payload_size, sizeof(*receive));
return -EINVAL;
}
receive = op->request->payload;
len = le16_to_cpu(receive->len);
if (len != (op->request->payload_size - sizeof(*receive))) {
dev_err(dev, "log request wrong size %d vs %zu\n", len,
- (op->request->payload_size - sizeof(*receive)));
+ (op->request->payload_size - sizeof(*receive)));
return -EINVAL;
}
if (len == 0) {
@@ -83,7 +83,7 @@ static int gb_log_probe(struct gb_bundle *bundle,
return -ENOMEM;
connection = gb_connection_create(bundle, le16_to_cpu(cport_desc->id),
- gb_log_request_handler);
+ gb_log_request_handler);
if (IS_ERR(connection)) {
retval = PTR_ERR(connection);
goto error_free;
--
2.23.0
[PATCH 8/9] staging: greybus: move the greybus core to drivers/greybus
The Greybus core code has been stable for a long time, and has been
shipping for many years in millions of phones. With the advent of a
recent Google Summer of Code project, and a number of new devices in the
works from various companies, it is time to get the core greybus code
out of staging as it really is going to be with us for a while.
Cc: Johan Hovold
Cc: Alex Elder
Cc: linux-kernel@vger.kernel.org
Cc: greybus-...@lists.linaro.org
Signed-off-by: Greg Kroah-Hartman
---
MAINTAINERS | 3 +++
drivers/Kconfig | 2 ++
drivers/Makefile | 1 +
drivers/greybus/Kconfig | 16
drivers/greybus/Makefile | 19 +++
drivers/{staging => }/greybus/bundle.c| 0
drivers/{staging => }/greybus/connection.c| 0
drivers/{staging => }/greybus/control.c | 0
drivers/{staging => }/greybus/core.c | 0
drivers/{staging => }/greybus/debugfs.c | 0
drivers/{staging => }/greybus/greybus_trace.h | 0
drivers/{staging => }/greybus/hd.c| 0
drivers/{staging => }/greybus/interface.c | 0
drivers/{staging => }/greybus/manifest.c | 0
drivers/{staging => }/greybus/module.c| 0
drivers/{staging => }/greybus/operation.c | 0
drivers/{staging => }/greybus/svc.c | 0
drivers/{staging => }/greybus/svc_watchdog.c | 0
drivers/staging/greybus/Kconfig | 16
drivers/staging/greybus/Makefile | 17 -
drivers/staging/greybus/es2.c | 2 +-
21 files changed, 42 insertions(+), 34 deletions(-)
create mode 100644 drivers/greybus/Kconfig
create mode 100644 drivers/greybus/Makefile
rename drivers/{staging => }/greybus/bundle.c (100%)
rename drivers/{staging => }/greybus/connection.c (100%)
rename drivers/{staging => }/greybus/control.c (100%)
rename drivers/{staging => }/greybus/core.c (100%)
rename drivers/{staging => }/greybus/debugfs.c (100%)
rename drivers/{staging => }/greybus/greybus_trace.h (100%)
rename drivers/{staging => }/greybus/hd.c (100%)
rename drivers/{staging => }/greybus/interface.c (100%)
rename drivers/{staging => }/greybus/manifest.c (100%)
rename drivers/{staging => }/greybus/module.c (100%)
rename drivers/{staging => }/greybus/operation.c (100%)
rename drivers/{staging => }/greybus/svc.c (100%)
rename drivers/{staging => }/greybus/svc_watchdog.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f38cba2c581..e3242687cd19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7003,6 +7003,9 @@ M:Alex Elder
M: Greg Kroah-Hartman
S: Maintained
F: drivers/staging/greybus/
+F: drivers/greybus/
+F: include/linux/greybus.h
+F: include/linux/greybus/
L: greybus-...@lists.linaro.org (moderated for non-subscribers)
GREYBUS UART PROTOCOLS DRIVERS
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 61cf4ea2c229..7dce76ae7369 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -146,6 +146,8 @@ source "drivers/hv/Kconfig"
source "drivers/xen/Kconfig"
+source "drivers/greybus/Kconfig"
+
source "drivers/staging/Kconfig"
source "drivers/platform/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 6d37564e783c..73df8e5a2fce 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -148,6 +148,7 @@ obj-$(CONFIG_BCMA) += bcma/
obj-$(CONFIG_VHOST_RING) += vhost/
obj-$(CONFIG_VHOST)+= vhost/
obj-$(CONFIG_VLYNQ)+= vlynq/
+obj-$(CONFIG_GREYBUS) += greybus/
obj-$(CONFIG_STAGING) += staging/
obj-y += platform/
diff --git a/drivers/greybus/Kconfig b/drivers/greybus/Kconfig
new file mode 100644
index ..158d8893114c
--- /dev/null
+++ b/drivers/greybus/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+menuconfig GREYBUS
+ tristate "Greybus support"
+ depends on SYSFS
+ ---help---
+ This option enables the Greybus driver core. Greybus is an
+ hardware protocol that was designed to provide Unipro with a
+ sane application layer. It was originally designed for the
+ ARA project, a module phone system, but has shown up in other
+ phones, and can be tunneled over other busses in order to
+ control hardware devices.
+
+ Say Y here to enable support for these types of drivers.
+
+ To compile this code as a module, chose M here: the module
+ will be called greybus.ko
diff --git a/drivers/greybus/Makefile b/drivers/greybus/Makefile
new file mode 100644
index ..03b22616ec7d
--- /dev/null
+++ b/drivers/greybus/Makefile
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+# Greybus core
+greybus-y := core.o \
+ debugfs.o \
+ hd.o\
+ manifest.o \
+ module.o
[PATCH 2/9] staging: greybus: remove license "boilerplate"
When the greybus drivers were converted to SPDX identifiers for the license text, some license boilerplate was not removed. Clean this up by removing this unneeded text now. Cc: Johan Hovold Cc: Alex Elder Cc: Vaibhav Agarwal Cc: Mark Greer Cc: Viresh Kumar Cc: "Bryan O'Donoghue" Cc: greybus-...@lists.linaro.org Cc: de...@driverdev.osuosl.org Signed-off-by: Greg Kroah-Hartman --- .../Documentation/firmware/authenticate.c | 46 --- .../greybus/Documentation/firmware/firmware.c | 46 --- drivers/staging/greybus/arpc.h| 46 --- drivers/staging/greybus/audio_apbridgea.h | 26 +-- .../staging/greybus/greybus_authentication.h | 46 --- drivers/staging/greybus/greybus_firmware.h| 46 --- drivers/staging/greybus/greybus_protocols.h | 46 --- drivers/staging/greybus/tools/loopback_test.c | 2 - 8 files changed, 1 insertion(+), 303 deletions(-) diff --git a/drivers/staging/greybus/Documentation/firmware/authenticate.c b/drivers/staging/greybus/Documentation/firmware/authenticate.c index 806e75b7f405..3d2c6f88a138 100644 --- a/drivers/staging/greybus/Documentation/firmware/authenticate.c +++ b/drivers/staging/greybus/Documentation/firmware/authenticate.c @@ -2,54 +2,8 @@ /* * Sample code to test CAP protocol * - * This file is provided under a dual BSD/GPLv2 license. When using or - * redistributing this file, you may do so under either license. - * - * GPL LICENSE SUMMARY - * * Copyright(c) 2016 Google Inc. All rights reserved. * Copyright(c) 2016 Linaro Ltd. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License version 2 for more details. - * - * BSD LICENSE - * - * Copyright(c) 2016 Google Inc. All rights reserved. - * Copyright(c) 2016 Linaro Ltd. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in - *the documentation and/or other materials provided with the - *distribution. - * * Neither the name of Google Inc. or Linaro Ltd. nor the names of - *its contributors may be used to endorse or promote products - *derived from this software without specific prior written - *permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL GOOGLE INC. OR - * LINARO LTD. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, - * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, - * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR - * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY - * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include diff --git a/drivers/staging/greybus/Documentation/firmware/firmware.c b/drivers/staging/greybus/Documentation/firmware/firmware.c index 31d9c23e2eeb..765d69faa9cc 100644 --- a/drivers/staging/greybus/Documentation/firmware/firmware.c +++ b/drivers/staging/greybus/Documentation/firmware/firmware.c @@ -2,54 +2,8 @@ /* * Sample code to test firmware-management protocol * - * This file is provided under a dual BSD/GPLv2 license. When using or - * redistributing this file, you may do so under either license. - * - * GPL LICENSE SUMMARY - * * Copyright(c) 2016 Google Inc. All rights reserved. * Copyright(c) 2016 Linaro Ltd. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License version 2 for more details. - * - * BSD LICENSE - * - * Copyright(c) 2016 Google Inc. All
[PATCH 9/9] staging: greybus: move es2 to drivers/greybus/
The es2 Greybus host controller has long been stable, so move it out of
drivers/staging/ to drivers/greybus/
Cc: Johan Hovold
Cc: Alex Elder
Cc: greybus-...@lists.linaro.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/greybus/Kconfig | 16
drivers/greybus/Makefile | 7 +++
drivers/{staging => }/greybus/arpc.h | 0
drivers/{staging => }/greybus/es2.c | 2 +-
drivers/staging/greybus/Kconfig | 11 ---
drivers/staging/greybus/Makefile | 5 -
6 files changed, 24 insertions(+), 17 deletions(-)
rename drivers/{staging => }/greybus/arpc.h (100%)
rename drivers/{staging => }/greybus/es2.c (99%)
diff --git a/drivers/greybus/Kconfig b/drivers/greybus/Kconfig
index 158d8893114c..b84fcaf8b105 100644
--- a/drivers/greybus/Kconfig
+++ b/drivers/greybus/Kconfig
@@ -14,3 +14,19 @@ menuconfig GREYBUS
To compile this code as a module, chose M here: the module
will be called greybus.ko
+
+if GREYBUS
+
+config GREYBUS_ES2
+ tristate "Greybus ES3 USB host controller"
+ depends on USB
+ ---help---
+ Select this option if you have a Toshiba ES3 USB device that
+ acts as a Greybus "host controller". This device is a bridge
+ from a USB device to a Unipro network.
+
+ To compile this code as a module, chose M here: the module
+ will be called gb-es2.ko
+
+endif # GREYBUS
+
diff --git a/drivers/greybus/Makefile b/drivers/greybus/Makefile
index 03b22616ec7d..9bccdd229aa2 100644
--- a/drivers/greybus/Makefile
+++ b/drivers/greybus/Makefile
@@ -17,3 +17,10 @@ obj-$(CONFIG_GREYBUS)+= greybus.o
# needed for trace events
ccflags-y += -I$(src)
+
+# Greybus Host controller drivers
+gb-es2-y := es2.o
+
+obj-$(CONFIG_GREYBUS_ES2) += gb-es2.o
+
+
diff --git a/drivers/staging/greybus/arpc.h b/drivers/greybus/arpc.h
similarity index 100%
rename from drivers/staging/greybus/arpc.h
rename to drivers/greybus/arpc.h
diff --git a/drivers/staging/greybus/es2.c b/drivers/greybus/es2.c
similarity index 99%
rename from drivers/staging/greybus/es2.c
rename to drivers/greybus/es2.c
index 5b755e76d8a4..366716f11b1a 100644
--- a/drivers/staging/greybus/es2.c
+++ b/drivers/greybus/es2.c
@@ -15,7 +15,7 @@
#include
#include "arpc.h"
-#include "../../greybus/greybus_trace.h"
+#include "greybus_trace.h"
/* Default timeout for USB vendor requests. */
diff --git a/drivers/staging/greybus/Kconfig b/drivers/staging/greybus/Kconfig
index d03c37e1e6e8..d4777f5a8b90 100644
--- a/drivers/staging/greybus/Kconfig
+++ b/drivers/staging/greybus/Kconfig
@@ -1,17 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
if GREYBUS
-config GREYBUS_ES2
- tristate "Greybus ES3 USB host controller"
- depends on USB
- ---help---
- Select this option if you have a Toshiba ES3 USB device that
- acts as a Greybus "host controller". This device is a bridge
- from a USB device to a Unipro network.
-
- To compile this code as a module, chose M here: the module
- will be called gb-es2.ko
-
config GREYBUS_AUDIO
tristate "Greybus Audio Class driver"
depends on SOUND
diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile
index d16853399c9a..627e44f2a983 100644
--- a/drivers/staging/greybus/Makefile
+++ b/drivers/staging/greybus/Makefile
@@ -2,11 +2,6 @@
# needed for trace events
ccflags-y += -I$(src)
-# Greybus Host controller drivers
-gb-es2-y := es2.o
-
-obj-$(CONFIG_GREYBUS_ES2) += gb-es2.o
-
# Greybus class drivers
gb-bootrom-y := bootrom.o
gb-camera-y:= camera.o
--
2.23.0
[PATCH 7/9] staging: greybus: move core include files to include/linux/greybus/
With the goal of moving the core of the greybus code out of staging, the
include files need to be moved to include/linux/greybus.h and
include/linux/greybus/
Cc: Vaibhav Hiremath
Cc: Johan Hovold
Cc: Alex Elder
Cc: Vaibhav Agarwal
Cc: Mark Greer
Cc: Viresh Kumar
Cc: Rui Miguel Silva
Cc: David Lin
Cc: "Bryan O'Donoghue"
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/arche-platform.c | 2 +-
drivers/staging/greybus/audio_apbridgea.c | 3 +--
drivers/staging/greybus/audio_codec.h | 4 +---
drivers/staging/greybus/audio_gb.c| 4 +---
drivers/staging/greybus/authentication.c | 3 +--
drivers/staging/greybus/bootrom.c | 2 +-
drivers/staging/greybus/bundle.c | 2 +-
drivers/staging/greybus/camera.c | 2 +-
drivers/staging/greybus/connection.c | 2 +-
drivers/staging/greybus/control.c | 2 +-
drivers/staging/greybus/core.c| 2 +-
drivers/staging/greybus/debugfs.c | 3 +--
drivers/staging/greybus/es2.c | 3 +--
drivers/staging/greybus/firmware.h| 2 +-
drivers/staging/greybus/fw-core.c | 2 +-
drivers/staging/greybus/fw-download.c | 2 +-
drivers/staging/greybus/fw-management.c | 2 +-
drivers/staging/greybus/gbphy.c | 2 +-
drivers/staging/greybus/gpio.c| 2 +-
drivers/staging/greybus/hd.c | 2 +-
drivers/staging/greybus/hid.c | 3 +--
drivers/staging/greybus/i2c.c | 2 +-
drivers/staging/greybus/interface.c | 2 +-
drivers/staging/greybus/light.c | 4 +---
drivers/staging/greybus/log.c | 3 +--
drivers/staging/greybus/loopback.c| 5 +---
drivers/staging/greybus/manifest.c| 2 +-
drivers/staging/greybus/module.c | 2 +-
drivers/staging/greybus/operation.c | 2 +-
drivers/staging/greybus/power_supply.c| 3 +--
drivers/staging/greybus/pwm.c | 2 +-
drivers/staging/greybus/raw.c | 3 +--
drivers/staging/greybus/sdio.c| 2 +-
drivers/staging/greybus/spi.c | 2 +-
drivers/staging/greybus/spilib.c | 2 +-
drivers/staging/greybus/svc.c | 3 +--
drivers/staging/greybus/svc_watchdog.c| 2 +-
drivers/staging/greybus/uart.c| 2 +-
drivers/staging/greybus/usb.c | 2 +-
drivers/staging/greybus/vibrator.c| 3 +--
.../greybus => include/linux}/greybus.h | 24 +--
.../linux}/greybus/bundle.h | 0
.../linux}/greybus/connection.h | 0
.../linux}/greybus/control.h | 0
.../linux}/greybus/greybus_id.h | 0
.../linux}/greybus/greybus_manifest.h | 0
.../linux}/greybus/greybus_protocols.h| 0
.../staging => include/linux}/greybus/hd.h| 0
.../linux}/greybus/interface.h| 0
.../linux}/greybus/manifest.h | 0
.../linux}/greybus/module.h | 0
.../linux}/greybus/operation.h| 0
.../staging => include/linux}/greybus/svc.h | 0
53 files changed, 52 insertions(+), 71 deletions(-)
rename {drivers/staging/greybus => include/linux}/greybus.h (89%)
rename {drivers/staging => include/linux}/greybus/bundle.h (100%)
rename {drivers/staging => include/linux}/greybus/connection.h (100%)
rename {drivers/staging => include/linux}/greybus/control.h (100%)
rename {drivers/staging => include/linux}/greybus/greybus_id.h (100%)
rename {drivers/staging => include/linux}/greybus/greybus_manifest.h (100%)
rename {drivers/staging => include/linux}/greybus/greybus_protocols.h (100%)
rename {drivers/staging => include/linux}/greybus/hd.h (100%)
rename {drivers/staging => include/linux}/greybus/interface.h (100%)
rename {drivers/staging => include/linux}/greybus/manifest.h (100%)
rename {drivers/staging => include/linux}/greybus/module.h (100%)
rename {drivers/staging => include/linux}/greybus/operation.h (100%)
rename {drivers/staging => include/linux}/greybus/svc.h (100%)
diff --git a/drivers/staging/greybus/arche-platform.c
b/drivers/staging/greybus/arche-platform.c
index 6eb842040c22..eebf0deb39f5 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -19,8 +19,8 @@
#include
#include
#include
+#include
#include "arche_platform.h"
-#include "greybus.h"
#if IS_ENABLED(CONFIG_USB_HSIC_USB3613)
#include
diff --git a/drivers/staging/greybus/audio_apbridgea.c
b/drivers/staging/greybus/audio_apbridgea.c
index 7ebb1bde5cb7..26117e390deb 100644
--- a/drivers/staging/greybus/audio_apbridgea.c
+++ b/drivers/staging/greybus/audio_apbridgea.c
@@ -5,8 +5,7 @@
* Copyright 2015-2016 Google Inc.
*/
[PATCH 3/9] staging: greybus: hd: Fix up some alignment checkpatch issues
Some function prototypes do not match the expected alignment formatting
so fix that up so that checkpatch is happy.
Cc: Johan Hovold
Cc: Alex Elder
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/hd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/hd.c b/drivers/staging/greybus/hd.c
index 969f86697673..e2b9ab5f6ec2 100644
--- a/drivers/staging/greybus/hd.c
+++ b/drivers/staging/greybus/hd.c
@@ -31,7 +31,7 @@ int gb_hd_output(struct gb_host_device *hd, void *req, u16
size, u8 cmd,
EXPORT_SYMBOL_GPL(gb_hd_output);
static ssize_t bus_id_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute *attr, char *buf)
{
struct gb_host_device *hd = to_gb_host_device(dev);
@@ -70,7 +70,7 @@ EXPORT_SYMBOL_GPL(gb_hd_cport_release_reserved);
/* Locking: Caller guarantees serialisation */
int gb_hd_cport_allocate(struct gb_host_device *hd, int cport_id,
- unsigned long flags)
+unsigned long flags)
{
struct ida *id_map = >cport_id_map;
int ida_start, ida_end;
@@ -122,9 +122,9 @@ struct device_type greybus_hd_type = {
};
struct gb_host_device *gb_hd_create(struct gb_hd_driver *driver,
- struct device *parent,
- size_t buffer_size_max,
- size_t num_cports)
+ struct device *parent,
+ size_t buffer_size_max,
+ size_t num_cports)
{
struct gb_host_device *hd;
int ret;
--
2.23.0
[PATCH 0/9] staging: move greybus core out of staging
The Greybus code has long been "stable" but was living in the
drivers/staging/ directory to see if there really was going to be
devices using this protocol over the long-term. With the success of
millions of phones with this hardware and code in it, and the recent
Google Summer of Code project, and a number of of new devices in the
works from various companies, it is time to finally move this code out
of staging into the "real" portion of the kernel so that people know
they can rely on it.
This series first does a little bit of checkpatch cleanups for some
basic remaining issues in the greybus files, and then moves the include
directory, the greybus core code, and the es2 greybus host controller
driver into drivers/greybus.
To come after this is the movement of the Documentation entries and a
number of the module drivers that are stable.
Greg Kroah-Hartman (9):
staging: greybus: fix up SPDX comment in .h files
staging: greybus: remove license "boilerplate"
staging: greybus: hd: Fix up some alignment checkpatch issues
staging: greybus: manifest: Fix up some alignment checkpatch issues
staging: greybus: log: Fix up some alignment checkpatch issues
staging: greybus: loopback: Fix up some alignment checkpatch issues
staging: greybus: move core include files to include/linux/greybus/
staging: greybus: move the greybus core to drivers/greybus
staging: greybus: move es2 to drivers/greybus/
MAINTAINERS | 3 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/greybus/Kconfig | 32 +
drivers/greybus/Makefile | 26 +
drivers/greybus/arpc.h| 63 ++
drivers/{staging => }/greybus/bundle.c| 2 +-
drivers/{staging => }/greybus/connection.c| 2 +-
drivers/{staging => }/greybus/control.c | 2 +-
drivers/{staging => }/greybus/core.c | 2 +-
drivers/{staging => }/greybus/debugfs.c | 3 +-
drivers/{staging => }/greybus/es2.c | 3 +-
drivers/{staging => }/greybus/greybus_trace.h | 2 +-
drivers/{staging => }/greybus/hd.c| 12 +-
drivers/{staging => }/greybus/interface.c | 2 +-
drivers/{staging => }/greybus/manifest.c | 41 ---
drivers/{staging => }/greybus/module.c| 2 +-
drivers/{staging => }/greybus/operation.c | 2 +-
drivers/{staging => }/greybus/svc.c | 3 +-
drivers/{staging => }/greybus/svc_watchdog.c | 2 +-
.../Documentation/firmware/authenticate.c | 46
.../greybus/Documentation/firmware/firmware.c | 46
drivers/staging/greybus/Kconfig | 27 -
drivers/staging/greybus/Makefile | 22
drivers/staging/greybus/arche-platform.c | 2 +-
drivers/staging/greybus/arpc.h| 109 --
drivers/staging/greybus/audio_apbridgea.c | 3 +-
drivers/staging/greybus/audio_apbridgea.h | 26 +
drivers/staging/greybus/audio_codec.h | 4 +-
drivers/staging/greybus/audio_gb.c| 4 +-
drivers/staging/greybus/authentication.c | 3 +-
drivers/staging/greybus/bootrom.c | 2 +-
drivers/staging/greybus/camera.c | 2 +-
drivers/staging/greybus/firmware.h| 4 +-
drivers/staging/greybus/fw-core.c | 2 +-
drivers/staging/greybus/fw-download.c | 2 +-
drivers/staging/greybus/fw-management.c | 2 +-
drivers/staging/greybus/gb-camera.h | 2 +-
drivers/staging/greybus/gbphy.c | 2 +-
drivers/staging/greybus/gbphy.h | 2 +-
drivers/staging/greybus/gpio.c| 2 +-
.../staging/greybus/greybus_authentication.h | 48 +---
drivers/staging/greybus/greybus_firmware.h| 48 +---
drivers/staging/greybus/hid.c | 3 +-
drivers/staging/greybus/i2c.c | 2 +-
drivers/staging/greybus/light.c | 4 +-
drivers/staging/greybus/log.c | 9 +-
drivers/staging/greybus/loopback.c| 9 +-
drivers/staging/greybus/power_supply.c| 3 +-
drivers/staging/greybus/pwm.c | 2 +-
drivers/staging/greybus/raw.c | 3 +-
drivers/staging/greybus/sdio.c| 2 +-
drivers/staging/greybus/spi.c | 2 +-
drivers/staging/greybus/spilib.c | 2 +-
drivers/staging/greybus/spilib.h | 2 +-
drivers/staging/greybus/tools/loopback_test.c | 2 -
drivers/staging/greybus/uart.c| 2 +-
drivers/staging/greybus/usb.c | 2 +-
drivers/staging/greybus/vibrator.c| 3 +-
.../greybus => include/linux}/greybus.h | 26 ++---
.../linux}/greybus/bundle.h | 0
.../linux}/greybus/connection.h | 0
.../linux}/greybus/control.h
[PATCH 1/9] staging: greybus: fix up SPDX comment in .h files
When these files originally got an SPDX tag, I used // instead of /* */ for the .h files. Fix this up to use // properly. Cc: Viresh Kumar Cc: Johan Hovold Cc: Alex Elder Cc: greybus-...@lists.linaro.org Cc: de...@driverdev.osuosl.org Signed-off-by: Greg Kroah-Hartman --- drivers/staging/greybus/firmware.h | 2 +- drivers/staging/greybus/gb-camera.h | 2 +- drivers/staging/greybus/gbphy.h | 2 +- drivers/staging/greybus/greybus.h| 2 +- drivers/staging/greybus/greybus_authentication.h | 2 +- drivers/staging/greybus/greybus_firmware.h | 2 +- drivers/staging/greybus/greybus_manifest.h | 2 +- drivers/staging/greybus/greybus_protocols.h | 2 +- drivers/staging/greybus/greybus_trace.h | 2 +- drivers/staging/greybus/hd.h | 2 +- drivers/staging/greybus/interface.h | 2 +- drivers/staging/greybus/manifest.h | 2 +- drivers/staging/greybus/module.h | 2 +- drivers/staging/greybus/operation.h | 2 +- drivers/staging/greybus/spilib.h | 2 +- drivers/staging/greybus/svc.h| 2 +- 16 files changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/staging/greybus/firmware.h b/drivers/staging/greybus/firmware.h index 946221307ef6..72dfabfa4704 100644 --- a/drivers/staging/greybus/firmware.h +++ b/drivers/staging/greybus/firmware.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus Firmware Management Header * diff --git a/drivers/staging/greybus/gb-camera.h b/drivers/staging/greybus/gb-camera.h index ee293e461fc3..5fc469101fc1 100644 --- a/drivers/staging/greybus/gb-camera.h +++ b/drivers/staging/greybus/gb-camera.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus Camera protocol driver. * diff --git a/drivers/staging/greybus/gbphy.h b/drivers/staging/greybus/gbphy.h index 99463489d7d6..087928a586fb 100644 --- a/drivers/staging/greybus/gbphy.h +++ b/drivers/staging/greybus/gbphy.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus Bridged-Phy Bus driver * diff --git a/drivers/staging/greybus/greybus.h b/drivers/staging/greybus/greybus.h index d03ddb7c9df0..f048893e 100644 --- a/drivers/staging/greybus/greybus.h +++ b/drivers/staging/greybus/greybus.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus driver and device API * diff --git a/drivers/staging/greybus/greybus_authentication.h b/drivers/staging/greybus/greybus_authentication.h index 03ea9615b217..d654760cf175 100644 --- a/drivers/staging/greybus/greybus_authentication.h +++ b/drivers/staging/greybus/greybus_authentication.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ /* * Greybus Component Authentication User Header * diff --git a/drivers/staging/greybus/greybus_firmware.h b/drivers/staging/greybus/greybus_firmware.h index b58281a63ba4..13ef3aa5279e 100644 --- a/drivers/staging/greybus/greybus_firmware.h +++ b/drivers/staging/greybus/greybus_firmware.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ /* * Greybus Firmware Management User Header * diff --git a/drivers/staging/greybus/greybus_manifest.h b/drivers/staging/greybus/greybus_manifest.h index 2cec5cf7a846..db68f7e7d5a7 100644 --- a/drivers/staging/greybus/greybus_manifest.h +++ b/drivers/staging/greybus/greybus_manifest.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus manifest definition * diff --git a/drivers/staging/greybus/greybus_protocols.h b/drivers/staging/greybus/greybus_protocols.h index ddc73f10eb22..7d649a7fc4c9 100644 --- a/drivers/staging/greybus/greybus_protocols.h +++ b/drivers/staging/greybus/greybus_protocols.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ /* * This file is provided under a dual BSD/GPLv2 license. When using or * redistributing this file, you may do so under either license. diff --git a/drivers/staging/greybus/greybus_trace.h b/drivers/staging/greybus/greybus_trace.h index 7b5e2c6b1f6b..1bc9f1275c65 100644 --- a/drivers/staging/greybus/greybus_trace.h +++ b/drivers/staging/greybus/greybus_trace.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * Greybus driver and device API * diff --git a/drivers/staging/greybus/hd.h b/drivers/staging/greybus/hd.h index 6cf024a20a58..348b76fabc9a 100644 --- a/drivers/staging/greybus/hd.h +++ b/drivers/staging/greybus/hd.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/*
[PATCH 4/9] staging: greybus: manifest: Fix up some alignment checkpatch issues
Some function prototypes do not match the expected alignment formatting
so fix that up so that checkpatch is happy.
Cc: Johan Hovold
Cc: Alex Elder
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/manifest.c | 39 +++---
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/greybus/manifest.c
b/drivers/staging/greybus/manifest.c
index 08db49264f2b..4ebbba52b07c 100644
--- a/drivers/staging/greybus/manifest.c
+++ b/drivers/staging/greybus/manifest.c
@@ -104,15 +104,15 @@ static int identify_descriptor(struct gb_interface *intf,
size_t expected_size;
if (size < sizeof(*desc_header)) {
- dev_err(>dev, "manifest too small (%zu < %zu)\n",
- size, sizeof(*desc_header));
+ dev_err(>dev, "manifest too small (%zu < %zu)\n", size,
+ sizeof(*desc_header));
return -EINVAL; /* Must at least have header */
}
desc_size = le16_to_cpu(desc_header->size);
if (desc_size > size) {
dev_err(>dev, "descriptor too big (%zu > %zu)\n",
- desc_size, size);
+ desc_size, size);
return -EINVAL;
}
@@ -139,22 +139,22 @@ static int identify_descriptor(struct gb_interface *intf,
case GREYBUS_TYPE_INVALID:
default:
dev_err(>dev, "invalid descriptor type (%u)\n",
- desc_header->type);
+ desc_header->type);
return -EINVAL;
}
if (desc_size < expected_size) {
dev_err(>dev, "%s descriptor too small (%zu < %zu)\n",
- get_descriptor_type_string(desc_header->type),
- desc_size, expected_size);
+ get_descriptor_type_string(desc_header->type),
+ desc_size, expected_size);
return -EINVAL;
}
/* Descriptor bigger than what we expect */
if (desc_size > expected_size) {
dev_warn(>dev, "%s descriptor size mismatch (want %zu got
%zu)\n",
- get_descriptor_type_string(desc_header->type),
- expected_size, desc_size);
+get_descriptor_type_string(desc_header->type),
+expected_size, desc_size);
}
descriptor = kzalloc(sizeof(*descriptor), GFP_KERNEL);
@@ -208,7 +208,7 @@ static char *gb_string_get(struct gb_interface *intf, u8
string_id)
/* Allocate an extra byte so we can guarantee it's NUL-terminated */
string = kmemdup(_string->string, desc_string->length + 1,
- GFP_KERNEL);
+GFP_KERNEL);
if (!string)
return ERR_PTR(-ENOMEM);
string[desc_string->length] = '\0';
@@ -264,8 +264,7 @@ static u32 gb_manifest_parse_cports(struct gb_bundle
*bundle)
desc_cport = tmp->data;
if (cport_id == le16_to_cpu(desc_cport->id)) {
dev_err(>dev,
- "duplicate CPort %u found\n",
- cport_id);
+ "duplicate CPort %u found\n", cport_id);
goto exit;
}
}
@@ -277,7 +276,7 @@ static u32 gb_manifest_parse_cports(struct gb_bundle
*bundle)
return 0;
bundle->cport_desc = kcalloc(count, sizeof(*bundle->cport_desc),
- GFP_KERNEL);
+GFP_KERNEL);
if (!bundle->cport_desc)
goto exit;
@@ -287,7 +286,7 @@ static u32 gb_manifest_parse_cports(struct gb_bundle
*bundle)
list_for_each_entry_safe(desc, next, , links) {
desc_cport = desc->data;
memcpy(>cport_desc[i++], desc_cport,
- sizeof(*desc_cport));
+ sizeof(*desc_cport));
/* Release the cport descriptor */
release_manifest_descriptor(desc);
@@ -333,9 +332,9 @@ static u32 gb_manifest_parse_bundles(struct gb_interface
*intf)
/* Ignore any legacy control bundles */
if (bundle_id == GB_CONTROL_BUNDLE_ID) {
dev_dbg(>dev, "%s - ignoring control bundle\n",
- __func__);
+ __func__);
release_cport_descriptors(>manifest_descs,
- bundle_id);
+ bundle_id);
continue;
Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
On 2019/08/25 5:22, Ingo Molnar wrote:
>> So I'd be willing to try that (and then if somebody reports a
>> regression we can make it use "fatal_signal_pending()" instead)
>
> Ok, will post a changelogged patch (unless Tetsuo beats me to it?).
Here is a patch. This patch also tries to fix handling of return code when
partial read/write happened (because we should return bytes processed when
we return due to -EINTR). But asymmetric between read function and write
function looks messy. Maybe we should just make /dev/{mem,kmem} killable
for now, and defer making /dev/{mem,kmem} interruptible till rewrite of
read/write functions.
drivers/char/mem.c | 89 ++
1 file changed, 50 insertions(+), 39 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index cb8e653..3c6a3c2 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -108,7 +108,7 @@ static ssize_t read_mem(struct file *file, char __user *buf,
ssize_t read, sz;
void *ptr;
char *bounce;
- int err;
+ int err = 0;
if (p != *ppos)
return 0;
@@ -132,8 +132,10 @@ static ssize_t read_mem(struct file *file, char __user
*buf,
#endif
bounce = kmalloc(PAGE_SIZE, GFP_KERNEL);
- if (!bounce)
- return -ENOMEM;
+ if (!bounce) {
+ err = -ENOMEM;
+ goto failed;
+ }
while (count > 0) {
unsigned long remaining;
@@ -142,7 +144,7 @@ static ssize_t read_mem(struct file *file, char __user *buf,
sz = size_inside_page(p, count);
cond_resched();
err = -EINTR;
- if (fatal_signal_pending(current))
+ if (signal_pending(current))
goto failed;
err = -EPERM;
@@ -180,14 +182,11 @@ static ssize_t read_mem(struct file *file, char __user
*buf,
count -= sz;
read += sz;
}
+failed:
kfree(bounce);
*ppos += read;
- return read;
-
-failed:
- kfree(bounce);
- return err;
+ return read ? read : err;
}
static ssize_t write_mem(struct file *file, const char __user *buf,
@@ -197,6 +196,7 @@ static ssize_t write_mem(struct file *file, const char
__user *buf,
ssize_t written, sz;
unsigned long copied;
void *ptr;
+ int err = 0;
if (p != *ppos)
return -EFBIG;
@@ -223,13 +223,16 @@ static ssize_t write_mem(struct file *file, const char
__user *buf,
sz = size_inside_page(p, count);
cond_resched();
- if (fatal_signal_pending(current))
- return -EINTR;
+ err = -EINTR;
+ if (signal_pending(current))
+ break;
+ err = -EPERM;
allowed = page_is_allowed(p >> PAGE_SHIFT);
if (!allowed)
- return -EPERM;
+ break;
+ err = -EFAULT;
/* Skip actual writing when a page is marked as restricted. */
if (allowed == 1) {
/*
@@ -238,19 +241,14 @@ static ssize_t write_mem(struct file *file, const char
__user *buf,
* by the kernel or data corruption may occur.
*/
ptr = xlate_dev_mem_ptr(p);
- if (!ptr) {
- if (written)
- break;
- return -EFAULT;
- }
+ if (!ptr)
+ break;
copied = copy_from_user(ptr, buf, sz);
unxlate_dev_mem_ptr(p, ptr);
if (copied) {
written += sz - copied;
- if (written)
- break;
- return -EFAULT;
+ break;
}
}
@@ -261,7 +259,7 @@ static ssize_t write_mem(struct file *file, const char
__user *buf,
}
*ppos += written;
- return written;
+ return written ? written : err;
}
int __weak phys_mem_access_prot_allowed(struct file *file,
@@ -459,8 +457,10 @@ static ssize_t read_kmem(struct file *file, char __user
*buf,
while (low_count > 0) {
sz = size_inside_page(p, low_count);
cond_resched();
- if (fatal_signal_pending(current))
- return -EINTR;
+ if (signal_pending(current)) {
+ err = -EINTR;
+ goto failed;
+ }
/*
*
[PATCH v2] pcmcia/i82092: Refactored dprintk macro for dev_dbg().
As suggested in https://kernelnewbies.org/KernelJanitors/Todo
this patch replaces the outdated macro of DPRINTK for dev_dbg()
To: Dominik Brodowski
To: Thomas Gleixner
To: Greg Kroah-Hartman
To: Adam Zerella
To: linux-kernel@vger.kernel.org
Signed-off-by: Adam Zerella
---
Changes in v2:
- Swap pr_debug() for dev_dbg()
- Clarify commit summary message
drivers/pcmcia/i82092.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pcmcia/i82092.c b/drivers/pcmcia/i82092.c
index ec54a2aa5cb8..245d60189375 100644
--- a/drivers/pcmcia/i82092.c
+++ b/drivers/pcmcia/i82092.c
@@ -117,9 +117,9 @@ static int i82092aa_pci_probe(struct pci_dev *dev, const
struct pci_device_id *i
if (card_present(i)) {
sockets[i].card_state = 3;
- dprintk(KERN_DEBUG "i82092aa: slot %i is occupied\n",i);
+ dev_dbg(>dev, "i82092aa: slot %i is occupied\n",
i);
} else {
- dprintk(KERN_DEBUG "i82092aa: slot %i is vacant\n",i);
+ dev_dbg(>dev, "i82092aa: slot %i is vacant\n", i);
}
}
@@ -128,7 +128,7 @@ static int i82092aa_pci_probe(struct pci_dev *dev, const
struct pci_device_id *i
pci_write_config_byte(dev, 0x50, configbyte); /* PCI Interrupt Routing
Register */
/* Register the interrupt handler */
- dprintk(KERN_DEBUG "Requesting interrupt %i \n",dev->irq);
+ dev_dbg(>dev, "Requesting interrupt %i\n", dev->irq);
if ((ret = request_irq(dev->irq, i82092aa_interrupt, IRQF_SHARED,
"i82092aa", i82092aa_interrupt))) {
printk(KERN_ERR "i82092aa: Failed to register IRQ %d,
aborting\n", dev->irq);
goto err_out_free_res;
--
2.20.1
[PATCH 3/7] arm64: dts: meson-gxbb-wetek-hub: add rc-wetek-hub keymap
add the rc-wetek-hub keymap to the ir node
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
index 2bfe699..83b985b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -12,3 +12,7 @@
compatible = "wetek,hub", "amlogic,meson-gxbb";
model = "WeTek Hub";
};
+
+ {
+ linux,rc-map-name = "rc-wetek-hub";
+};
--
2.7.4
[PATCH 4/7] arm64: dts: meson-gxbb-wetek-play2: add rc-wetek-play2 keymap
add the rc-wetek-play2 keymap to the ir node
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
index 0038522..1d32d1f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -54,3 +54,7 @@
{
status = "okay";
};
+
+ {
+ linux,rc-map-name = "rc-wetek-play2";
+};
--
2.7.4
[PATCH 2/7] arm64: dts: meson-g12a-x96-max: add rc-x96max keymap
add the rc-x96max keymap to the ir node
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
index fe4013c..357d7dc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
@@ -277,6 +277,7 @@
status = "okay";
pinctrl-0 = <_input_ao_pins>;
pinctrl-names = "default";
+ linux,rc-map-name = "rc-x96max";
};
_mdio {
--
2.7.4
[PATCH 6/7] arm64: dts: meson-gxl-s905w-tx3-mini: add rc-tx3mini keymap
add the rc-tx3mini keymap to the ir node
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
index 789c819..dd729ac 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
@@ -20,3 +20,7 @@
reg = <0x0 0x0 0x0 0x4000>; /* 1 GiB or 2 GiB */
};
};
+
+ {
+ linux,rc-map-name = "rc-tanix-tx3mini";
+};
--
2.7.4
[PATCH 0/7] arm64: dts: meson: ir keymap updates
This series adds keymaps for several box/board vendor IR remote devices to respective device-tree files. The keymaps were submitted in [0] and have been queued for inclusion in Linux 5.4. The Khadas remote change swaps the rc-geekbox keymap for rc-khadas. The Geekbox branded remote was only sold for a brief period when VIM(1) was a new device. The Khadas branded remote that replaced it exchanged the Geekbox full-screen key for an Android mouse button using a different IR keycode. The rc-khadas keymap supports the mouse button keycode and maps it to KEY_MUTE. [0] https://patchwork.kernel.org/project/linux-media/list/?series=160309 Christian Hewitt (7): arm64: dts: meson-g12b-odroid-n2: add rc-odroid keymap arm64: dts: meson-g12a-x96-max: add rc-x96max keymap arm64: dts: meson-gxbb-wetek-hub: add rc-wetek-hub keymap arm64: dts: meson-gxbb-wetek-play2: add rc-wetek-play2 keymap arm64: dts: meson-gxl-s905x-khadas-vim: use rc-khadas keymap arm64: dts: meson-gxl-s905w-tx3-mini: add rc-tx3mini keymap arm64: dts: meson-gxm-khadas-vim2: use rc-khadas keymap arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 1 + arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 + arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 4 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 4 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts | 4 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 2 +- arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +- 7 files changed, 16 insertions(+), 2 deletions(-) -- 2.7.4
[PATCH 1/7] arm64: dts: meson-g12b-odroid-n2: add rc-odroid keymap
add the rc-odroid keymap to the ir node Signed-off-by: Christian Hewitt --- arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts index 81780ff..35cef76 100644 --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts @@ -314,6 +314,7 @@ status = "okay"; pinctrl-0 = <_input_ao_pins>; pinctrl-names = "default"; + linux,rc-map-name = "rc-odroid"; }; /* SD card */ -- 2.7.4
[PATCH 5/7] arm64: dts: meson-gxl-s905x-khadas-vim: use rc-khadas keymap
Swap to the rc-khadas keymap that maps the mouse button to KEY_MUTE.
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
index 5499e8d..2a5cd30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
@@ -110,7 +110,7 @@
};
{
- linux,rc-map-name = "rc-geekbox";
+ linux,rc-map-name = "rc-khadas";
};
_ao {
--
2.7.4
[PATCH 7/7] arm64: dts: meson-gxm-khadas-vim2: use rc-khadas keymap
Swap to the rc-khadas keymap that maps the mouse button to KEY_MUTE.
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index 989d33a..f25ddd1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -299,7 +299,7 @@
status = "okay";
pinctrl-0 = <_input_ao_pins>;
pinctrl-names = "default";
- linux,rc-map-name = "rc-geekbox";
+ linux,rc-map-name = "rc-khadas";
};
_AO_ab {
--
2.7.4
Re: [PATCH] ext4: change the type of ext4 cache stats to percpu_counter to improve performance
On Fri, Aug 23, 2019 at 10:47:34AM +0800, Shaokun Zhang wrote: > From: Yang Guo > > @es_stats_cache_hits and @es_stats_cache_misses are accessed frequently in > ext4_es_lookup_extent function, it would influence the ext4 read/write > performance in NUMA system. > Let's optimize it using percpu_counter, it is profitable for the > performance. > > The test command is as below: > fio -name=randwrite -numjobs=8 -filename=/mnt/test1 -rw=randwrite > -ioengine=libaio -direct=1 -iodepth=64 -sync=0 -norandommap -group_reporting > -runtime=120 -time_based -bs=4k -size=5G > > And the result is better 10% than the initial implement: > without the patch，IOPS=197k, BW=770MiB/s (808MB/s)(90.3GiB/120002msec) > with the patch, IOPS=218k, BW=852MiB/s (894MB/s)(99.9GiB/120002msec) > > Cc: "Theodore Ts'o" > Cc: Andreas Dilger > Signed-off-by: Yang Guo > Signed-off-by: Shaokun Zhang Applied with some adjustments so it would apply. I also changed the patch summary to: ext4: use percpu_counters for extent_status cache hits/misses - Ted
RE: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
> -Original Message-
> From: christophe leroy
> Sent: 2019年8月24日 14:45
> To: Xiaowei Bao ; Andrew Murray
>
> Cc: mark.rutl...@arm.com; Roy Zang ;
> lorenzo.pieral...@arm.co; a...@arndb.de; devicet...@vger.kernel.org;
> gre...@linuxfoundation.org; linuxppc-...@lists.ozlabs.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; kis...@ti.com; M.h.
> Lian ; robh...@kernel.org;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com;
> bhelg...@google.com; Leo Li ; shawn...@kernel.org;
> Mingkai Hu ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
>
>
> Le 24/08/2019 à 02:18, Xiaowei Bao a écrit :
> >
> >
> >> -Original Message-
> >> From: Andrew Murray
> >> Sent: 2019年8月23日 22:28
> >> To: Xiaowei Bao
> >> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> >> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> >> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org;
> M.h.
> >> Lian ; Mingkai Hu ; Roy
> >> Zang ; jingooh...@gmail.com;
> >> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> >> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org
> >> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> >> for ls1088a and ls2088a
> >>
> >> On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> >>> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> >>> difference between LS1 and LS2 platform, so refactor the code of the
> >>> EP driver.
> >>>
> >>> Signed-off-by: Xiaowei Bao
> >>> ---
> >>> v2:
> >>> - New mechanism for layerscape EP driver.
> >>
> >> Was there a v1 of this patch?
> >
> > Yes, but I don't know how to comments, ^_^
>
> As far as I can see, in the previous version of the series
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Flinuxppc-dev%2Flist%2F%3Fseries%3D125315
> %26state%3D*data=02%7C01%7Cxiaowei.bao%40nxp.com%7C1befe9
> a67c8046f9535e08d7285eaab6%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C637022259387139020sdata=p4wbycd04Z7qRUfAoZtwc
> UP7pR%2FuA3%2FjVcWMz6YyQVQ%3Dreserved=0),
> the 8/10 was something completely different, and I can't find any other patch
> in the series that could have been the v1 of this patch.
Thanks, I will correct it to v1 in next version patch.
>
> Christophe
>
> >
> >>
> >>>
> >>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> >>> --
> >>> 1 file changed, 58 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> >>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> >>> index 7ca5fe8..2a66f07 100644
> >>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> >>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> >>> @@ -20,27 +20,29 @@
> >>>
> >>> #define PCIE_DBI2_OFFSET0x1000 /* DBI2 base address*/
> >>>
> >>> -struct ls_pcie_ep {
> >>> - struct dw_pcie *pci;
> >>> - struct pci_epc_features *ls_epc;
> >>> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> >>> +
> >>> +struct ls_pcie_ep_drvdata {
> >>> + u32 func_offset;
> >>> + const struct dw_pcie_ep_ops *ops;
> >>> + const struct dw_pcie_ops*dw_pcie_ops;
> >>> };
> >>>
> >>> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> >>> +struct ls_pcie_ep {
> >>> + struct dw_pcie *pci;
> >>> + struct pci_epc_features *ls_epc;
> >>> + const struct ls_pcie_ep_drvdata *drvdata; };
> >>>
> >>> static int ls_pcie_establish_link(struct dw_pcie *pci) {
> >>> return 0;
> >>> }
> >>>
> >>> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> >>> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> >>> .start_link = ls_pcie_establish_link, };
> >>>
> >>> -static const struct of_device_id ls_pcie_ep_of_match[] = {
> >>> - { .compatible = "fsl,ls-pcie-ep",},
> >>> - { },
> >>> -};
> >>> -
> >>> static const struct pci_epc_features*
> >>> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10 +84,44
> >>> @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> >>> }
> >>> }
> >>>
> >>> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> >>> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> >>> + u8 func_no)
> >>> +{
> >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> >>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> >>> + u8 header_type;
> >>> +
> >>> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> >>> +
> >>> + if (header_type & (1 << 7))
> >>> + return pcie->drvdata->func_offset * func_no;
> >>> + else
> >>> + return 0;
> >>
> >> It looks like there isn't a PCI define for multi function, the
> >> nearest I could find was
Re: dataring_push() barriers Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
On 2019-08-20, Petr Mladek wrote:
>> +/**
>> + * dataring_push() - Reserve a data block in the data array.
>> + *
>> + * @dr: The data ringbuffer to reserve data in.
>> + *
>> + * @size: The size to reserve.
>> + *
>> + * @desc: A pointer to a descriptor to store the data block information.
>> + *
>> + * @id: The ID of the descriptor to be associated.
>> + *The data block will not be set with @id, but rather initialized
>> with
>> + *a value that is explicitly different than @id. This is to handle
>> the
>> + *case when newly available garbage by chance matches the descriptor
>> + *ID.
>> + *
>> + * This function expects to move the head pointer forward. If this would
>> + * result in overtaking the data array index of the tail, the tail data
>> block
>> + * will be invalidated.
>> + *
>> + * Return: A pointer to the reserved writer data, otherwise NULL.
>> + *
>> + * This will only fail if it was not possible to invalidate the tail data
>> + * block.
>> + */
>> +char *dataring_push(struct dataring *dr, unsigned int size,
>> +struct dr_desc *desc, unsigned long id)
>> +{
>> +unsigned long begin_lpos;
>> +unsigned long next_lpos;
>> +struct dr_datablock *db;
>> +bool ret;
>> +
>> +to_db_size();
>> +
>> +do {
>> +/* fA: */
>> +ret = get_new_lpos(dr, size, _lpos, _lpos);
>> +
>> +/*
>> + * fB:
>> + *
>> + * The data ringbuffer tail may have been pushed (by this or
>> + * any other task). The updated @tail_lpos must be visible to
>> + * all observers before changes to @begin_lpos, @next_lpos, or
>> + * @head_lpos by this task are visible in order to allow other
>> + * tasks to recognize the invalidation of the data
>> + * blocks.
>
> This sounds strange. The write barrier should be done only on CPU
> that really modified tail_lpos. I.e. it should be in _dataring_pop()
> after successful dr->tail_lpos modification.
The problem is that there are no data dependencies between the different
variables. When a new datablock is being reserved, it is critical that
all other observers see that the tail_lpos moved forward _before_ any
other changes. _dataring_pop() uses an smp_rmb() to synchronize for
tail_lpos movement. This CPU is about to make some changes and may have
seen an updated tail_lpos. An smp_wmb() is useless if this is not the
CPU that performed that update. The full memory barrier ensures that all
other observers will see what this CPU sees before any of its future
changes are seen.
You suggest an alternative implementation below. I will address that
there.
>> + * This pairs with the smp_rmb() in _dataring_pop() as well as
>> + * any reader task using smp_rmb() to post-validate data that
>> + * has been read from a data block.
>> +
>> + * Memory barrier involvement:
>> + *
>> + * If dE reads from fE, then dI reads from fA->eA.
>> + * If dC reads from fG, then dI reads from fA->eA.
>> + * If dD reads from fH, then dI reads from fA->eA.
>> + * If mC reads from fH, then mF reads from fA->eA.
>> + *
>> + * Relies on:
>> + *
>> + * FULL MB between fA->eA and fE
>> + *matching
>> + * RMB between dE and dI
>> + *
>> + * FULL MB between fA->eA and fG
>> + *matching
>> + * RMB between dC and dI
>> + *
>> + * FULL MB between fA->eA and fH
>> + *matching
>> + * RMB between dD and dI
>> + *
>> + * FULL MB between fA->eA and fH
>> + *matching
>> + * RMB between mC and mF
>> + */
>> +smp_mb();
>
> All these comments talk about sychronization against read barriers.
> It means that we would need a write barrier here. But it does
> not make much sense to do write barrier before actually
> writing dr->head_lpos.
I think my comments above address this.
> After all I think that we do not need any barrier here.
> The write barrier for dr->tail_lpos should be in
> _dataring_pop(). The read barrier is not needed because
> we are not reading anything here.
>
> Instead we should put a barrier after modyfying dr->head_lpos,
> see below.
Comments below.
>> +if (!ret) {
>> +/*
>> + * Force @desc permanently invalid to minimize risk
>> + * of the descriptor later unexpectedly being
>> + * determined as valid due to overflowing/wrapping of
>> + * @head_lpos. An unaligned @begin_lpos can never
>> + * point to a data block and having the same value
>> + * for @begin_lpos and @next_lpos is also invalid.
>> +
Re: [PATCH v2 -next] soundwire: Fix -Wunused-function warning
Hi YueHaibing, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20190823] url: https://github.com/0day-ci/linux/commits/YueHaibing/soundwire-Fix-Wunused-function-warning/20190825-083159 config: x86_64-randconfig-g004-201934 (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "sdw_acpi_find_slaves" [drivers/soundwire/soundwire-bus.ko] undefined! WARNING: "ftrace_set_clr_event" [vmlinux] is a static EXPORT_SYMBOL_GPL --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: assign_desc() barriers: Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
On 2019-08-22, Petr Mladek wrote:
> --- /dev/null
> +++ b/kernel/printk/ringbuffer.c
> +/**
> + * assign_desc() - Assign a descriptor to the caller.
> + *
> + * @e: The entry structure to store the assigned descriptor to.
> + *
> + * Find an available descriptor to assign to the caller. First it is
> checked
> + * if the tail descriptor from the committed list can be recycled. If
> not,
> + * perhaps a never-used descriptor is available. Otherwise, data blocks
> will
> + * be invalidated until the tail descriptor from the committed list can
> be
> + * recycled.
> + *
> + * Assigned descriptors are invalid until data has been reserved for
> them.
> + *
> + * Return: true if a descriptor was assigned, otherwise false.
> + *
> + * This will only fail if it was not possible to invalidate data blocks
> in
> + * order to recycle a descriptor. This can happen if a writer has
> reserved but
> + * not yet committed data and that reserved data is currently the oldest
> data.
> + */
> +static bool assign_desc(struct prb_reserved_entry *e)
> +{
> + struct printk_ringbuffer *rb = e->rb;
> + struct prb_desc *d;
> + struct nl_node *n;
> + unsigned long i;
> +
> + for (;;) {
> + /*
> + * jA:
> + *
> + * Try to recycle a descriptor on the committed list.
> + */
> + n = numlist_pop(>nl);
> + if (n) {
> + d = container_of(n, struct prb_desc, list);
> + break;
> + }
> +
> + /* Fallback to static never-used descriptors. */
> + if (atomic_read(>desc_next_unused) < DESCS_COUNT(rb)) {
> + i = atomic_fetch_inc(>desc_next_unused);
> + if (i < DESCS_COUNT(rb)) {
> + d = >descs[i];
> + atomic_long_set(>id, i);
> + break;
> + }
> + }
> +
> + /*
> + * No descriptor available. Make one available for recycling
> + * by invalidating data (which some descriptor will be
> + * referencing).
> + */
> + if (!dataring_pop(>dr))
> + return false;
> + }
> +
> + /*
> + * jB:
> + *
> + * Modify the descriptor ID so that users of the descriptor see that
> + * it has been recycled. A _release() is used so that prb_getdesc()
> + * callers can see all data ringbuffer updates after issuing a
> + * pairing smb_rmb(). See iA for details.
> + *
> + * Memory barrier involvement:
> + *
> + * If dB->iA reads from jB, then dI reads the same value as
> + * jA->cD->hA.
> + *
> + * Relies on:
> + *
> + * RELEASE from jA->cD->hA to jB
> + *matching
> + * RMB between dB->iA and dI
> + */
> + atomic_long_set_release(>id, atomic_long_read(>id) +
> + DESCS_COUNT(rb));
atomic_long_set_release() might be a bit confusing here.
There is no related acquire.
>>
>> As the comment states, this release is for prb_getdesc() users. The
>> only prb_getdesc() user is _dataring_pop(). (i.e. the descriptor's
>> ID is not what _dataring_pop() was expecting), then the tail must
>> have moved and _dataring_pop() needs to see that. Since there are no
>> data dependencies between descriptor ID and tail_pos, an explicit
>> memory barrier is used. More on this below.
After reading through your post, I think you are pairing the wrong
barriers together. jB pairs with dH (i.e. the set_release() in
assign_desc() pairs with the smp_rmb() in _dataring_pop()).
(The comment for jB wrongly says dI instead of dH! Argh!)
> OK, let me show how complicated and confusing this looks for me:
I want to address all your points here. _Not_ because I want to justify
or defend my insanity, but because it may help to provide some clarity.
> + The two related barriers are in different source files
> and APIs:
>
>+ assign_desc() in ringbuffer.c; ringbuffer API
>+ _dataring_pop in dataring.c; dataring API
Agreed. This is a consequence of the ID management being within the
high-level ringbuffer code. I could have added an smp_rmb() to the NULL
case in prb_getdesc(). Then both barriers would be in the same
file. However, this would mean smp_rmb() is called many times
(particularly by readers) when it is not necessary.
> + Both the related barriers are around "id" manipulation.
> But one is in dataring, other is in descriptors array.
> One is about an old released "id". One is about a newly
> assigned "id".
dB is not the pairing barrier of jB. As dB's comment says, it pairs with
gA. (The load_acquire(id) in _dataring_pop() pairs with the
Re: [PATCH] .gitignore: ignore modules.order explicitly
On Mon, Aug 19, 2019 at 1:18 PM Masahiro Yamada
wrote:
>
> The pattern '*.order' was added by commit c6025f4c8bbe ("kbuild: ignore
> *.order files") to ignore modules.order files.
>
> I do not see any other user of the '.order' extension.
>
> Ignore 'modules.order' explicitly instead of '*.order'.
>
> Signed-off-by: Masahiro Yamada
Applied to linux-kbuild.
> ---
>
> .gitignore | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.gitignore b/.gitignore
> index 2030c7a4d2f8..ce2c6348d372 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -34,7 +34,6 @@
> *.mod.c
> *.o
> *.o.*
> -*.order
> *.patch
> *.s
> *.so
> @@ -46,6 +45,7 @@
> *.xz
> Module.symvers
> modules.builtin
> +modules.order
>
> #
> # Top-level generic files
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
[PATCH 2/2] kbuild: remove unneeded '+' marker from cmd_clean
This '+' was added a long time ago: | commit c23e6bf05f7802e92fd3da69a1ed35e56f9c85bb (HEAD) | Author: Kai Germaschewski | Date: Mon Oct 28 01:16:34 2002 -0600 | | kbuild: Fix a "make -j" warning | | diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean | index 2c843e0380bc..e7c392fd5788 100644 | --- a/scripts/Makefile.clean | +++ b/scripts/Makefile.clean | @@ -42,7 +42,7 @@ quiet_cmd_clean = CLEAN $(obj) | | __clean: $(subdir-ymn) | ifneq ($(strip $(__clean-files) $(clean-rule)),) | -$(call cmd,clean) | ++$(call cmd,clean) | else | @: | endif At that time, cmd_clean contained $(clean-rule), which was able to invoke sub-make. That was why cleaning with the -j option showed: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. It is not the case any more. cmd_clean now just runs the 'rm' command. The '+' marker is pointless. Signed-off-by: Masahiro Yamada --- scripts/Makefile.clean | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index cbfbe13dc87d..fc38a34128d4 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -59,7 +59,7 @@ quiet_cmd_clean = CLEAN $(obj) __clean: $(subdir-ymn) ifneq ($(strip $(__clean-files)),) - +$(call cmd,clean) + $(call cmd,clean) endif @: -- 2.17.1
[PATCH] kbuild: clean up subdir-ymn calculation in Makefile.clean
Remove some variables. Signed-off-by: Masahiro Yamada --- scripts/Makefile.clean | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index fc38a34128d4..e367eb95c5c0 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -17,17 +17,8 @@ include $(if $(wildcard $(kbuild-dir)/Kbuild), $(kbuild-dir)/Kbuild, $(kbuild-di # Figure out what we need to build from the various variables # == -__subdir-y := $(patsubst %/,%,$(filter %/, $(obj-y))) -subdir-y += $(__subdir-y) -__subdir-m := $(patsubst %/,%,$(filter %/, $(obj-m))) -subdir-m += $(__subdir-m) -__subdir- := $(patsubst %/,%,$(filter %/, $(obj-))) -subdir-+= $(__subdir-) - -# Subdirectories we need to descend into - -subdir-ym := $(sort $(subdir-y) $(subdir-m)) -subdir-ymn := $(sort $(subdir-ym) $(subdir-)) +subdir-ymn := $(sort $(subdir-y) $(subdir-m) $(subdir-) \ + $(patsubst %/,%, $(filter %/, $(obj-y) $(obj-m) $(obj- # Add subdir path -- 2.17.1
[PATCH 1/2] kbuild: remove clean-dirs syntax
The only the difference between clean-files and clean-dirs is the -r option passed to the 'rm' command. You can always pass -r, and then remove the clean-dirs syntax. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 16 scripts/Makefile.clean | 16 ++-- scripts/kconfig/Makefile | 2 +- usr/include/Makefile | 4 +--- 4 files changed, 8 insertions(+), 30 deletions(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 68ed20ef37dd..78aa51a6fcd4 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -765,7 +765,8 @@ Files matching the patterns "*.[oas]", "*.ko", plus some additional files generated by kbuild are deleted all over the kernel src tree when "make clean" is executed. -Additional files can be specified in kbuild makefiles by use of $(clean-files). +Additional files or directories can be specified in kbuild makefiles by use of +$(clean-files). Example:: @@ -776,17 +777,8 @@ When executing "make clean", the file "crc32table.h" will be deleted. Kbuild will assume files to be in the same relative directory as the Makefile, except if prefixed with $(objtree). -To delete a directory hierarchy use: - - Example:: - - #scripts/package/Makefile - clean-dirs := $(objtree)/debian/ - -This will delete the directory debian in the toplevel directory, including all -subdirectories. - -To exclude certain files from make clean, use the $(no-clean-files) variable. +To exclude certain files or directories from make clean, use the +$(no-clean-files) variable. Usually kbuild descends down in subdirectories due to "obj-* := dir/", but in the architecture makefiles where the kbuild infrastructure diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index 0b80e3207b20..cbfbe13dc87d 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -52,26 +52,14 @@ __clean-files := $(wildcard \ $(addprefix $(obj)/, $(filter-out $(objtree)/%, $(__clean-files))) \ $(filter $(objtree)/%, $(__clean-files))) -# same as clean-files - -__clean-dirs:= $(wildcard \ - $(addprefix $(obj)/, $(filter-out $(objtree)/%, $(clean-dirs)))\ - $(filter $(objtree)/%, $(clean-dirs))) - # == -quiet_cmd_clean= CLEAN $(obj) - cmd_clean= rm -f $(__clean-files) -quiet_cmd_cleandir = CLEAN $(__clean-dirs) - cmd_cleandir = rm -rf $(__clean-dirs) - +quiet_cmd_clean = CLEAN $(obj) + cmd_clean = rm -rf $(__clean-files) __clean: $(subdir-ymn) ifneq ($(strip $(__clean-files)),) +$(call cmd,clean) -endif -ifneq ($(strip $(__clean-dirs)),) - +$(call cmd,cleandir) endif @: diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 7656e1137b6b..bed7a5a2fbe9 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -114,7 +114,7 @@ testconfig: $(obj)/conf $(PYTHON3) -B -m pytest $(srctree)/$(src)/tests \ -o cache_dir=$(abspath $(obj)/tests/.cache) \ $(if $(findstring 1,$(KBUILD_VERBOSE)),--capture=no) -clean-dirs += tests/.cache +clean-files += tests/.cache # Help text used by make help help: diff --git a/usr/include/Makefile b/usr/include/Makefile index 1fb6abe29b2f..05c71ef42f51 100644 --- a/usr/include/Makefile +++ b/usr/include/Makefile @@ -115,6 +115,4 @@ header-test-y += $(filter-out $(header-test-), \ $(patsubst $(obj)/%,%, $(wildcard \ $(addprefix $(obj)/, *.h */*.h */*/*.h */*/*/*.h -# For GNU Make <= 4.2.1, $(wildcard $(obj)/*/) matches to not only directories -# but also regular files. Use $(filter %/, ...) just in case. -clean-dirs += $(patsubst $(obj)/%/,%,$(filter %/, $(wildcard $(obj)/*/))) +clean-files += $(filter-out Makefile, $(notdir $(wildcard $(obj)/*))) -- 2.17.1
[PATCH] lib/rbtree: set successor's parent unconditionally
Both in Case 2 and 3, we exchange n and s. This mean no matter whether
child2 is NULL or not, successor's parent should be assigned to node's.
This patch takes this step out to make it explicit and reduce the
ambiguity.
Besides, this step reduces some symbol size like rb_erase().
KERN_CONFIG upstream patched
OPT_FOR_PERF 877870
OPT_FOR_SIZE 635621
Signed-off-by: Wei Yang
---
include/linux/rbtree_augmented.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index 179faab29f52..8fcddfef7876 100644
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -237,14 +237,13 @@ __rb_erase_augmented(struct rb_node *node, struct rb_root
*root,
__rb_change_child(node, successor, tmp, root);
if (child2) {
- successor->__rb_parent_color = pc;
rb_set_parent_color(child2, parent, RB_BLACK);
rebalance = NULL;
} else {
unsigned long pc2 = successor->__rb_parent_color;
- successor->__rb_parent_color = pc;
rebalance = __rb_is_black(pc2) ? parent : NULL;
}
+ successor->__rb_parent_color = pc;
tmp = successor;
}
--
2.17.1
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On 8/24/19 11:01 AM, shuah wrote: On 8/24/19 9:33 AM, Greg KH wrote: On Sat, Aug 24, 2019 at 09:21:53AM -0600, shuah wrote: On 8/23/19 8:38 PM, Greg KH wrote: On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: On 8/22/19 11:05 AM, Sasha Levin wrote: This is the start of the stable review cycle for the 5.2.10 release. There are 135 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 24 Aug 2019 05:07:10 PM UTC. 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-5.2.10-rc1.gz I am seeing "Sorry I can't find your kernels". Is this posted? Ah, Sasha didn't generate the patch but it was still listed here, oops. He copied my format and we didn't notice this, sorry about that. As the thread shows, we didn't generate this file this time to see what would happen. If your test process requires it, we can generate it as I don't want to break it. It will make it lot easier for me to have continued support for patch generation. My scripts do "wget" to pull the patch and apply. Ok, we will get this back and working, sorry about that. Great. Thanks for accommodating my workflow. Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH] [PATCH v3] sock: fix potential memory leak in proto_register()
From: zhanglin Date: Fri, 23 Aug 2019 09:14:11 +0800 > If protocols registered exceeded PROTO_INUSE_NR, prot will be > added to proto_list, but no available bit left for prot in > proto_inuse_idx. > > Changes since v2: > * Propagate the error code properly > > Signed-off-by: zhanglin Applied.
Re: [PATCH net-next] net: hns3: Fix -Wunused-const-variable warning
From: YueHaibing Date: Thu, 22 Aug 2019 22:49:37 +0800 > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:542:30: > warning: meta_data_key_info defined but not used [-Wunused-const-variable=] > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:553:30: > warning: tuple_key_info defined but not used [-Wunused-const-variable=] > > The two variable is only used in hclge_main.c, > so just move the definition over there. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Applied, thanks.
mmotm 2019-08-24-16-02 uploaded
The mm-of-the-moment snapshot 2019-08-24-16-02 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 5.3-rc5: (patches marked "*" will be included in linux-next) origin.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * mm-z3foldc-fix-race-between-migration-and-destruction.patch * mm-page_alloc-move_freepages-should-not-examine-struct-page-of-reserved-memory.patch * parisc-fix-compilation-errrors.patch * mm-memcontrol-flush-percpu-vmstats-before-releasing-memcg.patch * mm-memcontrol-flush-percpu-vmevents-before-releasing-memcg.patch * mm-memcontrol-flush-percpu-slab-vmstats-on-kmem-offlining.patch * psi-get-poll_work-to-run-when-calling-poll-syscall-next-time.patch * userfaultfd_release-always-remove-uffd-flags-and-clear-vm_userfaultfd_ctx.patch * mm-page_owner-handle-thp-splits-correctly.patch * mm-zsmallocc-migration-can-leave-pages-in-zs_empty-indefinitely.patch * mm-zsmallocc-fix-race-condition-in-zs_destroy_pool.patch * mm-kasan-fix-false-positive-invalid-free-reports-with-config_kasan_sw_tags=y.patch * partially-revert-mm-memcontrolc-keep-local-vm-counters-in-sync-with-the-hierarchical-ones.patch * kbuild-clean-compressed-initramfs-image.patch * ocfs2-use-jbd2_inode-dirty-range-scoping.patch * jbd2-remove-jbd2_journal_inode_add_.patch * ocfs-further-debugfs-cleanups.patch * ocfs-further-debugfs-cleanups-fix.patch * ocfs2-the-function-ocfs2_calc_tree_trunc_credits-is-not-used-anymore-so-as-to-be-removed.patch * ocfs2-the-function-ocfs2_orphan_scan_exit-is-declared-but-not-implemented-and-called-so-as-to-be-removed.patch * fs-ocfs2-nameic-remove-set-but-not-used-variables.patch * fs-ocfs2-filec-remove-set-but-not-used-variables.patch * fs-ocfs2-dirc-remove-set-but-not-used-variables.patch * ocfs2-clear-zero-in-unaligned-direct-io.patch * ocfs2-clear-zero-in-unaligned-direct-io-checkpatch-fixes.patch * ocfs2-wait-for-recovering-done-after-direct-unlock-request.patch * ocfs2-checkpoint-appending-truncate-log-transaction-before-flushing.patch * fs-ocfs2-fix-possible-null-pointer-dereferences-in-ocfs2_xa_prepare_entry.patch * fs-ocfs2-fix-possible-null-pointer-dereferences-in-ocfs2_xa_prepare_entry-fix.patch * fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_write_end_nolock.patch * fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_info_scan_inode_alloc.patch * ramfs-support-o_tmpfile.patch mm.patch * mm-slab-extend-slab-shrink-to-shrink-all-memcg-caches.patch * mm-slab-move-memcg_cache_params-structure-to-mm-slabh.patch * kmemleak-increase-debug_kmemleak_early_log_size-default-to-16k.patch * mm-kmemleak-make-the-tool-tolerant-to-struct-scan_area-allocation-failures.patch * mm-kmemleak-simple-memory-allocation-pool-for-kmemleak-objects.patch * mm-kmemleak-use-the-memory-pool-for-early-allocations.patch * mm-kmemleak-use-the-memory-pool-for-early-allocations-checkpatch-fixes.patch * mm-kmemleak-use-the-memory-pool-for-early-allocations-checkpatch-fixes-fix.patch * mm-kmemleak-record-the-current-memory-pool-size.patch * mm-kmemleak-increase-the-max-mem-pool-to-1m.patch * kasan-add-memory-corruption-identification-for-software-tag-based-mode.patch * lib-test_kasan-add-roundtrip-tests.patch * lib-test_kasan-add-roundtrip-tests-checkpatch-fixes.patch * mm-page_poison-fix-a-typo-in-a-comment.patch *
Re: cleanup the walk_page_range interface
On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > So what is the plan forward? Probably a little late for 5.3, > > so queue it up in -mm for 5.4 and deal with the conflicts in at least > > hmm? Queue it up in the hmm tree even if it doesn't 100% fit? > > Did we make a decision on this? Due to travel & LPC I'd like to > finalize the hmm tree next week. I don't think we've made any decision. I'd still love to see this in hmm.git. It has a minor conflict, but I can resend a rebased version.
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 11:36:26PM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a): > > Hello Jernej, > > > > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > > > Visually? > > > > > > > > That would explain why it doesn't work for you. The mainline RTC driver > > > > disables auto-switch feature, and if your board doesn't have a crystal > > > > for > > > > LOSC, RTC will not generate a clock for the RTC. > > > > > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > > > doesn't have the crystal. You need to fix this in the DTS for your board > > > > instead of patching the driver. > > > > > > I see that reparenting is supported, but I'm not sure how to fix that in > > > DT. Any suggestion? > > > > You may try removing the clocks property from rtc node. > > I don't think this would work: > https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246 Well, I don't know. There has to be some way to make it work, since the code deals with it here: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L270 Number of parents for LOSC is calculated from the DT somehow. Maybne something to do with the #clock-cells property? Sorry I can't be of more help here. > > > > > > The driver has parent clock selection logic in case the LOSC crystal is > > > > not > > > > used. > > > > > > > > Your patch enables automatic detection of LOSC failure and RTC changes > > > > clock to LOSC automatically, despite what's described in the DTS. That > > > > may fix the issue, but is not the correct solution. > > > > > > > > Registers on my board look like this (external 32k osc is used) for > > > > reference: > > > > > > > > LOSC_CTRL_REG[700]: 8011 > > > > > > > > KEY_FIELD ??? (0) > > > > LOSC_AUTO_SWT_BYPASS EN (1) > > > > LOSC_AUTO_SWT_EN DIS (0) > > > > EXT_LOSC_ENEN (1) > > > > EXT_LOSC_GSM LOW (0) > > > > BATTERY_DIRDISCHARGE(0) > > > > LOSC_SRC_SEL EXT32k (1) > > > > > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > > > > > > > EXT_LOSC_STA OK (0) > > > > LOSC_AUTO_SWT_PEND NOEFF(0) > > > > LOSC_SRC_SEL_STA EXT32K (1) > > > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > > > has value 0x4, so there is issue with external crystal (it's missing) and > > > RTC switched to internal one. > > > > > > BTW, what's wrong with automatic switching? Why is it disabled? > > > > It always was disabled on mainline (bit 14 was set to 0 even before my > > patch). H6 just probably has another extra undocummented bit, that's needed > > to disables it properly. > > > > You probably don't want a glitch to switch your RTC from high-precision > > clock to a low precision one possibly without any indication in the > > userspace or a kernel log. > > > > Regardless of all this, DTS needs to have a correct description of the HW, > > which means if RTC module is not connected to the 32.757kHz crystal/clock, > > clocks property should be empty. > > If we are talking about correct HW description, then clock property should > actually have possibility that two clocks are defined - one for internal RC > (always present) and one external crystal (optional). In such case I could > really just omit external clock and be done with it. But I'm not sure if such Internal RC is thought to be part of the RTC module, so it's not defined as an input clock to the RTC module. regards, Ondrej > > Best regards, > Jernej > > > > > regards, > > o. > > > > > Best regards, > > > Jernej > > > > > > > regards, > > > > > > > > o. > > > > > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b > > > > > > sp#n > > > > > > 650 > > > > > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > Jernej > > > > > > > > > > > regards, > > > > > > > > > > > > o. > > > >
Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
On 23 Aug 2019, at 23:03, Tim Froidcoeur wrote:
> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> triggers following stack trace:
>
> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
> [25244.888167] Call Trace:
> [25244.889182]
> [25244.890001] tcp_fragment+0x9c/0x2cf
> [25244.891295] tcp_write_xmit+0x68f/0x988
> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
> [25244.894347] tcp_data_snd_check+0x2a/0xc8
> [25244.895775] tcp_rcv_established+0x2a8/0x30d
> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
> [25244.898666] tcp_v4_rcv+0x692/0x956
> [25244.899959] ip_local_deliver_finish+0xeb/0x169
> [25244.901547] __netif_receive_skb_core+0x51c/0x582
> [25244.903193] ? inet_gro_receive+0x239/0x247
> [25244.904756] netif_receive_skb_internal+0xab/0xc6
> [25244.906395] napi_gro_receive+0x8a/0xc0
> [25244.907760] receive_buf+0x9a1/0x9cd
> [25244.909160] ? load_balance+0x17a/0x7b7
> [25244.910536] ? vring_unmap_one+0x18/0x61
> [25244.911932] ? detach_buf+0x60/0xfa
> [25244.913234] virtnet_poll+0x128/0x1e1
> [25244.914607] net_rx_action+0x12a/0x2b1
> [25244.915953] __do_softirq+0x11c/0x26b
> [25244.917269] ? handle_irq_event+0x44/0x56
> [25244.918695] irq_exit+0x61/0xa0
> [25244.919947] do_IRQ+0x9d/0xbb
> [25244.921065] common_interrupt+0x85/0x85
> [25244.922479]
>
> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
> tcp_write_queue_prev() on the first packet in the queue, which will trigger
> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>
> This happens when the retransmit queue is empty, for example in case of a
> zero window.
>
> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>
> Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> Change-Id: I839bde7167ae59e2f7d916c913507372445765c5
> Signed-off-by: Tim Froidcoeur
> Signed-off-by: Matthieu Baerts
> Reviewed-by: Christoph Paasch
Acked-by: Jonathan Lemon
Re: [GIT PULL] GPIO fixes for v5.3
The pull request you sent on Sat, 24 Aug 2019 23:17:54 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > tags/gpio-v5.3-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/083f0f2cd402df40f62e16b1e4208e6033f52aba Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On 8/24/19 12:14 PM, Greg KH wrote: On Sat, Aug 24, 2019 at 11:01:19AM -0600, shuah wrote: On 8/24/19 9:33 AM, Greg KH wrote: On Sat, Aug 24, 2019 at 09:21:53AM -0600, shuah wrote: On 8/23/19 8:38 PM, Greg KH wrote: On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: On 8/22/19 11:05 AM, Sasha Levin wrote: This is the start of the stable review cycle for the 5.2.10 release. There are 135 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 24 Aug 2019 05:07:10 PM UTC. 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-5.2.10-rc1.gz I am seeing "Sorry I can't find your kernels". Is this posted? Ah, Sasha didn't generate the patch but it was still listed here, oops. He copied my format and we didn't notice this, sorry about that. As the thread shows, we didn't generate this file this time to see what would happen. If your test process requires it, we can generate it as I don't want to break it. It will make it lot easier for me to have continued support for patch generation. My scripts do "wget" to pull the patch and apply. Ok, we will get this back and working, sorry about that. Great. Thanks for accommodating my workflow. I have uploaded it to kernel.org now, should show up on the "public side" in 15 minutes or so. Great. Downloaded successfully. thanks, -- Shuah
Re: CONGRATULATION ONCE AGAIN
-- Attention: This is to inform you that you have been selected to receive the 2019 United Nations Democracy Fund (UNDEF) of $250,000 (US Dollars). The selection process was carried out through The United Nations (UN) computerized email selection system (ESS), from a database of over 250,000 email addresses obtained from all continents of the world, which you were selected among to receive $250,000 (US Dollars). The United Nations Democracy Fund (UNDEF) was created by the former UN Secretary-General Kofi A. Annan in 2005 as a United Nations General Trust Fund to support democratization efforts and civil society organizations around the world. You are advice to contact The United Nations Democracy Fund (UNDEF) Grants Manager to claim your Cashier Check valued the sum of $250,000 (US Dollars). Name: Christine Maulhardt Email: c.maulhard...@yahoo.com Phone: +1 (708) 390-8956 Contact her by providing her with the under listed information as soon as possible. 1. Name In Full : 2. Address : 3. Nationality : 4. Direct Phone : Be inform that Christine Maulhardt is the Grants Manager and she is responsible for the smooth and efficient processing of your $250,000 (US Dollars) United Nations Democracy Fund grants,therefore, contact her immediately with these informations as required above. Congratulations once again. Mrs.Amina Jane Mohammed Deputy Secretary-General of the United Nations.
Re: [tip: x86/urgent] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On 8/24/19 11:19 AM, Pavel Machek wrote: > On Fri 2019-08-23 01:10:49, tip-bot2 for Tom Lendacky wrote: >> The following commit has been merged into the x86/urgent branch of tip: >> >> Commit-ID: c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 >> Gitweb: >> https://git.kernel.org/tip/c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 >> Author:Tom Lendacky >> AuthorDate:Mon, 19 Aug 2019 15:52:35 >> Committer: Borislav Petkov >> CommitterDate: Mon, 19 Aug 2019 19:42:52 +02:00 >> >> x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h >> >> There have been reports of RDRAND issues after resuming from suspend on >> some AMD family 15h and family 16h systems. This issue stems from a BIOS >> not performing the proper steps during resume to ensure RDRAND continues >> to function properly. > > There are quite a few unanswered questions here. > > a) Is there/should there be CVE for this? > > b) Can we perform proper steps in kernel, thus making RDRAND usable > even when BIOS is buggy? > The kernel should at least be able to set its internal "CPUID" bit, visible through /proc/cpuinfo. -hpa
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a): > Hello Jernej, > > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > > Visually? > > > > > > That would explain why it doesn't work for you. The mainline RTC driver > > > disables auto-switch feature, and if your board doesn't have a crystal > > > for > > > LOSC, RTC will not generate a clock for the RTC. > > > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > > doesn't have the crystal. You need to fix this in the DTS for your board > > > instead of patching the driver. > > > > I see that reparenting is supported, but I'm not sure how to fix that in > > DT. Any suggestion? > > You may try removing the clocks property from rtc node. I don't think this would work: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246 > > > > The driver has parent clock selection logic in case the LOSC crystal is > > > not > > > used. > > > > > > Your patch enables automatic detection of LOSC failure and RTC changes > > > clock to LOSC automatically, despite what's described in the DTS. That > > > may fix the issue, but is not the correct solution. > > > > > > Registers on my board look like this (external 32k osc is used) for > > > reference: > > > > > > LOSC_CTRL_REG[700]: 8011 > > > > > > KEY_FIELD ??? (0) > > > LOSC_AUTO_SWT_BYPASS EN (1) > > > LOSC_AUTO_SWT_EN DIS (0) > > > EXT_LOSC_ENEN (1) > > > EXT_LOSC_GSM LOW (0) > > > BATTERY_DIRDISCHARGE(0) > > > LOSC_SRC_SEL EXT32k (1) > > > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > > > > > EXT_LOSC_STA OK (0) > > > LOSC_AUTO_SWT_PEND NOEFF(0) > > > LOSC_SRC_SEL_STA EXT32K (1) > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > > has value 0x4, so there is issue with external crystal (it's missing) and > > RTC switched to internal one. > > > > BTW, what's wrong with automatic switching? Why is it disabled? > > It always was disabled on mainline (bit 14 was set to 0 even before my > patch). H6 just probably has another extra undocummented bit, that's needed > to disables it properly. > > You probably don't want a glitch to switch your RTC from high-precision > clock to a low precision one possibly without any indication in the > userspace or a kernel log. > > Regardless of all this, DTS needs to have a correct description of the HW, > which means if RTC module is not connected to the 32.757kHz crystal/clock, > clocks property should be empty. If we are talking about correct HW description, then clock property should actually have possibility that two clocks are defined - one for internal RC (always present) and one external crystal (optional). In such case I could really just omit external clock and be done with it. But I'm not sure if such solution is acceptable at this point. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > regards, > > > > > > o. > > > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b > > > > > sp#n > > > > > 650 > > > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > > > > > Best regards, > > > > Jernej > > > > > > > > > regards, > > > > > > > > > > o.
[PATCH] ASoC: es8316: limit headphone mixer volume
This patch limits Headphone mixer volume to 4 from 7.
Because output sound suddenly becomes very loudly with many noise if
set volume over 4.
Signed-off-by: Katsuhiro Suzuki
---
sound/soc/codecs/es8316.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index 8dfb5dbeebbf..bc4141e1eb7f 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -91,7 +91,7 @@ static const struct snd_kcontrol_new es8316_snd_controls[] = {
SOC_DOUBLE_TLV("Headphone Playback Volume", ES8316_CPHP_ICAL_VOL,
4, 0, 3, 1, hpout_vol_tlv),
SOC_DOUBLE_TLV("Headphone Mixer Volume", ES8316_HPMIX_VOL,
- 0, 4, 7, 0, hpmixer_gain_tlv),
+ 0, 4, 4, 0, hpmixer_gain_tlv),
SOC_ENUM("Playback Polarity", dacpol),
SOC_DOUBLE_R_TLV("DAC Playback Volume", ES8316_DAC_VOLL,
--
2.23.0.rc1
Re: [PATCH net] rxrpc: Fix lack of conn cleanup when local endpoint is cleaned up
From: David Howells
Date: Thu, 22 Aug 2019 13:26:38 +0100
> + spin_lock(>client_conn_cache_lock);
> + nr_active = rxnet->nr_active_client_conns;
> +
> + list_for_each_entry_safe(conn, tmp, >idle_client_conns,
> + cache_link) {
> + if (conn->params.local == local) {
> + ASSERTCMP(conn->cache_state, ==,
> RXRPC_CONN_CLIENT_IDLE);
> +
> + trace_rxrpc_client(conn, -1, rxrpc_client_discard);
> + if (!test_and_clear_bit(RXRPC_CONN_EXPOSED,
> >flags))
> + BUG();
> + conn->cache_state = RXRPC_CONN_CLIENT_INACTIVE;
> + list_move(>cache_link, );
> + nr_active--;
> + }
> + }
> +
> + rxnet->nr_active_client_conns = nr_active;
> + spin_unlock(>client_conn_cache_lock);
> + ASSERTCMP(nr_active, >=, 0);
> +
> + spin_lock(>client_conn_cache_lock);
> + while (!list_empty()) {
> + conn = list_entry(graveyard.next,
> + struct rxrpc_connection, cache_link);
> + list_del_init(>cache_link);
> + spin_unlock(>client_conn_cache_lock);
> +
> + rxrpc_put_connection(conn);
> +
> + spin_lock(>client_conn_cache_lock);
> + }
> + spin_unlock(>client_conn_cache_lock);
> +
> + _leave(" [culled]");
Once you've removed the entries from the globally visible idle_client_comms
list, and put them on the local garbage list, they cannot be seen in any way
by external threads of control outside of this function.
Therefore, you don't need to take the client_conn_cache_lock at all in the
second while loop.
Re: [PATCH net 0/9] rxrpc: Fix use of skb_cow_data()
I'm marking this series "deferred" while you investigate skb_unshare() etc.
Re: [PATCH RFC v1 2/2] mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host
Hi Ulf, On Thu, Aug 22, 2019 at 3:53 PM Ulf Hansson wrote: > > On Mon, 8 Jul 2019 at 19:33, Martin Blumenstingl > wrote: > > > > WiP - only partially working - see performance numbers. > > > > Odroid-C1 eMMC (HS-200): > > Amlogic's vendor driver @ Linux 3.10: > > 7781351936 bytes (7.8 GB) copied, 134.714 s, 57.8 MB/s > > This driver: > > 7781351936 bytes (7.8 GB, 7.2 GiB) copied, 189.02 s, 41.2 MB/s > > > > EC-100 eMMC (HS MMC): > > Amlogic's vendor driver @ Linux 3.10: > > 15762194432 bytes (16 GB) copied, 422.967 s, 37.3 MB/s > > This driver: > > 15762194432 bytes (16 GB, 15 GiB) copied, 9232.65 s, 1.7 MB/s > > > > 1) Amlogic's vendor driver does some magic with the divider: > > clk_div = input_rate / clk_ios - !(input_rate%clk_ios); > > if (!(clk_div & 0x01)) // if even number, turn it to an odd one > > clk_div++; > >It's not clear to me whether what the reason behind this is, what is > >supposed to be achieved with this? > > > > 2) The hardcoded RX clock phases are taken from the vendor driver. It > >seems that these are only valid when fclk_div3 is used as input > >clock (however, there are four more inputs). It's not clear to me how > >to calculate the RX clock phases in set_ios based on the input clock > >and the ios rate. > > > > 3) The hardware supports a timeout IRQ but the max_busy_timeout is not > >documented anywhere. > > > > Signed-off-by: Martin Blumenstingl > > Martin, overall this looks good to me. Once you moved from RFC to a > formal patch I will check again, of course. OK, great in the meantime I got answers to my questions (off-list) from Jianxin. also someone asked me (just this week) for the .dts patches so he could test on his own board (I have them ready but didn't send them yet) unfortunately he ran into some data corruption on writing I can reproduce it but I didn't have time to debug this yet I'll send an updated version once I have resolved that - as non-RFC > There are a couple of calls to readl_poll_timeout(), for different > reasons, that I have some questions about, but we can discuss those in > the next step. sure. feel free to ask now since I still have to debug that data corruption problem as stated above Martin
Re: [PATCH v2, 3/3] arm64: dts: meson-g12b-ugoos-am6: add initial device-tree
Hi Christian,
On Sat, Aug 24, 2019 at 10:06 AM Christian Hewitt
wrote:
>
> The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
> S922X chipset. Hardware specifications:
>
> - 2GB LPDDR4 RAM
> - 16GB eMMC storage
> - 10/100/1000 Base-T Ethernet using External RGMII PHY
> - 802.11 a/b/g/b/ac + BT 5.0 sdio wireless (Ampak 6398S)
> - HDMI 2.0 (4k@60p) video
> - Composite video + 2-channel audio output on 3.5mm jack
> - S/PDIF audio output
> - Aux input
> - 1x USB 3.0
> - 3x USB 2.0
> - 1x micro SD card slot
>
> The device-tree is laregly based on meson-g12b-odroid-n2 but with audio
typo -> largely
[...]
> + tflash_vdd: regulator-tflash_vdd {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "TFLASH_VDD";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> +
> + gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
do we need regulator-always-on here as well, see [0]?
[...]
> + usb_pwr_en: regulator-usb_pwr_en {
> + compatible = "regulator-fixed";
> + regulator-name = "USB_PWR_EN";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <_5v>;
> +
> + /* Connected to the microUSB port power enable */
> + gpio = < GPIOH_6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
the photos I found don't show a micro USB port (but 3x USB A 2.0 and
1x USB A 3.0 - just like you mentioned in the patch description)
does this regulator exist?
[...]
> + {
> + pinctrl-0 = <_pins>, <_rgmii_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + phy-mode = "rgmii";
> + phy-handle = <_phy>;
> + amlogic,tx-delay-ns = <2>;
> +};
is the PHY reset GPIO not wired to GPIOZ_15 like on Odroid-N2 and X96 Max?
Martin
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts?id=dc7f2cb218b5ef65ab3d455a0e62d27e44075203
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hello Jernej, On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > Visually? > > > > That would explain why it doesn't work for you. The mainline RTC driver > > disables auto-switch feature, and if your board doesn't have a crystal for > > LOSC, RTC will not generate a clock for the RTC. > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > doesn't have the crystal. You need to fix this in the DTS for your board > > instead of patching the driver. > > I see that reparenting is supported, but I'm not sure how to fix that in DT. > Any suggestion? You may try removing the clocks property from rtc node. > > > > The driver has parent clock selection logic in case the LOSC crystal is not > > used. > > > > Your patch enables automatic detection of LOSC failure and RTC changes clock > > to LOSC automatically, despite what's described in the DTS. That may fix > > the issue, but is not the correct solution. > > > > Registers on my board look like this (external 32k osc is used) for > > reference: > > > > LOSC_CTRL_REG[700]: 8011 > > KEY_FIELD ??? (0) > > LOSC_AUTO_SWT_BYPASS EN (1) > > LOSC_AUTO_SWT_EN DIS (0) > > EXT_LOSC_ENEN (1) > > EXT_LOSC_GSM LOW (0) > > BATTERY_DIRDISCHARGE(0) > > LOSC_SRC_SEL EXT32k (1) > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > EXT_LOSC_STA OK (0) > > LOSC_AUTO_SWT_PEND NOEFF(0) > > LOSC_SRC_SEL_STA EXT32K (1) > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > has value 0x4, so there is issue with external crystal (it's missing) and RTC > switched to internal one. > > BTW, what's wrong with automatic switching? Why is it disabled? It always was disabled on mainline (bit 14 was set to 0 even before my patch). H6 just probably has another extra undocummented bit, that's needed to disables it properly. You probably don't want a glitch to switch your RTC from high-precision clock to a low precision one possibly without any indication in the userspace or a kernel log. Regardless of all this, DTS needs to have a correct description of the HW, which means if RTC module is not connected to the 32.757kHz crystal/clock, clocks property should be empty. regards, o. > Best regards, > Jernej > > > regards, > > o. > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n > > > > 650 > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > Best regards, > > > Jernej > > > > > > > regards, > > > > > > > > o. > > > >
Re: [PATCH net-next] net/mlx5e: Use PTR_ERR_OR_ZERO in mlx5e_tc_add_nic_flow()
From: YueHaibing Date: Thu, 22 Aug 2019 06:52:19 + > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR > > Signed-off-by: YueHaibing Saeed, please pick this up if you haven't already. Thank you.
Re: [PATCH -next] net: mediatek: remove set but not used variable 'status'
From: Mao Wenan
Date: Thu, 22 Aug 2019 14:30:26 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status
> set but not used [-Wunused-but-set-variable]
>
> It is not used since commit 296c9120752b ("net: ethernet: mediatek: Add
> MT7628/88 SoC support")
This is not a standard commit tag, please use Fixes: or similar.
Re: [PATCHv4 0/3] Odroid c2 usb fixs
Hi Anand, thank you for the patches On Sat, Aug 24, 2019 at 8:49 PM Anand Moon wrote: [...] > Anand Moon (3): > arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input > arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus > arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power > failed warning this whole series is: Acked-by: Martin Blumenstingl
[GIT PULL] GPIO fixes for v5.3
Hi Linus, here is a (hopefully last) set of GPIO fixes for the v5.3 kernel cycle. Two are pretty core. Please pull them in! Details in the signed tag. Yours, Linus Walleij The following changes since commit d45331b00ddb179e291766617259261c112db872: Linux 5.3-rc4 (2019-08-11 13:26:41 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v5.3-4 for you to fetch changes up to 48057ed1840fde9239b1e000bea1a0a1f07c5e99: gpio: Fix irqchip initialization order (2019-08-23 11:00:43 +0200) GPIO fixes for the v5.3 kernel: - Fix not reporting open drain/source lines to userspace as "input" - Fix a minor build error found in randconfigs - Fix a chip select quirk on the Freescale SPI - Fix the irqchip initialization semantic order to reflect what it was using the old API Andreas Kemnade (1): gpio: of: fix Freescale SPI CS quirk handling Bartosz Golaszewski (1): gpiolib: never report open-drain/source lines as 'input' to user-space Linus Walleij (1): gpio: Fix irqchip initialization order YueHaibing (1): gpio: Fix build error of function redefinition drivers/gpio/gpiolib-of.c | 2 +- drivers/gpio/gpiolib.c| 36 +++- include/linux/gpio.h | 24 3 files changed, 20 insertions(+), 42 deletions(-)
RE: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi Dilip,
> Add driver for the reset controller present on Intel
> Lightening Mountain (LGM) SoC for performing reset
> management of the devices present on the SoC. Driver also
> registers a reset handler to peform the entire device reset.
[...]
> +static const struct of_device_id intel_reset_match[] = {
> + { .compatible = "intel,rcu-lgm" },
> + {}
> +};
how is this IP block differnet from the one used in many Lantiq SoCs?
there is already an upstream driver for the RCU IP block on the Lantiq
SoCs: drivers/reset/reset-lantiq.c
some background:
Lantiq was started as a spinoff from Infineon in 2009. Intel then
acquired Lantiq in 2015. source: [0]
Intel is re-using some of the IP blocks from the MIPS Lantiq SoCs
(Intel even has some own MIPS SoCs as part of the Lantiq acquisition,
typically used for PON/GPON/ADSL/VDSL capable network devices).
Thus I think it is likely that the new "Lightening Mountain" SoCs use
an updated version of the Lantiq RCU IP.
Martin
[0] https://wikidevi.com/wiki/Lantiq
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:30:57 CEST je Ondřej Jirman napisal(a): > On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > > > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > > > Hi, > > > > > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > > > Hi! > > > > > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > > > > > napisal(a): > > > > > > > From: Ondrej Jirman > > > > > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > > > differences > > > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > > > code. > > > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > > > called > > > > > > > EXT_LOSC_EN to enable/disable external low speed crystal > > > > > > > oscillator. > > > > > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > > > whether > > > > > > > external low speed oscillator is working correctly. > > > > > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > > > > > - during reparenting > > > > > > > - when probing the clock > > > > > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > > > external crystal oscillator, to internal RC oscillator, if > > > > > > > external > > > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > > > probe. > > > > > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > > Reviewed-by: Chen-Yu Tsai > > > > > > > --- > > > > > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > > > ++-- > > > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > > > > > /* Control register */ > > > > > > > #define SUN6I_LOSC_CTRL 0x > > > > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa > > > > << 16) > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15) > > > > > > > > > > > > User manual says that above field is bit 14. > > > > > > > > > > See the previous discussion, this is from BSP. > > > > > > > > I have two versions of BSP (don't ask me which) which have this set as > > > > bit > > > > 14 and changing this to 14 actually solves all my problems with LOSC > > > > (no > > > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > > > parent) on Tanix TX6 box. > > > > > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > > > crystal oscillator on your board? > > > > I really don't know, but here is DT: http://ix.io/1ThI > > > > > Anyway, see here: > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n > > > 649 > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n > > > 652 > > > > Interesting, 4.9 BSP has additional bit definition, which is not > > documented in manual and 3.10 BSP to which I refer. > > > > I was referring to 3.10 BSP, which uses only bit 14. I thought that you > > named it differently. > > > > > It would be nice to know what's really happening. > > > > > > My output is: > > > > > > [0.832252] sun6i-rtc 700.rtc: registered as rtc0 > > > [0.832257] sun6i-rtc 700.rtc: RTC enabled > > > [1.728968] sun6i-rtc 700.rtc: setting system clock to > > > 1970-01-01T00:00:07 UTC (7) > > > > With change, I get same output. > > > > > I think, you may have just enabled the auto switch feature, and running > > > the > > > clock from low precision RC oscillator with your patch. > > > > True, now I think there is no external crystal, but I'm still not sure how > > to confirm that. > > Visually? > > That would explain why it doesn't work for you. The mainline RTC driver > disables auto-switch feature, and if your board doesn't have a crystal for > LOSC, RTC will not generate a clock for the RTC. > > H6's dtsi describes by default a situatiuon with external 32k crystal > oscillator. See ext_osc32k node. That's incorrect for your board if it > doesn't have the crystal. You need to fix this in the DTS for your board > instead of patching the driver. I see that reparenting is supported, but I'm not sure how to fix that in DT. Any suggestion? > > The driver has parent clock selection logic in case the LOSC crystal is not > used.
RE: [PATCH v2 3/3] dwc: PCI: intel: Intel PCIe RC controller driver
Hi Dilip, first of all: thank you for submitting this upstream! I hope that we can use this driver to replace the out-of-tree PCIe driver that's used in OpenWrt for the Lantiq VRX200 SoCs. a small disclaimer: I don't have access to any Lantiq, Intel or DesignWare datasheets. so everything I write below is based on my own understanding of the Tegra public datasheet (which describes the DesignWare PCIe registers) as well as the public Lantiq UGW code drops with out-of-tree drivers for an older version of this PCIe IP. thus some of my statements below may be wrong - in this case I would appreciate an explanation of how the hardware really works. please keep me CC'ed on further revisions of this series. I am highly interested in making this driver work on the Lantiq VRX200 SoCs once the initial version has landed in linux-next. > +config PCIE_INTEL_AXI > +bool "Intel AHB/AXI PCIe host controller support" I believe that this is mostly the same IP block as it's used in Lantiq (xDSL) VRX200 SoCs (with MIPS cores) which was introduced in 2010 (before Intel acquired Lantiq). This is why I would have personally called the driver PCIE_LANTIQ [...] > +#define PCIE_CCRID 0x8 > + > +#define PCIE_LCAP0x7C > +#define PCIE_LCAP_MAX_LINK_SPEED GENMASK(3, 0) > +#define PCIE_LCAP_MAX_LENGTH_WIDTH GENMASK(9, 4) > + > +/* Link Control and Status Register */ > +#define PCIE_LCTLSTS 0x80 > +#define PCIE_LCTLSTS_ASPM_ENABLE GENMASK(1, 0) > +#define PCIE_LCTLSTS_RCB128 BIT(3) > +#define PCIE_LCTLSTS_LINK_DISABLEBIT(4) > +#define PCIE_LCTLSTS_COM_CLK_CFG BIT(6) > +#define PCIE_LCTLSTS_HW_AW_DIS BIT(9) > +#define PCIE_LCTLSTS_LINK_SPEED GENMASK(19, 16) > +#define PCIE_LCTLSTS_NEGOTIATED_LINK_WIDTH GENMASK(25, 20) > +#define PCIE_LCTLSTS_SLOT_CLK_CFGBIT(28) > + > +#define PCIE_LCTLSTS20xA0 > +#define PCIE_LCTLSTS2_TGT_LINK_SPEED GENMASK(3, 0) > +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_25GT0x1 > +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_5GT 0x2 > +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_8GT 0x3 > +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_16GT0x4 > +#define PCIE_LCTLSTS2_HW_AUTO_DISBIT(5) > + > +/* Ack Frequency Register */ > +#define PCIE_AFR 0x70C > +#define PCIE_AFR_FTS_NUM GENMASK(15, 8) > +#define PCIE_AFR_COM_FTS_NUM GENMASK(23, 16) > +#define PCIE_AFR_GEN12_FTS_NUM_DFT (SZ_128 - 1) > +#define PCIE_AFR_GEN3_FTS_NUM_DFT180 > +#define PCIE_AFR_GEN4_FTS_NUM_DFT196 > + > +#define PCIE_PLCR_DLL_LINK_ENBIT(5) > +#define PCIE_PORT_LOGIC_FTS GENMASK(7, 0) > +#define PCIE_PORT_LOGIC_DFT_FTS_NUM (SZ_128 - 1) > + > +#define PCIE_MISC_CTRL 0x8BC > +#define PCIE_MISC_CTRL_DBI_RO_WR_EN BIT(0) > + > +#define PCIE_MULTI_LANE_CTRL 0x8C0 > +#define PCIE_UPCONFIG_SUPPORTBIT(7) > +#define PCIE_DIRECT_LINK_WIDTH_CHANGEBIT(6) > +#define PCIE_TARGET_LINK_WIDTH GENMASK(5, 0) > + > +#define PCIE_IOP_CTRL0x8C4 > +#define PCIE_IOP_RX_STANDBY_CTRL GENMASK(6, 0) are you sure that you need any of the registers above? as far as I can tell most (all?) of them are part of the DesignWare register set. why doesn't pcie-designware-host initialize these? I don't have any datasheet or register documentation for the DesignWare PCIe core. In my own experiment from a month ago on the Lantiq VRX200 SoC I didn't need any of this: [0] this also makes me wonder if various functions below like intel_pcie_link_setup() and intel_pcie_max_speed_setup() (and probably more) are really needed or if it's just cargo cult / copy paste from an out-of-tree driver). > +/* APP RC Core Control Register */ > +#define PCIE_RC_CCR 0x10 > +#define PCIE_RC_CCR_LTSSM_ENABLE BIT(0) > +#define PCIE_DEVICE_TYPE GENMASK(7, 4) > +#define PCIE_RC_CCR_RC_MODE BIT(2) > + > +/* PCIe Message Control */ > +#define PCIE_MSG_CR 0x30 > +#define PCIE_XMT_PM_TURNOFF BIT(0) > + > +/* PCIe Power Management Control */ > +#define PCIE_PMC 0x44 > +#define PCIE_PM_IN_L2BIT(20) > + > +/* Interrupt Enable Register */ > +#define PCIE_IRNEN 0xF4 > +#define PCIE_IRNCR 0xF8 > +#define PCIE_IRN_AER_REPORT BIT(0) > +#define PCIE_IRN_PME BIT(2) > +#define PCIE_IRN_HOTPLUG BIT(3) > +#define PCIE_IRN_RX_VDM_MSG BIT(4) > +#define PCIE_IRN_PM_TO_ACK
Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
On Sat, Aug 24, 2019 at 1:22 PM Ingo Molnar wrote:
>
> That makes sense: I measured 17 seconds per 100 MB of data, which is is
> 0.16 usecs per byte. The instruction used by
> copy_user_enhanced_fast_string() is REP MOVSB - which supposedly goes as
> high as cacheline size accesses - but perhaps those get broken down for
> physical memory that has no device claiming it?
All the "rep string" optimizations are _only_ done for regular memory.
When it hits any IO accesses, it will do the accesses at the specified
size (so "movsb" will do it a byte at a time).
0.16 usec per byte is faster than the traditional ISA 'inb', but not
by a huge factor.
> Interruption is arguably *not* an 'error', so preserving partial reads
> sounds like the higher quality solution, nevertheless one could argue
> that particual read *could* be returned by read_kmem() if progress was
> made.
So if we react to regular signals, not just fatal ones, we definitely
need to honor partial reads.
> I.e. if for example an iomem area is already mapped by a driver with some
> conflicting cache attribute, xlate_dev_mem_ptr() AFAICS will not
> ioremap_cache() it to cached? IIRC some CPUs would triple fault or
> completely misbehave on certain cache attribute conflicts.
Yeah, I guess we have the machine check possibility with mixed cached cases.
> This check in mremap() might also trigger:
>
> if (is_ram == REGION_MIXED) {
> WARN_ONCE(1, "memremap attempted on mixed range %pa size:
> %#lx\n",
> , (unsigned long) size);
> return NULL;
> }
>
> So I'd say xlate_dev_mem_ptr() looks messy, but is possibly a bit more
> robust in this regard?
It clearly does work. Slowly, but work.
At least it works on x86. On some other architectures /dev/mem
definitely cannot possibly handle IO memory correctly, because you
can't even try to just read it as regular memory.
But those architectures are few and likely not relevant anyway (eg early alpha).
Linus
Re: [PATCH v3 0/3] vmstats/vmevents flushing
On Fri, 23 Aug 2019 00:33:51 + Roman Gushchin wrote:
> On Thu, Aug 22, 2019 at 04:27:09PM -0700, Andrew Morton wrote:
> > On Mon, 19 Aug 2019 16:00:51 -0700 Roman Gushchin wrote:
> >
> > > v3:
> > > 1) rearranged patches [2/3] and [3/3] to make [1/2] and [2/2] suitable
> > > for stable backporting
> > >
> > > v2:
> > > 1) fixed !CONFIG_MEMCG_KMEM build by moving memcg_flush_percpu_vmstats()
> > > and memcg_flush_percpu_vmevents() out of CONFIG_MEMCG_KMEM
> > > 2) merged add-comments-to-slab-enums-definition patch in
> > >
> > > Thanks!
> > >
> > > Roman Gushchin (3):
> > > mm: memcontrol: flush percpu vmstats before releasing memcg
> > > mm: memcontrol: flush percpu vmevents before releasing memcg
> > > mm: memcontrol: flush percpu slab vmstats on kmem offlining
> > >
> >
> > Can you please explain why the first two patches were cc:stable but not
> > the third?
> >
> >
>
> Because [1] and [2] are fixing commit 42a300353577 ("mm: memcontrol: fix
> recursive statistics correctness & scalabilty"), which has been merged into
> 5.2.
>
> And [3] fixes commit fb2f2b0adb98 ("mm: memcg/slab: reparent memcg kmem_caches
> on cgroup removal"), which is in not yet released 5.3, so stable backport
> isn't
> required.
OK, thanks. Patches 1 & 2 are good to go but I don't think that #3 has
had suitable review and I have a note here that Michal has concerns
with it.
Re: [PATCH v3] psi: get poll_work to run when calling poll syscall next time
On Fri, 23 Aug 2019 08:53:09 +0800 Joseph Qi wrote: > > Should this be backported into -stable kernels? > > > Sorry for missing that, should I resend it with cc stable tag? I added cc:stable to this patch.
Re: [PATCH 1/1] arm64: dts: imx8mq: Add mux controller to iomuxc_gpr
On Thu, Aug 22, 2019 at 01:10:23PM +0200, Guido Günther wrote: > The only mux controls the MIPI DSI input selection. > > Signed-off-by: Guido Günther Applied, thanks.
Re: [PATCH v7 1/4] dt-bindings: vendor-prefixes: Add Anvo-Systems
On Thu, Aug 22, 2019 at 08:02:35AM +0200, Krzysztof Kozlowski wrote: > Add vendor prefix for Anvo-Systems Dresden GmbH. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Rob Herring Applied all, thanks.
Re: [PATCH] soc: imx: gpcv2: Print the correct error code
On Wed, Aug 21, 2019 at 06:33:04PM +0200, Guido Günther wrote: > The current code prints 'ret' (thus 0) while it should use 'err'. > > Signed-off-by: Guido Günther Applied, thanks.
Re: [PATCH] af_unix: utilize skb's fragment list for sending large datagrams
On 8/22/19 9:04 PM, David Miller wrote: > From: Jan Dakinevich > Date: Thu, 22 Aug 2019 10:38:39 + > >> However, paged part can not exceed MAX_SKB_FRAGS * PAGE_SIZE, and large >> datagram causes increasing skb's data buffer. Thus, if any user-space >> program sets send buffer (by calling setsockopt(SO_SNDBUF, ...)) to >> maximum allowed size (wmem_max) it becomes able to cause any amount >> of uncontrolled high-order kernel allocations. > So? You want huge SKBs you get the high order allocations, seems > rather reasonable to me. > > SKBs using fragment lists are the most difficult and cpu intensive > geometry for an SKB to have and we should avoid using it where > feasible. > > I don't want to apply this, sorry. Under even mediocre memory pressure this will either takes seconds or fail, which does not look good. We can try to allocate memory of big order but not that hard and switch to fragments when possible. Please also note that even ordinary user could trigger really big allocations and thus force the whole node to dance. Den Den
Re: [PATCHv2] lib/test_kasan: add roundtrip tests
On Fri, 23 Aug 2019 11:41:08 +0100 Mark Rutland wrote: > > > > /* > > > > which is really kinda wrong. We should strictly include linux/io.h for > > things like virt_to_phys(). > > > > So I think I'll stick with v1 plus my fixlet: > > > > --- a/lib/test_kasan.c~lib-test_kasan-add-roundtrip-tests-checkpatch-fixes > > +++ a/lib/test_kasan.c > > @@ -18,8 +18,8 @@ > > #include > > #include > > #include > > +#include > > > > -#include > > #include > > > > /* > > > > Assuming that you mean *v3* with that fix, that looks good to me! Yes, that's what we have.
[PATCH v2 5/6] misc: atmel-ssc: get LRCLK pin selection from DT
Store LRCLK pin selection for use by ASoC DAI driver.
Signed-off-by: Michał Mirosław
---
v2: split from ASoC implementation
---
drivers/misc/atmel-ssc.c | 9 +
include/linux/atmel-ssc.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index ab4144ea1f11..1322e29bc37a 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -210,6 +210,15 @@ static int ssc_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
ssc->clk_from_rk_pin =
of_property_read_bool(np, "atmel,clk-from-rk-pin");
+ ssc->lrclk_from_tf_pin =
+ of_property_read_bool(np, "atmel,lrclk-from-tf-pin");
+ ssc->lrclk_from_rf_pin =
+ of_property_read_bool(np, "atmel,lrclk-from-rf-pin");
+
+ if (ssc->lrclk_from_tf_pin && ssc->lrclk_from_rf_pin) {
+ dev_err(>dev, "both LRCLK from RK/TK options
found in DT node");
+ return -EINVAL;
+ }
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 6091d2abc1eb..fbe1c2ffaa81 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -21,6 +21,8 @@ struct ssc_device {
int user;
int irq;
boolclk_from_rk_pin;
+ boollrclk_from_tf_pin;
+ boollrclk_from_rf_pin;
boolsound_dai;
};
--
2.20.1
[PATCH v2 4/6] dt-bindings: misc: atmel-ssc: LRCLK from TF/RF pin option
Add single-pin LRCLK source options for Atmel SSC module. Signed-off-by: Michał Mirosław --- v2: split from implementation patch --- Documentation/devicetree/bindings/misc/atmel-ssc.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt index f9fb412642fe..c98e96dbec3a 100644 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt @@ -24,6 +24,11 @@ Optional properties: this parameter to choose where the clock from. - By default the clock is from TK pin, if the clock from RK pin, this property is needed. + - atmel,lrclk-from-tf-pin: bool property. + - atmel,lrclk-from-rf-pin: bool property. + - SSC in slave mode gets LRCLK from RF for receive and TF for transmit + data direction. This property makes both use single TF (or RF) pin + as LRCLK. At most one can be present. - #sound-dai-cells: Should contain <0>. - This property makes the SSC into an automatically registered DAI. -- 2.20.1
[PATCH v2 6/6] ASoC: atmel_ssc_dai: Enable shared FSYNC source in frame-slave mode
SSC driver allows only synchronous TX and RX. In slave mode for BCLK
it uses only one of TK or RK pin, but for LRCLK it configured separate
inputs from TF and RF pins. Allow configuration with common FS signal.
Signed-off-by: Michał Mirosław
---
v2: use alternate DT binding
split DT and drivers/misc changes
---
sound/soc/atmel/atmel_ssc_dai.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 48e9eef34c0f..035d4da58f2b 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -605,14 +605,32 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream
*substream,
return -EINVAL;
}
- if (!atmel_ssc_cfs(ssc_p)) {
+ if (atmel_ssc_cfs(ssc_p)) {
+ /*
+* SSC provides LRCLK
+*
+* Both TF and RF are generated, so use them directly.
+*/
+ rcmr |= SSC_BF(RCMR_START, fs_edge);
+ tcmr |= SSC_BF(TCMR_START, fs_edge);
+ } else {
fslen = fslen_ext = 0;
rcmr_period = tcmr_period = 0;
fs_osync = SSC_FSOS_NONE;
- }
- rcmr |= SSC_BF(RCMR_START, fs_edge);
- tcmr |= SSC_BF(TCMR_START, fs_edge);
+ if (ssc->lrclk_from_tf_pin) {
+ rcmr |= SSC_BF(RCMR_START, SSC_START_TX_RX);
+ tcmr |= SSC_BF(TCMR_START, fs_edge);
+ } else if (ssc->lrclk_from_rf_pin) {
+ /* assume RF is to be used when RK is used as BCLK
input */
+ /* Note: won't work correctly on SAMA5D2 due to errata
*/
+ rcmr |= SSC_BF(RCMR_START, fs_edge);
+ tcmr |= SSC_BF(TCMR_START, SSC_START_TX_RX);
+ } else {
+ rcmr |= SSC_BF(RCMR_START, fs_edge);
+ tcmr |= SSC_BF(TCMR_START, fs_edge);
+ }
+ }
if (atmel_ssc_cbs(ssc_p)) {
/*
--
2.20.1
[PATCH v2 2/6] ASoC: atmel_ssc_dai: rework DAI format configuration
Rework DAI format calculation in preparation for adding more formats
later. As a side-effect this enables all CBM/CBS x CFM/CFS combinations
for supported formats. (Note: the additional modes are not tested.)
Note: this changes FSEDGE to POSITIVE for I2S CBM_CFS mode as the TXSYN
interrupt is not used anyway.
Signed-off-by: Michał Mirosław
---
v2: added note about extended modes' status
incorporated common FS (LRCLK) configuration
---
sound/soc/atmel/atmel_ssc_dai.c | 286 +---
1 file changed, 80 insertions(+), 206 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 6f89483ac88c..7dc6ec9b8c7a 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -471,7 +471,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream
*substream,
int dir, channels, bits;
u32 tfmr, rfmr, tcmr, rcmr;
int ret;
- int fslen, fslen_ext;
+ int fslen, fslen_ext, fs_osync, fs_edge;
u32 cmr_div;
u32 tcmr_period;
u32 rcmr_period;
@@ -558,226 +558,36 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream
*substream,
/*
* Compute SSC register settings.
*/
- switch (ssc_p->daifmt
- & (SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_MASTER_MASK)) {
- case SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS:
- /*
-* I2S format, SSC provides BCLK and LRC clocks.
-*
-* The SSC transmit and receive clocks are generated
-* from the MCK divider, and the BCLK signal
-* is output on the SSC TK line.
-*/
-
- if (bits > 16 && !ssc->pdata->has_fslen_ext) {
- dev_err(dai->dev,
- "sample size %d is too large for SSC device\n",
- bits);
- return -EINVAL;
- }
-
- fslen_ext = (bits - 1) / 16;
- fslen = (bits - 1) % 16;
-
- rcmr =SSC_BF(RCMR_PERIOD, rcmr_period)
- | SSC_BF(RCMR_STTDLY, START_DELAY)
- | SSC_BF(RCMR_START, SSC_START_FALLING_RF)
- | SSC_BF(RCMR_CKI, SSC_CKI_RISING)
- | SSC_BF(RCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(RCMR_CKS, SSC_CKS_DIV);
-
- rfmr =SSC_BF(RFMR_FSLEN_EXT, fslen_ext)
- | SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
- | SSC_BF(RFMR_FSOS, SSC_FSOS_NEGATIVE)
- | SSC_BF(RFMR_FSLEN, fslen)
- | SSC_BF(RFMR_DATNB, (channels - 1))
- | SSC_BIT(RFMR_MSBF)
- | SSC_BF(RFMR_LOOP, 0)
- | SSC_BF(RFMR_DATLEN, (bits - 1));
-
- tcmr =SSC_BF(TCMR_PERIOD, tcmr_period)
- | SSC_BF(TCMR_STTDLY, START_DELAY)
- | SSC_BF(TCMR_START, SSC_START_FALLING_RF)
- | SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
- | SSC_BF(TCMR_CKO, SSC_CKO_CONTINUOUS)
- | SSC_BF(TCMR_CKS, SSC_CKS_DIV);
-
- tfmr =SSC_BF(TFMR_FSLEN_EXT, fslen_ext)
- | SSC_BF(TFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
- | SSC_BF(TFMR_FSDEN, 0)
- | SSC_BF(TFMR_FSOS, SSC_FSOS_NEGATIVE)
- | SSC_BF(TFMR_FSLEN, fslen)
- | SSC_BF(TFMR_DATNB, (channels - 1))
- | SSC_BIT(TFMR_MSBF)
- | SSC_BF(TFMR_DATDEF, 0)
- | SSC_BF(TFMR_DATLEN, (bits - 1));
- break;
-
- case SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBM_CFM:
- /* I2S format, CODEC supplies BCLK and LRC clocks. */
- rcmr =SSC_BF(RCMR_PERIOD, 0)
- | SSC_BF(RCMR_STTDLY, START_DELAY)
- | SSC_BF(RCMR_START, SSC_START_FALLING_RF)
- | SSC_BF(RCMR_CKI, SSC_CKI_RISING)
- | SSC_BF(RCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
- SSC_CKS_PIN : SSC_CKS_CLOCK);
-
- rfmr =SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
- | SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
- | SSC_BF(RFMR_FSLEN, 0)
- | SSC_BF(RFMR_DATNB, (channels - 1))
- | SSC_BIT(RFMR_MSBF)
- | SSC_BF(RFMR_LOOP, 0)
- | SSC_BF(RFMR_DATLEN, (bits - 1));
-
- tcmr =SSC_BF(TCMR_PERIOD, 0)
- | SSC_BF(TCMR_STTDLY, START_DELAY)
- | SSC_BF(TCMR_START, SSC_START_FALLING_RF)
- | SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
-
[PATCH v2 1/6] ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig
Allow SSC to be used on platforms described using audio-graph-card in Device Tree. Signed-off-by: Michał Mirosław --- v2: extended to PDC mode reworked and fixed Kconfig option dependencies --- sound/soc/atmel/Kconfig | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig index 06c1d5ce642c..f118c229ed82 100644 --- a/sound/soc/atmel/Kconfig +++ b/sound/soc/atmel/Kconfig @@ -12,25 +12,31 @@ if SND_ATMEL_SOC config SND_ATMEL_SOC_PDC tristate depends on HAS_DMA - default m if SND_ATMEL_SOC_SSC_PDC=m && SND_ATMEL_SOC_SSC=m - default y if SND_ATMEL_SOC_SSC_PDC=y || (SND_ATMEL_SOC_SSC_PDC=m && SND_ATMEL_SOC_SSC=y) - -config SND_ATMEL_SOC_SSC_PDC - tristate config SND_ATMEL_SOC_DMA tristate select SND_SOC_GENERIC_DMAENGINE_PCM - default m if SND_ATMEL_SOC_SSC_DMA=m && SND_ATMEL_SOC_SSC=m - default y if SND_ATMEL_SOC_SSC_DMA=y || (SND_ATMEL_SOC_SSC_DMA=m && SND_ATMEL_SOC_SSC=y) - -config SND_ATMEL_SOC_SSC_DMA - tristate config SND_ATMEL_SOC_SSC tristate - default y if SND_ATMEL_SOC_SSC_DMA=y || SND_ATMEL_SOC_SSC_PDC=y - default m if SND_ATMEL_SOC_SSC_DMA=m || SND_ATMEL_SOC_SSC_PDC=m + +config SND_ATMEL_SOC_SSC_PDC + tristate "SoC PCM DAI support for AT91 SSC controller using PDC" + depends on ATMEL_SSC + select SND_ATMEL_SOC_PDC + select SND_ATMEL_SOC_SSC + help + Say Y or M if you want to add support for Atmel SSC interface + in PDC mode configured using audio-graph-card in device-tree. + +config SND_ATMEL_SOC_SSC_DMA + tristate "SoC PCM DAI support for AT91 SSC controller using DMA" + depends on ATMEL_SSC + select SND_ATMEL_SOC_DMA + select SND_ATMEL_SOC_SSC + help + Say Y or M if you want to add support for Atmel SSC interface + in DMA mode configured using audio-graph-card in device-tree. config SND_AT91_SOC_SAM9G20_WM8731 tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation board" -- 2.20.1
[PATCH v2 3/6] ASoC: atmel_ssc_dai: implement left-justified data mode
Enable support for left-justified data mode for SSC-codec link.
Signed-off-by: Michał Mirosław
---
v2: rebased
---
sound/soc/atmel/atmel_ssc_dai.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 7dc6ec9b8c7a..48e9eef34c0f 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -564,6 +564,15 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream
*substream,
switch (ssc_p->daifmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_LEFT_J:
+ fs_osync = SSC_FSOS_POSITIVE;
+ fs_edge = SSC_START_RISING_RF;
+
+ rcmr =SSC_BF(RCMR_STTDLY, 0);
+ tcmr =SSC_BF(TCMR_STTDLY, 0);
+
+ break;
+
case SND_SOC_DAIFMT_I2S:
fs_osync = SSC_FSOS_NEGATIVE;
fs_edge = SSC_START_FALLING_RF;
--
2.20.1
[PATCH v2 0/6] ] ASoC: atmel: extend SSC support
This series improves support for various configurations using SSC module as implemented in Atmel SAMA5Dx SoCs. Patches are: 1. enable SSC in Kconfig for audio-graph-card support 2. DRY mode setting code 3. implement left-justified data mode 4-6. enable shared FSYNC source for slave mode Patches against tiwai/sound/for-next tree. You can also pull from https://rere.qmqm.pl/git/linux branch: atmel-ssc Michał Mirosław (6): ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig ASoC: atmel_ssc_dai: rework DAI format configuration ASoC: atmel_ssc_dai: implement left-justified data mode dt-bindings: misc: atmel-ssc: LRCLK from TF/RF pin option misc: atmel-ssc: get LRCLK pin selection from DT ASoC: atmel_ssc_dai: Enable shared FSYNC source in frame-slave mode .../devicetree/bindings/misc/atmel-ssc.txt| 5 + drivers/misc/atmel-ssc.c | 9 + include/linux/atmel-ssc.h | 2 + sound/soc/atmel/Kconfig | 30 +- sound/soc/atmel/atmel_ssc_dai.c | 305 ++ 5 files changed, 137 insertions(+), 214 deletions(-) -- 2.20.1
Re: [PATCH] Partially revert "mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones"
Den 24-08-2019 kl. 22:57, skrev Andrew Morton:
On Sat, 17 Aug 2019 19:15:23 + Roman Gushchin wrote:
Fixes: 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync with the
hierarchical ones")
Signed-off-by: Roman Gushchin
Cc: Yafang Shao
Cc: Johannes Weiner
---
mm/memcontrol.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Oh, I'm sorry, will read and follow next time. Thanks!
766a4c19d880 is not present in 5.2 so no -stable backport is needed, yes?
Unfortunately it got added in 5.2.7, so backport is needed.
--
Thomas
Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
* Linus Torvalds wrote: > On Sat, Aug 24, 2019 at 9:14 AM Ingo Molnar wrote: > > > > What I noticed is that while reading regular RAM is reasonably fast even > > in very large chunks, accesses become very slow once they hit iomem - and > > delays even longer than the reported 145 seconds become possible if > > bs=100M is increased to say bs=1000M. > > Ok, that makes sense. > > So for IOMEM, we actually have two independent issues: > > (a) for normal unmapped IOMEM (ie no device), which is probably the > case your test triggers anyway, it quite possibly ends up having ISA > timings (ie around 1us per read) That makes sense: I measured 17 seconds per 100 MB of data, which is is 0.16 usecs per byte. The instruction used by copy_user_enhanced_fast_string() is REP MOVSB - which supposedly goes as high as cacheline size accesses - but perhaps those get broken down for physical memory that has no device claiming it? > (b) we use "probe_kernel_read()" to a temporary buffer avoid page > faults, which uses __copy_from_user_inatomic(). So far so good. But on > modern x86, because we treat it as just a regular memcpy, we probably > have ERMS and do "rep movsb". > > So (a) means that each access is slow to begin with, and then (b) > means that we don't use "copy_from_io()" but a slow byte-by-byte > access. > > > With Tetsuo's approach the delays are fixed, because the fatal signal is > > noticed within the 4K chunks of read_mem() immediately: > > Yeah. that's the size of the temp buffer. > > > Note how the first 100MB chunk took 17 seconds, the second chunk was > > interrupted within ~2 seconds after I sent a SIGKILL. > > It looks closer to 1 second from that trace, but that actually is > still within the basic noise above: a 4kB buffer being copied one byte > at a time would take about 4s, but maybe it's not *quite* as bad as > traditional ISA PIO timings. Yeah - and note that I phrased it imprecisely: the real in-kernel signal interruption delay was probably below 1 msec: in my test the SIGKILL was manually triggered, with an about 1 second delay caused by the human brain, not by the kernel. ;-) The in-kernel interruption is almost instantaneous - the 4K max chunking is good I think. > > Except that I think the regular pattern here is not 'break' but 'goto > > failed' - 'break' would just result in a partial read and 'err' gets > > ignored. > > That's actually the correct signal handling pattern: either a partial > read, or -EINTR. > > In the case of SIGKILL, the return value doesn't matter, of course, > but *if* we were to decide that we can make it interruptible, then it > would. Yeah. So while error cases and signals are not equivalent, I also went by existing precedent within read_kmem(): the 2 other error cases return an error (-ENXIO and -EFAULT), while they could also conceivably return a partial read of the previously completed read and only return an error if the *first* chunk generates an error without making any progress? Interruption is arguably *not* an 'error', so preserving partial reads sounds like the higher quality solution, nevertheless one could argue that particual read *could* be returned by read_kmem() if progress was made. > > I also agree that we should probably allow regular interrupts to > > interrupt /dev/mem accesses - while the 'dd' process is killable, it's > > not Ctrl-C-able. > > I'm a bit nervous about it, but there probably aren't all that many > actual /dev/mem users. > > The main ones I can see are things like "dmidecode" etc. > > > If I change the fatal_signal_pending() to signal_pending() it all behaves > > much better IMHO - assuming that no utility learned rely on > > non-interruptibility ... > > So I cloned the dmidecode git tree, and it does "myread()" on the > /dev/mem file as far as I can tell. And that one correctly hanles > partial reads. > > It still makes me a bit nervous, but just plain "signal_pending()" is > not just nicer, it's technically the right thing to do (it's not a > regular file, so partial reads are permissible, and other files like > it - eg /dev/zero - already does exactly that). > > I also wonder if we should just not use that crazy > "probe_kernel_read()" to begin with. The /dev/mem code uses it to > avoid faults - and that's the intent of it - but it's not meant for > IO-memory at all. > > But "read()" on /dev/mem does that off "xlate_dev_mem_ptr()", which is > a bastardized "kernel address or ioremap" thing. It works, but it's > all kinds of stupid. We'd be a *lot* better off using kmap(), I think. Hm, I think xlate_dev_mem_ptr() and thus ioremap() would also perform a cache aliasing conflict check - which kmap() wouldn't do? I.e. if for example an iomem area is already mapped by a driver with some conflicting cache attribute, xlate_dev_mem_ptr() AFAICS will not ioremap_cache() it to cached? IIRC some CPUs would triple fault or completely misbehave on certain cache attribute conflicts. This
Re: [PATCH] Partially revert "mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones"
On Sat, 17 Aug 2019 19:15:23 + Roman Gushchin wrote:
> > > Fixes: 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync
> > > with the hierarchical ones")
> > > Signed-off-by: Roman Gushchin
> > > Cc: Yafang Shao
> > > Cc: Johannes Weiner
> > > ---
> > > mm/memcontrol.c | 8 +++-
> > > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> >
> >
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree. Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this properly.
>
> Oh, I'm sorry, will read and follow next time. Thanks!
766a4c19d880 is not present in 5.2 so no -stable backport is needed, yes?
Re: [PATCH v2] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100 kHz
On Tue, Aug 20, 2019 at 06:39:36PM -0700, Andrey Smirnov wrote: > Fiber-optic modules attached to the bus are only rated to work at > 100 kHz, so decrease the bus frequency to accommodate that. > > Signed-off-by: Andrey Smirnov > Cc: Shawn Guo > Cc: Chris Healy > Cc: Fabio Estevam > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org Applied, thanks.
Re: [PATCH v4] arm64: dts: ls1088a: fix gpio node
On Tue, Aug 20, 2019 at 01:54:38PM +0800, Hui Song wrote:
> From: Song Hui
>
> add ls1088a gpio specify compatible.
>
> Signed-off-by: Song Hui
I updated the patch subject as below, and applied the patch.
arm64: dts: ls1088a: update gpio compatible
Shawn
> ---
> Changes in v4:
> - update the patch description.
> Changes in v3:
> - delete the attribute of little-endian.
> Changes in v2:
> - update the subject.
>
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index dfbead4..ff669c8 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -269,7 +269,7 @@
> };
>
> gpio0: gpio@230 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x230 0x0 0x1>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -280,7 +280,7 @@
> };
>
> gpio1: gpio@231 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x231 0x0 0x1>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -291,7 +291,7 @@
> };
>
> gpio2: gpio@232 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x232 0x0 0x1>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -302,7 +302,7 @@
> };
>
> gpio3: gpio@233 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x233 0x0 0x1>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> --
> 2.9.5
>
Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Drop redundant I2C properties
On Mon, Aug 19, 2019 at 08:19:52PM -0700, Andrey Smirnov wrote:
> Drop redundant I2C properties that are already specified in
> vf610-zii-dev.dtsi
>
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> index 48086c5e8549..e500911ce0a5 100644
> --- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> @@ -323,11 +323,6 @@
> };
>
> {
> - clock-frequency = <10>;
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c0>;
pinctrl for i2c0 is not same as what vf610-zii-dev.dtsi has.
Shawn
> - status = "okay";
> -
> gpio5: io-expander@20 {
> compatible = "nxp,pca9554";
> reg = <0x20>;
> @@ -350,11 +345,6 @@
> };
>
> {
> - clock-frequency = <10>;
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c2>;
> - status = "okay";
> -
> tca9548@70 {
> compatible = "nxp,pca9548";
> pinctrl-0 = <_i2c_mux_reset>;
> --
> 2.21.0
>
Re: [PATCH] ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
On Mon, Aug 19, 2019 at 08:13:01PM -0700, Andrey Smirnov wrote: > LPUART driver does not support specifying "rs485-rts-delay" > property. Drop it. If so, we need to fix bindings/serial/fsl-lpuart.txt in the meantime? Shawn > > Signed-off-by: Andrey Smirnov > Cc: Shawn Guo > Cc: Chris Healy > Cc: Fabio Estevam > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts > b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts > index 666ec27a73e3..d8c38ef6a98a 100644 > --- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts > +++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts > @@ -685,7 +685,6 @@ > linux,rs485-enabled-at-boot-time; > pinctrl-names = "default"; > pinctrl-0 = <_uart1>; > - rs485-rts-delay = <0 200>; > status = "okay"; > }; > > @@ -693,7 +692,6 @@ > linux,rs485-enabled-at-boot-time; > pinctrl-names = "default"; > pinctrl-0 = <_uart2>; > - rs485-rts-delay = <0 200>; > status = "okay"; > }; > > -- > 2.21.0 >
Re: [PATCH v4 2/2] arm64: dts: imx: Add i.mx8mq nitrogen8m basic dts support
On Mon, Aug 19, 2019 at 07:26:06PM +0200, Dafna Hirschfeld wrote: > From: Gary Bisson > > Add basic dts support for i.MX8MQ NITROGEN8M. > > Signed-off-by: Gary Bisson > Signed-off-by: Troy Kisky > [Dafna: porting vendor's code to mainline] > Signed-off-by: Dafna Hirschfeld Applied, thanks.
Re: [PATCH v4 1/2] dt-bindings: arm: imx: add imx8mq nitrogen support
On Tue, Aug 20, 2019 at 06:27:39PM +0200, Dafna Hirschfeld wrote: > On Mon, 2019-08-19 at 14:08 -0500, Rob Herring wrote: > > On Mon, Aug 19, 2019 at 12:26 PM Dafna Hirschfeld > > wrote: > > > From: Gary Bisson > > > > > > The Nitrogen8M is an ARM based single board computer (SBC) > > > designed to leverage the full capabilities of NXP’s i.MX8M > > > Quad processor. > > > > > > Signed-off-by: Gary Bisson > > > Signed-off-by: Troy Kisky > > > [Dafna: porting vendor's code to mainline] > > > Signed-off-by: Dafna Hirschfeld > > > --- > > > Documentation/devicetree/bindings/arm/fsl.yaml | 1 + > > > 1 file changed, 1 insertion(+) > > > > Please add acks/reviewed-bys when posting new versions. > > > Hi, > Thank you for the remark, I forgot to add it. I will add it in the > next. I applied the patch with Rob's Reviewed-by on v3. Shawn
[no subject]
Wir sind zuverlässige, vertrauenswürdige Kreditgeber, leihen wir Unternehmen und Einzelpersonen zu einem niedrigen Zinssatz von 2%, Sind Sie auf der Suche nach einem Geschäftskredit, Privatkredite, Schuldenkonsolidierung, unbesicherte Kredite, Risikokapital, wenn ja Kontaktieren Sie uns jetzt für weitere Einzelheiten.
[PATCHv4 1/3] arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
As per the schematic Monolithic Power Systems MP2161GJ-C499
supply a fixed output voltage of 5.0V. This supplies linked
to VDD_EE, HDMI_P5V0, USB_POWER, VCCK, VDDIO_AO1V8, DDR_VDDC
according to the schematics.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
Changes from my previous attempt below
[1] https://lore.kernel.org/patchwork/patch/1031243/
New patch and fix the commit message.
Added regulator-always-on since this is core input regulator.
Split the linking on regulator and usb node in separate patch.
Later more patchs will follow linking more core regulator as per
shematics.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 9972b1515da6..41d5fa370eb3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -50,6 +50,15 @@
};
};
+ p5v0: regulator-p5v0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
tflash_vdd: regulator-tflash_vdd {
/*
* signal name from schematics: TFLASH_VDD_EN
--
2.23.0
[PATCHv4 2/3] arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
Add missing linking regulator node to usb bus for power usb devices.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
Changes from previous patch
[1] https://lore.kernel.org/patchwork/patch/1031243/
split the changes and add the comments to power source
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 41d5fa370eb3..f3dcabf97c63 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -36,8 +36,15 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+ /*
+* signal name from schematics: PWREN
+*/
gpio = <_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /*
+* signal name from sehematics: USB_POWER
+*/
+ vin-supply = <>;
};
leds {
--
2.23.0
[PATCHv4 3/3] arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning
usb_otg bus needs to get initialize from the u-boot to be configured to used as power source to SBC or usb otg port will get configured as host device. Right now this support is missing in the u-boot and phy driver so to avoid power failed warning, we would disable this feature until proper fix is found. [2.716048] phy phy-c000.phy.0: USB ID detect failed! [2.720186] phy phy-c000.phy.0: phy poweron failed --> -22 [2.726001] [ cut here ] [2.730583] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8 [2.738983] Modules linked in: [2.742005] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.9-1-ARCH #1 [2.748643] Hardware name: Hardkernel ODROID-C2 (DT) [2.753566] Workqueue: events deferred_probe_work_func [2.758649] pstate: 6005 (nZCv daif -PAN -UAO) [2.763394] pc : _regulator_put+0x3c/0xe8 [2.767361] lr : _regulator_put+0x3c/0xe8 [2.771326] sp : 11aa3a50 [2.774604] x29: 11aa3a50 x28: 80007ed1b600 [2.779865] x27: 80007f7036a8 x26: 80007f7036a8 [2.785126] x25: x24: 11a44458 [2.790387] x23: 11344218 x22: 0009 [2.795649] x21: 11aa3b68 x20: 80007ed1b500 [2.800910] x19: 80007ed1b500 x18: 0010 [2.806171] x17: 5be5943c x16: f1c73b29 [2.811432] x15: x14: 117396c8 [2.816694] x13: 91aa37a7 x12: 11aa37af [2.821955] x11: 11763000 x10: 11aa3730 [2.827216] x9 : ffd0 x8 : 10871760 [2.832477] x7 : 00d0 x6 : 119d151b [2.837739] x5 : 000f x4 : [2.843000] x3 : x2 : 38104b2678c20100 [2.848261] x1 : x0 : 0024 [2.853523] Call trace: [2.855940] _regulator_put+0x3c/0xe8 [2.859562] regulator_put+0x34/0x48 [2.863098] regulator_bulk_free+0x40/0x58 [2.867153] devm_regulator_bulk_release+0x24/0x30 [2.871896] release_nodes+0x1f0/0x2e0 [2.875604] devres_release_all+0x64/0xa4 [2.879571] really_probe+0x1c8/0x3e0 [2.883194] driver_probe_device+0xe4/0x138 [2.887334] __device_attach_driver+0x90/0x110 [2.891733] bus_for_each_drv+0x8c/0xd8 [2.895527] __device_attach+0xdc/0x160 [2.899322] device_initial_probe+0x24/0x30 [2.903463] bus_probe_device+0x9c/0xa8 [2.907258] deferred_probe_work_func+0xa0/0xf0 [2.911745] process_one_work+0x1b4/0x408 [2.915711] worker_thread+0x54/0x4b8 [2.919334] kthread+0x12c/0x130 [2.922526] ret_from_fork+0x10/0x1c [2.926060] ---[ end trace 51a68f4c0035d6c0 ]--- [2.930691] [ cut here ] [2.935242] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8 [2.943653] Modules linked in: [2.946675] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: GW 5.2.9-1-ARCH #1 [2.954694] Hardware name: Hardkernel ODROID-C2 (DT) [2.959613] Workqueue: events deferred_probe_work_func [2.964700] pstate: 6005 (nZCv daif -PAN -UAO) [2.969445] pc : _regulator_put+0x3c/0xe8 [2.973412] lr : _regulator_put+0x3c/0xe8 [2.977377] sp : 11aa3a50 [2.980655] x29: 11aa3a50 x28: 80007ed1b600 [2.985916] x27: 80007f7036a8 x26: 80007f7036a8 [2.991177] x25: x24: 11a44458 [2.996439] x23: 11344218 x22: 0009 [3.001700] x21: 11aa3b68 x20: 80007ed1bd00 [3.006961] x19: 80007ed1bd00 x18: 0010 [3.01] x17: 5be5943c x16: f1c73b29 [3.017484] x15: x14: 117396c8 [3.022745] x13: 91aa37a7 x12: 11aa37af [3.028006] x11: 11763000 x10: 11aa3730 [3.033267] x9 : ffd0 x8 : 10871760 [3.038528] x7 : 00fd x6 : 119d151b [3.043790] x5 : 000f x4 : [3.049051] x3 : x2 : 38104b2678c20100 [3.054312] x1 : x0 : 0024 [3.059574] Call trace: [3.061991] _regulator_put+0x3c/0xe8 [3.065613] regulator_put+0x34/0x48 [3.069149] regulator_bulk_free+0x40/0x58 [3.073203] devm_regulator_bulk_release+0x24/0x30 [3.077947] release_nodes+0x1f0/0x2e0 [3.081655] devres_release_all+0x64/0xa4 [3.085622] really_probe+0x1c8/0x3e0 [3.089245] driver_probe_device+0xe4/0x138 [3.093385] __device_attach_driver+0x90/0x110 [3.097784] bus_for_each_drv+0x8c/0xd8 [3.101578] __device_attach+0xdc/0x160 [3.105373] device_initial_probe+0x24/0x30 [3.109514] bus_probe_device+0x9c/0xa8 [3.113309] deferred_probe_work_func+0xa0/0xf0 [3.117796] process_one_work+0x1b4/0x408 [3.121762] worker_thread+0x54/0x4b8 [3.125384] kthread+0x12c/0x130 [
[PATCHv4 0/3] Odroid c2 usb fixs
Some time ago I had tired to enable usb bus 1 for Odroid C2/C1 but it's look like some more work is needed to u-boot and usb_phy driver to initialize this port. Below patches tries to address the issue regarding usb bus 2 (4 port) while disable the usb bus 1 on this board. Prevoius patch [0] https://lkml.org/lkml/2019/1/29/325 I have tried to split the patchs for now. Anand Moon (3): arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 20 +-- 1 file changed, 18 insertions(+), 2 deletions(-) -- 2.23.0
Re: [git pull] drm fixes for 5.3-rc6 (the second coming)
The pull request you sent on Sat, 24 Aug 2019 15:22:55 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bc67b17eb91ea6a2b6d943bb64cde8d1438a11ec Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Hyper-V commits for v5.3-rc
The pull request you sent on Sat, 24 Aug 2019 10:59:21 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git > tags/hyperv-fixes-signed has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/361469211f876e67d7ca3d3d29e6d1c3e313d0f1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SCSI fixes for 5.3-rc5
The pull request you sent on Sat, 24 Aug 2019 10:23:28 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/17d0fbf47eb15ab7780cc77b28de070ec37e15c5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] xfs: fix for 5.3-rc6
The pull request you sent on Sat, 24 Aug 2019 09:27:05 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8942230a7e1c5277969adb0fbaad50dec9b4651b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [RESEND PATCHv4 0/3] fpga: altera-cvp: Add Stratix10 Support
Hi Thor, On Mon, Aug 19, 2019 at 03:48:05PM -0500, thor.tha...@linux.intel.com wrote: > From: Thor Thayer > > Newer versions (V2) of Altera/Intel FPGAs CvP have different PCI > Vendor Specific Capability offsets than the older (V1) Altera/FPGAs. > > Most of the CvP registers and their bitfields remain the same > between both the older parts and the newer parts. > > This patchset implements changes to discover the Vendor Specific > Capability offset and then add Stratix10 CvP support. > > V2 Changes: > Remove inline designator from abstraction functions. > Reverse Christmas Tree format for local variables > Remove redundant mask from credit calculation > Add commment for the delay(1) function in wait_for_credit() > > V3 Changes > Return int instead of void for abstraction functions > Check the return code from read in altera_cvp_chk_error() > Move reset of current_credit_byte to clear_state(). > Check return codes of read/writes in added functions. > > V4 Changes > Rename delta_credit to space > Simplify wait for credit do-while loop. > Change from udelay() to usleep_range() > Use min() to find length to send > Remove NULL initialization from private structure > Use #define for Version1 offsets > Change current_credit_byte to u32 sent_packets. > Changes to Kconfig title and description to support Stratix10. > > Thor Thayer (3): > fpga: altera-cvp: Discover Vendor Specific offset > fpga: altera-cvp: Preparation for V2 parts. > fpga: altera-cvp: Add Stratix10 (V2) Support > > drivers/fpga/Kconfig | 6 +- > drivers/fpga/altera-cvp.c | 339 > -- > 2 files changed, 271 insertions(+), 74 deletions(-) > > -- > 2.7.4 > Applied to for-next. If all goes well I'll send it out with next PR. - Moritz
Re: [PATCH 2/3] arm64: dts: ls1088a: Add the DSPI controller node
On Thu, Aug 01, 2019 at 04:31:04PM +0800, Chuanhua Han wrote:
> This patch adds the DSPI controller node for ls1088a boards.
>
> Signed-off-by: Chuanhua Han
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index dacd8cf..fe8f1bd 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -252,6 +252,19 @@
> #thermal-sensor-cells = <1>;
> };
>
> + dspi: spi@210 {
> + compatible = "fsl,ls1088a-dspi",
> + "fsl,ls1021a-v1.0-dspi";
I fixed the indent to have two compatible strings aligned on same
column when applying.
Shawn
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x210 0x0 0x1>;
> + interrupts = ;
> + clock-names = "dspi";
> + clocks = < 4 1>;
> + spi-num-chipselects = <6>;
> + status = "disabled";
> + };
> +
> duart0: serial@21c0500 {
> compatible = "fsl,ns16550", "ns16550a";
> reg = <0x0 0x21c0500 0x0 0x100>;
> --
> 2.9.5
>
Re: [PATCH 1/3] dt-bindings: fsl: dspi: Add fsl,ls1088a-dspi compatible string
On Thu, Aug 01, 2019 at 04:31:03PM +0800, Chuanhua Han wrote: > new compatible string: "fsl,ls1088a-dspi". > > Signed-off-by: Chuanhua Han Applied all, thanks.
Re: [PATCH] ARM: imx: Drop imx_anatop_init()
On Thu, Aug 22, 2019 at 05:33:13PM +, Leonard Crestez wrote:
> On 31.07.2019 21:01, Andrey Smirnov wrote:
> > With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
> > detect in mxs_phy_hw_init()") in tree all of the necessary charger
> > setup is done by the USB PHY driver which covers all of the affected
> > i.MX6 SoCs.
> >
> > NOTE: Imx_anatop_init() was also called for i.MX7D, but looking at its
> > datasheet it appears to have a different USB PHY IP block, so
> > executing i.MX6 charger disable configuration seems unnecessary.
> >
> > -void __init imx_anatop_init(void)
> > -{
> > - anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
> > - if (IS_ERR(anatop)) {
> > - pr_err("%s: failed to find imx6q-anatop regmap!\n", __func__);
> > - return;
> > - }
>
> This patch breaks suspend on imx6 in linux-next because the "anatop"
> regmap is no longer initialized. This was found via bisect but
> no_console_suspend prints a helpful stack anyway:
>
> (regmap_read) from [] (imx_anatop_enable_weak2p5+0x28/0x70)
> (imx_anatop_enable_weak2p5) from []
> (imx_anatop_pre_suspend+0x18/0x64)
> (imx_anatop_pre_suspend) from [] (imx6q_pm_enter+0x60/0x16c)
> (imx6q_pm_enter) from [] (suspend_devices_and_enter+0x7d4/0xcbc)
> (suspend_devices_and_enter) from [] (pm_suspend+0x7b8/0x904)
> (pm_suspend) from [] (state_store+0x68/0xc8)
I dropped it from my branch for now. Thanks for reporting!
Shawn
Re: [PATCH] ARM: dts: pbab01: correct rtc vendor
On Thu, Aug 22, 2019 at 11:35 PM Alexandre Belloni wrote: > > The rtc8564 is made by Epson but is similar to the NXP pcf8563. Use the > correct vendor name. > > Signed-off-by: Alexandre Belloni Please use my kernel.org mailbox for future patches. Applied, thanks.
Official request
<<< No Message Collected >>>
Re: [PATCH 4.4 00/78] 4.4.190-stable review
On Sat, Aug 24, 2019 at 12:03:07PM -0600, shuah wrote: > On 8/22/19 11:18 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.190 release. > > There are 78 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 24 Aug 2019 05:18:13 PM UTC. > > 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.4.190-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.4.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On Sat, Aug 24, 2019 at 11:01:19AM -0600, shuah wrote: > On 8/24/19 9:33 AM, Greg KH wrote: > > On Sat, Aug 24, 2019 at 09:21:53AM -0600, shuah wrote: > > > On 8/23/19 8:38 PM, Greg KH wrote: > > > > On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: > > > > > On 8/22/19 11:05 AM, Sasha Levin wrote: > > > > > > > > > > > > This is the start of the stable review cycle for the 5.2.10 release. > > > > > > There are 135 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 24 Aug 2019 05:07:10 PM UTC. > > > > > > 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-5.2.10-rc1.gz > > > > > > > > > > I am seeing "Sorry I can't find your kernels". Is this posted? > > > > > > > > Ah, Sasha didn't generate the patch but it was still listed here, oops. > > > > He copied my format and we didn't notice this, sorry about that. > > > > > > > > As the thread shows, we didn't generate this file this time to see what > > > > would happen. If your test process requires it, we can generate it as I > > > > don't want to break it. > > > > > > > > > > It will make it lot easier for me to have continued support for patch > > > generation. My scripts do "wget" to pull the patch and apply. > > > > Ok, we will get this back and working, sorry about that. > > > > Great. Thanks for accommodating my workflow. I have uploaded it to kernel.org now, should show up on the "public side" in 15 minutes or so. thanks, greg k-h
Re: [PATCH RT v2 1/3] rcu: Acquire RCU lock when disabling BHs
On Thu, Aug 22, 2019 at 10:23:23PM -0500, Scott Wood wrote:
> On Thu, 2019-08-22 at 09:39 -0400, Joel Fernandes wrote:
> > On Wed, Aug 21, 2019 at 04:33:58PM -0700, Paul E. McKenney wrote:
> > > On Wed, Aug 21, 2019 at 06:19:04PM -0500, Scott Wood wrote:
[ . . . ]
> > > > include/linux/rcupdate.h | 4
> > > > kernel/rcu/update.c | 4
> > > > kernel/softirq.c | 12 +---
> > > > 3 files changed, 17 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index 388ace315f32..d6e357378732 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -615,10 +615,12 @@ static inline void rcu_read_unlock(void)
> > > > static inline void rcu_read_lock_bh(void)
> > > > {
> > > > local_bh_disable();
> > > > +#ifndef CONFIG_PREEMPT_RT_FULL
> > > > __acquire(RCU_BH);
> > > > rcu_lock_acquire(_bh_lock_map);
> > > > RCU_LOCKDEP_WARN(!rcu_is_watching(),
> > > > "rcu_read_lock_bh() used illegally while
> > > > idle");
> > > > +#endif
> > >
> > > Any chance of this using "if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL))"?
> > > We should be OK providing a do-nothing __maybe_unused rcu_bh_lock_map
> > > for lockdep-enabled -rt kernels, right?
> >
> > Since this function is small, I prefer if -rt defines their own
> > rcu_read_lock_bh() which just does the local_bh_disable(). That would be
> > way
> > cleaner IMO. IIRC, -rt does similar things for spinlocks, but it has been
> > sometime since I look at the -rt patchset.
>
> I'll do it whichever way you all decide, though I'm not sure I agree about
> it being cleaner (especially while RT is still out-of-tree and a change to
> the non-RT version that fails to trigger a merge conflict is a concern).
>
> What about moving everything but the local_bh_disable into a separate
> function called from rcu_read_lock_bh, and making that a no-op on RT?
That makes a lot of sense to me!
Thanx, Paul
Re: [GIT PULL rcu/next + tools/memory-model] RCU and LKMM commits for 5.4
On Sat, Aug 24, 2019 at 02:01:02PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > On Thu, Aug 22, 2019 at 08:54:29PM +0200, Ingo Molnar wrote: > > > > [ . . . ] > > > > > Pulled into tip:core/rcu, thanks a lot Paul! > > > > Thank you! > > > > > The merge commit is a bit non-standard: > > > > > > 07f038a408fb: Merge LKMM and RCU commits > > > > > > but clear enough IMHO. Usually we try to keep this format: > > > > > > 6c06b66e957c: Merge branch 'X' into Y > > > > > > even for internal merge commits. > > > > Please accept my apologies! How about as shown below? If this works > > for you, I will rebase my development commits on top this merge commit > > in order to make sure I don't revert back to my old format for next > > merge window. > > Looks good - but I don't think we should create a new merge commit just > for this. Ah, right -- I need to keep my development commits on top of the old merge commit to enable the likely additional pull request that I mentioned below. Good point! ;-) Thanx, Paul > > Ah, speaking of reminding me... There is likely to be one more small RCU > > commit requested by the RISC-V guys. If testing and review goes well, > > I will send you a pull request for it by the middle of next week. > > Thanks! > > Ingo
Re: [PATCH 4.4 00/78] 4.4.190-stable review
On 8/22/19 11:18 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.190 release. There are 78 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 24 Aug 2019 05:18:13 PM UTC. 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.4.190-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.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 000/103] 4.9.190-stable review
On 8/22/19 11:17 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.190 release. There are 103 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 24 Aug 2019 05:15:44 PM UTC. 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.9.190-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.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
