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] [day] [month] [year] [list]
Message-ID: <ab560610d70a4e3499255284b3170b0b16572bb8.camel@puri.sm>
Date:   Thu, 13 Jan 2022 10:15:56 +0100
From:   Martin Kepplinger <martin.kepplinger@...i.sm>
To:     Hector Martin <marcan@...can.st>, 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()

Am Dienstag, dem 11.01.2022 um 20:10 +0900 schrieb Hector Martin:
> 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.
> 

true. sorry for the confusion. we need to submit the patches for the
interrupt handler to handle what we need and then we'll extend the mask
accordingly. please ignore this patch.

thank you,
                               martin


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