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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F1D9FC433DF for ; Fri, 29 May 2020 17:45:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D46B72065C for ; Fri, 29 May 2020 17:45:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QBaHbk14" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727085AbgE2RpJ (ORCPT ); Fri, 29 May 2020 13:45:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727890AbgE2RpI (ORCPT ); Fri, 29 May 2020 13:45:08 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87E1BC03E969; Fri, 29 May 2020 10:45:08 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id l11so4766810wru.0; Fri, 29 May 2020 10:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qyilkDkEXs9eRR0aDai46RFr8RI6mIia71DbVroQLVU=; b=QBaHbk14iG9YRTPIDgH26JV5us6Yd6RFPJILW7tz8taGcaqrr9mIlhsj9vJhGaDFq+ qfKEXRifzavH8I54c/tLxqSunkEkVlWh21Gt6sRPbc8lUhXDAr6nauuVZpyKjXkbKJmZ MnD/rQk9TB3pUljpVQovYABH0pJYAH+KQWliJWDjjHebs4ff5hS56CY9bpi4WXiRf2iy 9FpvllK0UNz6bJBDjSsSU85k+WMBKGstzExCTPxy+JecIxbKAj6hhPL3ya+0JbonyKzx UXz9VLTFO9bbHT1pbfZ+v4vDsxNKcHH1AGmWkRQKv+xKajqCFx7I9yQM1xb00YJBTDGl UiaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qyilkDkEXs9eRR0aDai46RFr8RI6mIia71DbVroQLVU=; b=l74uMM0DzF5ffY5ZHJum9NemSBkQtsdENhwbWmuuysqYht0Sw4ihgo1LScUOFFWWW4 fiHD1pgKWvkCrut2mi3QqSUPjXFZybpPmDeY8vHfkd1S1+iuJDi/Z5O7K9omqejtkqDT IdsM+U9eZ9AVCyyln7usrPXss6BBjsTFULwMWuyYSTBHmeNWfub2CSz5H5/ZqSgrLWYu ytUVB4OQKfff4DEN8u4gpwQD032b5LtSozstsviZoeqJZ8W4NpaNNokAjiigYS3u5+Qh FV6mHZRrXJfpOHjvBubf7dQmiKLIPE8z9XmLSM2qstnhKMPpGSfoTJijwUOWL5q7BhQL N1ow== X-Gm-Message-State: AOAM5324mOVMceaaNy4xAeXbTTPwiq0WR8wDniszR5rOxkbWbvcmE7Yv bVCA1EIkiQQVTLjy27aSIR074V2cUyGlB2mL7zk= X-Google-Smtp-Source: ABdhPJwPloB0m/tm/NkncwwpHlp2HQrubDQbocpXuvAjz21ovS5umtEBdESPCcRDxA0c19JkEgtieM94rFX9YK9+O7c= X-Received: by 2002:adf:e3c4:: with SMTP id k4mr9620950wrm.262.1590774307312; Fri, 29 May 2020 10:45:07 -0700 (PDT) MIME-Version: 1.0 References: <1d3bae1b3048f5d6e19f7ef569dd77e9e160a026.1590753016.git.hminas@synopsys.com> <0f6b1580-41d8-b7e7-206b-64cda87abfd5@synopsys.com> In-Reply-To: From: Frank Mori Hess Date: Fri, 29 May 2020 13:44:56 -0400 Message-ID: Subject: Re: [PATCH] usb: dwc2: Fix shutdown callback in platform To: Doug Anderson Cc: Minas Harutyunyan , John Youn , Felipe Balbi , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , Felipe Balbi , =?UTF-8?Q?Heiko_St=C3=BCbner?= , "# 4.0+" Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Fri, May 29, 2020 at 12:37 PM Doug Anderson wrote: > > I'm not sure I understand. Are you saying that you'll just add > shutdown callbacks to all the drivers using this IRQ and call > disable_irq() there? That seems like the best solution to me. I don't get it. A hypothetical machine could have literally anything sharing the IRQ line, right? If it is important to call disable_irq during shutdown (I have no idea if it is) then shouldn't the kernel core just disable all irqs after calling all the driver shutdown callbacks? Anyways, my screaming interrupt occurs after a a new kernel has been booted with kexec. In this case, it doesn't matter if the old kernel called disable_irq or not. As soon as the new kernel re-enables the interrupt line, the kernel immediately disables it again with a backtrace due to the unhandled screaming interrupt. That's why the dwc2 hardware needs to have its interrupts turned off when the old kernel is shutdown. -- Frank