From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 805BBC5519F for ; Sat, 14 Nov 2020 20:17:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3DB2620709 for ; Sat, 14 Nov 2020 20:17:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726334AbgKNUQt (ORCPT ); Sat, 14 Nov 2020 15:16:49 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:55578 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726325AbgKNUQt (ORCPT ); Sat, 14 Nov 2020 15:16:49 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1ke1yP-0074po-V3; Sat, 14 Nov 2020 21:16:37 +0100 Date: Sat, 14 Nov 2020 21:16:37 +0100 From: Andrew Lunn To: Marek Behun Cc: Gregory CLEMENT , arm@kernel.org, Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Jason Cooper , Andreas =?iso-8859-1?Q?F=E4rber?= , Rob Herring , devicetree@vger.kernel.org Subject: Re: [PATCH mvebu-dt 3/6] ARM: dts: turris-omnia: describe ethernet-phy interrupt Message-ID: <20201114201637.GG1480543@lunn.ch> References: <20201114160409.19670-1-kabel@kernel.org> <20201114160409.19670-4-kabel@kernel.org> <20201114174928.5ab4f8ae@kernel.org> <20201114171639.GO1456319@lunn.ch> <20201114184221.1f74de86@kernel.org> <20201114184717.3018bff5@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201114184717.3018bff5@nic.cz> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, Nov 14, 2020 at 06:47:17PM +0100, Marek Behun wrote: > On Sat, 14 Nov 2020 18:42:21 +0100 > Marek Behún wrote: > > > Do you think we should just poll for interrupts with the PHY? Yes. > > Andrew, JFI, there are also SFP GPIOs connected to this expander. So > interrupt will be generated on changes from those gpios as well. Is an > interrupt storm seriosly probable here? As far as i remember on the device i was using, all inputs are interrupt sources. And all pins default as inputs, so you don't accidentally drive the output against something else. So you need to get the device properly configured before enabling its interrupt. And i'm not too sure how that works with the GPIO framework where you effectively have a collection of individual GPIOs. How do you know they have all be configured, and it is safe to enable the interrupt output? Do you have any pins floating? Those you are going to have to configure as output. Plus is the interrupt output from the gpio expander level triggered? If so you need to ensure the upstream interrupt controller can do level. And Marvell SoCs often cannot. The device i was working on i had trouble even getting it to boot without dying. Polling the PHY and SFP was working O.K, so i gave up. And i suggested the next revision of the board used an sx150x which has much better interrupt support. That has worked well against a Vybrid. Andrew