Received: by 10.192.165.148 with SMTP id m20csp2060078imm; Thu, 26 Apr 2018 05:51:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx48bgMkrirCTNndkU7F28ZKHhJgGXwndgmDr5GCq8RJ6jW4k5nZZbQDKE988DgQYhdsdpy+d X-Received: by 10.101.72.140 with SMTP id n12mr27625272pgs.155.1524747063324; Thu, 26 Apr 2018 05:51:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524747063; cv=none; d=google.com; s=arc-20160816; b=mPePFAz/9xo0toc+hvvhu0Ped5E8cr6n1ipoBSX1Boa98z48owaDBK+VOUeNgoYX0I e2tiISeqCg2rkxg6teyYZwZiu5xz8oR/6z0TX+CNth7f78+orCUXsAWtvK1Bt8k/Ysjn VcqH2Y0H3oAA7dlb/g8A2SkA4ZBaUJLe4Nj0okD2ujwN5q/OMnGysfUhXI8q+mR5OI0c GTUF+jcqZUHgBm9/r9E7AGlGsRq1JAV0SMSkxJCvPSy67y4LbKt5LEhIaLpckBHMvsyh Z8ZhJ916gZNx5f3SpIdEnZ2SW24SMb0WfoTWR2Lhs709xjaARI9tzl1IYHOTahT55MrG xCZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Jxh0y+qq2M0/URUyDOELZBw4JgVjaxkZj5CIXlWOH9A=; b=LEhzV0TNBgEq9hJhOmBq2G4typA2lEBtREWYjuH9HQB1IjQ6D/Q8qPMTaz7+/62ixM V8tKEyuzmZLRYpwxtVCJyFNSrTbhUfZ62RUXiNsWTFCDBPsZPyf0E2ZGPd3yJGGNjcA2 uIcAc6MgUJMqOWs8eXRXlO1c6TyyOm9re6LFs2IbVsuQ4SamFzPcgm9tqvVg6SXnFf2S fKn95ROlCYH5ZLaEQIGKyOzTrYIQNplUoX7ZqMc3P/iLkJ+umTt9DxDf9foAkpSf3b9Y Bi59umXOs9rBFCcnqlD9Q7niMwiVIoi7zUgeiM+tsJoSN+tQCMrwm1zTtzX3aknMRRlh PRnQ== ARC-Authentication-Results: i=1; mx.google.com; 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 g7-v6si19531074plk.388.2018.04.26.05.50.48; Thu, 26 Apr 2018 05:51:03 -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; 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 S1755998AbeDZMtc (ORCPT + 99 others); Thu, 26 Apr 2018 08:49:32 -0400 Received: from bert.emutex.com ([91.103.1.109]:55032 "EHLO bert.emutex.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755384AbeDZMt1 (ORCPT ); Thu, 26 Apr 2018 08:49:27 -0400 Received: from [92.51.199.138] (helo=statler.emutex.com) by bert.emutex.com with esmtp (Exim 4.84) (envelope-from ) id 1fBgLb-0002XD-IJ; Thu, 26 Apr 2018 13:50:03 +0100 Received: from [79.140.212.107] (helo=localhost) by statler.emutex.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84) (envelope-from ) id 1fBgKx-000387-2z; Thu, 26 Apr 2018 13:49:23 +0100 Date: Thu, 26 Apr 2018 13:49:22 +0100 From: Javier Arteaga To: Andy Shevchenko Cc: Jacek Anaszewski , Pavel Machek , Dan O'Donovan , Mika Westerberg , Heikki Krogerus , Lee Jones , Linus Walleij , linux-gpio@vger.kernel.org, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH RESEND 2/3] leds: upboard: Add LED support Message-ID: <20180426124922.haddppocljgnj2ei@localhost> References: <20180421085009.28773-1-javier@emutex.com> <20180421085009.28773-3-javier@emutex.com> <1524672945.21176.594.camel@linux.intel.com> <20180426023441.f2a7337sjlyd6xhf@localhost> <1524729349.21176.614.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1524729349.21176.614.camel@linux.intel.com> X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "statler.emutex.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Thanks Andy for these pointers :) On Thu, Apr 26, 2018 at 10:55:49AM +0300, Andy Shevchenko wrote: > On Thu, 2018-04-26 at 03:34 +0100, Javier Arteaga wrote: > > My understanding was that in this context, __init allows this probe() > > to > > be dropped from memory after module load. > > > > What am I doing wrong there? > > Just give another thought about it. The keyword(s) here is(are): time to > live of the objects in question. It's good to get knowing what unbind- > bind means (for built-in drivers). [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks Andy for these pointers :) On Thu, Apr 26, 2018 at 10:55:49AM +0300, Andy Shevchenko wrote: > On Thu, 2018-04-26 at 03:34 +0100, Javier Arteaga wrote: > > My understanding was that in this context, __init allows this probe() > > to > > be dropped from memory after module load. > > > > What am I doing wrong there? > > Just give another thought about it. The keyword(s) here is(are): time to > live of the objects in question. It's good to get knowing what unbind- > bind means (for built-in drivers). So this is the bit that I _believed_ applied to the platform drivers for these MFD-registered devices (from driver-model/platform.txt): Or, in common situations where the device is known not to be hot-pluggable, the probe() routine can live in an init section to reduce the driver's runtime memory footprint: int platform_driver_probe(struct platform_driver *drv, int (*probe)(struct platform_device *)) I'm thinking my misunderstanding probably stems from assuming that these leds/pinctrl drivers will always find all devices registered at init time. Can't say I've validated that assumption - I just didn't see anything obviously blowing up in my tests so far :) I'll keep reading and test out a few more things so I fully understand. Until then, I've taken out __init annotations from next version. > > > Don't use direct dereference to platform_data. > > > > Sorry, I don't understand this one. What's the alternative? > > See other drivers how they do that stuff. Hint: check inline functions > in include/linux/device.h. I wasn't looking at the right other drivers :) I'll use the dev_get_platdata() wrapper going forwards.