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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 23C1BC433DF for ; Mon, 15 Jun 2020 14:57:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F3C3E20644 for ; Mon, 15 Jun 2020 14:57:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592233040; bh=uymLKgjS97z/sTHQNwWzkQyWi0WqhtFk0Kd2t3cwE8k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=lMev/NA+3Lkmw2MKV0WqRoXaqrhrONGR8wUPvAv5D6jbtgd5LYL9FRsi5j6aAlOAr 1Ppd8owXeGKGoPE1RdCgodOOErH/fORCwDfrQTGQ0BGwCI1QNzRuAr+fErFTDQpnKz 0qDxNfBuTIfzluj52vlEsAYOn0tNTZ3B+gA1Geuc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730856AbgFOO5S (ORCPT ); Mon, 15 Jun 2020 10:57:18 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:40081 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730652AbgFOO5R (ORCPT ); Mon, 15 Jun 2020 10:57:17 -0400 Received: by mail-wm1-f66.google.com with SMTP id r15so15150729wmh.5; Mon, 15 Jun 2020 07:57:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mHcrbBO+Fo3bCvnKiSJoGOEsXEa+5QUFU82tEXS61oo=; b=ogcYxfeBxA3qwa97mzrPW4jopWKMl64hXm7wg3STD1q+94yNg/pyj0DXYNIJfvSOQT azvYNagX3x48ssnmy+HICSeQ2mkqKvnCs2zl9PU5Yj78VmJW6Lqy2vhHl0nmbcZV/649 w8vkmTP+K5H+jRoSaw5eRCWd3CT8Lr0zstF1/8VNEiXajHcuHSAKjpIoNnVhBOQE510m LKUUEKVpyNKoZAV3ZMq8TRtpgEdtHwSN8H80hyALfXvVZs5VnK/IZas882+H30MCsHU7 U4uu/U/K3UKJNxMKH5oY4DoC+3XrOvRdimldFlX+9CVqmDw34Jwn7h55Ij8Yj1SlOps2 m2Uw== X-Gm-Message-State: AOAM533t3mN9LVm+kKdihYnfkL7IFG8kPLbsu+IVn0cwfVWqLUDdeQlx KY1FV+M9ItiPOfq0Nv5DCjE= X-Google-Smtp-Source: ABdhPJxeN+YKTx2rDQYMG6z/DLFGaJz5APWUznLyEEfgFrNUKvASgGOX1PuuNkKdoJhfxX4g/JUpFA== X-Received: by 2002:a1c:7903:: with SMTP id l3mr13169484wme.50.1592233034481; Mon, 15 Jun 2020 07:57:14 -0700 (PDT) Received: from kozik-lap ([194.230.155.184]) by smtp.googlemail.com with ESMTPSA id s8sm24402667wrm.96.2020.06.15.07.57.13 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Jun 2020 07:57:13 -0700 (PDT) Date: Mon, 15 Jun 2020 16:57:11 +0200 From: Krzysztof Kozlowski To: Vladimir Oltean Cc: Mark Brown , Marc Kleine-Budde , Thomas Gleixner , Vladimir Oltean , linux-spi , lkml , Wolfram Sang , stable@vger.kernel.org, Pengutronix Kernel Team Subject: Re: [PATCH v2 1/3] spi: spi-fsl-dspi: Fix external abort on interrupt in exit paths Message-ID: <20200615145711.GA24927@kozik-lap> References: <1592208439-17594-1-git-send-email-krzk@kernel.org> <20200615123052.GO4447@sirena.org.uk> <20200615131006.GR4447@sirena.org.uk> <20200615134119.GB3321@kozik-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 15, 2020 at 05:23:28PM +0300, Vladimir Oltean wrote: > On Mon, 15 Jun 2020 at 16:41, Krzysztof Kozlowski wrote: > > > > On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote: > > > On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote: > > > > > > > > > > > It's a bit unusual to need to actually free the IRQ over suspend - > > > > what's driving that requirement here? > > > > > > clk_disable_unprepare(dspi->clk); is driving the requirement - same as > > > in dspi_remove case, the module will fault when its registers are > > > accessed without a clock. > > > > In few cases when I have shared interrupt in different drivers, they > > were just disabling it during suspend. Why it has to be freed? > > > > Best regards, > > Krzysztof > > > > Not saying it _has_ to be freed, just to be prevented from running > concurrently with us disabling the clock. > But if we can get away in dspi_suspend with just disable_irq, can't we > also get away in dspi_remove with just devm_free_irq? One reason why they have to be different could be following scenario: 1. Device could be unbound any time and disabling IRQ in remove() would effectively disable the IRQ also for other devices using this shared line. First disable_irq() really disables it, the latter just increases the counter. 2. However during system suspend, it is expected that all drivers in their suspend (and later resume) callbacks will do the same - disable the shared IRQ line. And finally the system disables interrupts globally so the line will be balanced. Freeing IRQ solves the case #1 without causing any imbalance between enables/disables or requests/frees. Disabling IRQ solves the #2, also without any imbalance. Best regards, Krzysztof