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]
Date:   Mon, 11 Dec 2017 11:02:51 +0100
From:   Alexander Stein <alexander.stein@...tec-electronic.com>
To:     Alexander Stein <alexander.stein@...tec-electronic.com>
Cc:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Marc Zyngier <marc.zyngier@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [RFC] irqchip: add support for LS1021A external interrupt lines

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