linux-kernel - [PATCH 0/5] irqchip: vt8500: Cleanups and fixes for the irq-vt8500 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250424-vt8500-intc-updates-v1-0-4ab7397155b3@gmail.com>
Date: Thu, 24 Apr 2025 22:35:41 +0400
From: Alexey Charkov <alchark@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>, 
 Krzysztof Kozlowski <krzk@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
 Alexey Charkov <alchark@...il.com>
Subject: [PATCH 0/5] irqchip: vt8500: Cleanups and fixes for the irq-vt8500
 driver

Fix the logic of ack/mask functions to actually do what their semantics
implies instead of lumping both actions into one. Also rework the chained
interrupts handling using common kernel infrastructure, while getting rid
of a boot-time WARN_ON due to a misplaced call to enable_irq.

Apparently neither edge-triggered interrupts nor chained interrupts had
any users, so nobody complained in 15 years.

Signed-off-by: Alexey Charkov <alchark@...il.com>
---
Alexey Charkov (5):
      irqchip: vt8500: Split up ack/mask functions
      irqchip: vt8500: Drop redundant copy of the device node pointer
      irqchip: vt8500: Don't require 8 interrupts from a chained controller
      irqchip: vt8500: Use a dedicated chained handler function
      irqchip: vt8500: Use fewer global variables and add error handling

 drivers/irqchip/irq-vt8500.c | 149 +++++++++++++++++++++++--------------------
 1 file changed, 80 insertions(+), 69 deletions(-)
---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20250424-vt8500-intc-updates-c364a31a36a9

Best regards,
-- 
Alexey Charkov <alchark@...il.com>