[RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver
Expose the virtio-rtc UTC clock as an RTC clock to userspace, if it is
present. Support RTC alarm if the virtio-rtc alarm feature is present. The
virtio-rtc device signals an alarm by marking an alarmq buffer as used.
Peculiarities
-
A virtio-rtc clock is a bit special for an RTC clock in that
- the clock may step (also backwards) autonomously at any time and
- the device, and its notification mechanism, will be reset during boot or
resume from sleep.
The virtio-rtc device avoids that the driver might miss an alarm. The
device signals an alarm whenever the clock has reached or passed the alarm
time, and also when the device is reset (on boot or resume from sleep), if
the alarm time is in the past.
Open Issue
--
The CLOCK_BOOTTIME_ALARM will use the RTC clock to wake up from sleep, and
implicitly assumes that no RTC clock steps will occur during sleep. The RTC
class driver does not know whether the current alarm is a real-time alarm
or a boot-time alarm.
Perhaps this might be handled by the driver also setting a virtio-rtc
monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). The
virtio-rtc monotonic alarm would just be used to wake up in case it was a
CLOCK_BOOTTIME_ALARM alarm.
Otherwise, the behavior should not differ from other RTC class drivers.
Signed-off-by: Peter Hilber
---
Notes:
Added in v3.
drivers/virtio/Kconfig | 21 +-
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_rtc_class.c| 269 +++
drivers/virtio/virtio_rtc_driver.c | 477 ++-
drivers/virtio/virtio_rtc_internal.h | 53 +++
include/uapi/linux/virtio_rtc.h | 88 -
6 files changed, 902 insertions(+), 7 deletions(-)
create mode 100644 drivers/virtio/virtio_rtc_class.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index d35c728778d2..e97bb2e9eca1 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -180,7 +180,8 @@ config VIRTIO_RTC
help
This driver provides current time from a Virtio RTC device. The driver
provides the time through one or more clocks. The Virtio RTC PTP
-clocks must be enabled to expose the clocks to userspace.
+clocks and/or the Real Time Clock driver for Virtio RTC must be
+enabled to expose the clocks to userspace.
To compile this code as a module, choose M here: the module will be
called virtio_rtc.
@@ -189,8 +190,8 @@ config VIRTIO_RTC
if VIRTIO_RTC
-comment "WARNING: Consider enabling VIRTIO_RTC_PTP."
- depends on !VIRTIO_RTC_PTP
+comment "WARNING: Consider enabling VIRTIO_RTC_PTP and/or VIRTIO_RTC_CLASS."
+ depends on !VIRTIO_RTC_PTP && !VIRTIO_RTC_CLASS
comment "Enable PTP_1588_CLOCK in order to enable VIRTIO_RTC_PTP."
depends on PTP_1588_CLOCK=n
@@ -218,6 +219,20 @@ config VIRTIO_RTC_ARM
If unsure, say Y.
+comment "Enable RTC_CLASS in order to enable VIRTIO_RTC_CLASS."
+ depends on RTC_CLASS=n
+
+config VIRTIO_RTC_CLASS
+ bool "Real Time Clock driver for Virtio RTC"
+ default y
+ depends on RTC_CLASS
+ help
+This exposes the Virtio RTC UTC clock as a Linux Real Time Clock. It
+only has an effect if the Virtio RTC device has a UTC clock. The Real
+Time Clock is read-only, and may support setting an alarm.
+
+If unsure, say Y.
+
endif # VIRTIO_RTC
endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 781dff9f8822..6c26bad777db 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
virtio_rtc-y := virtio_rtc_driver.o
virtio_rtc-$(CONFIG_VIRTIO_RTC_PTP) += virtio_rtc_ptp.o
virtio_rtc-$(CONFIG_VIRTIO_RTC_ARM) += virtio_rtc_arm.o
+virtio_rtc-$(CONFIG_VIRTIO_RTC_CLASS) += virtio_rtc_class.o
diff --git a/drivers/virtio/virtio_rtc_class.c
b/drivers/virtio/virtio_rtc_class.c
new file mode 100644
index ..fcb694f0f9a0
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_class.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * virtio_rtc RTC class driver
+ *
+ * Copyright (C) 2023 OpenSynergy GmbH
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "virtio_rtc_internal.h"
+
+/**
+ * struct viortc_class - RTC class wrapper
+ * @viortc: virtio_rtc device data
+ * @rtc: RTC device
+ * @vio_clk_id: virtio_rtc clock id
+ * @stopped: Whether RTC ops are disallowed. Access protected by rtc_lock().
+ */
+struct viortc_class {
+ struct viortc_dev *viortc;
+ struct rtc_device *rtc;
+ u16 vio_clk_id;
+ bool stopped;
+};
+
+/**
+ * viortc_class_get_locked() - get RTC class wrapper, if ops allowed
+ * @dev: virtio device
+ *
+ * Gets the RTC class wrapper from the virtio device, if it is available and
+ * ops are allowed.
+ *
+ * Context: Caller must hold rtc_lock().
+ * Return: RTC class wrapper if available and ops
[RFC PATCH v3 4/7] virtio_rtc: Add module and driver core
Add the virtio_rtc module and driver core. The virtio_rtc module implements
a driver compatible with the proposed Virtio RTC device specification.
The Virtio RTC (Real Time Clock) device provides information about current
time. The device can provide different clocks, e.g. for the UTC or TAI time
standards, or for physical time elapsed since some past epoch. The driver
can read the clocks with simple or more accurate methods.
Implement the core, which interacts with the Virtio RTC device. Apart from
this, the core does not expose functionality outside of the virtio_rtc
module. A follow-up patch will expose PTP clocks.
Provide synchronous messaging, which is enough for the expected time
synchronization use cases through PTP clocks (similar to ptp_kvm) or RTC
Class driver.
Signed-off-by: Peter Hilber
---
Notes:
v3:
- merge readq and controlq into a single requestq (spec v3)
- don't guard cross-timestamping with feature bit (spec v3)
- pad message headers to 64 bits (spec v3)
- reduce clock id to 16 bits (spec v3)
- change Virtio status codes (spec v3)
- use 'VIRTIO_RTC_REQ_' prefix for request messages (spec v3)
MAINTAINERS | 7 +
drivers/virtio/Kconfig | 13 +
drivers/virtio/Makefile | 2 +
drivers/virtio/virtio_rtc_driver.c | 761 +++
drivers/virtio/virtio_rtc_internal.h | 23 +
include/uapi/linux/virtio_rtc.h | 144 +
6 files changed, 950 insertions(+)
create mode 100644 drivers/virtio/virtio_rtc_driver.c
create mode 100644 drivers/virtio/virtio_rtc_internal.h
create mode 100644 include/uapi/linux/virtio_rtc.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..0c157a19bbfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23200,6 +23200,13 @@ S: Maintained
F: drivers/nvdimm/nd_virtio.c
F: drivers/nvdimm/virtio_pmem.c
+VIRTIO RTC DRIVER
+M: Peter Hilber
+L: virtualizat...@lists.linux.dev
+S: Maintained
+F: drivers/virtio/virtio_rtc_*
+F: include/uapi/linux/virtio_rtc.h
+
VIRTIO SOUND DRIVER
M: Anton Yakovlev
M: "Michael S. Tsirkin"
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 0a53a61231c2..834dd14bc070 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -173,4 +173,17 @@ config VIRTIO_DMA_SHARED_BUFFER
This option adds a flavor of dma buffers that are backed by
virtio resources.
+config VIRTIO_RTC
+ tristate "Virtio RTC driver"
+ depends on VIRTIO
+ depends on PTP_1588_CLOCK_OPTIONAL
+ help
+This driver provides current time from a Virtio RTC device. The driver
+provides the time through one or more clocks.
+
+To compile this code as a module, choose M here: the module will be
+called virtio_rtc.
+
+If unsure, say M.
+
endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 8e98d24917cc..f760414ed6ab 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -12,3 +12,5 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o
obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
+obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
+virtio_rtc-y := virtio_rtc_driver.o
diff --git a/drivers/virtio/virtio_rtc_driver.c
b/drivers/virtio/virtio_rtc_driver.c
new file mode 100644
index ..ef1ea14b3bec
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -0,0 +1,761 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * virtio_rtc driver core
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "virtio_rtc_internal.h"
+
+/* virtqueue order */
+enum {
+ VIORTC_REQUESTQ,
+ VIORTC_MAX_NR_QUEUES,
+};
+
+/**
+ * struct viortc_vq - virtqueue abstraction
+ * @vq: virtqueue
+ * @lock: protects access to vq
+ */
+struct viortc_vq {
+ struct virtqueue *vq;
+ spinlock_t lock;
+};
+
+/**
+ * struct viortc_dev - virtio_rtc device data
+ * @vdev: virtio device
+ * @vqs: virtqueues
+ * @num_clocks: # of virtio_rtc clocks
+ */
+struct viortc_dev {
+ struct virtio_device *vdev;
+ struct viortc_vq vqs[VIORTC_MAX_NR_QUEUES];
+ u16 num_clocks;
+};
+
+/**
+ * struct viortc_msg - Message requested by driver, responded by device.
+ * @viortc: device data
+ * @req: request buffer
+ * @resp: response buffer
+ * @responded: vqueue callback signals response reception
+ * @refcnt: Message reference count, message and buffers will be deallocated
+ * once 0. refcnt is decremented in the vqueue callback and in the
+ * thread waiting on the responded completion.
+ * If a message response wait function times out, the message will be
+ * freed upon late reception (refcnt will reach 0 in the callback), or
+ * device
[RFC PATCH v3 5/7] virtio_rtc: Add PTP clocks
Expose the virtio_rtc clocks as PTP clocks to userspace, similar to
ptp_kvm. virtio_rtc can expose multiple clocks, e.g. a UTC clock and a
monotonic clock. Userspace should distinguish different clocks through the
name assigned by the driver. A udev rule such as the following can be used
to get a symlink /dev/ptp_virtio to the UTC clock:
SUBSYSTEM=="ptp", ATTR{clock_name}=="Virtio PTP UTC", SYMLINK +=
"ptp_virtio"
The preferred PTP clock reading method is ioctl PTP_SYS_OFFSET_PRECISE2,
through the ptp_clock_info.getcrosststamp() op. For now,
PTP_SYS_OFFSET_PRECISE2 will return -EOPNOTSUPP through a weak function.
PTP_SYS_OFFSET_PRECISE2 requires cross-timestamping support for specific
clocksources, which will be added in the following. If the clocksource
specific code is enabled, check that the Virtio RTC device supports the
respective HW counter before obtaining an actual cross-timestamp from the
Virtio device.
The Virtio RTC device response time may be higher than the timekeeper
seqcount increment interval. Therefore, obtain the cross-timestamp before
calling get_device_system_crosststamp().
As a fallback, support the ioctl PTP_SYS_OFFSET_EXTENDED2 for all
platforms.
Assume that concurrency issues during PTP clock removal are avoided by the
posix_clock framework.
Kconfig recursive dependencies prevent virtio_rtc from implicitly enabling
PTP_1588_CLOCK, therefore just warn the user if PTP_1588_CLOCK is not
available. Since virtio_rtc should in the future also expose clocks as RTC
class devices, do not have VIRTIO_RTC depend on PTP_1588_CLOCK.
Signed-off-by: Peter Hilber
---
Notes:
v3:
- don't guard cross-timestamping with feature bit (spec v3)
- reduce clock id to 16 bits (spec v3)
v2:
- Depend on prerequisite patch series "treewide: Use clocksource id for
get_device_system_crosststamp()".
- Check clocksource id before sending crosststamp message to device.
- Do not support multiple hardware counters at runtime any more, since
distinction of Arm physical and virtual counter appears unneeded after
discussion with Marc Zyngier.
drivers/virtio/Kconfig | 23 +-
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_rtc_driver.c | 131 +-
drivers/virtio/virtio_rtc_internal.h | 46
drivers/virtio/virtio_rtc_ptp.c | 342 +++
5 files changed, 539 insertions(+), 4 deletions(-)
create mode 100644 drivers/virtio/virtio_rtc_ptp.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 834dd14bc070..8542b2f20201 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -179,11 +179,32 @@ config VIRTIO_RTC
depends on PTP_1588_CLOCK_OPTIONAL
help
This driver provides current time from a Virtio RTC device. The driver
-provides the time through one or more clocks.
+provides the time through one or more clocks. The Virtio RTC PTP
+clocks must be enabled to expose the clocks to userspace.
To compile this code as a module, choose M here: the module will be
called virtio_rtc.
If unsure, say M.
+if VIRTIO_RTC
+
+comment "WARNING: Consider enabling VIRTIO_RTC_PTP."
+ depends on !VIRTIO_RTC_PTP
+
+comment "Enable PTP_1588_CLOCK in order to enable VIRTIO_RTC_PTP."
+ depends on PTP_1588_CLOCK=n
+
+config VIRTIO_RTC_PTP
+ bool "Virtio RTC PTP clocks"
+ default y
+ depends on PTP_1588_CLOCK
+ help
+This exposes any Virtio RTC clocks as PTP Hardware Clocks (PHCs) to
+userspace.
+
+If unsure, say Y.
+
+endif # VIRTIO_RTC
+
endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index f760414ed6ab..4d48cbcae6bb 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
virtio_rtc-y := virtio_rtc_driver.o
+virtio_rtc-$(CONFIG_VIRTIO_RTC_PTP) += virtio_rtc_ptp.o
diff --git a/drivers/virtio/virtio_rtc_driver.c
b/drivers/virtio/virtio_rtc_driver.c
index ef1ea14b3bec..c331b7383285 100644
--- a/drivers/virtio/virtio_rtc_driver.c
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -35,11 +35,16 @@ struct viortc_vq {
* struct viortc_dev - virtio_rtc device data
* @vdev: virtio device
* @vqs: virtqueues
+ * @clocks_to_unregister: Clock references, which are only used during device
+ *removal.
+ * For other uses, there would be a race between device
+ * creation and setting the pointers here.
* @num_clocks: # of virtio_rtc clocks
*/
struct viortc_dev {
struct virtio_device *vdev;
struct viortc_vq vqs[VIORTC_MAX_NR_QUEUES];
+ struct viortc_ptp_clock **clocks_to_unregister;
u16 num_clocks;
};
@@ -626,6 +631,109 @@ int
[RFC PATCH v3 6/7] virtio_rtc: Add Arm Generic Timer cross-timestamping
Add PTP_SYS_OFFSET_PRECISE2 support on platforms using the Arm Generic
Timer.
Always report the CP15 virtual counter as the HW counter in use by
arm_arch_timer, since the Linux kernel's usage of the Arm Generic Timer
should always be compatible with this.
Signed-off-by: Peter Hilber
---
Notes:
v2:
- Depend on prerequisite patch series "treewide: Use clocksource id for
get_device_system_crosststamp()".
- Return clocksource id instead of calling dropped arm_arch_timer helpers.
- Always report the CP15 virtual counter to be in use by arm_arch_timer,
since distinction of Arm physical and virtual counter appears unneeded
after discussion with Marc Zyngier.
drivers/virtio/Kconfig | 13 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_rtc_arm.c | 22 ++
3 files changed, 36 insertions(+)
create mode 100644 drivers/virtio/virtio_rtc_arm.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 8542b2f20201..d35c728778d2 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -205,6 +205,19 @@ config VIRTIO_RTC_PTP
If unsure, say Y.
+config VIRTIO_RTC_ARM
+ bool "Virtio RTC cross-timestamping using Arm Generic Timer"
+ default y
+ depends on VIRTIO_RTC_PTP && ARM_ARCH_TIMER
+ help
+This enables Virtio RTC cross-timestamping using the Arm Generic Timer.
+It only has an effect if the Virtio RTC device also supports this. The
+cross-timestamp is available through the PTP clock driver precise
+cross-timestamp ioctl (PTP_SYS_OFFSET_PRECISE2 or
+PTP_SYS_OFFSET_PRECISE).
+
+If unsure, say Y.
+
endif # VIRTIO_RTC
endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 4d48cbcae6bb..781dff9f8822 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
virtio_rtc-y := virtio_rtc_driver.o
virtio_rtc-$(CONFIG_VIRTIO_RTC_PTP) += virtio_rtc_ptp.o
+virtio_rtc-$(CONFIG_VIRTIO_RTC_ARM) += virtio_rtc_arm.o
diff --git a/drivers/virtio/virtio_rtc_arm.c b/drivers/virtio/virtio_rtc_arm.c
new file mode 100644
index ..5185b130b3f1
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_arm.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Provides cross-timestamp params for Arm.
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#include
+
+#include
+
+#include "virtio_rtc_internal.h"
+
+/* see header for doc */
+
+int viortc_hw_xtstamp_params(u16 *hw_counter, enum clocksource_ids *cs_id)
+{
+ *hw_counter = VIRTIO_RTC_COUNTER_ARM_VIRT;
+ *cs_id = CSID_ARM_ARCH_COUNTER;
+
+ return 0;
+}
--
2.40.1
[RFC PATCH v3 0/7] Add virtio_rtc module and related changes
RFC v3 updates
--
This series implements a driver for a virtio-rtc device conforming to spec
RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to
the PTP clock driver already present before.
This patch series depends on the patch series "treewide: Use clocksource id
for get_device_system_crosststamp()" [3]. Pull [4] to get the combined
series on top of mainline.
Overview
This patch series adds the virtio_rtc module, and related bugfixes. The
virtio_rtc module implements a driver compatible with the proposed Virtio
RTC device specification [1]. The Virtio RTC (Real Time Clock) device
provides information about current time. The device can provide different
clocks, e.g. for the UTC or TAI time standards, or for physical time
elapsed since some past epoch. The driver can read the clocks with simple
or more accurate methods. Optionally, the driver can set an alarm.
The series first fixes some bugs in the get_device_system_crosststamp()
interpolation code, which is required for reliable virtio_rtc operation.
Then, add the virtio_rtc implementation.
For the Virtio RTC device, there is currently a proprietary implementation,
which has been used for provisional testing.
PTP clock interface
---
virtio_rtc exposes clocks as PTP clocks to userspace, similar to ptp_kvm.
If both the Virtio RTC device and this driver have special support for the
current clocksource, time synchronization programs can use
cross-timestamping using ioctl PTP_SYS_OFFSET_PRECISE2 aka
PTP_SYS_OFFSET_PRECISE. Similar to ptp_kvm, system time synchronization
with single-digit ns precision is possible with a quiescent reference clock
(from the Virtio RTC device). This works even when the Virtio device
response is slow compared to ptp_kvm hypercalls.
The following illustrates a test using PTP_SYS_OFFSET_PRECISE, with
interspersed strace log and chrony [2] refclocks log, on arm64. In the
example, chrony tracks a virtio_rtc PTP clock ("PHCV", /dev/ptp0). The raw
offset between the virtio_rtc clock and CLOCK_REALTIME is 0 to 1 ns. At the
device side, the Virtio RTC device artificially delays both the clock read
request, and the response, by 50 ms. Cross-timestamp interpolation still
works with this delay. chrony also monitors a ptp_kvm clock ("PHCK",
/dev/ptp3) for comparison, which yields a similar offset.
ioctl(5, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.000329>
===
Date (UTC) Time Refid DP L P Raw offset Cooked offset
Disp.
===
2023-06-29 18:49:55.595742 PHCK0 N 0 1.00e-09 8.717931e-10
5.500e-08
2023-06-29 18:49:55.595742 PHCK- N - -8.717931e-10
5.500e-08
ioctl(6, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.101545>
2023-06-29 18:49:56.147766 PHCV0 N 0 1.00e-09 8.801870e-10
5.500e-08
2023-06-29 18:49:56.147766 PHCV- N - -8.801870e-10
5.500e-08
ioctl(5, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.000195>
2023-06-29 18:49:56.202446 PHCK0 N 0 1.00e-09 7.364180e-10
5.500e-08
2023-06-29 18:49:56.202446 PHCK- N - -7.364180e-10
5.500e-08
ioctl(6, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.101484>
2023-06-29 18:49:56.754641 PHCV0 N 0 0.00e+00 -2.617368e-10
5.500e-08
2023-06-29 18:49:56.754641 PHCV- N - - -2.617368e-10
5.500e-08
ioctl(5, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.000270>
2023-06-29 18:49:56.809282 PHCK0 N 0 1.00e-09 7.779321e-10
5.500e-08
2023-06-29 18:49:56.809282 PHCK- N - -7.779321e-10
5.500e-08
ioctl(6, PTP_SYS_OFFSET_PRECISE, 0xe86691c8) = 0
<0.101510>
2023-06-29 18:49:57.361376 PHCV0 N 0 0.00e+00 -2.198794e-10
5.500e-08
2023-06-29 18:49:57.361376 PHCV- N - - -2.198794e-10
5.500e-08
This patch series only adds special support for the Arm Generic Timer
clocksource. At the driver side, it should be easy to support more
clocksources.
Fallback PTP clock interface
Without special support for the current clocksource, time synchronization
programs can still use ioctl PTP_SYS_OFFSET_EXTENDED2 aka
PTP_SYS_OFFSET_EXTENDED. In this case, precision will generally be worse
and will depend on the Virtio device response characteristics.
The following illustrates a test using PTP_SYS_OFFSET_EXTENDED, with
interspersed strace log and chrony refclocks log, on x86-64 (with `ts'
values omitted):
ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
===
Date (UTC) Time Refid DP L P
[mhiramat:topic/fprobe-on-fgraph] [function_graph] b92a5e78c3: WARNING:at_kernel/trace/trace.c:#run_tracer_selftest
Hello,
kernel test robot noticed
"WARNING:at_kernel/trace/trace.c:#run_tracer_selftest" on:
commit: b92a5e78c35fde3c1be7263b39724388482a4bd9 ("function_graph: Add a new
entry handler with parent_ip and ftrace_regs")
https://git.kernel.org/cgit/linux/kernel/git/mhiramat/linux.git
topic/fprobe-on-fgraph
in testcase: trinity
version: trinity-i386-abe9de86-1_20230429
with following parameters:
runtime: 600s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
compiler: gcc-12
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
+--+++
|
| 26fcffc6d7 | b92a5e78c3 |
+--+++
| WARNING:at_kernel/trace/trace.c:#run_tracer_selftest
| 0 | 8 |
| EIP:run_tracer_selftest
| 0 | 8 |
+--+++
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-lkp/202312181100.508f8f48-oliver.s...@intel.com
[5.502226][T1] [ cut here ]
[ 5.502226][ T1] WARNING: CPU: 1 PID: 1 at kernel/trace/trace.c:2031
run_tracer_selftest (kernel/trace/trace.c:2031 (discriminator 1))
[5.502899][T1] Modules linked in:
[5.503348][T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
6.7.0-rc2-00034-gb92a5e78c35f #1
[5.504358][T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 5.505125][ T1] EIP: run_tracer_selftest (kernel/trace/trace.c:2031
(discriminator 1))
[ 5.505764][ T1] Code: ff ff a3 18 30 4b c2 89 f8 89 15 1c 30 4b c2 e8 cb b1 ff
ff 89 f8 e8 58 52 ff ff e9 c1 fe ff ff 68 50 d6 f9 c1 e8 2d 61 f7 ff <0f> 0b b8
ff ff ff ff 5a e9 22 ff ff ff b8 f4 ff ff ff e9 18 ff ff
All code
0: ff (bad)
1: ff a3 18 30 4b c2 jmp*-0x3db4cfe8(%rbx)
7: 89 f8 mov%edi,%eax
9: 89 15 1c 30 4b c2 mov%edx,-0x3db4cfe4(%rip)#
0xc24b302b
f: e8 cb b1 ff ff call 0xb1df
14: 89 f8 mov%edi,%eax
16: e8 58 52 ff ff call 0x5273
1b: e9 c1 fe ff ff jmp0xfee1
20: 68 50 d6 f9 c1 push $0xc1f9d650
25: e8 2d 61 f7 ff call 0xfff76157
2a:* 0f 0b ud2 <-- trapping instruction
2c: b8 ff ff ff ff mov$0x,%eax
31: 5a pop%rdx
32: e9 22 ff ff ff jmp0xff59
37: b8 f4 ff ff ff mov$0xfff4,%eax
3c: e9 .byte 0xe9
3d: 18 ff sbb%bh,%bh
3f: ff .byte 0xff
Code starting with the faulting instruction
===
0: 0f 0b ud2
2: b8 ff ff ff ff mov$0x,%eax
7: 5a pop%rdx
8: e9 22 ff ff ff jmp0xff2f
d: b8 f4 ff ff ff mov$0xfff4,%eax
12: e9 .byte 0xe9
13: 18 ff sbb%bh,%bh
15: ff .byte 0xff
[5.508031][T1] EAX: 0007 EBX: c1f9fa5b ECX: EDX:
[5.508856][T1] ESI: c25e18e0 EDI: c0109500 EBP: c031bed4 ESP: c031bec4
[5.513135][T1] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS:
00010286
[5.514023][T1] CR0: 80050033 CR2: CR3: 02763000 CR4: 000406d0
[5.514855][T1] DR0: DR1: DR2: DR3:
[5.515688][T1] DR6: fffe0ff0 DR7: 0400
[5.516235][T1] Call Trace:
[ 5.516632][ T1] ? show_regs (arch/x86/kernel/dumpstack.c:479)
[ 5.517125][ T1] ? run_tracer_selftest (kernel/trace/trace.c:2031
(discriminator 1))
[ 5.517722][ T1] ? __warn (kernel/panic.c:677)
[ 5.518185][ T1] ? run_tracer_selftest (kernel/trace/trace.c:2031
(discriminator 1))
[ 5.518797][ T1] ? report_bug (lib/bug.c:201 lib/bug.c:219)
[ 5.519323][ T1] ? exc_overflow (arch/x86/kernel/traps.c:250)
[ 5.519844][ T1] ? handle_bug (arch/x86/kernel/traps.c:216)
[ 5.520351][ T1] ? exc_invalid_op (arch/x86/kernel/traps.c:258 (discriminator
1))
[ 5.521153][ T1] ? handle_exception (arch/x86/entry/entry_32.S:1049)
[
[PATCH V3] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the current implementation.
Add support to pass crash_reason_partition along with crash_reason_item
number in qcom_q6v5_init call and use the same to get the crash
information from SMEM in fatal and watchdog IRQ handlers.
Signed-off-by: Vignesh Viswanathan
---
Changes in V3: Updated commit message.
Changes in V2: Addressed comments in V1.
This patch depends on [1] which adds support for IPQ9574 and IPQ5332
remoteproc q5v5_mpd driver.
[1]:
https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
drivers/remoteproc/qcom_q6v5.c | 10 ++
drivers/remoteproc/qcom_q6v5.h | 6 --
drivers/remoteproc/qcom_q6v5_adsp.c | 5 +++--
drivers/remoteproc/qcom_q6v5_mpd.c | 14 --
drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
7 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 0e32f13c196d..e4a28bf25130 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -100,7 +100,7 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
+ msg = qcom_smem_get(q6v5->crash_reason_partition,
q6v5->crash_reason_item, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "watchdog received: %s\n", msg);
else
@@ -121,7 +121,7 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
if (!q6v5->running)
return IRQ_HANDLED;
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
+ msg = qcom_smem_get(q6v5->crash_reason_partition,
q6v5->crash_reason_item, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "fatal error received: %s\n", msg);
else
@@ -279,14 +279,16 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
* Return: 0 on success, negative errno on failure
*/
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason_partition,
+ int crash_reason_item, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5))
{
int ret;
q6v5->rproc = rproc;
q6v5->dev = >dev;
- q6v5->crash_reason = crash_reason;
+ q6v5->crash_reason_partition = crash_reason_partition;
+ q6v5->crash_reason_item = crash_reason_item;
q6v5->handover = handover;
init_completion(>start_done);
diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
index 4e1bb1a68284..cd02372e9856 100644
--- a/drivers/remoteproc/qcom_q6v5.h
+++ b/drivers/remoteproc/qcom_q6v5.h
@@ -40,7 +40,8 @@ struct qcom_q6v5 {
struct completion stop_done;
struct completion spawn_done;
- int crash_reason;
+ int crash_reason_partition;
+ int crash_reason_item;
bool running;
@@ -49,7 +50,8 @@ struct qcom_q6v5 {
};
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason_partition,
+ int crash_reason_item, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5));
void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 6c67514cc493..8feb2eb45737 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -731,8 +731,9 @@ static int adsp_probe(struct platform_device *pdev)
if (ret)
goto disable_pm;
- ret = qcom_q6v5_init(>q6v5, pdev, rproc, desc->crash_reason_smem,
-desc->load_state, qcom_adsp_pil_handover);
+ ret = qcom_q6v5_init(>q6v5, pdev, rproc, QCOM_SMEM_HOST_ANY,
+desc->crash_reason_smem, desc->load_state,
+qcom_adsp_pil_handover);
if (ret)
goto disable_pm;
diff --git a/drivers/remoteproc/qcom_q6v5_mpd.c
b/drivers/remoteproc/qcom_q6v5_mpd.c
index b133285888c7..c893deac30e1 100644
--- a/drivers/remoteproc/qcom_q6v5_mpd.c
+++ b/drivers/remoteproc/qcom_q6v5_mpd.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -555,9 +556,9 @@ static int q6_get_outbound_irq(struct
Re: [PATCH V2] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On 12/18/2023 11:36 AM, Vignesh Viswanathan wrote:
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
> present in target specific partition due to which the crash reason is
> not printed in the current implementation.
>
> Add support to pass crash_reason_smem_id along with crash_reason item
> number in qcom_q6v5_init call and use the same to get the crash
> information from SMEM in fatal and watchdog IRQ handlers.
This commit message needs a minor update, please ignore this V2.
Will post V3 with updated commit message.
Thanks,
Vignesh
>
> Signed-off-by: Vignesh Viswanathan
> ---
> Changes in V2: Addressed comments in V1.
>
> This patch depends on [1] which adds support for IPQ9574 and IPQ5332
> remoteproc q5v5_mpd driver.
>
> [1]:
> https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
>
> drivers/remoteproc/qcom_q6v5.c | 10 ++
> drivers/remoteproc/qcom_q6v5.h | 6 --
> drivers/remoteproc/qcom_q6v5_adsp.c | 5 +++--
> drivers/remoteproc/qcom_q6v5_mpd.c | 14 --
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
> drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
> drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
> 7 files changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 0e32f13c196d..e4a28bf25130 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -100,7 +100,7 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
> *data)
> return IRQ_HANDLED;
> }
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
> else
> @@ -121,7 +121,7 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
> if (!q6v5->running)
> return IRQ_HANDLED;
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> else
> @@ -279,14 +279,16 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
> * Return: 0 on success, negative errno on failure
> */
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason_partition,
> +int crash_reason_item, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5))
> {
> int ret;
>
> q6v5->rproc = rproc;
> q6v5->dev = >dev;
> - q6v5->crash_reason = crash_reason;
> + q6v5->crash_reason_partition = crash_reason_partition;
> + q6v5->crash_reason_item = crash_reason_item;
> q6v5->handover = handover;
>
> init_completion(>start_done);
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 4e1bb1a68284..cd02372e9856 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -40,7 +40,8 @@ struct qcom_q6v5 {
> struct completion stop_done;
> struct completion spawn_done;
>
> - int crash_reason;
> + int crash_reason_partition;
> + int crash_reason_item;
>
> bool running;
>
> @@ -49,7 +50,8 @@ struct qcom_q6v5 {
> };
>
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason_partition,
> +int crash_reason_item, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5));
> void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
>
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
> b/drivers/remoteproc/qcom_q6v5_adsp.c
> index 6c67514cc493..8feb2eb45737 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -731,8 +731,9 @@ static int adsp_probe(struct platform_device *pdev)
> if (ret)
> goto disable_pm;
>
> - ret = qcom_q6v5_init(>q6v5, pdev, rproc, desc->crash_reason_smem,
> - desc->load_state, qcom_adsp_pil_handover);
> + ret = qcom_q6v5_init(>q6v5, pdev, rproc, QCOM_SMEM_HOST_ANY,
> + desc->crash_reason_smem, desc->load_state,
> + qcom_adsp_pil_handover);
> if (ret)
> goto disable_pm;
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mpd.c
>
[PATCH V2] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the current implementation.
Add support to pass crash_reason_smem_id along with crash_reason item
number in qcom_q6v5_init call and use the same to get the crash
information from SMEM in fatal and watchdog IRQ handlers.
Signed-off-by: Vignesh Viswanathan
---
Changes in V2: Addressed comments in V1.
This patch depends on [1] which adds support for IPQ9574 and IPQ5332
remoteproc q5v5_mpd driver.
[1]:
https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
drivers/remoteproc/qcom_q6v5.c | 10 ++
drivers/remoteproc/qcom_q6v5.h | 6 --
drivers/remoteproc/qcom_q6v5_adsp.c | 5 +++--
drivers/remoteproc/qcom_q6v5_mpd.c | 14 --
drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
7 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 0e32f13c196d..e4a28bf25130 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -100,7 +100,7 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
+ msg = qcom_smem_get(q6v5->crash_reason_partition,
q6v5->crash_reason_item, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "watchdog received: %s\n", msg);
else
@@ -121,7 +121,7 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
if (!q6v5->running)
return IRQ_HANDLED;
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
+ msg = qcom_smem_get(q6v5->crash_reason_partition,
q6v5->crash_reason_item, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "fatal error received: %s\n", msg);
else
@@ -279,14 +279,16 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
* Return: 0 on success, negative errno on failure
*/
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason_partition,
+ int crash_reason_item, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5))
{
int ret;
q6v5->rproc = rproc;
q6v5->dev = >dev;
- q6v5->crash_reason = crash_reason;
+ q6v5->crash_reason_partition = crash_reason_partition;
+ q6v5->crash_reason_item = crash_reason_item;
q6v5->handover = handover;
init_completion(>start_done);
diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
index 4e1bb1a68284..cd02372e9856 100644
--- a/drivers/remoteproc/qcom_q6v5.h
+++ b/drivers/remoteproc/qcom_q6v5.h
@@ -40,7 +40,8 @@ struct qcom_q6v5 {
struct completion stop_done;
struct completion spawn_done;
- int crash_reason;
+ int crash_reason_partition;
+ int crash_reason_item;
bool running;
@@ -49,7 +50,8 @@ struct qcom_q6v5 {
};
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason_partition,
+ int crash_reason_item, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5));
void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 6c67514cc493..8feb2eb45737 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -731,8 +731,9 @@ static int adsp_probe(struct platform_device *pdev)
if (ret)
goto disable_pm;
- ret = qcom_q6v5_init(>q6v5, pdev, rproc, desc->crash_reason_smem,
-desc->load_state, qcom_adsp_pil_handover);
+ ret = qcom_q6v5_init(>q6v5, pdev, rproc, QCOM_SMEM_HOST_ANY,
+desc->crash_reason_smem, desc->load_state,
+qcom_adsp_pil_handover);
if (ret)
goto disable_pm;
diff --git a/drivers/remoteproc/qcom_q6v5_mpd.c
b/drivers/remoteproc/qcom_q6v5_mpd.c
index b133285888c7..c893deac30e1 100644
--- a/drivers/remoteproc/qcom_q6v5_mpd.c
+++ b/drivers/remoteproc/qcom_q6v5_mpd.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -555,9 +556,9 @@ static int q6_get_outbound_irq(struct qcom_q6v5 *q6,
return 0;
}
-static
Re: [PATCH] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On 12/18/2023 2:13 AM, Bjorn Andersson wrote:
> On Sat, Nov 25, 2023 at 12:20:59AM +0530, Vignesh Viswanathan wrote:
>> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
>> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>>
>> For some targets like IPQ9574 and IPQ5332, crash reason information is
>> present in target specific partition due to which the crash reason is
>> not printed in the current implementation.
>>
>> Add support to pass crash_reason_smem_id along with crash_reason item
>> number in qcom_q6v5_init call and use the same to get the crash
>> information from SMEM in fatal and watchdog IRQ handlers.
>>
>> This patch depends on [1] which adds support for IPQ9574 and IPQ5332
>> remoteproc q5v5_mpd driver.
>
> This is solely here to ensure things are applied in appropriate order,
> there's no benefit in documenting it in the eternal git history. So
> please move this comment below the "---" line.
>
Ack. Will move this below in V2.
>>
>> [1]:
>> https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
>>
>> Signed-off-by: Vignesh Viswanathan
>> ---
>> drivers/remoteproc/qcom_q6v5.c | 10 +++---
>> drivers/remoteproc/qcom_q6v5.h | 4 +++-
>> drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++-
>> drivers/remoteproc/qcom_q6v5_mpd.c | 2 +-
>> drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
>> drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
>> drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
>> 7 files changed, 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
>> index 0e32f13c196d..072e41730110 100644
>> --- a/drivers/remoteproc/qcom_q6v5.c
>> +++ b/drivers/remoteproc/qcom_q6v5.c
>> @@ -100,7 +100,8 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
>> *data)
>> return IRQ_HANDLED;
>> }
>>
>> -msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
>> +msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
>> +);
>
> No need to break lines that are just slightly over 80 characters...
Ack.
>
>> if (!IS_ERR(msg) && len > 0 && msg[0])
>> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
>> else
>> @@ -121,7 +122,8 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
>> if (!q6v5->running)
>> return IRQ_HANDLED;
>>
>> -msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
>> +msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
>> +);
>> if (!IS_ERR(msg) && len > 0 && msg[0])
>> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
>> else
>> @@ -279,7 +281,8 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
>> * Return: 0 on success, negative errno on failure
>> */
>> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
>> - struct rproc *rproc, int crash_reason, const char
>> *load_state,
>> + struct rproc *rproc, int crash_reason,
>> + int crash_reason_smem_id, const char *load_state,
>> void (*handover)(struct qcom_q6v5 *q6v5))
>> {
>> int ret;
>> @@ -287,6 +290,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
>> platform_device *pdev,
>> q6v5->rproc = rproc;
>> q6v5->dev = >dev;
>> q6v5->crash_reason = crash_reason;
>> +q6v5->crash_reason_smem_id = crash_reason_smem_id;
>> q6v5->handover = handover;
>>
>> init_completion(>start_done);
>> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
>> index 4e1bb1a68284..21cd879e6e1e 100644
>> --- a/drivers/remoteproc/qcom_q6v5.h
>> +++ b/drivers/remoteproc/qcom_q6v5.h
>> @@ -41,6 +41,7 @@ struct qcom_q6v5 {
>> struct completion spawn_done;
>>
>> int crash_reason;
>> +int crash_reason_smem_id;
>
> While this is called "smem_id" in some places, you refer to it as SMEM
> partition in the commit message - and that's much less confusing.
>
> So please rename this.
>
Sure, partition makes more sense in this context. Will rename.
>>
>> bool running;
>>
>> @@ -49,7 +50,8 @@ struct qcom_q6v5 {
>> };
>>
>> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
>> - struct rproc *rproc, int crash_reason, const char
>> *load_state,
>> + struct rproc *rproc, int crash_reason,
>> + int crash_reason_smem_id, const char *load_state,
>
> To me it would be more natural if the most significant specifier was
> given before the least significant specifier. Please swap the partition
> and item parameters...
>
> Regards,
> Bjorn
Ack.
Thanks,
Vignesh
>
>> void (*handover)(struct qcom_q6v5 *q6v5));
>> void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
>>
>> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
>> b/drivers/remoteproc/qcom_q6v5_adsp.c
>> index 6c67514cc493..30d91205f199
Re: [PATCH v5 2/4] vduse: Temporarily disable control queue features
On Wed, Dec 13, 2023 at 7:23 PM Maxime Coquelin
wrote:
>
> Hi Jason,
>
> On 12/13/23 05:52, Jason Wang wrote:
> > On Tue, Dec 12, 2023 at 9:17 PM Maxime Coquelin
> > wrote:
> >>
> >> Virtio-net driver control queue implementation is not safe
> >> when used with VDUSE. If the VDUSE application does not
> >> reply to control queue messages, it currently ends up
> >> hanging the kernel thread sending this command.
> >>
> >> Some work is on-going to make the control queue
> >> implementation robust with VDUSE. Until it is completed,
> >> let's disable control virtqueue and features that depend on
> >> it.
> >>
> >> Signed-off-by: Maxime Coquelin
> >
> > I wonder if it's better to fail instead of a mask as a start.
>
> I think it is better to use a mask and not fail, so that we can in the
> future use a recent VDUSE application with an older kernel.
It may confuse the userspace unless userspace can do post check after
CREATE_DEV.
And for blk we fail when WCE is set in feature_is_valid():
static bool features_is_valid(u64 features)
{
if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
return false;
/* Now we only support read-only configuration space */
if (features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))
return false;
return true;
}
Thanks
>
> Why would it be better to fail than negotiating?
>
> Thanks,
> Maxime
>
[PATCH] block: Add ioprio to block_rq tracepoint
Sometimes we need to track the processing order of
requests with ioprio set, especially when using
mq-deadline. So the ioprio of request can be useful
information.
Signed-off-by: Dongliang Cui
---
include/trace/events/block.h | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index 0e128ad..e84ff93 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -82,6 +82,7 @@
__field( dev_t,dev )
__field( sector_t, sector )
__field( unsigned int, nr_sector )
+ __field( unsigned int, ioprio )
__array( char, rwbs, RWBS_LEN)
__dynamic_array( char, cmd,1 )
),
@@ -90,16 +91,17 @@
__entry->dev = rq->q->disk ? disk_devt(rq->q->disk) : 0;
__entry->sector= blk_rq_trace_sector(rq);
__entry->nr_sector = blk_rq_trace_nr_sectors(rq);
+ __entry->ioprio= rq->ioprio;
blk_fill_rwbs(__entry->rwbs, rq->cmd_flags);
__get_str(cmd)[0] = '\0';
),
- TP_printk("%d,%d %s (%s) %llu + %u [%d]",
+ TP_printk("%d,%d %s (%s) %llu + %u 0x%x [%d]",
MAJOR(__entry->dev), MINOR(__entry->dev),
__entry->rwbs, __get_str(cmd),
(unsigned long long)__entry->sector,
- __entry->nr_sector, 0)
+ __entry->nr_sector, __entry->ioprio, 0)
);
DECLARE_EVENT_CLASS(block_rq_completion,
@@ -112,6 +114,7 @@
__field( dev_t,dev )
__field( sector_t, sector )
__field( unsigned int, nr_sector )
+ __field( unsigned int, ioprio )
__field( int , error )
__array( char, rwbs, RWBS_LEN)
__dynamic_array( char, cmd,1 )
@@ -121,17 +124,19 @@
__entry->dev = rq->q->disk ? disk_devt(rq->q->disk) : 0;
__entry->sector= blk_rq_pos(rq);
__entry->nr_sector = nr_bytes >> 9;
+ __entry->ioprio= rq->ioprio;
__entry->error = blk_status_to_errno(error);
blk_fill_rwbs(__entry->rwbs, rq->cmd_flags);
__get_str(cmd)[0] = '\0';
),
- TP_printk("%d,%d %s (%s) %llu + %u [%d]",
+ TP_printk("%d,%d %s (%s) %llu + %u 0x%x [%d]",
MAJOR(__entry->dev), MINOR(__entry->dev),
__entry->rwbs, __get_str(cmd),
(unsigned long long)__entry->sector,
- __entry->nr_sector, __entry->error)
+ __entry->nr_sector, __entry->ioprio,
+ __entry->error)
);
/**
@@ -180,6 +185,7 @@
__field( sector_t, sector )
__field( unsigned int, nr_sector )
__field( unsigned int, bytes )
+ __field( unsigned int, ioprio )
__array( char, rwbs, RWBS_LEN)
__array( char, comm, TASK_COMM_LEN )
__dynamic_array( char, cmd,1 )
@@ -190,17 +196,19 @@
__entry->sector= blk_rq_trace_sector(rq);
__entry->nr_sector = blk_rq_trace_nr_sectors(rq);
__entry->bytes = blk_rq_bytes(rq);
+ __entry->ioprio= rq->ioprio;
blk_fill_rwbs(__entry->rwbs, rq->cmd_flags);
__get_str(cmd)[0] = '\0';
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
- TP_printk("%d,%d %s %u (%s) %llu + %u [%s]",
+ TP_printk("%d,%d %s %u (%s) %llu + %u 0x%x [%s]",
MAJOR(__entry->dev), MINOR(__entry->dev),
__entry->rwbs, __entry->bytes, __get_str(cmd),
(unsigned long long)__entry->sector,
- __entry->nr_sector, __entry->comm)
+ __entry->nr_sector, __entry->ioprio,
+ __entry->comm)
);
/**
--
1.9.1
Re: [PATCH] x86/sgx: fix kernel-doc comment misuse
On Sat, 2023-12-16 at 09:16 -0800, Randy Dunlap wrote: > Don't use "/**" for a non-kernel-doc comment. This prevents a warning > from scripts/kernel-doc: > > main.c:740: warning: expecting prototype for A section metric is concatenated > in a way that @low bits 12(). Prototype was for sgx_calc_section_metric() > instead > > Signed-off-by: Randy Dunlap > Cc: Jarkko Sakkinen > Cc: Dave Hansen > Cc: linux-...@vger.kernel.org > Cc: x...@kernel.org Reviewed-by: Kai Huang > --- > arch/x86/kernel/cpu/sgx/main.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -- a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c > --- a/arch/x86/kernel/cpu/sgx/main.c > +++ b/arch/x86/kernel/cpu/sgx/main.c > @@ -731,7 +731,7 @@ out: > return 0; > } > > -/** > +/* > * A section metric is concatenated in a way that @low bits 12-31 define the > * bits 12-31 of the metric and @high bits 0-19 define the bits 32-51 of the > * metric. >
Re: [PATCH v6 09/12] x86/sgx: Restructure top-level EPC reclaim function
> > > > The point is, with or w/o this patch, you can only reclaim 16 EPC pages > > in one > > function call (as you have said you are going to remove > > SGX_NR_TO_SCAN_MAX, > > which is a cipher to both of us). The only difference I can see is, > > with this > > patch, you can have multiple calls of "isolate" and then call the > > "do_reclaim" > > once. > > > > But what's the good of having the "isolate" if the "do_reclaim" can only > > reclaim > > 16 pages anyway? > > > > Back to my last reply, are you afraid of any LRU has less than 16 pages > > to > > "isolate", therefore you need to loop LRUs of descendants to get 16? > > Cause I > > really cannot think of any other reason why you are doing this. > > > > > > I think I see your point. By capping pages reclaimed per cycle to 16, > there is not much difference even if those 16 pages are spread in separate > LRUs . The difference is only significant when we ever raise that cap. To > preserve the current behavior of ewb loops independent on number of LRUs > to loop through for each reclaiming cycle, regardless of the exact value > of the page cap, I would still think current approach in the patch is > reasonable choice. What do you think? To me I won't bother to do that. Having less than 16 pages in one LRU is *extremely rare* that should never happen in practice. It's pointless to make such code adjustment at this stage. Let's focus on enabling functionality first. When you have some real performance issue that is related to this, we can come back then. Btw, I think you need to step back even further. IIUC the whole multiple LRU thing isn't mandatory in this initial support. Please (again) take a look at the comments from Dave and Michal: https://lore.kernel.org/lkml/7a1a5125-9da2-47b6-ba0f-cf24d84df...@intel.com/#t https://lore.kernel.org/lkml/yz44wukoic3syy6s4fcrngagurkjhe2hzka6kvxbajdtro3fwu@zd2ilht7wcw3/
Re: [PATCH] tracing: Add disable-filter-buf option
On Sun, 17 Dec 2023 17:10:45 +0900
Masami Hiramatsu (Google) wrote:
> > >> It exposes the following details which IMHO should be hidden or
> > >> configurable in a way that allows moving to a whole new mechanism
> > >> which will have significantly different characteristics in the
> > >> future:
> > >>
> > >> It exposes that:
> > >>
> > >> - filtering uses a copy to a temporary buffer, and
> > >> - that this copy is enabled by default.
> > >>
> > >> Once exposed, those design constraints become immutable due to ABI.
> > >
> > > No it is not. There is no such thing as "immutable ABI". The rule is
> > > "don't break user space" If this functionality in the kernel goes away,
> > > the knob could become a nop, and I doubt any user space will break
> > > because of it.
> > >
> > > That is, the only burden is keeping this option exposed. But it could
> > > be just like that light switch that has nothing connected to it. It's
> > > still there, but does nothing if you switch it. This knob can act the
> > > same way. This does not in anyway prevent future innovation.
> >
> > I am not comfortable with exposing internal ring buffer implementation
> > details to userspace which may or may not be deprecated as no-ops
> > in the future. This will lead to useless clutter.
>
> Hmm, but this may change the ring buffer consumption rate if the filter
> is enabled. The ring buffer may be filled quickly than the user expected.
WHich it has been since 0fc1b09ff1ff4 ("tracing: Use temp buffer when
filtering events"), and before that commit, things were a bit slower.
That commit sped things up. But, even with that commit, there's no
guarantee that you will get to use the temp buffer and just write
directly into the ring buffer.
And I found that currently histograms (and sythetic events!) also write
directly into the buffer :-p
> Thus if user specifies the rare condition, most of the events on the ring
> buffer is filled with garbage. And user will know the buffer size *seems*
> smaller than the setting.
Not sure what you mean by that. The event on the buffer is removed
unless another event sneaks in and makes it impossible to reset the
next write location before the discarded event.
> I think copying overhead will be a secondary effect, the biggest noticable
> difference is how many events are recorded in the ring buffer. Thus, what
> about naming the option as "filter-on-buffer"?
I'm not sure I understand that. How about just call it "filter_direct",
which means to write directly on the buffer, and default that off.
>
> If we introduce filtering on input directly, at that point we will use
> it if "filter-on-buffer = no", because this is also not noticable from
> users.
The "filter on input" will be a different interface, as the current
filter is only on the output of TRACE_EVENT() fields. The input
parameters isn't exposed at all, and may never be, as that would make
peterz and others keep all tracepoints from their subsystems.
As my main motivation for this was to create a kselftest that can
stress test the filtering directly into the ring buffer (like it use
to, and like it does for interrupting events and histograms and
synthetic events), we can still add tests to make sure that part works.
I'm fine slapping a Kconfig of CONFIG_TRACE_FORCE_DIRECT_KNOB and
place the documentation in the help content saying it adds a knob to
allow kselftest stress test the direct to ring buffer filtering.
-- Steve
Re: [PATCH] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On Sat, Nov 25, 2023 at 12:20:59AM +0530, Vignesh Viswanathan wrote:
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
> present in target specific partition due to which the crash reason is
> not printed in the current implementation.
>
> Add support to pass crash_reason_smem_id along with crash_reason item
> number in qcom_q6v5_init call and use the same to get the crash
> information from SMEM in fatal and watchdog IRQ handlers.
>
> This patch depends on [1] which adds support for IPQ9574 and IPQ5332
> remoteproc q5v5_mpd driver.
This is solely here to ensure things are applied in appropriate order,
there's no benefit in documenting it in the eternal git history. So
please move this comment below the "---" line.
>
> [1]:
> https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
>
> Signed-off-by: Vignesh Viswanathan
> ---
> drivers/remoteproc/qcom_q6v5.c | 10 +++---
> drivers/remoteproc/qcom_q6v5.h | 4 +++-
> drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++-
> drivers/remoteproc/qcom_q6v5_mpd.c | 2 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
> drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
> drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
> 7 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 0e32f13c196d..072e41730110 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -100,7 +100,8 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
> *data)
> return IRQ_HANDLED;
> }
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
> + msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
> + );
No need to break lines that are just slightly over 80 characters...
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
> else
> @@ -121,7 +122,8 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
> if (!q6v5->running)
> return IRQ_HANDLED;
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
> + msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
> + );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> else
> @@ -279,7 +281,8 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
> * Return: 0 on success, negative errno on failure
> */
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason,
> +int crash_reason_smem_id, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5))
> {
> int ret;
> @@ -287,6 +290,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
> platform_device *pdev,
> q6v5->rproc = rproc;
> q6v5->dev = >dev;
> q6v5->crash_reason = crash_reason;
> + q6v5->crash_reason_smem_id = crash_reason_smem_id;
> q6v5->handover = handover;
>
> init_completion(>start_done);
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 4e1bb1a68284..21cd879e6e1e 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -41,6 +41,7 @@ struct qcom_q6v5 {
> struct completion spawn_done;
>
> int crash_reason;
> + int crash_reason_smem_id;
While this is called "smem_id" in some places, you refer to it as SMEM
partition in the commit message - and that's much less confusing.
So please rename this.
>
> bool running;
>
> @@ -49,7 +50,8 @@ struct qcom_q6v5 {
> };
>
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason,
> +int crash_reason_smem_id, const char *load_state,
To me it would be more natural if the most significant specifier was
given before the least significant specifier. Please swap the partition
and item parameters...
Regards,
Bjorn
> void (*handover)(struct qcom_q6v5 *q6v5));
> void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
>
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
> b/drivers/remoteproc/qcom_q6v5_adsp.c
> index 6c67514cc493..30d91205f199 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -732,7 +732,8 @@ static int adsp_probe(struct platform_device *pdev)
> goto disable_pm;
>
> ret = qcom_q6v5_init(>q6v5, pdev, rproc, desc->crash_reason_smem,
> -
Re: [PATCH 0/3] Several smaller msm8974 fixes
On Sun, 17 Dec 2023 16:22:52 +0100, Luca Weiss wrote: > Send some smaller fixes that have been sitting around in my tree for > some time. > > Applied, thanks! [1/3] ARM: dts: qcom: msm8974-klte: Remove unused property commit: 32b075f8a2d4fefb8d791431606930883a5d5f15 [2/3] ARM: dts: qcom: msm8974: Remove bogus cd-gpio pinctrl commit: 1522b3bb306986e2f3923152a05939176b2a8a0c [3/3] ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards commit: 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 00/11] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
On Fri, 08 Dec 2023 16:07:56 +0100, Luca Weiss wrote: > This series adds support for the ADSP, CDSP and WPSS remoteprocs found > on SC7280. And finally enable them and WiFi on the QCM6490-based > Fairphone 5 smartphone. > > The first two patches are fixes for the MPSS to fix some dt validation > issues. They're included in this series to avoid conflicts with the > later patches and keep it simpler. > > [...] Applied, thanks! [02/11] arm64: dts: qcom: sc7280: Remove unused second MPSS reg commit: 419618bd90f6b2c3adec87beb0d62adfcae619eb [03/11] arm64: dts: qcom: sc7280: Rename reserved-memory nodes commit: 6615713c10c974d13a13297e95acd304e419dfba [04/11] arm64: dts: qcom: sc7280*: move MPSS and WPSS memory to dtsi commit: 5037ca35ce42a962ea1b03895effd632a516b3b7 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 00/11] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
On Fri, 08 Dec 2023 16:07:56 +0100, Luca Weiss wrote: > This series adds support for the ADSP, CDSP and WPSS remoteprocs found > on SC7280. And finally enable them and WiFi on the QCM6490-based > Fairphone 5 smartphone. > > The first two patches are fixes for the MPSS to fix some dt validation > issues. They're included in this series to avoid conflicts with the > later patches and keep it simpler. > > [...] Applied, thanks! [01/11] dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names commit: 9d598fab9731055638c6e9333c4f21aa0d174a48 [05/11] dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles commit: 11eff1020440060c53d2261531432927c9fb4ee3 [06/11] remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS commit: 300ed425dfa99f6926299ec196a1eedf05f47b21 Best regards, -- Bjorn Andersson
Re: [PATCH v3 1/3] media: venus: core: Set up secure memory ranges for SC7280
On Fri, Dec 01, 2023 at 10:33:18AM +0100, Luca Weiss wrote:
> Not all SC7280 devices ship with ChromeOS firmware. Other devices need
> PAS for image authentication. That requires the predefined virtual
> address ranges to be passed via scm calls. Define them to enable Venus
> on non-CrOS SC7280 devices.
>
> Reviewed-by: Konrad Dybcio
> Reviewed-by: Bryan O'Donoghue
> Reviewed-by: Vikash Garodia
> Signed-off-by: Luca Weiss
Mauro, this series looks ready to be picked up. Can you please merge
this driver patch, so I can pick the two dts changes?
Thanks,
Bjorn
> ---
> drivers/media/platform/qcom/venus/core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index 9cffe975581b..a712dd4f02a5 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -881,6 +881,10 @@ static const struct venus_resources sc7280_res = {
> .vmem_size = 0,
> .vmem_addr = 0,
> .dma_mask = 0xe000 - 1,
> + .cp_start = 0,
> + .cp_size = 0x2580,
> + .cp_nonpixel_start = 0x100,
> + .cp_nonpixel_size = 0x2480,
> .fwname = "qcom/vpu-2.0/venus.mbn",
> };
>
>
> --
> 2.43.0
>
RE: [PATCH] ring-buffer: Remove 32bit timestamp logic
... > My guess is that *most* 32-bit architectures do not have a 64-bit > cmpxchg - not even the irq-safe one. Does any sparc32 even have a 32-bit cmpxchg? The original versions (which were definitely SMP capable) only had a byte sized atomic exchange that always wrote 0xff. Sparc32 does have 'load/store double' (two 32bit registers) but 32bit cpu like nios2 and (I think) RISCV (and probably anything else loosely based on MIPS) only have single register load/store instructions. They'll mainly be UP only, I've not looked at RISCV enough to see what it has when supporting SMP. > For the UP case you can do your own, of course. A generic version of the soft interrupt disable code would help. Then it would just be an inc/dec of memory rather than having to save the current interrupt enable state. Especially for code that only disables interrupts for a few instructions - so the costs of deferring the interrupt don't happen often. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] dt-bindings: arm: qcom: Fix up htc-memul compatible
On Mon, 11 Dec 2023 20:28:07 +0100, Luca Weiss wrote: > While applying the original patch, some things got messed up and it > didn't apply to the correct section. Move the compatible to the correct > location to fix that. > > Applied, thanks! [1/1] dt-bindings: arm: qcom: Fix up htc-memul compatible commit: 82d8c1e49c1be63c6927842a7c3042d4d53fe8b2 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree
On Thu, 14 Dec 2023 21:59:32 +0100, André Apitzsch wrote: > This dts adds support for Motorola Moto G 4G released in 2013. > > Add a device tree with initial support for: > > - GPIO keys > - Hall sensor > - SDHCI > - Vibrator > > [...] Applied, thanks! [2/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree commit: 690e367e0e75a46a0b3d76ae42a14f7f31f451dd Best regards, -- Bjorn Andersson
[PATCH 1/3] ARM: dts: qcom: msm8974-klte: Remove unused property
From: Alexey Minnekhanov
Panel driver samsung,s6e3fa2 does not use te-gpios. The pin is already
configured properly through pinctrl.
Fixes: 3657b677d20d ("ARM: dts: qcom: msm8974-klte: add support for display")
Signed-off-by: Alexey Minnekhanov
[luca: adjust commit message, add Fixes tag]
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
index ca3aa16b4b10..b93539e2b87e 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
@@ -363,7 +363,6 @@ panel: panel@0 {
vddr-supply = <_panel>;
reset-gpios = <_gpios 17 GPIO_ACTIVE_LOW>;
- te-gpios = < 12 GPIO_ACTIVE_HIGH>;
port {
panel_in: endpoint {
--
2.43.0
[PATCH 3/3] ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards
Even though a previous patch re-added the supplies to the adsp and modem
remoteprocs, due to timing differences in the meantime the remoteprocs
were disabled by default, but the commit re-adding the supplies didn't
enable them.
Enable them now to hopefully properly resolve the fallout now.
Fixes: 6d933c0ec171 ("ARM: dts: qcom: msm8974-*: re-add remoteproc supplies")
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 ++
arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi| 2 ++
arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts | 2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index ca402b4a68bd..4aaae8537a3f 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -367,6 +367,7 @@ led@5 {
_adsp {
cx-supply = <_s2>;
+ status = "okay";
};
_mss {
@@ -374,6 +375,7 @@ _mss {
mss-supply = <_s3>;
mx-supply = <_s1>;
pll-supply = <_l12>;
+ status = "okay";
};
_requests {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
index 94cbad81379f..d34659ebac22 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
@@ -217,6 +217,7 @@ _wled {
_adsp {
cx-supply = <_s2>;
+ status = "okay";
};
_mss {
@@ -224,6 +225,7 @@ _mss {
mss-supply = <_s3>;
mx-supply = <_s1>;
pll-supply = <_l12>;
+ status = "okay";
};
_requests {
diff --git
a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
index 7c6fe442b559..ee94741a26ed 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
@@ -324,6 +324,7 @@ led@7 {
_adsp {
cx-supply = <_s2>;
+ status = "okay";
};
_mss {
@@ -331,6 +332,7 @@ _mss {
mss-supply = <_s3>;
mx-supply = <_s1>;
pll-supply = <_l12>;
+ status = "okay";
};
_requests {
--
2.43.0
[PATCH 2/3] ARM: dts: qcom: msm8974: Remove bogus cd-gpio pinctrl
No board in mainline uses GPIO 54 for card-detect on sdhc_2, and this
also causes conflict when both sdhc_2 and blsp2_uart4 are used, such as
on qcom-msm8974-lge-nexus5-hammerhead.
Fixes: 1dfe967ec7cf ("ARM: dts: qcom-msm8974*: Consolidate I2C/UART/SDHCI")
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index ee202f3f161e..b1413983787c 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -1641,13 +1641,6 @@ data-pins {
bias-pull-up;
drive-strength = <2>;
};
-
- cd-pins {
- pins = "gpio54";
- function = "gpio";
- bias-disable;
- drive-strength = <2>;
- };
};
blsp1_uart2_default: blsp1-uart2-default-state {
--
2.43.0
[PATCH 0/3] Several smaller msm8974 fixes
Send some smaller fixes that have been sitting around in my tree for some time. Signed-off-by: Luca Weiss --- Alexey Minnekhanov (1): ARM: dts: qcom: msm8974-klte: Remove unused property Luca Weiss (2): ARM: dts: qcom: msm8974: Remove bogus cd-gpio pinctrl ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 ++ arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi | 2 ++ arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 7 --- arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts| 1 - .../boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts | 2 ++ 5 files changed, 6 insertions(+), 8 deletions(-) --- base-commit: de06a4144d8e2c0923d08cab7c24958c28ddf17f change-id: 20231217-msm8974-misc-5d5861522ad1 Best regards, -- Luca Weiss
Re: [RFC PATCH 3/5] dt-bindings: input: add entry for 88pm88x-onkey
On Sun, 17 Dec 2023 14:17:01 +0100, Karel Balej wrote: > From: Karel Balej > > Marvell 88PM88X PMICs provide onkey functionality. Document it. > > Signed-off-by: Karel Balej > --- > .../bindings/input/marvell,88pm88x-onkey.yaml | 30 +++ > .../bindings/mfd/marvell,88pm88x.yaml | 4 +++ > 2 files changed, 34 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231217131838.7569-4-kar...@gimli.ms.mff.cuni.cz The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [RFC PATCH 1/5] dt-bindings: mfd: add entry for the Marvell 88PM88X PMICs
On Sun, 17 Dec 2023 14:16:59 +0100, Karel Balej wrote: > From: Karel Balej > > Marvell 88PM880 and 88PM886 are two similar PMICs with mostly matching > register mapping and subdevices such as onkey, regulators or battery and > charger. Both seem to come in two revisions which seem to be handled > slightly differently in some subdevice drivers. > > Signed-off-by: Karel Balej > --- > .../bindings/mfd/marvell,88pm88x.yaml | 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/mfd/marvell,88pm88x.example.dts:30.31-32 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/mfd/marvell,88pm88x.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231217131838.7569-2-kar...@gimli.ms.mff.cuni.cz The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[RFC PATCH 0/5] support for Marvell 88PM886 PMIC
From: Karel Balej Hello, the following implements basic support for Marvell's 88PM886 PMIC which is found for instance as a component of the samsung,coreprimevelte smartphone which inspired this and also serves as a testing platform. The code for the MFD is based primarily on this old series [1] with the addition of poweroff based on the smartphone's downstream kernel tree [2]. The onkey driver is based on the latter. I am not in possesion of the datasheet. The vendor version of this driver includes support for a similar chip: 88PM880. While that is not included here it was written with it in mind and it should be quite straighforward to add it. [1] https://lore.kernel.org/all/1434098601-3498-1-git-send-email-yizh...@marvell.com/ [2] https://github.com/CoderCharmander/g361f-kernel Thank you and kind regards, K. B. Karel Balej (5): dt-bindings: mfd: add entry for the Marvell 88PM88X PMICs mfd: add 88pm88x driver dt-bindings: input: add entry for 88pm88x-onkey input: add onkey driver for Marvell 88PM88X PMICs MAINTAINERS: add myself for Marvell 88PM88X PMICs .../bindings/input/marvell,88pm88x-onkey.yaml | 30 +++ .../bindings/mfd/marvell,88pm88x.yaml | 59 ++ MAINTAINERS | 9 + drivers/input/misc/88pm88x-onkey.c| 103 + drivers/input/misc/Kconfig| 10 + drivers/input/misc/Makefile | 1 + drivers/mfd/88pm88x.c | 199 ++ drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + include/linux/mfd/88pm88x.h | 60 ++ 10 files changed, 483 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml create mode 100644 drivers/input/misc/88pm88x-onkey.c create mode 100644 drivers/mfd/88pm88x.c create mode 100644 include/linux/mfd/88pm88x.h -- 2.43.0
[RFC PATCH 5/5] MAINTAINERS: add myself for Marvell 88PM88X PMICs
From: Karel Balej Add an entry to MAINTAINERS for the Marvell 88PM88X PMICs MFD and onkey drivers. Signed-off-by: Karel Balej --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e2c6187a3ac8..eb0171cd2323 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12737,6 +12737,15 @@ F: drivers/net/dsa/mv88e6xxx/ F: include/linux/dsa/mv88e6xxx.h F: include/linux/platform_data/mv88e6xxx.h +MARVELL 88PM88X PMIC MFD DRIVER +M: Karel Balej +S: Maintained +F: Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml +F: Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml +F: drivers/input/misc/88pm88x-onkey.c +F: drivers/mfd/88pm88x.c +F: include/linux/mfd/88pm88x.h + MARVELL ARMADA 3700 PHY DRIVERS M: Miquel Raynal S: Maintained -- 2.43.0
[RFC PATCH 4/5] input: add onkey driver for Marvell 88PM88X PMICs
From: Karel Balej
The Marvell 88PM88X PMICs provide onkey among other things. Add client
driver to handle it. The driver currently only provides a basic support
omitting additional functions found in the vendor version, such as long
onkey and GPIO integration.
Signed-off-by: Karel Balej
---
drivers/input/misc/88pm88x-onkey.c | 103 +
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile| 1 +
3 files changed, 114 insertions(+)
create mode 100644 drivers/input/misc/88pm88x-onkey.c
diff --git a/drivers/input/misc/88pm88x-onkey.c
b/drivers/input/misc/88pm88x-onkey.c
new file mode 100644
index ..0d6056a3cab2
--- /dev/null
+++ b/drivers/input/misc/88pm88x-onkey.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct pm88x_onkey {
+ struct input_dev *idev;
+ struct pm88x_chip *chip;
+ int irq;
+};
+
+static irqreturn_t pm88x_onkey_irq_handler(int irq, void *data)
+{
+ struct pm88x_onkey *onkey = data;
+ unsigned int val;
+ int ret = 0;
+
+ ret = regmap_read(onkey->chip->regmaps[PM88X_REGMAP_BASE],
PM88X_REG_STATUS1, );
+ if (ret) {
+ dev_err(onkey->idev->dev.parent, "Failed to read status: %d\n",
ret);
+ return IRQ_NONE;
+ }
+ val &= PM88X_ONKEY_STS1;
+
+ input_report_key(onkey->idev, KEY_POWER, val);
+ input_sync(onkey->idev);
+
+ return IRQ_HANDLED;
+}
+
+static int pm88x_onkey_probe(struct platform_device *pdev)
+{
+ struct pm88x_chip *chip = dev_get_drvdata(pdev->dev.parent);
+ struct pm88x_onkey *onkey;
+ int err;
+
+ onkey = devm_kzalloc(>dev, sizeof(*onkey), GFP_KERNEL);
+ if (!onkey)
+ return -ENOMEM;
+
+ onkey->chip = chip;
+
+ onkey->irq = platform_get_irq(pdev, 0);
+ if (onkey->irq < 0) {
+ dev_err(>dev, "Failed to get IRQ\n");
+ return -EINVAL;
+ }
+
+ onkey->idev = devm_input_allocate_device(>dev);
+ if (!onkey->idev) {
+ dev_err(>dev, "Failed to allocate input device\n");
+ return -ENOMEM;
+ }
+
+ onkey->idev->name = "88pm88x-onkey";
+ onkey->idev->phys = "88pm88x-onkey/input0";
+ onkey->idev->id.bustype = BUS_I2C;
+ onkey->idev->dev.parent = >dev;
+ onkey->idev->evbit[0] = BIT_MASK(EV_KEY);
+ onkey->idev->keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+
+ err = devm_request_threaded_irq(>dev, onkey->irq, NULL,
pm88x_onkey_irq_handler,
+ IRQF_ONESHOT | IRQF_NO_SUSPEND, "onkey", onkey);
+ if (err) {
+ dev_err(>dev, "Failed to request IRQ: %d\n", err);
+ return err;
+ }
+
+ err = input_register_device(onkey->idev);
+ if (err) {
+ dev_err(>dev, "Failed to register input device: %d\n",
err);
+ return err;
+ }
+
+ device_init_wakeup(>dev, 1);
+
+ return 0;
+}
+
+static const struct of_device_id pm88x_onkey_of_match[] = {
+ { .compatible = "marvell,88pm88x-onkey", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, pm88x_onkey_of_match);
+
+static struct platform_driver pm88x_onkey_driver = {
+ .driver = {
+ .name = "88pm88x-onkey",
+ .of_match_table = of_match_ptr(pm88x_onkey_of_match),
+ },
+ .probe = pm88x_onkey_probe,
+};
+module_platform_driver(pm88x_onkey_driver);
+
+MODULE_DESCRIPTION("Marvell 88PM88X onkey driver");
+MODULE_AUTHOR("Karel Balej ");
+MODULE_LICENSE("GPL");
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6ba984d7f0b1..fdfa3e23c3cf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -33,6 +33,16 @@ config INPUT_88PM80X_ONKEY
To compile this driver as a module, choose M here: the module
will be called 88pm80x_onkey.
+config INPUT_88PM88X_ONKEY
+ tristate "Marvell 88PM88X onkey support"
+ depends on MFD_88PM88X
+ help
+ Support the onkey of Marvell 88PM88X PMICs as an input device
+ reporting power button status.
+
+ To compile this driver as a module, choose M here: the module
+ will be called 88pm88x-onkey.
+
config INPUT_AB8500_PONKEY
tristate "AB8500 Pon (PowerOn) Key"
depends on AB8500_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 04296a4abe8e..eab7a364188c 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_INPUT_88PM860X_ONKEY) += 88pm860x_onkey.o
obj-$(CONFIG_INPUT_88PM80X_ONKEY) += 88pm80x_onkey.o
+obj-$(CONFIG_INPUT_88PM88X_ONKEY) += 88pm88x-onkey.o
obj-$(CONFIG_INPUT_AB8500_PONKEY) += ab8500-ponkey.o
obj-$(CONFIG_INPUT_AD714X) += ad714x.o
obj-$(CONFIG_INPUT_AD714X_I2C)
[RFC PATCH 3/5] dt-bindings: input: add entry for 88pm88x-onkey
From: Karel Balej
Marvell 88PM88X PMICs provide onkey functionality. Document it.
Signed-off-by: Karel Balej
---
.../bindings/input/marvell,88pm88x-onkey.yaml | 30 +++
.../bindings/mfd/marvell,88pm88x.yaml | 4 +++
2 files changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
diff --git a/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
new file mode 100644
index ..aeb7673189f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/marvell,88pm88x-onkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Onkey driver for Marvell 88PM88X PMICs.
+
+maintainers:
+ - Karel Balej
+
+description: |
+ This module is part of the 88PM88X MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml.
+
+ The onkey controller is represented as a sub-node of the PMIC node in
+ the device tree.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+const: marvell,88pm88x-onkey
+
+required:
+ - compatible
+
+additionalProperties: false
+...
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
index e075729c360f..115b41c9f22c 100644
--- a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
@@ -50,6 +50,10 @@ examples:
interrupt-parent = <>;
interrupt-controller;
#interrupt-cells = <1>;
+
+onkey {
+ compatible = "marvell,88pm88x-onkey";
+};
};
};
...
--
2.43.0
[RFC PATCH 2/5] mfd: add 88pm88x driver
From: Karel Balej
Marvell 88PM880 and 8PM886 are two similar PMICs with mostly matching
register mapping. They provide various functions such as onkey, battery,
charger and regulators.
Add support for 88PM886 found for instance in the samsung,coreprimevelte
smartphone with which this was tested. Support for 88PM880 is not
implemented here but should be straightforward to add.
Implement only the most basic support omitting the currently unused
registers and I2C subclients which should thus be added with the
respective subdevices. However, add support for the onkey already.
Signed-off-by: Karel Balej
---
drivers/mfd/88pm88x.c | 199
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile| 1 +
include/linux/mfd/88pm88x.h | 60 +++
4 files changed, 271 insertions(+)
create mode 100644 drivers/mfd/88pm88x.c
create mode 100644 include/linux/mfd/88pm88x.h
diff --git a/drivers/mfd/88pm88x.c b/drivers/mfd/88pm88x.c
new file mode 100644
index ..5db6c65b667d
--- /dev/null
+++ b/drivers/mfd/88pm88x.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* interrupt status registers */
+#define PM88X_REG_INT_STATUS1 0x05
+
+#define PM88X_REG_INT_ENA_10x0a
+#define PM88X_INT_ENA1_ONKEY BIT(0)
+
+enum pm88x_irq_number {
+ PM88X_IRQ_ONKEY,
+
+ PM88X_MAX_IRQ
+};
+
+static struct regmap_irq pm88x_regmap_irqs[] = {
+ REGMAP_IRQ_REG(PM88X_IRQ_ONKEY, 0, PM88X_INT_ENA1_ONKEY),
+};
+
+static struct regmap_irq_chip pm88x_regmap_irq_chip = {
+ .name = "88pm88x",
+ .irqs = pm88x_regmap_irqs,
+ .num_irqs = ARRAY_SIZE(pm88x_regmap_irqs),
+ .num_regs = 4,
+ .status_base = PM88X_REG_INT_STATUS1,
+ .ack_base = PM88X_REG_INT_STATUS1,
+ .unmask_base = PM88X_REG_INT_ENA_1,
+};
+
+static struct reg_sequence pm886_presets[] = {
+ /* disable watchdog */
+ REG_SEQ0(PM88X_REG_WDOG, 0x01),
+ /* GPIO1: DVC, GPIO0: input */
+ REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
+ /* GPIO2: input */
+ REG_SEQ0(PM88X_REG_GPIO_CTRL2, 0x00),
+ /* DVC2, DVC1 */
+ REG_SEQ0(PM88X_REG_GPIO_CTRL3, 0x44),
+ /* GPIO5V_1:input, GPIO5V_2: input */
+ REG_SEQ0(PM88X_REG_GPIO_CTRL4, 0x00),
+ /* output 32 kHz from XO */
+ REG_SEQ0(PM88X_REG_AON_CTRL2, 0x2a),
+ /* OSC_FREERUN = 1, to lock FLL */
+ REG_SEQ0(PM88X_REG_BK_OSC_CTRL1, 0x0f),
+ /* XO_LJ = 1, enable low jitter for 32 kHz */
+ REG_SEQ0(PM88X_REG_LOWPOWER2, 0x20),
+ /* OV_VSYS and UV_VSYS1 comparators on VSYS disabled, VSYS_OVER_TH :
5.6V */
+ REG_SEQ0(PM88X_REG_LOWPOWER4, 0xc8),
+ /* set the duty cycle of charger DC/DC to max */
+ REG_SEQ0(PM88X_REG_BK_OSC_CTRL3, 0xc0),
+};
+
+static struct resource onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(PM88X_IRQ_ONKEY, "88pm88x-onkey"),
+};
+
+static struct mfd_cell pm88x_devs[] = {
+ {
+ .name = "88pm88x-onkey",
+ .num_resources = ARRAY_SIZE(onkey_resources),
+ .resources = onkey_resources,
+ .id = -1,
+ },
+};
+
+static struct pm88x_data pm886_a1_data = {
+ .whoami = PM886_A1_WHOAMI,
+ .presets = pm886_presets,
+ .num_presets = ARRAY_SIZE(pm886_presets),
+};
+
+static const struct regmap_config pm88x_i2c_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0xfe,
+};
+
+static int pm88x_power_off_handler(struct sys_off_data *data)
+{
+ struct pm88x_chip *chip = data->cb_data;
+ int ret;
+
+ ret = regmap_update_bits(chip->regmaps[PM88X_REGMAP_BASE],
PM88X_REG_MISC_CONFIG1,
+ PM88X_SW_PDOWN, PM88X_SW_PDOWN);
+ if (ret) {
+ dev_err(>client->dev, "Failed to power off the device:
%d\n", ret);
+ return NOTIFY_BAD;
+ }
+ return NOTIFY_DONE;
+}
+
+static int pm88x_setup_irq(struct pm88x_chip *chip)
+{
+ int ret;
+
+ /* set interrupt clearing mode to clear on write */
+ ret = regmap_update_bits(chip->regmaps[PM88X_REGMAP_BASE],
PM88X_REG_MISC_CONFIG2,
+ PM88X_INT_INV | PM88X_INT_CLEAR | PM88X_INT_MASK_MODE,
+ PM88X_INT_WC);
+ if (ret) {
+ dev_err(>client->dev, "Failed to set interrupt clearing
mode: %d\n", ret);
+ return ret;
+ }
+
+ ret = devm_regmap_add_irq_chip(>client->dev,
chip->regmaps[PM88X_REGMAP_BASE],
+ chip->client->irq, IRQF_ONESHOT, -1,
_regmap_irq_chip,
+ >irq_data);
+ if (ret) {
+ dev_err(>client->dev, "Failed to request IRQ: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int pm88x_probe(struct i2c_client *client)
+{
+ struct pm88x_chip *chip;
+
[RFC PATCH 1/5] dt-bindings: mfd: add entry for the Marvell 88PM88X PMICs
From: Karel Balej
Marvell 88PM880 and 88PM886 are two similar PMICs with mostly matching
register mapping and subdevices such as onkey, regulators or battery and
charger. Both seem to come in two revisions which seem to be handled
slightly differently in some subdevice drivers.
Signed-off-by: Karel Balej
---
.../bindings/mfd/marvell,88pm88x.yaml | 55 +++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
new file mode 100644
index ..e075729c360f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/marvell,88pm88x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 88PM88X PMIC core MFD
+
+maintainers:
+ - Karel Balej
+
+description: |
+ Marvell 88PM880 and 88PM886 are two similar PMICs providing
+ several functions such as onkey, regulators or battery and
+ charger. Both seem to come in two revisions -- A0 and A1.
+
+properties:
+ compatible:
+const: marvell,88pm886-a1
+
+ reg:
+description: I2C device address
+maxItems: 1
+
+ interrupt-controller: true
+
+ interrupts:
+maxItems: 1
+
+ "#interrupt-cells":
+const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic0: 88pm886@30 {
+compatible = "marvell,88pm886-a1";
+reg = <0x30>;
+interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+interrupt-parent = <>;
+interrupt-controller;
+#interrupt-cells = <1>;
+ };
+};
+...
--
2.43.0
Re: [PATCH] tracing: Add disable-filter-buf option
On Fri, 15 Dec 2023 14:08:40 -0500 Mathieu Desnoyers wrote: > On 2023-12-15 13:43, Steven Rostedt wrote: > > On Fri, 15 Dec 2023 13:25:07 -0500 > > Mathieu Desnoyers wrote: > >> > >> I am not against exposing an ABI that allows userspace to alter the > >> filter behavior. I disagree on the way you plan to expose the ABI. > > > > These are no different than the knobs for sched_debug > > These are very much different. The sched features are enabled at > build-time by modifying kernel/sched/features.h. There is no userspace > ABI involved. > > > > >> > >> Exposing this option as an ABI in this way exposes too much internal > >> ring buffer implementation details to userspace. > > > > There's already lots of exposure using options. The options are just > > knobs, nothing more. > > > >> > >> It exposes the following details which IMHO should be hidden or > >> configurable in a way that allows moving to a whole new mechanism > >> which will have significantly different characteristics in the > >> future: > >> > >> It exposes that: > >> > >> - filtering uses a copy to a temporary buffer, and > >> - that this copy is enabled by default. > >> > >> Once exposed, those design constraints become immutable due to ABI. > > > > No it is not. There is no such thing as "immutable ABI". The rule is > > "don't break user space" If this functionality in the kernel goes away, > > the knob could become a nop, and I doubt any user space will break > > because of it. > > > > That is, the only burden is keeping this option exposed. But it could > > be just like that light switch that has nothing connected to it. It's > > still there, but does nothing if you switch it. This knob can act the > > same way. This does not in anyway prevent future innovation. > > I am not comfortable with exposing internal ring buffer implementation > details to userspace which may or may not be deprecated as no-ops > in the future. This will lead to useless clutter. Hmm, but this may change the ring buffer consumption rate if the filter is enabled. The ring buffer may be filled quickly than the user expected. Thus if user specifies the rare condition, most of the events on the ring buffer is filled with garbage. And user will know the buffer size *seems* smaller than the setting. I think copying overhead will be a secondary effect, the biggest noticable difference is how many events are recorded in the ring buffer. Thus, what about naming the option as "filter-on-buffer"? If we introduce filtering on input directly, at that point we will use it if "filter-on-buffer = no", because this is also not noticable from users. Thank you, -- Masami Hiramatsu (Google)
[PATCH net-next v2 3/3] net: add netmem_t to skb_frag_t
Use netmem_t instead of page directly in skb_frag_t. Currently netmem_t
is always a struct page underneath, but the abstraction allows efforts
to add support for skb frags not backed by pages.
There is unfortunately 1 instance where the skb_frag_t is assumed to be
a bio_vec in kcm. For this case, add a debug assert that the skb frag is
indeed backed by a page, and do a cast.
Add skb[_frag]_fill_netmem_*() and skb_add_rx_frag_netmem() helpers so
that the API can be used to create netmem skbs.
Signed-off-by: Mina Almasry
---
v2:
- Add skb frag filling helpers.
---
include/linux/skbuff.h | 70 --
net/core/skbuff.c | 22 +
net/kcm/kcmsock.c | 10 --
3 files changed, 78 insertions(+), 24 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7ce38874dbd1..03ab13072962 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -37,6 +37,7 @@
#endif
#include
#include
+#include
/**
* DOC: skb checksums
@@ -359,7 +360,11 @@ extern int sysctl_max_skb_frags;
*/
#define GSO_BY_FRAGS 0x
-typedef struct bio_vec skb_frag_t;
+typedef struct skb_frag {
+ struct netmem *bv_page;
+ unsigned int bv_len;
+ unsigned int bv_offset;
+} skb_frag_t;
/**
* skb_frag_size() - Returns the size of a skb fragment
@@ -2431,22 +2436,37 @@ static inline unsigned int skb_pagelen(const struct
sk_buff *skb)
return skb_headlen(skb) + __skb_pagelen(skb);
}
+static inline void skb_frag_fill_netmem_desc(skb_frag_t *frag,
+struct netmem *netmem, int off,
+int size)
+{
+ frag->bv_page = netmem;
+ frag->bv_offset = off;
+ skb_frag_size_set(frag, size);
+}
+
static inline void skb_frag_fill_page_desc(skb_frag_t *frag,
struct page *page,
int off, int size)
{
- frag->bv_page = page;
- frag->bv_offset = off;
- skb_frag_size_set(frag, size);
+ skb_frag_fill_netmem_desc(frag, page_to_netmem(page), off, size);
+}
+
+static inline void __skb_fill_netmem_desc_noacc(struct skb_shared_info *shinfo,
+ int i, struct netmem *netmem,
+ int off, int size)
+{
+ skb_frag_t *frag = >frags[i];
+
+ skb_frag_fill_netmem_desc(frag, netmem, off, size);
}
static inline void __skb_fill_page_desc_noacc(struct skb_shared_info *shinfo,
int i, struct page *page,
int off, int size)
{
- skb_frag_t *frag = >frags[i];
-
- skb_frag_fill_page_desc(frag, page, off, size);
+ __skb_fill_netmem_desc_noacc(shinfo, i, page_to_netmem(page), off,
+size);
}
/**
@@ -2462,10 +2482,10 @@ static inline void skb_len_add(struct sk_buff *skb, int
delta)
}
/**
- * __skb_fill_page_desc - initialise a paged fragment in an skb
+ * __skb_fill_netmem_desc - initialise a paged fragment in an skb
* @skb: buffer containing fragment to be initialised
* @i: paged fragment index to initialise
- * @page: the page to use for this fragment
+ * @netmem: the netmem to use for this fragment
* @off: the offset to the data with @page
* @size: the length of the data
*
@@ -2474,10 +2494,13 @@ static inline void skb_len_add(struct sk_buff *skb, int
delta)
*
* Does not take any additional reference on the fragment.
*/
-static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
- struct page *page, int off, int size)
+static inline void __skb_fill_netmem_desc(struct sk_buff *skb, int i,
+ struct netmem *netmem, int off,
+ int size)
{
- __skb_fill_page_desc_noacc(skb_shinfo(skb), i, page, off, size);
+ struct page *page = netmem_to_page(netmem);
+
+ __skb_fill_netmem_desc_noacc(skb_shinfo(skb), i, netmem, off, size);
/* Propagate page pfmemalloc to the skb if we can. The problem is
* that not all callers have unique ownership of the page but rely
@@ -2485,7 +2508,21 @@ static inline void __skb_fill_page_desc(struct sk_buff
*skb, int i,
*/
page = compound_head(page);
if (page_is_pfmemalloc(page))
- skb->pfmemalloc = true;
+ skb->pfmemalloc = true;
+}
+
+static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
+ struct page *page, int off, int size)
+{
+ __skb_fill_netmem_desc(skb, i, page_to_netmem(page), off, size);
+}
+
+static inline void skb_fill_netmem_desc(struct sk_buff *skb, int i,
+ struct netmem *netmem, int off,
+ int
[PATCH net-next v2 2/3] net: introduce abstraction for network memory
Add the netmem_t type, an abstraction for network memory.
To add support for new memory types to the net stack, we must first
abstract the current memory type from the net stack. Currently parts of
the net stack use struct page directly:
- page_pool
- drivers
- skb_frag_t
Originally the plan was to reuse struct page* for the new memory types,
and to set the LSB on the page* to indicate it's not really a page.
However, for compiler type checking we need to introduce a new type.
netmem_t is introduced to abstract the underlying memory type. Currently
it's a no-op abstraction that is always a struct page underneath. In
parallel there is an undergoing effort to add support for devmem to the
net stack:
https://lore.kernel.org/netdev/20231208005250.2910004-1-almasrym...@google.com/
Signed-off-by: Mina Almasry
---
v2:
- Use container_of instead of a type cast (David).
---
include/net/netmem.h | 35 +++
1 file changed, 35 insertions(+)
create mode 100644 include/net/netmem.h
diff --git a/include/net/netmem.h b/include/net/netmem.h
new file mode 100644
index ..b60b00216704
--- /dev/null
+++ b/include/net/netmem.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * netmem.h
+ * Author: Mina Almasry
+ * Copyright (C) 2023 Google LLC
+ */
+
+#ifndef _NET_NETMEM_H
+#define _NET_NETMEM_H
+
+struct netmem {
+ union {
+ struct page page;
+
+ /* Stub to prevent compiler implicitly converting from page*
+* to netmem_t* and vice versa.
+*
+* Other memory type(s) net stack would like to support
+* can be added to this union.
+*/
+ void *addr;
+ };
+};
+
+static inline struct page *netmem_to_page(struct netmem *netmem)
+{
+ return >page;
+}
+
+static inline struct netmem *page_to_netmem(struct page *page)
+{
+ return container_of(page, struct netmem, page);
+}
+
+#endif /* _NET_NETMEM_H */
--
2.43.0.472.g3155946c3a-goog
[PATCH net-next v2 1/3] vsock/virtio: use skb_frag_*() helpers
Minor fix for virtio: code wanting to access the fields inside an skb frag should use the skb_frag_*() helpers, instead of accessing the fields directly. This allows for extensions where the underlying memory is not a page. Signed-off-by: Mina Almasry --- v2: - Also fix skb_frag_off() + skb_frag_size() (David) - Did not apply the reviewed-by from Stefano since the patch changed relatively much. --- net/vmw_vsock/virtio_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index f495b9e5186b..1748268e0694 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -153,10 +153,10 @@ virtio_transport_send_pkt_work(struct work_struct *work) * 'virt_to_phys()' later to fill the buffer descriptor. * We don't touch memory at "virtual" address of this page. */ - va = page_to_virt(skb_frag->bv_page); + va = page_to_virt(skb_frag_page(skb_frag)); sg_init_one(sgs[out_sg], - va + skb_frag->bv_offset, - skb_frag->bv_len); + va + skb_frag_off(skb_frag), + skb_frag_size(skb_frag)); out_sg++; } } -- 2.43.0.472.g3155946c3a-goog
[PATCH net-next v2 0/3] Abstract page from net stack
Changes in v2: - Reverted changes to the page_pool. The page pool now retains the same API, so that we don't have to touch many existing drivers. The devmem TCP series will include the changes to the page pool. - Addressed comments. This series is a prerequisite to the devmem TCP series. For a full snapshot of the code which includes these changes, feel free to check: https://github.com/mina/linux/commits/tcpdevmem-rfcv5/ --- Currently these components in the net stack use the struct page directly: 1. Drivers. 2. Page pool. 3. skb_frag_t. To add support for new (non struct page) memory types to the net stack, we must first abstract the current memory type. Originally the plan was to reuse struct page* for the new memory types, and to set the LSB on the page* to indicate it's not really a page. However, for safe compiler type checking we need to introduce a new type. struct netmem is introduced to abstract the underlying memory type. Currently it's a no-op abstraction that is always a struct page underneath. In parallel there is an undergoing effort to add support for devmem to the net stack: https://lore.kernel.org/netdev/20231208005250.2910004-1-almasrym...@google.com/ Cc: Jason Gunthorpe Cc: Christian König Cc: Shakeel Butt Cc: Yunsheng Lin Cc: Willem de Bruijn Mina Almasry (3): vsock/virtio: use skb_frag_*() helpers net: introduce abstraction for network memory net: add netmem_t to skb_frag_t include/linux/skbuff.h | 70 include/net/netmem.h | 35 net/core/skbuff.c| 22 +++--- net/kcm/kcmsock.c| 10 - net/vmw_vsock/virtio_transport.c | 6 +-- 5 files changed, 116 insertions(+), 27 deletions(-) create mode 100644 include/net/netmem.h -- 2.43.0.472.g3155946c3a-goog
