Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2940787pxk; Tue, 15 Sep 2020 06:25:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzo0EaIjBa3awIqmjMdiHBYflFe1qwUafoRyyXVYA8YMREPapFPMk1FG5FHxnsJhzVdUoX X-Received: by 2002:aa7:d68c:: with SMTP id d12mr22807473edr.274.1600176332818; Tue, 15 Sep 2020 06:25:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600176332; cv=none; d=google.com; s=arc-20160816; b=NsArXZntaoLxNA4iX2Ov0vZBbotpPVw31WEx2FN3wjRE/pMH/IQ0nyNIWapmW+kiYa Q5WZzUWII2G8OV3m3bj1uJHo1w+zj4gPgdRxvIMwssJCn3knwxbnAseb38ELW9ZBvyI6 WB9/N3YBUOIsfTHUwkSfjFHonXPGFnbvYCzAQcne+QaiywDt3Xcha4hNQFkE+yxUsYbp DcCCQZ9lLeXCUKOT+dSf/35mVre3ehaFeCK0wlzSV4vCv+4G3OhF1lP7DkV4ePbs00vz 3eEW4JubK2Gk3+aAa5Jogiz+p+yI08womoUpuCrP8V20njB0M+uskm0ZQRsC3amy3fgo Tr7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=v/HlO2pz67e4hxYirmZqk4ySGJecTpWx3uH4onJVbvU=; b=ukkFqiievEtSs4rupMzC1pc6QX4nT9Ll3UuLgK6fA3UuJU4y3AcYGJDMt5lGJ/o9YX AdrPxlkc3+oz+t5MXoYke4B+XJKC1mETusBFcLqIwmlEBFQTU31/Bakh0HIJOFbOuAq2 JnqCrwm6kNrToRGapU+V97+VkAAaTjZH0YfD6yltgVv9Io2bCgxyDuYYXUVIQvmJevVV 5g2qePBTtgsiArUTQpPsaRg0xQzsSvVsF8ka8JNrUOLHBoXL6kBEvh1xN+8zDrD9FBnB kXnLjofS+FPRIxu8bk4OGBV1BWA1YHI3HnrjkPx0qnz1IRIxeThosRZ6RS9xtEcYzjnh fudg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=Ao6JMC6M; 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 j12si9012502ejy.198.2020.09.15.06.25.08; Tue, 15 Sep 2020 06:25:32 -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; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=Ao6JMC6M; 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 S1726333AbgIONUi (ORCPT + 99 others); Tue, 15 Sep 2020 09:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgIONRd (ORCPT ); Tue, 15 Sep 2020 09:17:33 -0400 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00590C06178C for ; Tue, 15 Sep 2020 06:16:55 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id t18so2942355ilp.5 for ; Tue, 15 Sep 2020 06:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/HlO2pz67e4hxYirmZqk4ySGJecTpWx3uH4onJVbvU=; b=Ao6JMC6MHz4vIH5oPcx8XvXMXNBpuT6aZgdgvKvyHV/hNMlBoELCsvdTJFmmq14gbE wpEde/KfyVyFa+9WwWJkJYfVu6a0Q3aJcrFAORKIbcdpmNJ2v9vG5QLHqNVDqT2mL71e 0YXAHgkC4RSoeJ2fQ0H4LNQ5DhFhFDiAX6dY7pFYVOS7ENh31SSkeYZhK+Y+PZ8GXtni it5g8WftJxlJ6qHd3exqCyuQIyIaqVW0k8SqqAOp7WiqgFAbXPp2vkFA7GJeDXi7QWuN 4Y0cLMfUJtcUKC9g6CzlkkBxSrMKYD2mmLINKs5X/rS/b0CeqJhOTjO/+4aMQTc3iy6N nSow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v/HlO2pz67e4hxYirmZqk4ySGJecTpWx3uH4onJVbvU=; b=E4zOgXuAjf2I809r/3UZ99lGLvNX5xN9q99tGhgui61wrdn0Z9b97ZRFMAaNtCrdTT dAsqLZMQiBGSIBqJLeNoLlC6gUUrm2a1pHQEE5GhS6OBsp4l5srVbDrj4KMPwVIzVGk1 2N+SZYdPBCa8iV7fR67NPZH1H1XzeVhMPyhhNIM/F1gZGAQGLA+vnMBqtsJ2MuKhxgcg kK16aeadKYKjLg4RZjqgFzgnxqqSzUbEjiekzzKAFT9T3q0o92O4bbjuI/W9M/Rp4sAJ t6LA+c3QUf2L1Jrmx0h2DIkxPcBQCBmqllxwb13dTxnhd082+nkYIR0bBIiYglTOePJ5 ToIA== X-Gm-Message-State: AOAM532nuDGWZyCQYVaNlh9JQi3YicOhl+TwLYhYaieLpFiWpo3HEhr7 M+UMR0gjIazu10nGYHHrYASrcfPEWVSURuX7XG5dqg== X-Received: by 2002:a92:c8c4:: with SMTP id c4mr16457759ilq.287.1600175813496; Tue, 15 Sep 2020 06:16:53 -0700 (PDT) MIME-Version: 1.0 References: <20200908125813.8809-1-brgl@bgdev.pl> <20200915131228.GX3956970@smile.fi.intel.com> In-Reply-To: <20200915131228.GX3956970@smile.fi.intel.com> From: Bartosz Golaszewski Date: Tue, 15 Sep 2020 15:16:42 +0200 Message-ID: Subject: Re: [PATCH 0/3] gpiolib: generalize GPIO line names property To: Andy Shevchenko Cc: Anders Roxell , Linus Walleij , Mika Westerberg , Kent Gibson , Greg Kroah-Hartman , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , ACPI Devel Maling List , Bartosz Golaszewski , lkft-triage@lists.linaro.org, Linux-Next Mailing List , Stephen Rothwell Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 15, 2020 at 3:12 PM Andy Shevchenko wrote: > > On Tue, Sep 15, 2020 at 02:01:56PM +0200, Anders Roxell wrote: > > On Tue, 8 Sep 2020 at 18:40, Bartosz Golaszewski wrote: > > > > > > From: Bartosz Golaszewski > > > > > > I initially sent this as part of the gpio-mockup overhaul but since > > > these patches are indepentent and the work on gpio-mockup may become > > > more complicated - I'm sending these separately. > > > > > > The only change is adding additional property helpers to count strings > > > in array. > > > > > > Bartosz Golaszewski (3): > > > device: property: add helpers to count items in string arrays > > > gpiolib: generalize devprop_gpiochip_set_names() for device properties > > > gpiolib: unexport devprop_gpiochip_set_names() > > Ha-ha, OF unittest is of_node centric. definitely there is no backed device. > > Bart, it seems we are stuck with fwnode interface. > Wait what?! This means the implementation is wrong - the whole concept of device properties is to be generic and to hide the underlying fwnode or OF properties. If anything we should fix device/base/property.c to fall back to OF. What is happening exactly? If all fwnode code compiled out? I'll try to give it a spin and see what can be done but I don't like that device_property_* functions fail if you have OF but not fwnode. Bart