Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1766890imm; Thu, 14 Jun 2018 03:37:23 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJReLTFdMItxsUksl4DiZZx9GA8sZlaA3PToihmRrCFN6CvUEpCv5poUXXsz6F7CMcNzS/P X-Received: by 2002:a17:902:b60b:: with SMTP id b11-v6mr2452981pls.330.1528972643630; Thu, 14 Jun 2018 03:37:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528972643; cv=none; d=google.com; s=arc-20160816; b=LVST4JXS6KMI9rTxluWyb6rvKi0eaR5sXGKcvLj3SU4ck3BiYUs/JZTO3j8MoAF1m2 5m7ImvwFuujIEFoYisxGjVZJxqMl9Eup2SUqVUVXJl0Dr6/sKiV0dXqs4K5crGSeNOgw speFH8IDrEskw369PKjz1qOXCOiBAKUkpnC2vO0VhC8Vd1+a8FPhPoQDG4Dh8sXGFr4p NM0eXNmx4sg70IUM/JgUQGQtyAwrGQ91jXVL20jPPFRZF6RlQXxtwWpMx0whfJEdcfN8 DU6PP9xHcu47S2BnsaUkG02qO3n+LpMq60gwEbuTUhlkOmN1v6S+akPSpCQUpA7ydLDk Oxdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=s0ayo8rMxOtMSw5pOYBFiLv/NYDg6iA0FWNq0qGYqcM=; b=GOIenGatngFVzUORlnu8hFaivVGfkwKMI8G6D2mWO0NG8iXMuHpOGdFxhQAOL39MKs Mfafz9xp0vaS9wy4vgGbv9DUoEQ98ztunypzxN5L876E1KUcJVpzIqsHxDNzixlBBaOL iBCmMUePBTLICsAitmxmpE1u/jWkAAOLFba7HIqwmpWUge7j/mhDsnvhxMOHVTUgmzlH fGqz4iqimWHnMFIGAf29AWXWHddDGoS50ASsdWmqZ3PLRxUsHxcaFtgOtBLURxqRv7OI 4NQ8oFYodNp/eE73ibE6CJe8oSdDaKafm3QOLGIYxwRrarwulyLH19/6f5VcAms7+ime u8Cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="d/jSyG9V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l3-v6si4122289pgp.345.2018.06.14.03.37.09; Thu, 14 Jun 2018 03:37:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="d/jSyG9V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754998AbeFNKgB (ORCPT + 99 others); Thu, 14 Jun 2018 06:36:01 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:36407 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754901AbeFNKgA (ORCPT ); Thu, 14 Jun 2018 06:36:00 -0400 Received: by mail-lf0-f65.google.com with SMTP id u4-v6so8644001lff.3 for ; Thu, 14 Jun 2018 03:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s0ayo8rMxOtMSw5pOYBFiLv/NYDg6iA0FWNq0qGYqcM=; b=d/jSyG9VqU5G8Wnyf9lgSusKottw+W3s+nB3v6S1DsBXSYQjMpP8bhOEDASMcE4fpV lWmvM9zH5kFX3Z/rygg4GdL468an04jdUzf9HNFg4tRBis4m9Hqp/d43evkAsUfsl8hd OwZXjwtFNZOKQcr2WTt/6drwTvsi367hWj7quzXqjr4uZ1nJvYsSzK65cSxCk+2FolZl 4+mGLGrvAS+3Ehw9+quIYoA30oDLPYm79TzO3/QxeaL5Qknc/6trb2lVvSCpyqDzWmSe poJaQTq9uvY3fHh6PhiInEX7zF2ykPDQpsRs3j9M5tBaG1QZvn5R35EXVBzHfwyAqTH/ oq9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s0ayo8rMxOtMSw5pOYBFiLv/NYDg6iA0FWNq0qGYqcM=; b=eCmREc5HrnlMq4qe6mRWka/njO/VsA9IzOhOT5Y8ipN4Hx//kiD2eNpeEjeM+TxpBQ kVGf9yHbuS6ZlVI1v1P5u4BdsydWTvJJLqfGsv6IaWbuAvzQjgNXBCSX1kSzL0D0ccwa Dlb3ZWVO/zN4EnNJ0HWofxGGb6EvbKfIgZsn/evbGWK2XCZOskBE1w/YFbgGtKc8ZHAu ulYQFQhtfXyIzPiqimKA03m6pc0sLXYaMa3cc2WQ1IZe24gV27WO3z4HDFuXWPvw8Dpm 3/SN6mGIhHdR0AgqNSh3Cnoc9+Q27PgD76r/2k5ABu2lJsi+wAj9mKlEJ7fJzVzaatuo kcsw== X-Gm-Message-State: APt69E0muu2/jzX9cokrwVZS3oYW5/z861hexcbAPSeLtwe/nntXKPbU 5a07UI1OjAZ05x6Phmoc++PGjC5AbZaKai/2d48= X-Received: by 2002:a19:9358:: with SMTP id v85-v6mr5538246lfd.83.1528972558747; Thu, 14 Jun 2018 03:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:56c8:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 03:35:58 -0700 (PDT) In-Reply-To: References: <20180608144834.3003465-1-arnd@arndb.de> <20180608181956.GA110395@decatoncale.mtv.corp.google.com> <20180611060819.GD5278@dell> From: Arnd Bergmann Date: Thu, 14 Jun 2018 12:35:58 +0200 X-Google-Sender-Auth: g393Q8QHW8FmElfsnmZqhs7RieI Message-ID: Subject: Re: [PATCH] mfd: cros_ec: remove unused __remove function To: Gwendal Grignou Cc: Lee Jones , Benson Leung , Enric Balletbo i Serra , Benson Leung , Andy Shevchenko , Linux Kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 12, 2018 at 9:53 PM, Gwendal Grignou wrote: > On Sun, Jun 10, 2018 at 11:08 PM Lee Jones wrote: >> >> On Fri, 08 Jun 2018, Benson Leung wrote: >> >> > >> > On Fri, Jun 08, 2018 at 04:48:06PM +0200, Arnd Bergmann wrote: >> > > This function is no longer called, so we get a harmless >> > > warning until it is removed as well: >> > > >> > > drivers/mfd/cros_ec_dev.c:265:13: error: '__remove' defined but not used [-Werror=unused-function] >> > > >> > > Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data") >> > >> > Gwendal, in PATCH v2 of https://patchwork.kernel.org/patch/10439449/ >> > you mentioned that you readded the __remove to avoid a warning when built >> > as a module. Can you explain what's going on? >> >> Yes please, and quickly. I'm going to sent the patch-set today. If I >> don't hear from you promptly, I'll probably pull the patch! > I readded it because when cros_ec_dev is loaded as module, I get a > warning on dmesg when unloading: > > """Device 'cros_pd' [or 'cros_ec'] does not have a release() function, > it is broken and must be fixed.""" > > The warning comes from device_release(). Given I get a warning when I > remove the release function or when I leave it empty. Let's pull the > patch. I had not realized that this function was supposed to be the .release callback for a device, only that it was not being called at all. The runtime warning you get is obviously correct and you do need a .release function in the device that will free the memory for the cros_ec_dev structure when the last reference to the device goes away. Please send a fix for this, replacing the incorrect devm_kzalloc with a working allocation/deallocation. Arnd