Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1455408 > unrolled thread

[PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

Started byPaul Gortmaker <paul.gortmaker@windriver.com>
First post2016-08-02 21:10 +0200
Last post2016-08-03 15:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-08-02 21:10 +0200
    Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new  parent field Ralf Baechle <ralf@linux-mips.org> - 2016-08-03 08:00 +0200
      Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new  parent field Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-08-03 15:40 +0200

#1455408 — [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

FromPaul Gortmaker <paul.gortmaker@windriver.com>
Date2016-08-02 21:10 +0200
Subject[PATCH] mips: lantiq: fix irq_chip name to not land in new parent field
Message-ID<s1NeG-gB-33@gated-at.bofh.it>
As of commit be45beb2df69 ("genirq: Add runtime power management
support for IRQ chips") the irq_chip struct got a struct *device
parent_device field added to it.  However, it was added at the
beginning of the struct, which previously was the "name" entry.

The driver here was using a mix of ordered struct init entries and
named init entries.  It was supplying the name assuming it was the 1st
in the order, and hence when that became a struct *device we get:

arch/mips/lantiq/irq.c:209:2: warning: initialization from incompatible pointer type [enabled by default]
arch/mips/lantiq/irq.c:209:2: warning: (near initialization for 'ltq_irq_type.parent_device') [enabled by default]
arch/mips/lantiq/irq.c:219:2: warning: initialization from incompatible pointer type [enabled by default]
arch/mips/lantiq/irq.c:219:2: warning: (near initialization for 'ltq_eiu_type.parent_device') [enabled by default]

While not runtime tested, I can't imagine trying to dereference a
a struct device field from a char string will end well.

Here we've used named element init entries for the name string as well
to fix it.

Fixes: be45beb2df69 ("genirq: Add runtime power management support for IRQ chips")
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: John Crispin <john@phrozen.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---

[
  in mainline via: commit a5c8a01968fc9dc94f182172cee7ab40bc496ea4
    Merge: ff5b706f5189 3faf24ea894a
    Author: Thomas Gleixner <tglx@linutronix.de>
    Date:   Mon Jun 13 16:33:48 2016 +0200

    Merge tag 'irqchip-for-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
]

 arch/mips/lantiq/irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index ff17669e30a3..02c0252b49a3 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -206,7 +206,7 @@ static void ltq_shutdown_eiu_irq(struct irq_data *d)
 }
 
 static struct irq_chip ltq_irq_type = {
-	"icu",
+	.name = "icu",
 	.irq_enable = ltq_enable_irq,
 	.irq_disable = ltq_disable_irq,
 	.irq_unmask = ltq_enable_irq,
@@ -216,7 +216,7 @@ static struct irq_chip ltq_irq_type = {
 };
 
 static struct irq_chip ltq_eiu_type = {
-	"eiu",
+	.name = "eiu",
 	.irq_startup = ltq_startup_eiu_irq,
 	.irq_shutdown = ltq_shutdown_eiu_irq,
 	.irq_enable = ltq_enable_irq,
-- 
2.8.4

[toc] | [next] | [standalone]


#1455636 — Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

FromRalf Baechle <ralf@linux-mips.org>
Date2016-08-03 08:00 +0200
SubjectRe: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field
Message-ID<s1XnH-6Gm-1@gated-at.bofh.it>
In reply to#1455408
On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote:

> As of commit be45beb2df69 ("genirq: Add runtime power management
> support for IRQ chips") the irq_chip struct got a struct *device
> parent_device field added to it.  However, it was added at the
> beginning of the struct, which previously was the "name" entry.
> 
> The driver here was using a mix of ordered struct init entries and
> named init entries.  It was supplying the name assuming it was the 1st
> in the order, and hence when that became a struct *device we get:
> 
> arch/mips/lantiq/irq.c:209:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/mips/lantiq/irq.c:209:2: warning: (near initialization for 'ltq_irq_type.parent_device') [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/mips/lantiq/irq.c:219:2: warning: (near initialization for 'ltq_eiu_type.parent_device') [enabled by default]
> 
> While not runtime tested, I can't imagine trying to dereference a
> a struct device field from a char string will end well.
> 
> Here we've used named element init entries for the name string as well
> to fix it.
> 
> Fixes: be45beb2df69 ("genirq: Add runtime power management support for IRQ chips")
> Cc: Jon Hunter <jonathanh@nvidia.com>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: John Crispin <john@phrozen.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-mips@linux-mips.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Thanks for the patch but I've already applied the identical patch
https://patchwork.linux-mips.org/patch/13684/.

  Ralf

[toc] | [prev] | [next] | [standalone]


#1455796 — Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

FromPaul Gortmaker <paul.gortmaker@windriver.com>
Date2016-08-03 15:40 +0200
SubjectRe: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field
Message-ID<s24yR-39v-5@gated-at.bofh.it>
In reply to#1455636
[Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field] On 03/08/2016 (Wed 07:56) Ralf Baechle wrote:

> On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote:
> 
> > As of commit be45beb2df69 ("genirq: Add runtime power management
> > support for IRQ chips") the irq_chip struct got a struct *device
> > parent_device field added to it.  However, it was added at the
> > beginning of the struct, which previously was the "name" entry.
> > 
> > The driver here was using a mix of ordered struct init entries and
> > named init entries.  It was supplying the name assuming it was the 1st
> > in the order, and hence when that became a struct *device we get:
> > 
> > arch/mips/lantiq/irq.c:209:2: warning: initialization from incompatible pointer type [enabled by default]
> > arch/mips/lantiq/irq.c:209:2: warning: (near initialization for 'ltq_irq_type.parent_device') [enabled by default]
> > arch/mips/lantiq/irq.c:219:2: warning: initialization from incompatible pointer type [enabled by default]
> > arch/mips/lantiq/irq.c:219:2: warning: (near initialization for 'ltq_eiu_type.parent_device') [enabled by default]
> > 
> > While not runtime tested, I can't imagine trying to dereference a
> > a struct device field from a char string will end well.
> > 
> > Here we've used named element init entries for the name string as well
> > to fix it.
> > 
> > Fixes: be45beb2df69 ("genirq: Add runtime power management support for IRQ chips")
> > Cc: Jon Hunter <jonathanh@nvidia.com>
> > Cc: Kevin Hilman <khilman@baylibre.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: John Crispin <john@phrozen.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: linux-mips@linux-mips.org
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> Thanks for the patch but I've already applied the identical patch
> https://patchwork.linux-mips.org/patch/13684/.

Patchwork shows that patch was from June, however I still saw the issue
on the linux-next from yesterday (or maybe the weekend?).   Is the
branch you applied it to being fed into sfr's daily merge queue?

P.
--
> 
>   Ralf

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web