All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: firas ashkar <firas.ashkar@savoirfairelinux.com>
Cc: alex@digriz.org.uk, tglx@linutronix.de,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] irqchip: add TS7800v1 fpga based controller driver
Date: Fri, 21 Oct 2022 18:18:24 +0100	[thread overview]
Message-ID: <86zgdpdrj3.wl-maz@kernel.org> (raw)
In-Reply-To: <7b2ac9ae5f18e5272e52478c73da53a76cf9f2a2.camel@savoirfairelinux.com>

On Fri, 21 Oct 2022 17:19:02 +0100,
firas ashkar <firas.ashkar@savoirfairelinux.com> wrote:
> 
> On Fri, 2022-10-21 at 10:22 +0100, Marc Zyngier wrote:
> > On Thu, 20 Oct 2022 15:13:51 +0100,
> > Firas Ashkar <firas.ashkar@savoirfairelinux.com> wrote:
> > > 
> > > 1. add TS-7800v1 fpga based irq controller driver, and
> > > 2. add related memory and irq resources
> > > 
> > > By default only mapped FPGA interrupts will be chained/multiplexed,
> > > these
> > > chained interrupts will then be available to other device drivers
> > > to
> > > request via the corresponding Linux IRQs.
> > > 
> > > $ cat /proc/cpuinfo
> > > processor       : 0
> > > model name      : Feroceon rev 0 (v5l)
> > > BogoMIPS        : 333.33
> > > Features        : swp half thumb fastmult edsp
> > > CPU implementer : 0x41
> > > CPU architecture: 5TEJ
> > > CPU variant     : 0x0
> > > CPU part        : 0x926
> > > CPU revision    : 0
> > > 
> > > Hardware        : Technologic Systems TS-78xx SBC
> > > Revision        : 0000
> > > Serial          : 0000000000000000
> > > $
> > > 
> > > $ cat /proc/interrupts
> > >            CPU0
> > >   1:        902  orion_irq     Level     orion_tick
> > >   4:        795  orion_irq     Level     ttyS0
> > >  13:          0  orion_irq     Level     ehci_hcd:usb2
> > >  18:          0  orion_irq     Level     ehci_hcd:usb1
> > >  22:         69  orion_irq     Level     eth0
> > >  23:        171  orion_irq     Level     orion-mdio
> > >  29:          0  orion_irq     Level     mv_crypto
> > >  31:          2  orion_irq     Level     mv_xor.0
> > >  65:          1  ts7800-irqc   0 Edge      ts-dmac-cpupci
> > > Err:          0
> > > $
> > > 
> > > $ uname -a
> > > Linux ts-7800 6.1.0-rc1 #2 PREEMPT Mon Oct 17 11:19:12 EDT 2022
> > > armv5tel
> > >  GNU/Linux
> > > $
> > > 
> > > Signed-off-by: Firas Ashkar <firas.ashkar@savoirfairelinux.com>
> > > ---
> > > 
> > > Notes:
> > >     Changes in V2
> > >     * limit the commit message
> > 
> > Well, there is still a lot of work to do. Most of this commit message
> > could be reduced to a single paragraph:
> > 
> > "Add support for FooBar IRQ controller usually found on Zorglub
> > platform."
> > 
> > The rest is plain obvious.
> nack, commit message is fine as is!

Allow me to be the judge of that.

