From: Alexander Stein <alexander.stein@systec-electronic.com> To: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Cc: Marc Zyngier <marc.zyngier@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Jason Cooper <jason@lakedaemon.net>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 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 10:45:09 +0100 [thread overview] Message-ID: <5117875.4tMaEC1223@ws-stein> (raw) In-Reply-To: <58297576-cc32-819d-c6b3-7d1355095482@prevas.dk> 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 *. > >> Anyway, please use BIT(x) instead. > > I really prefer not to, that macro obfuscates the type, and unsigned > long is the wrong thing to use for something that must be a 32 bit > quantity. Sure, BITS_PER_LONG==32 in this case, but I don't think > BIT(foo) is any easier to read than 1U << (foo). Well, there a lots of other places where BIT(x) is used for u32 data types, or even 16 Bit types. IMHO BIT(x) is more obvious as it already says set Bit x > >>> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK; > >>> + return 0; > >>> +} > >>> + > >>> +static int > >>> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq, > >>> + unsigned int nr_irqs, void *arg) > >>> +{ > >>> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169}; > >> ^^^^^^ > >> No need for static here. > > > > Why would you store this on the stack each time you enter the function? > > Exactly, it takes a lot less .rodata to make this static than having gcc > generate .text to build this array on the stack. > > > That's the wrong construct (these values should come from DT), but > > static is perfectly fine. > > OK. Intresting. Thanks for the info. Regards, Alexander
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Stein <alexander.stein-93q1YBGzJSMe9JSWTWOYM3xStJ4P+DSV@public.gmane.org> To: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [RFC] irqchip: add support for LS1021A external interrupt lines Date: Mon, 11 Dec 2017 10:45:09 +0100 [thread overview] Message-ID: <5117875.4tMaEC1223@ws-stein> (raw) In-Reply-To: <58297576-cc32-819d-c6b3-7d1355095482-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 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 *. > >> Anyway, please use BIT(x) instead. > > I really prefer not to, that macro obfuscates the type, and unsigned > long is the wrong thing to use for something that must be a 32 bit > quantity. Sure, BITS_PER_LONG==32 in this case, but I don't think > BIT(foo) is any easier to read than 1U << (foo). Well, there a lots of other places where BIT(x) is used for u32 data types, or even 16 Bit types. IMHO BIT(x) is more obvious as it already says set Bit x > >>> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK; > >>> + return 0; > >>> +} > >>> + > >>> +static int > >>> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq, > >>> + unsigned int nr_irqs, void *arg) > >>> +{ > >>> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169}; > >> ^^^^^^ > >> No need for static here. > > > > Why would you store this on the stack each time you enter the function? > > Exactly, it takes a lot less .rodata to make this static than having gcc > generate .text to build this array on the stack. > > > That's the wrong construct (these values should come from DT), but > > static is perfectly fine. > > OK. Intresting. Thanks for the info. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-12-11 9:45 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-04 15:11 polarity inversion on LS1021a Rasmus Villemoes 2017-12-04 15:23 ` Marc Zyngier 2017-12-08 14:33 ` [RFC] irqchip: add support for LS1021A external interrupt lines Rasmus Villemoes 2017-12-08 14:33 ` Rasmus Villemoes 2017-12-08 15:11 ` Alexander Stein 2017-12-08 15:11 ` Alexander Stein 2017-12-08 16:09 ` Marc Zyngier 2017-12-08 16:09 ` Marc Zyngier 2017-12-11 9:08 ` Rasmus Villemoes 2017-12-11 9:08 ` Rasmus Villemoes 2017-12-11 9:45 ` Alexander Stein [this message] 2017-12-11 9:45 ` Alexander Stein 2017-12-11 10:02 ` Alexander Stein 2017-12-11 10:02 ` Alexander Stein 2017-12-11 13:45 ` Rasmus Villemoes 2017-12-11 13:45 ` Rasmus Villemoes 2017-12-11 14:06 ` Rasmus Villemoes 2017-12-11 14:06 ` Rasmus Villemoes 2017-12-11 14:38 ` Alexander Stein 2017-12-11 14:38 ` Alexander Stein 2017-12-08 16:02 ` Marc Zyngier 2017-12-08 16:02 ` Marc Zyngier 2017-12-11 9:30 ` Rasmus Villemoes 2017-12-11 9:30 ` Rasmus Villemoes 2017-12-11 18:29 ` Marc Zyngier 2017-12-11 18:29 ` Marc Zyngier 2017-12-12 23:28 ` Rob Herring 2017-12-12 23:28 ` Rob Herring 2017-12-15 22:55 ` Rasmus Villemoes 2017-12-15 22:55 ` Rasmus Villemoes 2017-12-21 22:45 ` Rob Herring 2017-12-21 22:45 ` Rob Herring 2017-12-20 8:30 ` [PATCH v2 1/2] irqchip: add support for Layerscape " Rasmus Villemoes 2017-12-20 8:30 ` [PATCH v2 2/2] dt/bindings: Add bindings for Layerscape external irqs Rasmus Villemoes 2017-12-20 8:30 ` Rasmus Villemoes 2017-12-21 22:44 ` Rob Herring 2017-12-21 22:44 ` Rob Herring 2018-01-22 9:21 ` [PATCH v3 1/2] irqchip: add support for Layerscape external interrupt lines Rasmus Villemoes 2018-01-22 9:21 ` [PATCH v3 2/2] dt/bindings: Add bindings for Layerscape external irqs Rasmus Villemoes 2018-01-22 9:21 ` Rasmus Villemoes 2018-01-24 15:28 ` Marc Zyngier 2018-01-25 15:02 ` [PATCH v4 1/2] irqchip: add support for Layerscape external interrupt lines Rasmus Villemoes 2018-01-25 15:02 ` [PATCH v4 2/2] dt/bindings: Add bindings for Layerscape external irqs Rasmus Villemoes 2018-01-25 15:02 ` Rasmus Villemoes 2018-02-05 6:07 ` Rob Herring 2018-02-05 6:07 ` Rob Herring 2018-02-08 15:08 ` Rasmus Villemoes 2018-02-09 9:47 ` Marc Zyngier 2018-02-09 9:47 ` Marc Zyngier 2018-02-23 21:08 ` [PATCH v5 0/2] irqchip: add support for Layerscape external interrupt lines Rasmus Villemoes 2018-02-23 21:08 ` [PATCH v5 1/2] " Rasmus Villemoes 2018-03-01 12:16 ` Thomas Gleixner 2018-05-04 7:44 ` Rasmus Villemoes 2019-09-17 9:39 ` Kurt Kanzenbach 2018-02-23 21:09 ` [PATCH v5 2/2] dt/bindings: Add bindings for Layerscape external irqs Rasmus Villemoes 2018-03-02 19:49 ` Rob Herring 2018-05-04 8:07 ` Rasmus Villemoes 2017-12-04 15:31 ` polarity inversion on LS1021a Alexander Stein 2017-12-04 15:37 ` Marc Zyngier 2017-12-04 16:04 ` Alexander Stein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5117875.4tMaEC1223@ws-stein \ --to=alexander.stein@systec-electronic.com \ --cc=devicetree@vger.kernel.org \ --cc=jason@lakedaemon.net \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=rasmus.villemoes@prevas.dk \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.