Received: by 10.192.165.148 with SMTP id m20csp665933imm; Wed, 2 May 2018 06:57:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqPLxzgFfjno0gE9jkmbEGuDh5LN6EYLGawJ4vxfGRw5zjD6wrirsBdDZTtv7O+YPtO8bI7 X-Received: by 2002:a17:902:b10f:: with SMTP id q15-v6mr11777184plr.142.1525269424005; Wed, 02 May 2018 06:57:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525269423; cv=none; d=google.com; s=arc-20160816; b=tS4IE/AacUtu2wdVAfAF/AE6h5puV3LaXjHSZuelZZmJLakRALx0XYO80y7r4xkCvP VJKHO5yHLcpA4Af4DLF2w7GzTbD3/ky1DUAAvqnT762LVo2BKr9sE1xo7E9iq7P1vnim Ijk8LK/i3LmJk+RUHJLX4XYnmKThV7yy4rUTUDlupEYLEigPhuLTg8yKSqvqqVI4r5C9 welAUwqDKtDB4lX2sbwMQKCkbyMCc+/4WO25cFIZ+VPfpyiQZKbij9MCtMzrtsJbaEgG 6n0VJQaETjyG24L1oh3W9UddAQpx6wEuSAb5MuEzloPMuoF9YgdTPUEFXT/hMQ/nAWcn igTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=nlE33VKzjiUw2+t4A8tt5Q1ctT+uP7nbucMXrHcuIW8=; b=H4/Gxu5BGx3MD6t+jh5/qYflzz8TURIz+nxOrfwmIOKbITul+xkLluMED3vOAtHqaI J9Meajvf/e8L29RnYwaJy3NsNoYy1rRw4SeUhFPq5lyulu89nLg+w/fwOW3YdaRQZsQ/ 9D7sePB9vGxufU98pj1TmJkf+W++uWhrJVpLiRMB529FqRLN+amKNapW67DpJVfNZln6 nDdBVoBpnbDV3y+0tgSzdUJKxDe9c0uwP18Vf0Z9kZ7dONlLG5qqti95Ux+F/VlJciUR sggQZ6dnr2nfuDT472JE8y/9kqet9VnhbwrmGBfA03VXZDnC+tER131a/rhr/MQGQxCB Dcuw== 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 t23-v6si8815866plo.508.2018.05.02.06.56.50; Wed, 02 May 2018 06:57: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 S1751196AbeEBNzX (ORCPT + 99 others); Wed, 2 May 2018 09:55:23 -0400 Received: from mga04.intel.com ([192.55.52.120]:52669 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbeEBNzV (ORCPT ); Wed, 2 May 2018 09:55:21 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 06:55:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,354,1520924400"; d="scan'208";a="225150666" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga005.fm.intel.com with ESMTP; 02 May 2018 06:55:18 -0700 Message-ID: <1525269317.21176.625.camel@linux.intel.com> Subject: Re: [RFC PATCH RESEND 2/3] leds: upboard: Add LED support From: Andy Shevchenko To: Javier Arteaga 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 Date: Wed, 02 May 2018 16:55:17 +0300 In-Reply-To: <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> <20180426124922.haddppocljgnj2ei@localhost> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-04-26 at 13:49 +0100, Javier Arteaga wrote: > 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. Just do one small test. Try to unbind the (built-in) driver and bind it back. Would it work? Would kernel survive this? -- Andy Shevchenko Intel Finland Oy