Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2576534pxb; Tue, 13 Apr 2021 05:27:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7+GaAM3NmGFUEiOvzr4nwP3rJ8BOCw9SZUrPDzhY+zKXoGCxenX17gHlk+qOeK/qsfzYt X-Received: by 2002:a50:ed08:: with SMTP id j8mr35456147eds.351.1618316841584; Tue, 13 Apr 2021 05:27:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618316841; cv=none; d=google.com; s=arc-20160816; b=DRzKYhPFRmXFXOKNkRKJCRoX/HDDNgLqph/sZSRTZeNG6gOC5nen3ChfPukarlUaOT NutpPnyRL71WkzsNJyY2rIVDGs1tvT7L0HEkRyp472qgsd67BjDxITgC76uZteBVh10c xgL6nuHh2nJuRpxu+7uyfR0Yk9Ka0hdAW5HyiOWZNaxHvd2jsjr3KVo3pV9oRyaYn7BM 80DXDkQ4fYDNU6R6UxgM9S8WiK0sgxER5gm5ZWP35qEAlABklOb3127McneB3onxZZ7g wskuPuZPMsX+WXynkgHowEqZTiLBMLIAHvy0gNRu0Mad+D/dkY8T1T32rH4tZccxLKmc 4O/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=34ExIe+8R25fJHNiOuUFOiYzyB7blgnO1LGRtGjsmmU=; b=TDzWi1y9wrPCiD6t/V0cvHbwvKi3vehjzZKMhQgrUhnfEb/JW5uwkcLj1kx9wgZPMH AzjIwO+tNKPWEGo9zSCUZiDUgAwUUw6nOuPE7YIKV1t7yxuOgk+euSLIwYBs/a0K7Sb3 iTgYE+akFCif5/0bmWovq0/RkRGjqCbpg/4D7MlkcgZOMIp9wqxq+Q/MALC+WnxPfq22 6rWZJSNtpkU/nERUlKu+koWvNwuDC+rJBgjjVjt7H2/zPSRzQQsK2i70f/402zz8xM8o yOKYZr8hMEtd5aBCoxa7FBmI3P86KVDpIwtZPEf9VYYwIcO1aVP/W1kU0WUkMWxGokQ3 tTPg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c13si9844527eje.45.2021.04.13.05.26.58; Tue, 13 Apr 2021 05:27:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344260AbhDMAHt (ORCPT + 99 others); Mon, 12 Apr 2021 20:07:49 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46964 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238214AbhDMAHt (ORCPT ); Mon, 12 Apr 2021 20:07:49 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lW6aR-00GNup-Cv; Tue, 13 Apr 2021 02:07:23 +0200 Date: Tue, 13 Apr 2021 02:07:23 +0200 From: Andrew Lunn To: DENG Qingfang Cc: Marc Zyngier , "David S. Miller" , Florian Fainelli , Heiner Kallweit , Jakub Kicinski , Landen Chao , Matthias Brugger , Russell King , Sean Wang , Vivien Didelot , Vladimir Oltean , Rob Herring , Linus Walleij , Greg Kroah-Hartman , Sergio Paracuellos , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-staging@lists.linux.dev, devicetree@vger.kernel.org, netdev@vger.kernel.org, Weijie Gao , Chuanhong Guo , =?iso-8859-1?Q?Ren=E9?= van Dorst , Frank Wunderlich , Thomas Gleixner , Greg Ungerer Subject: Re: [RFC v4 net-next 2/4] net: dsa: mt7530: add interrupt support Message-ID: References: <20210412034237.2473017-1-dqfext@gmail.com> <20210412034237.2473017-3-dqfext@gmail.com> <87fszvoqvb.wl-maz@kernel.org> <20210412152210.929733-1-dqfext@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210412152210.929733-1-dqfext@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > +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. > Andrew, perhaps this can be done in DSA core? Not easily. It is not always a simple mapping like this. Two of the switches supported by mv88exxx offset the PHYs by 0x10. You really need the switch driver involved, with its detailed knowledge of the hardware. Andrew