Thread (32 messages) 32 messages, 2 authors, 2021-12-02

Re: [PATCH v11 2/6] gpiolib: allow to specify the firmware node in struct gpio_chip

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: 2021-12-01 14:41:27
Also in: linux-kselftest, lkml

On Wed, Dec 01, 2021 at 04:28:19PM +0200, Andy Shevchenko wrote:
On Wed, Dec 01, 2021 at 02:53:42PM +0100, Bartosz Golaszewski wrote:
quoted
On Wed, Dec 1, 2021 at 2:40 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Wed, Dec 01, 2021 at 02:11:28PM +0100, Bartosz Golaszewski wrote:
quoted
On Tue, Nov 30, 2021 at 10:04 PM Bartosz Golaszewski [off-list ref] wrote:
...
quoted
quoted
quoted
Let me maybe rephrase the problem: currently, for GPIO devices
instantiating multiple banks created outside of the OF or ACPI
frameworks (e.g. instantiated manually and configured using a
hierarchy of software nodes with a single parent swnode and a number
of child swnodes representing the children), it is impossible to
assign firmware nodes other than the one representing the top GPIO
device to the gpiochip child devices.

In fact if we want to drop the OF APIs entirely from gpiolib - this
would be the right first step as for gpio-sim it actually replaces the
gc->of_node = some_of_node; assignment that OF-based drivers do for
sub-nodes defining banks and it does work with device-tree (I verified
that too) thanks to the fwnode abstraction layer.
I still don't see how you set up hierarchy of primary/secondary fwnodes.

And I don't like this change. It seems it band-aids some issue with fwnode
usage. What the easiest way to reproduce the issue with your series applied
(without this change)?
Drop this patch and drop the line where the fwnode is assigned in
gpio-sim.c. Then probe the device and print the addresses of the
parent and child swnodes. See how they are the same and don't match
the swnode hierarchy we created. You can then apply this patch and see
how it becomes correct.
Thanks. I will give a spin.

Note, it seems I have to revert your older code first...
Okay, I have to postpone because simple revert doesn't work for me.
Can you clean up the next, please and I can use it starting from tomorrow?


$ git tag --contains 5065e08e4ef3
DONT-USE-next-20211105
next-20211101
next-20211102
next-20211103
next-20211104
next-20211105
next-20211106
next-20211108
next-20211109
next-20211110
next-20211111
next-20211112
next-20211115
next-20211116
next-20211117
next-20211118
next-20211123
next-20211124
next-20211125
next-20211126
next-20211129
next-20211130
next-20211201

-- 
With Best Regards,
Andy Shevchenko

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help