> > 
> > >     * format comments in source code
> > >     * use raw spin locks to protect mask/unmask ops
> > >     * use 'handle_edge_irq' and 'irq_ack' logic
> > >     * remove 'irq_domain_xlate_onecell'
> > >     * remove unnecessary status flags
> > >     * use 'builtin_platform_driver' helper routine
> > > 
> > > :100644 100644 2f4fe3ca5c1a ed8378893208 M      arch/arm/mach-
> > > orion5x/ts78xx-fpga.h
> > > :100644 100644 af810e7ccd79 d319a68b7160 M      arch/arm/mach-
> > > orion5x/ts78xx-setup.c
> > > :100644 100644 7ef9f5e696d3 d184fb435c5d
> > > M      drivers/irqchip/Kconfig
> > > :100644 100644 87b49a10962c b022eece2042
> > > M      drivers/irqchip/Makefile
> > > :000000 100644 000000000000 e975607fa4d5
> > > A      drivers/irqchip/irq-ts7800.c
> > >  arch/arm/mach-orion5x/ts78xx-fpga.h  |   1 +
> > >  arch/arm/mach-orion5x/ts78xx-setup.c |  55 +++++
> > >  drivers/irqchip/Kconfig              |  12 +
> > >  drivers/irqchip/Makefile             |   1 +
> > >  drivers/irqchip/irq-ts7800.c         | 347
> > > +++++++++++++++++++++++++++
> > >  5 files changed, 416 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-orion5x/ts78xx-fpga.h b/arch/arm/mach-
> > > orion5x/ts78xx-fpga.h
> > > index 2f4fe3ca5c1a..ed8378893208 100644
> > > --- a/arch/arm/mach-orion5x/ts78xx-fpga.h
> > > +++ b/arch/arm/mach-orion5x/ts78xx-fpga.h
> > > @@ -32,6 +32,7 @@ struct fpga_devices {
> > >         struct fpga_device      ts_rtc;
> > >         struct fpga_device      ts_nand;
> > >         struct fpga_device      ts_rng;
> > > +       struct fpga_device      ts_irqc;
> > >  };
> > >  
> > >  struct ts78xx_fpga_data {
> > > diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-
> > > orion5x/ts78xx-setup.c
> > > index af810e7ccd79..d319a68b7160 100644
> > > --- a/arch/arm/mach-orion5x/ts78xx-setup.c
> > > +++ b/arch/arm/mach-orion5x/ts78xx-setup.c
> > > @@ -322,6 +322,49 @@ static void ts78xx_ts_rng_unload(void)
> > >         platform_device_del(&ts78xx_ts_rng_device);
> > >  }
> > >  
> > > +/*****************************************************************
> > > ************
> > > + * fpga irq controller
> > > +
> > > *******************************************************************
> > > *********/
> > 
> > [...]
> > 
> > Sorry, but I have to ask: what part of "we're not taking any
> > additional non-DT changes to these obsolete setups" did I fail to
> > accurately communicate?
> > 
> > Until this board is entirely converted to DT, I'm not taking any
> > irqchip changes other than the most obvious bug fixes.
> as long as this board is present in the kernel in its current legacy
> form, this is a valid patch!

No. There is a cut of point. Code that we would taken 10 years ago
isn't necessarily valid anymore. We want to improve the kernel as a
whole, and not keep it in the past.

