Received: by 10.192.165.148 with SMTP id m20csp1459814imm; Wed, 25 Apr 2018 19:37:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpB7SycUAqK9mtmCc/l69v1ZfJCmOHPSAncvTZGHd7ywEhBZhYMdZ9n8W782XqZIrpKycds X-Received: by 10.99.66.133 with SMTP id p127mr5124298pga.421.1524710238450; Wed, 25 Apr 2018 19:37:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524710238; cv=none; d=google.com; s=arc-20160816; b=Thb9/p9BuAJTLtcf95Ea4zqbocTqiGYrlt4nsSD6IWJQTX+0ftUMK6ElI0v4OQlVhr b3e94KS0yCt+jil/lvZc5OUaqZ7SsNI8AAsQBhMo+vxhnulWNUMIpzwWaHxWtjRCQz+O WR4XQ0rf7YuXc7ZIW7gWzaywJ3N40LrDtNIkRArIaRxE3WCB/CoiA+jZXvVPmkjbTaJT I3Sp5iF1lGRcFTQbAuuLmlFjSDoW98d6enqXGd65M2Vl8ac2Zo3Iumj9h9PVJ3ge40uw D2ZJgtVoNMkBj6geoFwLrQPDB5/MJs609xbKV3c55yZRuvpzkqzM7gX9IBPrS/vpRqce N7Ug== 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=54vTa6lOpPTLNs76zs5g9N4Te8iEPUvBSfLw5AmdGf4=; b=1JoKGigUZpYDE54UJSz7ku3Yvfi8KPJGeUrTHt7X97ap6YSg9xR6rLMHpHPNNdEDjx LKHcM05YeBai5qxy3FXQOMxKobODtObNfkLY+n6sGese48/0jskfvVjyfPHR6Xc86vtY yDTiG0Eme1ANxmoasOtzuFTUXPy+KJV8tLBwZ0lOdSCEwPy2bLSnHUTw774wCqR28KrC B+JwbU8u0Gk5RSSkmUd7ahL4//7kKzWrYxNenjYxlm4WslFmFB+WXhGM22VEG2G7t1XJ kCLa4kzIupHgTxIr6/mm83xImzX6BIqWq3e0/GY46Qg63wU/fm6AvzoLswrCvxiP6+b3 MvJA== 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 s1si14609580pgb.281.2018.04.25.19.37.04; Wed, 25 Apr 2018 19:37:18 -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 S1752419AbeDZCeq (ORCPT + 99 others); Wed, 25 Apr 2018 22:34:46 -0400 Received: from bert.emutex.com ([91.103.1.109]:54914 "EHLO bert.emutex.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751528AbeDZCeo (ORCPT ); Wed, 25 Apr 2018 22:34:44 -0400 Received: from [92.51.199.138] (helo=statler.emutex.com) by bert.emutex.com with esmtp (Exim 4.84) (envelope-from ) id 1fBWkk-0001w8-Gc; Thu, 26 Apr 2018 03:35:22 +0100 Received: from [82.141.251.25] (helo=localhost) by statler.emutex.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84) (envelope-from ) id 1fBWk6-0001cx-47; Thu, 26 Apr 2018 03:34:42 +0100 Date: Thu, 26 Apr 2018 03:34:41 +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: <20180426023441.f2a7337sjlyd6xhf@localhost> References: <20180421085009.28773-1-javier@emutex.com> <20180421085009.28773-3-javier@emutex.com> <1524672945.21176.594.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1524672945.21176.594.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: On Wed, Apr 25, 2018 at 07:15:45PM +0300, Andy Shevchenko wrote: > On Sat, 2018-04-21 at 09:50 +0100, Javier Arteaga wrote: > > Allow userspace to use the on-board LEDs as "upboard::". > > > + struct upboard_led *led = container_of(cdev, struct > > upboard_led, cdev); > > #define to_upboard_led(cdev) container_of(cdev, struct upboard_led, > cdev) > > ... led = to_upboard_led(cdev); > > > + struct upboard_led *led = container_of(cdev, struct > > upboard_led, cdev); > > Ditto. [...] 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 On Wed, Apr 25, 2018 at 07:15:45PM +0300, Andy Shevchenko wrote: > On Sat, 2018-04-21 at 09:50 +0100, Javier Arteaga wrote: > > Allow userspace to use the on-board LEDs as "upboard::". > > > + struct upboard_led *led = container_of(cdev, struct > > upboard_led, cdev); > > #define to_upboard_led(cdev) container_of(cdev, struct upboard_led, > cdev) > > ... led = to_upboard_led(cdev); > > > + struct upboard_led *led = container_of(cdev, struct > > upboard_led, cdev); > > Ditto. Will do - thanks! > > +static int __init upboard_led_probe(struct platform_device *pdev) > > Are you sure about __init here? Not 100% now :) 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? > > + struct upboard_led_data * const pdata = pdev- > > >dev.platform_data; > > Don't use direct dereference to platform_data. Sorry, I don't understand this one. What's the alternative? > > + if (!pdev->dev.parent) > > + return -EINVAL; > > + > > + upboard = dev_get_drvdata(pdev->dev.parent); > > + if (!upboard || !pdata) > > + return -EINVAL; > > Wouldn't be better to supply regmap as part of platform data? > It will allow be flexible of parent device. I'll play around with that. > > +MODULE_LICENSE("GPL"); > > License mismatch. Will fix.