On Tue, Apr 13, 2021 at 02:52:59PM +0200, Andrew Lunn wrote: > > 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. > > Hi Marc > > The interrupts are generally used. Since this is an Ethernet switch, > generally the port is administratively up, even if there is no cable > plugged in. Once/if a cable is plugged in and there is a link peer, > the PHY will interrupt to indicate this. > > The only real case i can think of when the interrupts are not used is > when the switch has more ports than connected to the front panel. This > can happen in industrial settings, but not SOHO. Those ports which > don't go anywhere are never configured up and so the interrupt is > never used. Hi Andrew This is what the extra check (BIT(p) & ds->phys_mii_mask) avoids. Currently the mv88e6xxx driver does not have this check, and creates 15 PHY IRQ mappings on my 88E6176 unconditionally, leaving a gap in /proc/interrupts: ... 57: 0 0 mv88e6xxx-g1 3 Edge mv88e6xxx-f1072004.mdio-mii:00-g1-atu-prob 59: 0 0 mv88e6xxx-g1 5 Edge mv88e6xxx-f1072004.mdio-mii:00-g1-vtu-prob 61: 8 5 mv88e6xxx-g1 7 Edge mv88e6xxx-f1072004.mdio-mii:00-g2 63: 8 4 mv88e6xxx-g2 0 Edge mv88e6xxx-1:00 64: 0 0 mv88e6xxx-g2 1 Edge mv88e6xxx-1:01 65: 0 0 mv88e6xxx-g2 2 Edge mv88e6xxx-1:02 66: 0 0 mv88e6xxx-g2 3 Edge mv88e6xxx-1:03 67: 0 2 mv88e6xxx-g2 4 Edge mv88e6xxx-1:04 // IRQ 68~77 are created but not used 78: 0 0 mv88e6xxx-g2 15 Edge mv88e6xxx-f1072004.mdio-mii:00-watchdog ... You may as well add irq_set_nested_thread(irq, true) to irq_domain_map so all IRQs share a single thread. > > Andrew
