Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Lukasz Stelmach <l.stelmach@samsung.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v8 3/6] software node: implement reference properties
Date: Mon, 09 Nov 2020 20:47:14 +0100
Message-ID: <dleftjv9eenwhp.fsf%l.stelmach@samsung.com> (raw)
In-Reply-To: <20201109190245.GL4077@smile.fi.intel.com> (Andy Shevchenko's message of "Mon, 9 Nov 2020 21:02:45 +0200")


[-- Attachment #1: Type: text/plain, Size: 4221 bytes --]

It was <2020-11-09 pon 21:02>, when Andy Shevchenko wrote:
> On Mon, Nov 09, 2020 at 07:18:37PM +0100, Lukasz Stelmach wrote:
>> It was <2020-11-09 pon 19:24>, when Andy Shevchenko wrote:
>> > On Mon, Nov 09, 2020 at 06:02:29PM +0100, Lukasz Stelmach wrote:
>> >> It was <2019-11-07 czw 20:22>, when Dmitry Torokhov wrote:
>
> ...
>
>> >> I am writing a piece that needs to provide a list of gpios to a
>> >> diriver. The above example looks like what I need.
>> >
>> > Nope.
>> >
>> > It mustn't be used for GPIOs or PWMs or whatever that either should come via
>> > lookup tables or corresponding firmware interface.
>> 
>> May I ask why? I've read commit descriptions for drivers/base/swnode.c
>> and the discussion on lkml and I understand software nodes as a way to
>> provide (synthesize) a description for a device that is missing a
>> description in the firmware. Another use case seems to be to replace (in
>> the long run) platform data. That is what I am trying to use it for.
>
> Yes. Both are correct. They are simply not applicable for everything
> (it's not a silver bullet).
>
>> I want my device to be configured with either DT or software_nodes
>> created at run time with configfs.
>
> Okay.
>
>> My device is going to use GPIOs
>> described in the DT and it is going to be configured via configfs at run
>> time.
>
> How is this related to swnodes?

I thought I should mention it, because as far as I can tel mixing and
merging information from different fwnode backends seems to be tricky if
supported at all.

> Create GPIO lookup table.
>
>> I could use platform_data to pass structures from configfs but
>> software nodes would let me save some code in the device driver and use
>> the same paths for both static (DT) and dynamic (configfs)
>> configuration.
>> 
>> Probably I have missed something and I will be greatful, if you tell me
>> where I can find more information about software nodes. There are few
>> users in the kernel and it isn't obvious for me how to use software
>> nodes properly.
>
> gpiod_add_lookup_table().
>

Yes, that is exactly what my POC code does now. But having a lookup
table together with the rest of the device structures has several
advantages.

1) The device may be hotpluggable and there is no
   gpiod_remove_lookup_table().

2) Having the lookup table allocated and managed together with the rest
   of the device seems like a better way to go than on gpio_lookup_list.

3) As of now I've got a minor issue with device naming. I need to set
   dev_id of the table before the device is ready and only after it is
   ready, its name is set (in the hotpluggable use case).

4) Because no other devices would use this lookup table "publishing" it
   rather than keeping together with the device seems at least slightly
   odd.

When the lookup table is attached to the devices and can be passed
around  the final lookup can be done with a function like

static struct gpio_desc *gpiod_find_from_table(struct device *dev,
                             const char *con_id, unsigned int idx,
                 unsigned long *flags, struct gpiod_lookup *table)

>>>> At the moment the driver gets the list from fwnode/of_node. The list
>>>> contain references to phandles which get resolved and and the driver
>>>> ends up with a bunch of gpio descriptors. Great.
>>>> 
>>>> This example looks nice but does the code that reads the reference from
>>>> the gpios property and returns a gpiod actually exist? If it doesn't, I
>>>> am willing to write it.
>>>> 
>>>> At first glance it makes more sense to me to pass (struct gpiod_lookup
>>>> *) instead of (struct software_node *) and make gpiolib's gpiod_find()
>>>> accept lookup tables as parameter instead of searching the
>>>> gpio_lookup_list? Or do you think such temporary table should be
>>>> assembled from the above structure and then used in gpiod_find()?
>>>> 
>>>> Any other suggestions on how to get a bunch of gpios (the description
>>>> for gpios is available in the devicetree) for a device described with a
>>>> software nodes?

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  parent reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  4:22 [PATCH v8 0/6] software node: add support for " Dmitry Torokhov
2019-11-08  4:22 ` [PATCH v8 1/6] software node: rename is_array to is_inline Dmitry Torokhov
2019-11-08  9:49   ` Rafael J. Wysocki
2019-11-13  6:52   ` Bjørn Mork
2019-11-13  8:08     ` Dmitry Torokhov
     [not found]   ` <CGME20191212111237eucas1p1a278d2d5d2437e3219896367e82604cc@eucas1p1.samsung.com>
2019-12-12 11:12     ` Marek Szyprowski
2019-12-12 11:28       ` Andy Shevchenko
2019-12-12 16:41         ` Rafael J. Wysocki
2019-12-13  6:47           ` Marek Szyprowski
2019-12-13  8:37             ` Rafael J. Wysocki
2019-12-13  1:24       ` Dmitry Torokhov
2019-12-13  6:44         ` Marek Szyprowski
2019-11-08  4:22 ` [PATCH v8 2/6] software node: allow embedding of small arrays into property_entry Dmitry Torokhov
2019-11-08  4:22 ` [PATCH v8 3/6] software node: implement reference properties Dmitry Torokhov
     [not found]   ` <CGME20201109170241eucas1p14c2156334d8c6ef15d52664fa4776f41@eucas1p1.samsung.com>
2020-11-09 17:02     ` Lukasz Stelmach
2020-11-09 17:24       ` Andy Shevchenko
     [not found]         ` <CGME20201109181851eucas1p241de8938e399c0b603c764593b057c41@eucas1p2.samsung.com>
2020-11-09 18:18           ` Lukasz Stelmach
2020-11-09 18:53             ` Dmitry Torokhov
2020-11-09 19:05               ` Andy Shevchenko
2020-11-10 12:39                 ` Heikki Krogerus
2020-11-10 12:46                   ` Rafael J. Wysocki
     [not found]               ` <CGME20201109195504eucas1p19d493c947d8752e39c26202cf0978fc0@eucas1p1.samsung.com>
2020-11-09 19:54                 ` Lukasz Stelmach
2020-11-09 19:02             ` Andy Shevchenko
     [not found]               ` <CGME20201109194725eucas1p2cc9357486879a14b2ad2f6ef968ff4b2@eucas1p2.samsung.com>
2020-11-09 19:47                 ` Lukasz Stelmach [this message]
2020-11-09 21:20                   ` Andy Shevchenko
2019-11-08  4:22 ` [PATCH v8 4/6] platform/x86: intel_cht_int33fe: use inline " Dmitry Torokhov
2019-11-08  4:22 ` [PATCH v8 5/6] software node: remove separate handling of references Dmitry Torokhov
2019-11-08  4:22 ` [PATCH v8 6/6] software node: add basic tests for property entries Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dleftjv9eenwhp.fsf%l.stelmach@samsung.com \
    --to=l.stelmach@samsung.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git