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_INVALID,DKIM_SIGNED, 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 85F6BC76186 for ; Tue, 23 Jul 2019 21:52:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 58E2E218F0 for ; Tue, 23 Jul 2019 21:52:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="EsXqCRtQ"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="EsXqCRtQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731278AbfGWVwf (ORCPT ); Tue, 23 Jul 2019 17:52:35 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58132 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728103AbfGWVwf (ORCPT ); Tue, 23 Jul 2019 17:52:35 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 7B3C4615BF; Tue, 23 Jul 2019 21:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563918754; bh=RSyzP7VuwcQnmyMg0sztV95p9t97Vsc4pA9J0mnzN7U=; h=Date:From:To:Cc:Subject:From; b=EsXqCRtQp1rf1jr4V+cmLTUrlSbrf275bHrvQuYMmePO+GQyVPUzeXKrOQt+P09ij PAMcGcX5UX1dzHH2ctaWxWjcq8lS7qH0FRvI0F7MNYNEJUWQ83NvM65lQX8iD85HpK 3OFy9z1Wpt1HshIrKf+to8EF+UCeZPvmZ2+VreMo= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 34AAC61157; Tue, 23 Jul 2019 21:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563918754; bh=RSyzP7VuwcQnmyMg0sztV95p9t97Vsc4pA9J0mnzN7U=; h=Date:From:To:Cc:Subject:From; b=EsXqCRtQp1rf1jr4V+cmLTUrlSbrf275bHrvQuYMmePO+GQyVPUzeXKrOQt+P09ij PAMcGcX5UX1dzHH2ctaWxWjcq8lS7qH0FRvI0F7MNYNEJUWQ83NvM65lQX8iD85HpK 3OFy9z1Wpt1HshIrKf+to8EF+UCeZPvmZ2+VreMo= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 23 Jul 2019 14:52:34 -0700 From: pheragu@codeaurora.org To: marc.zyngier@arm.com, Linux Kernel , Linux-arm Msm Cc: psodagud@codeaurora.org, Tsoni , rananta@codeaurora.org, mnalajal@codeaurora.org Subject: Warning seen when removing a module using irqdomain framework Message-ID: X-Sender: pheragu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, I have been working on a interrupt controller driver that uses tree based mapping for its domain (irq_domain_add_tree(..)). If I understand correctly, the clients get a mapping when they call platform_get_irq(..). However, after these clients are removed (rmmod), when I try to remove the interrupt controller driver where it calls irq_domain_remove(..), I hit this warning from kernel/kernel/irq/irqdomain.c:: irq_domain_remove(..) [WARN_ON(!radix_tree_empty(&domain->revmap_tree));]- WARNING: CPU: 0 PID: 238 at /kernel/kernel/irq/irqdomain.c:246 irq_domain_remove+0x84/0x98 Also, I see that the requested IRQs by the clients are still present (in /proc/interrupts) even after they had been removed. Hence, I just wanted to know how to handle this warning. Should the client clean up by calling irq_dispose_mapping(..) or is it the responsibility of the interrupt controller driver to dispose the mappings one by one? Regards, Prakruthi Deepak Heragu