Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp757674pxy; Wed, 5 May 2021 13:09:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiLIOay+Mmd86+m+s+sic8wD5c6CBIH7nHlzDAcAQJw0E9Gowko6JtKogpBN/BLYyJQ84R X-Received: by 2002:a63:7e13:: with SMTP id z19mr636459pgc.184.1620245381257; Wed, 05 May 2021 13:09:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620245381; cv=none; d=google.com; s=arc-20160816; b=puTF/P0FsuRwr6WGiuLWImuLPmFZqrjz8ZnnYNWHmb282m3YjfK75KlBVRRG+Npd2l VZgvZvu64UK7F1Lj828daT0yfPXxfqQZfozjys3AY+INS1gDrfpmcj3ijPeMzlCEhlXA pCKpdheP0nIL+YO/pfOv1o6TFe2dbIuR2zBOlymQXfqSYCmp2e2WvBcmDHEQhHgoqL9o 3P1CC0Nh2erm24H4zmx+GNMAiX3e4oiRCaFsIgmC8pkR0rumLy+d2ClpwRpvI4goAX8V ghhCe3eWscTRcmElr9IUHxQ4JHKskGoPHkJJwqwfUCTsZFDrCt9xqIseaI0wiZCrLUZJ 44bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1WhTleXTzGZ2qxxjxvZM/6UkNyKW1KxtSAP1yiHUcmc=; b=jnR2rVLBG7dZ/zkawyWPic1I8V+f7TDLM235N58NkqVLv7Pr3s5OJih4WAGwxglY9l ES+RTgr5ICkFU/HLGJ6BncM5qpMbHUgd97VJ0k4AfIuB2ayy1JG9HQBv1dssiLlUtA3g hfCEPRcr6c8RB7CgXiuxO+z89/ybGRau5xLYxuZO+Ea5qGggYSv//M2P/TATQiZNZpcX ziHgYfLWQp4DZ39Nti73ovJzrb7rNI7SOhs241CL7lMY1AHh7fiSDMXR+TDiEhIUc0NW Oo4VS5rhvdvHIUbCvgFkGMuG9p33G9jLWDJxiMzAnPS5WVAwOFfI/Szh/BK9/6QE3C9k OmVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l5si251570pff.131.2021.05.05.13.09.28; Wed, 05 May 2021 13:09:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233981AbhEEQ0a (ORCPT + 99 others); Wed, 5 May 2021 12:26:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233882AbhEEQ03 (ORCPT ); Wed, 5 May 2021 12:26:29 -0400 Received: from viti.kaiser.cx (viti.kaiser.cx [IPv6:2a01:238:43fe:e600:cd0c:bd4a:7a3:8e9f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23637C061574; Wed, 5 May 2021 09:25:33 -0700 (PDT) Received: from martin by viti.kaiser.cx with local (Exim 4.89) (envelope-from ) id 1leKKw-0001MT-J6; Wed, 05 May 2021 18:25:22 +0200 Date: Wed, 5 May 2021 18:25:22 +0200 From: Martin Kaiser To: Alexandre Belloni Cc: Alessandro Zummo , Shawn Guo , Pengutronix Kernel Team , Fabio Estevam , linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd Subject: Re: [PATCH] rtc: imxdi: add wakeup support Message-ID: <20210505162522.whho2nbqtxof62zk@viti.kaiser.cx> References: <20210430093210.7034-1-martin@kaiser.cx> <20210504100858.4i2crnfwchlcopr7@viti.kaiser.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: Martin Kaiser Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexandre, thanks for the quick reply. Thus wrote Alexandre Belloni (alexandre.belloni@bootlin.com): > Doesn't everyone expect the RTC to be a wakeup source? :) Ok, I'll change this. > > What is the right approach here? Are there any rtc drivers that act as a > > wakeup source and can still be unloaded if compiled as a module? > Yes, when you don't have alarmtimer ;) > I honestly think the RTC selection needs to be a bit more dynamic but at > the same time, it would not be great to change it at suspend time. I > guess the best way would be to allow module unloading and tracking when > the RTC disappears. Ok, understood. There's no chance to address this in an rtc driver. Out of curiousity, I tried adding a .remove_dev function in alarmtimer. It isn't called when the I try to unload the rtc-imxdi module. It seems that the module layer checks the refcount and returns an error before we even attempt to remove the rtc device... Best regards, Martin