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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham 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 3B0ECC282C4 for ; Mon, 4 Feb 2019 21:38:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 047B020823 for ; Mon, 4 Feb 2019 21:38:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730140AbfBDViy convert rfc822-to-8bit (ORCPT ); Mon, 4 Feb 2019 16:38:54 -0500 Received: from simcoe207srvr.owm.bell.net ([184.150.200.207]:37207 "EHLO torfep01.bell.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726051AbfBDViy (ORCPT ); Mon, 4 Feb 2019 16:38:54 -0500 Received: from bell.net torfep01 184.150.200.158 by torfep01.bell.net with ESMTP id <20190204213853.DAXC24623.torfep01.bell.net@torspm01.bell.net> for ; Mon, 4 Feb 2019 16:38:53 -0500 Received: from [192.168.0.138] (really [64.231.92.241]) by torspm01.bell.net with ESMTP id <20190204213853.LLGO10318.torspm01.bell.net@[192.168.0.138]>; Mon, 4 Feb 2019 16:38:53 -0500 To: Andrew Lunn Cc: Russell King , Vivien Didelot , Florian Fainelli , netdev@vger.kernel.org References: <20190123002240.GF3634@lunn.ch> <20190130172818.GJ21904@lunn.ch> <2ea9fd81-f92d-9505-dd0b-bdd0f67d8ce7@bell.net> <20190130223846.GB30115@lunn.ch> <9415d82e-965b-7777-0ad0-f23d6c9f177e@bell.net> <53b49df8-53ed-704f-9197-230b18d83090@bell.net> <20190204193518.GE24989@lunn.ch> <2d8c0eff-00cd-31c7-9906-89ff9d3c7dd4@bell.net> <20190204201905.GA2488@lunn.ch> From: John David Anglin Openpgp: preference=signencrypt Subject: Re: [PATCH] net: phylink: dsa: mv88e6xxx: Revise irq setup ordering Message-ID: Date: Mon, 4 Feb 2019 16:38:53 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190204201905.GA2488@lunn.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Cloudmark-Analysis: v=2.2 cv=N5jGLy1B c=1 sm=0 tr=0 a=jJmVOGxBrKxWvcjqaG+oVg==:17 a=IkcTkHD0fZMA:10 a=CFTnQlWoA9kA:10 a=FBHGMhGWAAAA:8 a=ePnjWw5Cn9YE7r-1RVwA:9 a=QEXdDO2ut3YA:10 a=9gvnlMMaQFpL9xblJ6ne:22 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2019-02-04 3:19 p.m., Andrew Lunn wrote: > The IRQ core would do this if it was needed. > > How many other irq thread work functions can you point to which do > something similar? This is comment for handle_edge_irq: /**  *    handle_edge_irq - edge type IRQ handler  *    @desc:    the interrupt description structure for this irq  *  *    Interrupt occures on the falling and/or rising edge of a hardware  *    signal. The occurrence is latched into the irq controller hardware  *    and must be acked in order to be reenabled. After the ack another  *    interrupt can happen on the same source even before the first one  *    is handled by the associated event handler. If this happens it  *    might be necessary to disable (mask) the interrupt depending on the  *    controller hardware. This requires to reenable the interrupt inside  *    of the loop which handles the interrupts which have arrived while  *    the handler was running. If all pending interrupts are handled, the  *    loop is left.  */ As can be seen, the above comment suggests that it may be necessary to disable (mask) interrupt as I proposed. I see no evidence from the Marvell functional specifications for the 88E6341 that it sequences interrupts from the various sources although it might be that device interrupts are sequenced so INTn rises and falls.  I haven't seen any ports fail to link without the hunk on espressobin but it is hard to stress test the code. Disabling and re-enabling interrupts in the global control register does not affect their status. Thus, at worst, the hunk adds a bit of unnecessary code.  It could be skipped if we knew we were using level interrupts. Dave -- John David Anglin dave.anglin@bell.net