linux-kernel - Re: [PATCH v1] usb: typec: tipd: keep default interrupts enabled during probe()

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f8b4606a-e3ec-e452-f291-7ac36c69f8cd@marcan.st>
Date:   Tue, 11 Jan 2022 20:10:14 +0900
From:   Hector Martin <marcan@...can.st>
To:     Martin Kepplinger <martin.kepplinger@...i.sm>,
        heikki.krogerus@...ux.intel.com, gregkh@...uxfoundation.org,
        sven@...npeter.dev, hdegoede@...hat.com
Cc:     kernel@...i.sm, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] usb: typec: tipd: keep default interrupts enabled
 during probe()

On 2022/01/11 1:35, Martin Kepplinger wrote:
> Commit 9990f2f6264c ("usb: typec: tipd: Enable event interrupts by default")
> writes a fixed set of interrupts to TPS_REG_INT_MASK1. In case interrupts
> had been enabled by the firmware by default, these get disabled now
> which can break use cases. Only append to what is already enabled instead.
> 

I'm confused. The kernel drives the hardware, it needs to enable only
the interrupts it can handle. Do you have some kind of firmware trying
to share access to the same I2C port that needs other interrupts? That
sounds like a recipe for trouble... or am I misunderstanding things?

If the *kernel* needs other interrupts enabled to make something work,
then they should also be enabled unconditionally, and you'd have to
check the IRQ handler to make sure it actually handles it.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub