linux-kernel - Re: [RFC v4 net-next 2/4] net: dsa: mt7530: add interrupt support

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:   Tue, 13 Apr 2021 09:06:51 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     DENG Qingfang <dqfext@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Sean Wang <sean.wang@...iatek.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>,
        linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        linux-staging@...ts.linux.dev, devicetree@...r.kernel.org,
        netdev@...r.kernel.org, Weijie Gao <weijie.gao@...iatek.com>,
        Chuanhong Guo <gch981213@...il.com>,
        René van Dorst <opensource@...rst.com>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Ungerer <gerg@...nel.org>
Subject: Re: [RFC v4 net-next 2/4] net: dsa: mt7530: add interrupt support

On Tue, 13 Apr 2021 01:07:23 +0100,
Andrew Lunn <andrew@...n.ch> wrote:
> 
> > > > +static void
> > > > +mt7530_setup_mdio_irq(struct mt7530_priv *priv)
> > > > +{
> > > > +	struct dsa_switch *ds = priv->ds;
> > > > +	int p;
> > > > +
> > > > +	for (p = 0; p < MT7530_NUM_PHYS; p++) {
> > > > +		if (BIT(p) & ds->phys_mii_mask) {
> > > > +			unsigned int irq;
> > > > +
> > > > +			irq = irq_create_mapping(priv->irq_domain, p);
> > > 
> > > This seems odd. Why aren't the MDIO IRQs allocated on demand as
> > > endpoint attached to this interrupt controller are being probed
> > > individually? In general, doing this allocation upfront is an
> > > indication that there is some missing information in the DT to perform
> > > the discovery.
> > 
> > This is what Andrew's mv88e6xxx does, actually. In addition, I also check
> > the phys_mii_mask to avoid creating mappings for unused ports.
> 
> It can be done via DT, using the standard interrupt property, so long
> as you use of_mdiobus_register(np).
> 
> But when you have an 7 port switch, and a nice simple mapping, port 0
> PHY using interrupt 0, you can save a lot of device tree boilerplate
> by doing it in code. And when you have 4 of these switches, it gets
> very boring adding all the DT to just wire up the interrupts 28
> interrupts.

I guess this is depends whether the most usual case is to have all
these interrupts being actively in use or not. Most interrupts only
use a limited portion of their interrupt space at any given time.
Allocating all interrupts and creating mappings upfront is a waste of
memory.

If the use case here is that all these interrupts will be wired and
used in most cases, then upfront allocation is probably not a problem.

	M.

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