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
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
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
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:
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
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
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
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
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
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
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
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
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
> >
> > 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
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:
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
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:
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
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
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
...
> 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
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
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:
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]
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.
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
---
/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
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 +++
>
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
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
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
+++
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
---
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
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
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:
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
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 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
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() +
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
40 matches
Mail list logo
