summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-betopff.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2018-04-06genirq/affinity: Don't return with empty affinity masks on errorThomas Gleixner1-7/+8
When the allocation of node_to_possible_cpumask fails, then irq_create_affinity_masks() returns with a pointer to the empty affinity masks array, which will cause malfunction. Reorder the allocations so the masks array allocation comes last and every failure path returns NULL. Fixes: 9a0ef98e186d ("genirq/affinity: Assign vectors to all present CPUs") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com>
2018-04-04openrisc: Set CONFIG_MULTI_IRQ_HANDLERPalmer Dabbelt1-0/+4
arm has an optional MULTI_IRQ_HANDLER, which openrisc copied but didn't make optional. The multi irq handler infrastructure has been copied to generic code selectable with a new config symbol. That symbol can be selected by randconfig builds and can cause build breakage. Introduce CONFIG_MULTI_IRQ_HANDLER as an intermediate step which prevents the core config symbol from being selected. The openrisc local config symbol will be removed once openrisc gets converted to the generic code. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20180404043130.31277-3-palmer@sifive.com
2018-04-04arm64: Set CONFIG_MULTI_IRQ_HANDLERPalmer Dabbelt1-0/+4
arm has an optional MULTI_IRQ_HANDLER, which arm64 copied but didn't make optional. The multi irq handler infrastructure has been copied to generic code selectable with a new config symbol. That symbol can be selected by randconfig builds and can cause build breakage. Introduce CONFIG_MULTI_IRQ_HANDLER as an intermediate step which prevents the core config symbol from being selected. The arm64 local config symbol will be removed once arm64 gets converted to the generic code. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20180404043130.31277-2-palmer@sifive.com
2018-04-04genirq: Make GENERIC_IRQ_MULTI_HANDLER depend on !MULTI_IRQ_HANDLERPalmer Dabbelt1-0/+1
These config switches enable the same code in the core and the not yet converted architecture code. They can be selected both by randconfig builds and cause linker error because the same symbols are defined twice. Make the new GENERIC_IRQ_MULTI_HANDLER depend on !MULTI_IRQ_HANDLER to prevent that. The dependency will be removed once all architectures are converted over. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20180404043130.31277-4-palmer@sifive.com
2018-03-29irqchip/gic: Take lock when updating irq typeAniruddha Banerjee1-1/+8
Most MMIO GIC register accesses use a 1-hot bit scheme that avoids requiring any form of locking. This isn't true for the GICD_ICFGRn registers, which require a RMW sequence. Unfortunately, we seem to be missing a lock for these particular accesses, which could result in a race condition if changing the trigger type on any two interrupts within the same set of 16 interrupts (and thus controlled by the same CFGR register). Introduce a private lock in the GIC common comde for this particular case, making it cover both GIC implementations in one go. Cc: stable@vger.kernel.org Signed-off-by: Aniruddha Banerjee <aniruddhab@nvidia.com> [maz: updated changelog] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-28irqchip/gic: Update supports_deactivate static key to modern apiDavidlohr Bueso2-21/+21
No changes in semantics -- key init is true; replace static_key_slow_dec with static_branch_disable static_key_true with static_branch_likely The first is because we never actually do any couterpart incs, thus there is really no reference counting semantics going on. Use the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-23irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enablingShanker Donthineni2-14/+61
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may result in subtle memory corruption. Detecting this is thus pretty important. On detecting that LPIs are still enabled, we taint the kernel (because we're not sure of anything anymore), and try to disable LPIs. This can fail, as implementations are allowed to implement GICR_CTLR.EnableLPI as a one-way enable, meaning the redistributors cannot be reprogrammed with new tables. Should this happen, we fail probing the redistributor and warn the user that things are pretty dire. Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> [maz: reworded changelog, minor comment and message changes] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-22irqchip: Add a driver for the Microsemi Ocelot controllerAlexandre Belloni3-0/+124
The Microsemi Ocelot SoC has a pretty simple IRQ controller in its ICPU block. Add a driver for it. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>