Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1358252pxk; Fri, 18 Sep 2020 10:16:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPVz15gCoEKBHVXS8Ljk4d7PCtg3Zhz/QVKGsAYcuNbawM2jh6D5flhwqayOL5msN8prXY X-Received: by 2002:a05:6402:1558:: with SMTP id p24mr38652920edx.194.1600449390611; Fri, 18 Sep 2020 10:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600449390; cv=none; d=google.com; s=arc-20160816; b=VWE3MGxRJyKgu0dWN74YEQfsStrTnsgImA8twmGMuMGV4by9FzvRT5HXg9ZD74R/mw TLXBA1ZDbajsy+KLFJRKW8OrrPFsKPc3wcTgwpSaMC/1NerW9sUD1KIa6cDsxcnhVI+a 29CpcwEkRnZ8nlmMTDKPrkKlv4rUtFvdDgFU0jjVxqYtK0LXFPxY8kHOhtj3ouqV6DD3 V8WiCzPPiMtoIZT/lFaVkF3NvdlAO1hVVOAFm9EoDerPurA+t1kaUfvACVPtPUZ7uaJt pzGVtWDv86uwdu4OBzVucMI3851CqruapsnFYppPZmjvQWasFu/ODROoKLa9IjgrtArq N8VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=ZBdgWI+kielxj8xZOdz/x0RkCcC2eBIjp+W3SSq+L+A=; b=Jc4QuWAELmBq2UAY9jVd4kU2p/vtSCIGB+/eoOsrxCD6cw70HXuWloCLOgZqyyYwaf 8H1Ryo+fuHMO/23rcuiOxDuL91Ysymo4HrPoO46KMxKO7/yx+kPI0GzT2NrGF4oRa2+O /jcGRhqQ/dzylbKJA/s/ep/OTQGffNh70tUnY01HpPeXx9nD8y3dwyDAPmqDddVZxcQp rSaZ63TW4Fp4IXL95bT0yeLtQBXWywvaeIZldqr8+lV6DCV8P5KbBycmnse31BT9zYW1 qvOF2h3dyTm8AIZ8RsNDK/YhCsNMnjkA+A70Gf2xIxYPmIDxi1CZx2+P7vPTA8D7NGzy beEQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nic.cz Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v21si2647671edl.133.2020.09.18.10.16.06; Fri, 18 Sep 2020 10:16:30 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nic.cz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726376AbgIRROJ convert rfc822-to-8bit (ORCPT + 99 others); Fri, 18 Sep 2020 13:14:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbgIRROJ (ORCPT ); Fri, 18 Sep 2020 13:14:09 -0400 Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A361C0613CE; Fri, 18 Sep 2020 10:14:09 -0700 (PDT) Received: from localhost (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id 394E514093B; Fri, 18 Sep 2020 19:14:06 +0200 (CEST) Date: Fri, 18 Sep 2020 19:14:05 +0200 From: Marek Behun To: Simon Guinot Cc: linux-leds@vger.kernel.org, Pavel Machek , Dan Murphy , =?UTF-8?B?T25kxZllag==?= Jirman , linux-kernel@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org, Simon Guinot , Vincent Donnefort , Thomas Petazzoni , Linus Walleij Subject: Re: [PATCH leds v1 10/10] leds: ns2: refactor and use struct led_init_data Message-ID: <20200918191405.516b51ff@nic.cz> In-Reply-To: <20200918130206.GE29951@kw.sim.vm.gnt> References: <20200916231650.11484-1-marek.behun@nic.cz> <20200916231650.11484-11-marek.behun@nic.cz> <20200918130206.GE29951@kw.sim.vm.gnt> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-100.0 required=5.9 tests=SHORTCIRCUIT, USER_IN_WELCOMELIST,USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.nic.cz X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Sep 2020 15:02:06 +0200 Simon Guinot wrote: > On Thu, Sep 17, 2020 at 01:16:50AM +0200, Marek BehĂșn wrote: > > Hi Marek, > > > By using struct led_init_data when registering we do not need to parse > > `label` DT property nor `linux,default-trigger` property. > > > > Also, move forward from platform data to device tree only: > > since commit c7896490dd1a ("leds: ns2: Absorb platform data") the > > platform data structure is absorbed into the driver, because nothing > > else in the source tree used it. Since nobody complained and all usage > > Well, I probably should have... > > I am using this driver on the Seagate Superbee NAS devices. This devices > are based on a x86 SoC. Since I have been unable to get from the ODM the > LED information written in the ACPI tables, then platform data are used > to pass the LED description to the driver. > > The support of this boards is not available mainline yet but it is still > on my todo list. So that's why I am complaining right now :) If it is > not too much trouble I'd like to keep platform data support in this > driver. > > Thanks in advance. > > Simon > Simon, what if we refactored the driver to use fwnode API instead of OF API? Then if it is impossible for you to write DTS for that device, instead of platform data you could implement your device via swnode fwnodes. :) static const struct property_entry entries[] = { PROPERTY_ENTRY_STRING("compatible", "lacie,ns2-leds"), ... }; Look at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/chrome/chromeos_laptop.c?h=v5.9-rc5 search for PROPERTY_ENTRY. I am willing to work on this with you, but I would really like to rid the LED drivers of platform data. Marek