Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752625AbdLKKDK (ORCPT ); Mon, 11 Dec 2017 05:03:10 -0500 Received: from webbox1416.server-home.net ([77.236.96.61]:34766 "EHLO webbox1416.server-home.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752379AbdLKKC4 (ORCPT ); Mon, 11 Dec 2017 05:02:56 -0500 From: Alexander Stein To: Alexander Stein Cc: Rasmus Villemoes , Marc Zyngier , Thomas Gleixner , Jason Cooper , Rob Herring , Mark Rutland , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [RFC] irqchip: add support for LS1021A external interrupt lines Date: Mon, 11 Dec 2017 11:02:51 +0100 Message-ID: <2475814.YIHTfursNv@ws-stein> In-Reply-To: <5117875.4tMaEC1223@ws-stein> References: <48d2d08c-c57a-ce49-5958-0fd5ad4a2dc7@arm.com> <58297576-cc32-819d-c6b3-7d1355095482@prevas.dk> <5117875.4tMaEC1223@ws-stein> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1276 Lines: 29 On Monday, December 11, 2017, 10:45:09 AM CET Alexander Stein wrote: > On Monday, December 11, 2017, 10:08:20 AM CET Rasmus Villemoes wrote: > > >>> +static int > > >>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type) > > >>> +{ > > >>> + irq_hw_number_t hwirq = data->hwirq; > > >>> + struct extirq_chip_data *chip_data = data->chip_data; > > >>> + u32 value, mask; > > >>> + int ret; > > >>> + > > >>> + mask = 1U << (31 - hwirq); > > >> > > >> Is this really correct? IRQ0 is still at bit position 0. Don't be mislead > > >> by the left most position in the register layout. This is just strange way > > >> to express bit-endian access. > > > > Yes, I'm sure. The 26 unused bits in the INTPCR register are marked as > > reserved with a POR value of 0. Fortunately, they can still be set and > > read back, and when I did 1U << hwirq it was some of those bits that got > > set (the POR value of the six used bits are all 1, so the hardware still > > worked on my board because all the lines happen to be of negative polarity). > > Which functions do reg_read and reg_write in chip_data->syscon->bus_context > actually point to? > bus_context is actually a struct regmap_mmio_context *. Oh, and what is the content of register SCFG_SCFGREVCR? Alexander