> 
> > 
> > [...]
> > 
> > > +static void ts7800_irq_mask(struct irq_data *d)
> > > +{
> > > +       struct ts7800_irq_data *data =
> > > irq_data_get_irq_chip_data(d);
> > > +       u32 fpga_mask_reg = readl(data->base + IRQ_MASK_REG);
> > > +       u32 mask_bits = 1 << d->hwirq;
> > > +       unsigned long flags;
> > > +
> > > +       raw_spin_lock_irqsave(&data->lock, flags);
> > > +       writel(fpga_mask_reg & ~mask_bits, data->base +
> > > IRQ_MASK_REG);
> > > +       writel(fpga_mask_reg & ~mask_bits, data->bridge +
> > > IRQ_MASK_REG);
> > > +       raw_spin_unlock_irqrestore(&data->lock, flags);
> > 
> > OMFG. What do you expect this protects? Same question applies to all
> > the instances where you take this pointless lock.
> don't jump now
> the locks added as per your previous comment, quoting:
> "I know your HW is UP, but seeing these RMW sequences without a lock
> makes me jump."
> On this single CPU based arch TS78xx, locks are waste of cpu cycles,
> also note that IRQs/preemption are/is already off in this context
> 
> maybe you meant adding locks as to promote general correct coding ?

Let me spell it out for you: RMW means Read-Modify-Write. Putting a
lock around a *write only* serves zero purpose. It is just overhead,
and it is incorrect.

>
> or maybe it was like this previous nonsense comment, quoting :
> "We don't remove interrupt controllers. What happens if someone still
> had a mapping?"

And I stand by it.

> 
> 
> > 
> > [...]
> > 
> > > +static void ts7800_ic_chained_handle_irq(struct irq_desc *desc)
> > > +{
> > > +       struct ts7800_irq_data *data =
> > > irq_desc_get_handler_data(desc);
> > > +       struct irq_chip *chip = irq_desc_get_chip(desc);
> > > +       u32 mask_bits = readl(data->base + IRQ_MASK_REG);
> > > +       u32 status = readl(data->bridge);
> > > +
> > > +       chained_irq_enter(chip, desc);
> > > +
> > > +       if (unlikely(status == 0)) {
> > > +               handle_bad_irq(desc);
> > > +               goto out;
> > > +       }
> > > +
> > > +       do {
> > > +               unsigned int bit = __ffs(status);
> > > +               int irq = irq_find_mapping(data->domain, bit);
> > > +
> > > +               if (irq && (mask_bits & BIT(bit)))
> > > +                       generic_handle_irq(irq);
> > 
> > Again, this is not appropriate. I've pointed you to the right API in
> > my previous review of this patch.
> 'generic_handle_domain_irq' causing some issues

Which issue?

> >
> > [...]
> > 
> > > +static struct platform_driver ts7800_ic_driver = {
> > > +       .probe  = ts7800_ic_probe,
> > > +       .remove = ts7800_ic_remove,
> > > +       .id_table       = ts7800v1_ic_ids,
> > > +       .driver = {
> > > +               .name = DRIVER_NAME,
> > > +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > > +       },
> > > +};
> > > +builtin_platform_driver(ts7800_ic_driver);
> > 
> > Again, this isn't appropriate either, and I pointed it out last
> > time. We have specific helpers for irqchip, and using them isn't
> > optional. But of course, you'll need to move to DT for that.
> > 
> > Anyway, this is the last time I review this patch until you convert
> > the corresponding platform to DT.
> no problems, though have to note this is not constructive!

I've pointed out a bunch of issues, and provided advise on how you can
fix them. That's constructive. A non constructive approach would be to
just ignore your patch. If that's what you prefer, please say so.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: firas ashkar <firas.ashkar@savoirfairelinux.com>
Cc: alex@digriz.org.uk, tglx@linutronix.de,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] irqchip: add TS7800v1 fpga based controller driver
Date: Fri, 21 Oct 2022 18:18:24 +0100	[thread overview]
Message-ID: <86zgdpdrj3.wl-maz@kernel.org> (raw)
In-Reply-To: <7b2ac9ae5f18e5272e52478c73da53a76cf9f2a2.camel@savoirfairelinux.com>

On Fri, 21 Oct 2022 17:19:02 +0100,
firas ashkar <firas.ashkar@savoirfairelinux.com> wrote:
> 
> On Fri, 2022-10-21 at 10:22 +0100, Marc Zyngier wrote:
> > On Thu, 20 Oct 2022 15:13:51 +0100,
> > Firas Ashkar <firas.ashkar@savoirfairelinux.com> wrote:
> > > 
> > > 1. add TS-7800v1 fpga based irq controller driver, and
> > > 2. add related memory and irq resources
> > > 
> > > By default only mapped FPGA interrupts will be chained/multiplexed,
> > > these
> > > chained interrupts will then be available to other device drivers
> > > to
> > > request via the corresponding Linux IRQs.
> > > 
> > > $ cat /proc/cpuinfo
> > > processor       : 0
> > > model name      : Feroceon rev 0 (v5l)
> > > BogoMIPS        : 333.33
> > > Features        : swp half thumb fastmult edsp
> > > CPU implementer : 0x41
> > > CPU architecture: 5TEJ
> > > CPU variant     : 0x0
> > > CPU part        : 0x926
> > > CPU revision    : 0
> > > 
> > > Hardware        : Technologic Systems TS-78xx SBC
> > > Revision        : 0000
> > > Serial          : 0000000000000000
> > > $
> > > 
> > > $ cat /proc/interrupts
> > >            CPU0
> > >   1:        902  orion_irq     Level     orion_tick
> > >   4:        795  orion_irq     Level     ttyS0
> > >  13:          0  orion_irq     Level     ehci_hcd:usb2
> > >  18:          0  orion_irq     Level     ehci_hcd:usb1
> > >  22:         69  orion_irq     Level     eth0
> > >  23:        171  orion_irq     Level     orion-mdio
> > >  29:          0  orion_irq     Level     mv_crypto
> > >  31:          2  orion_irq     Level     mv_xor.0
> > >  65:          1  ts7800-irqc   0 Edge      ts-dmac-cpupci
> > > Err:          0
> > > $
> > > 
> > > $ uname -a
> > > Linux ts-7800 6.1.0-rc1 #2 PREEMPT Mon Oct 17 11:19:12 EDT 2022
> > > armv5tel
> > >  GNU/Linux
> > > $
> > > 
> > > Signed-off-by: Firas Ashkar <firas.ashkar@savoirfairelinux.com>
> > > ---
> > > 
> > > Notes:
> > >     Changes in V2
> > >     * limit the commit message
> > 
> > Well, there is still a lot of work to do. Most of this commit message
> > could be reduced to a single paragraph:
> > 
> > "Add support for FooBar IRQ controller usually found on Zorglub
> > platform."
> > 
> > The rest is plain obvious.
> nack, commit message is fine as is!

Allow me to be the judge of that.

> > 
> > >     * format comments in source code
> > >     * use raw spin locks to protect mask/unmask ops
> > >     * use 'handle_edge_irq' and 'irq_ack' logic
> > >     * remove 'irq_domain_xlate_onecell'
> > >     * remove unnecessary status flags
> > >     * use 'builtin_platform_driver' helper routine
> > > 
> > > :100644 100644 2f4fe3ca5c1a ed8378893208 M      arch/arm/mach-
> > > orion5x/ts78xx-fpga.h
> > > :100644 100644 af810e7ccd79 d319a68b7160 M      arch/arm/mach-
> > > orion5x/ts78xx-setup.c
> > > :100644 100644 7ef9f5e696d3 d184fb435c5d
> > > M      drivers/irqchip/Kconfig
> > > :100644 100644 87b49a10962c b022eece2042
> > > M      drivers/irqchip/Makefile
> > > :000000 100644 000000000000 e975607fa4d5
> > > A      drivers/irqchip/irq-ts7800.c
> > >  arch/arm/mach-orion5x/ts78xx-fpga.h  |   1 +
> > >  arch/arm/mach-orion5x/ts78xx-setup.c |  55 +++++
> > >  drivers/irqchip/Kconfig              |  12 +
> > >  drivers/irqchip/Makefile             |   1 +
> > >  drivers/irqchip/irq-ts7800.c         | 347
> > > +++++++++++++++++++++++++++
> > >  5 files changed, 416 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-orion5x/ts78xx-fpga.h b/arch/arm/mach-
> > > orion5x/ts78xx-fpga.h
> > > index 2f4fe3ca5c1a..ed8378893208 100644
> > > --- a/arch/arm/mach-orion5x/ts78xx-fpga.h
> > > +++ b/arch/arm/mach-orion5x/ts78xx-fpga.h
> > > @@ -32,6 +32,7 @@ struct fpga_devices {
> > >         struct fpga_device      ts_rtc;
> > >         struct fpga_device      ts_nand;
> > >         struct fpga_device      ts_rng;
> > > +       struct fpga_device      ts_irqc;
> > >  };
> > >  
> > >  struct ts78xx_fpga_data {
> > > diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-
> > > orion5x/ts78xx-setup.c
> > > index af810e7ccd79..d319a68b7160 100644
> > > --- a/arch/arm/mach-orion5x/ts78xx-setup.c
> > > +++ b/arch/arm/mach-orion5x/ts78xx-setup.c
> > > @@ -322,6 +322,49 @@ static void ts78xx_ts_rng_unload(void)
> > >         platform_device_del(&ts78xx_ts_rng_device);
> > >  }
> > >  
> > > +/*****************************************************************
> > > ************
> > > + * fpga irq controller
> > > +
> > > *******************************************************************
> > > *********/
> > 
> > [...]
> > 
> > Sorry, but I have to ask: what part of "we're not taking any
> > additional non-DT changes to these obsolete setups" did I fail to
> > accurately communicate?
> > 
> > Until this board is entirely converted to DT, I'm not taking any
> > irqchip changes other than the most obvious bug fixes.
> as long as this board is present in the kernel in its current legacy
> form, this is a valid patch!

No. There is a cut of point. Code that we would taken 10 years ago
isn't necessarily valid anymore. We want to improve the kernel as a
whole, and not keep it in the past.

> 
> > 
> > [...]
> > 
> > > +static void ts7800_irq_mask(struct irq_data *d)
> > > +{
> > > +       struct ts7800_irq_data *data =
> > > irq_data_get_irq_chip_data(d);
> > > +       u32 fpga_mask_reg = readl(data->base + IRQ_MASK_REG);
> > > +       u32 mask_bits = 1 << d->hwirq;
> > > +       unsigned long flags;
> > > +
> > > +       raw_spin_lock_irqsave(&data->lock, flags);
> > > +       writel(fpga_mask_reg & ~mask_bits, data->base +
> > > IRQ_MASK_REG);
> > > +       writel(fpga_mask_reg & ~mask_bits, data->bridge +
> > > IRQ_MASK_REG);
> > > +       raw_spin_unlock_irqrestore(&data->lock, flags);
> > 
> > OMFG. What do you expect this protects? Same question applies to all
> > the instances where you take this pointless lock.
> don't jump now
> the locks added as per your previous comment, quoting:
> "I know your HW is UP, but seeing these RMW sequences without a lock
> makes me jump."
> On this single CPU based arch TS78xx, locks are waste of cpu cycles,
> also note that IRQs/preemption are/is already off in this context
> 
> maybe you meant adding locks as to promote general correct coding ?

Let me spell it out for you: RMW means Read-Modify-Write. Putting a
lock around a *write only* serves zero purpose. It is just overhead,
and it is incorrect.

>
> or maybe it was like this previous nonsense comment, quoting :
> "We don't remove interrupt controllers. What happens if someone still
> had a mapping?"

And I stand by it.

> 
> 
> > 
> > [...]
> > 
> > > +static void ts7800_ic_chained_handle_irq(struct irq_desc *desc)
> > > +{
> > > +       struct ts7800_irq_data *data =
> > > irq_desc_get_handler_data(desc);
> > > +       struct irq_chip *chip = irq_desc_get_chip(desc);
> > > +       u32 mask_bits = readl(data->base + IRQ_MASK_REG);
> > > +       u32 status = readl(data->bridge);
> > > +
> > > +       chained_irq_enter(chip, desc);
> > > +
> > > +       if (unlikely(status == 0)) {
> > > +               handle_bad_irq(desc);
> > > +               goto out;
> > > +       }
> > > +
> > > +       do {
> > > +               unsigned int bit = __ffs(status);
> > > +               int irq = irq_find_mapping(data->domain, bit);
> > > +
> > > +               if (irq && (mask_bits & BIT(bit)))
> > > +                       generic_handle_irq(irq);
> > 
> > Again, this is not appropriate. I've pointed you to the right API in
> > my previous review of this patch.
> 'generic_handle_domain_irq' causing some issues

Which issue?

> >
> > [...]
> > 
> > > +static struct platform_driver ts7800_ic_driver = {
> > > +       .probe  = ts7800_ic_probe,
> > > +       .remove = ts7800_ic_remove,
> > > +       .id_table       = ts7800v1_ic_ids,
> > > +       .driver = {
> > > +               .name = DRIVER_NAME,
> > > +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > > +       },
> > > +};
> > > +builtin_platform_driver(ts7800_ic_driver);
> > 
> > Again, this isn't appropriate either, and I pointed it out last
> > time. We have specific helpers for irqchip, and using them isn't
> > optional. But of course, you'll need to move to DT for that.
> > 
> > Anyway, this is the last time I review this patch until you convert
> > the corresponding platform to DT.
> no problems, though have to note this is not constructive!

I've pointed out a bunch of issues, and provided advise on how you can
fix them. That's constructive. A non constructive approach would be to
just ignore your patch. If that's what you prefer, please say so.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-10-21 17:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 14:13 [PATCH v2] irqchip: add TS7800v1 fpga based controller driver Firas Ashkar
2022-10-20 14:13 ` Firas Ashkar
2022-10-21  9:22 ` Marc Zyngier
2022-10-21  9:22   ` Marc Zyngier
2022-10-21 16:19   ` firas ashkar
2022-10-21 16:19     ` firas ashkar
2022-10-21 17:18     ` Marc Zyngier [this message]
2022-10-21 17:18       ` Marc Zyngier
2022-10-21 18:14       ` firas ashkar
2022-10-21 18:14         ` firas ashkar
2022-10-22 10:04         ` Marc Zyngier
2022-10-22 10:04           ` Marc Zyngier
2022-10-24 20:08           ` firas ashkar
2022-10-24 20:08             ` firas ashkar

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=86zgdpdrj3.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alex@digriz.org.uk \
    --cc=firas.ashkar@savoirfairelinux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.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: link
Be 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.