This is needed for properly registering gpio regmap as a child of a regmap
pin controller.
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Reviewed-by: Michael Walle <[email protected]>
---
v4: fix documentation
v3: introduce patch needed for properly parsing gpio-ranges
drivers/gpio/gpio-regmap.c | 1 +
include/linux/gpio/regmap.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index 5412cb3b0b2a..1a43a90024bb 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -249,6 +249,7 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config
chip = &gpio->gpio_chip;
chip->parent = config->parent;
+ chip->of_node = config->of_node ?: dev_of_node(config->parent);
chip->base = -1;
chip->ngpio = config->ngpio;
chip->names = config->names;
diff --git a/include/linux/gpio/regmap.h b/include/linux/gpio/regmap.h
index ad76f3d0a6ba..73105ff830fb 100644
--- a/include/linux/gpio/regmap.h
+++ b/include/linux/gpio/regmap.h
@@ -4,6 +4,7 @@
#define _LINUX_GPIO_REGMAP_H
struct device;
+struct device_node;
struct gpio_regmap;
struct irq_domain;
struct regmap;
@@ -16,6 +17,7 @@ struct regmap;
* @parent: The parent device
* @regmap: The regmap used to access the registers
* given, the name of the device is used
+ * @of_node: (Optional) The device node
* @label: (Optional) Descriptive name for GPIO controller.
* If not given, the name of the device is used.
* @ngpio: Number of GPIOs
@@ -57,6 +59,7 @@ struct regmap;
struct gpio_regmap_config {
struct device *parent;
struct regmap *regmap;
+ struct device_node *of_node;
const char *label;
int ngpio;
--
2.20.1
On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
<[email protected]> wrote:
>
> This is needed for properly registering gpio regmap as a child of a regmap
gpio -> GPIO
> pin controller.
...
> + * @of_node: (Optional) The device node
> + struct device_node *of_node;
Can we use fwnode from day 1, please?
--
With Best Regards,
Andy Shevchenko
Hi Andy,
> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
>
> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
> <[email protected]> wrote:
>>
>> This is needed for properly registering gpio regmap as a child of a regmap
>
> gpio -> GPIO
>
>> pin controller.
>
> ...
>
>> + * @of_node: (Optional) The device node
>
>> + struct device_node *of_node;
>
> Can we use fwnode from day 1, please?
Could you explain this? I haven’t dealt with fwnode never :$
BTW, this is done to fix this check when parsing gpio ranges:
https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Álvaro.
On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
> > El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
> > On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
> > <[email protected]> wrote:
> >> + * @of_node: (Optional) The device node
> >
> >> + struct device_node *of_node;
> >
> > Can we use fwnode from day 1, please?
>
> Could you explain this? I haven’t dealt with fwnode never :$
> BTW, this is done to fix this check when parsing gpio ranges:
> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
Use struct fwnode_handle pointer instead of OF-specific one.
Also here is the question, why do you need to have that field in the
regmap config structure and can't simply use the parent's fwnode?
Also I'm puzzled why it's not working w/o this patch: GPIO library
effectively assigns parent's fwnode (okay, of_node right now).
--
With Best Regards,
Andy Shevchenko
> El 4 mar 2021, a las 16:28, Andy Shevchenko <[email protected]> escribió:
>
> On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>> El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
>>> On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>>>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
>>>>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
>>>>> <[email protected]> wrote:
>>>
>>>>>> + * @of_node: (Optional) The device node
>>>>>
>>>>>> + struct device_node *of_node;
>>>>>
>>>>> Can we use fwnode from day 1, please?
>>>>
>>>> Could you explain this? I haven’t dealt with fwnode never :$
>>>> BTW, this is done to fix this check when parsing gpio ranges:
>>>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
>>>
>>> Use struct fwnode_handle pointer instead of OF-specific one.
>>
>> But is that compatible with the current gpiolib-of code? :$
>
> Yes (after a bit of amendment I have sent today as v2:
> https://lore.kernel.org/linux-gpio/[email protected]/T/#u).
Well that doesn’t fulfill my definition of “current gpiolib-of code”…
@Linus what should I do about this?
>
>>> Also here is the question, why do you need to have that field in the
>>> regmap config structure and can't simply use the parent's fwnode?
>>> Also I'm puzzled why it's not working w/o this patch: GPIO library
>>> effectively assigns parent's fwnode (okay, of_node right now).
>>
>> Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
>> Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
>
> I see. Can you point me out to the code where we get the node and
> where it's being retrieved / filled?
Sure, this is where the child node is searched: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L100-L109
Then the gpio child node is probed and assigned here: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L51
Basically, I based that part of the code on the ingenic pin controller: https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/pinctrl/pinctrl-ingenic.c#L2485-L2491
https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/Documentation/devicetree/bindings/pinctrl/ingenic%2Cpinctrl.yaml#L155-L176
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Álvaro.
On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas <[email protected]> wrote:
> > El 4 mar 2021, a las 16:28, Andy Shevchenko <[email protected]> escribió:
> > On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>> El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
> >>> On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>>>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
> >>>>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
> >>>>> <[email protected]> wrote:
> >>>
> >>>>>> + * @of_node: (Optional) The device node
> >>>>>
> >>>>>> + struct device_node *of_node;
> >>>>>
> >>>>> Can we use fwnode from day 1, please?
> >>>>
> >>>> Could you explain this? I haven’t dealt with fwnode never :$
> >>>> BTW, this is done to fix this check when parsing gpio ranges:
> >>>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
> >>>
> >>> Use struct fwnode_handle pointer instead of OF-specific one.
> >>
> >> But is that compatible with the current gpiolib-of code? :$
> >
> > Yes (after a bit of amendment I have sent today as v2:
> > https://lore.kernel.org/linux-gpio/[email protected]/T/#u).
>
> Well that doesn’t fulfill my definition of “current gpiolib-of code”…
> @Linus what should I do about this?
Well, fwnode is a generic, and I strongly against spreading
OF-specific code when we have fwnode working. But let's hear Linus
out, of course!
But it seems you are right and the library needs a few more amendments.
> >>> Also here is the question, why do you need to have that field in the
> >>> regmap config structure and can't simply use the parent's fwnode?
> >>> Also I'm puzzled why it's not working w/o this patch: GPIO library
> >>> effectively assigns parent's fwnode (okay, of_node right now).
> >>
> >> Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
> >> Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
> >
> > I see. Can you point me out to the code where we get the node and
> > where it's being retrieved / filled?
>
> Sure, this is where the child node is searched: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L100-L109
> Then the gpio child node is probed and assigned here: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L51
So, this is not (*yet) in upstream, correct?
So, why not to switch to fwnode API in that driver as well?
When you do that and supply fwnode thru the regmap configuration, in
the gpio-regmap we may assign it to of_node (via to_of_node() API).
> Basically, I based that part of the code on the ingenic pin controller: https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/pinctrl/pinctrl-ingenic.c#L2485-L2491
> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/Documentation/devicetree/bindings/pinctrl/ingenic%2Cpinctrl.yaml#L155-L176
This doesn't use remgap GPIO.
--
With Best Regards,
Andy Shevchenko
Am 2021-03-04 17:46, schrieb Andy Shevchenko:
> On Thu, Mar 4, 2021 at 6:33 PM Andy Shevchenko
> <[email protected]> wrote:
>> On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas
>> <[email protected]> wrote:
>
> Let me summarize what we can do this independently on any of my
> patches and be okay with.
>
> In the regmap GPIO configuration you supply struct fwnode_handle
> *fwnode.
> You can you fwnode API in the actual GPIO controller driver.
> Inside gpio-regmap simply do this for now
>
> gc->of_node = to_of_node(config->fwnode);
If doing so, can we please have a comment saying that config->fwnode
might be NULL in which case the fwnode of the parent is used?
> The last part is an amendment I have told about, but it can be done
> later on by switching the entire GPIO chip to use fwnode instead of
> of_node.
--
-michael
Hi Andy,
> El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
>
> On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
>>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
>>> <[email protected]> wrote:
>
>>>> + * @of_node: (Optional) The device node
>>>
>>>> + struct device_node *of_node;
>>>
>>> Can we use fwnode from day 1, please?
>>
>> Could you explain this? I haven’t dealt with fwnode never :$
>> BTW, this is done to fix this check when parsing gpio ranges:
>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
>
> Use struct fwnode_handle pointer instead of OF-specific one.
But is that compatible with the current gpiolib-of code? :$
>
> Also here is the question, why do you need to have that field in the
> regmap config structure and can't simply use the parent's fwnode?
> Also I'm puzzled why it's not working w/o this patch: GPIO library
> effectively assigns parent's fwnode (okay, of_node right now).
Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Álvaro.
On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas <[email protected]> wrote:
> > El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
> > On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
> >>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
> >>> <[email protected]> wrote:
> >
> >>>> + * @of_node: (Optional) The device node
> >>>
> >>>> + struct device_node *of_node;
> >>>
> >>> Can we use fwnode from day 1, please?
> >>
> >> Could you explain this? I haven’t dealt with fwnode never :$
> >> BTW, this is done to fix this check when parsing gpio ranges:
> >> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
> >
> > Use struct fwnode_handle pointer instead of OF-specific one.
>
> But is that compatible with the current gpiolib-of code? :$
Yes (after a bit of amendment I have sent today as v2:
https://lore.kernel.org/linux-gpio/[email protected]/T/#u).
> > Also here is the question, why do you need to have that field in the
> > regmap config structure and can't simply use the parent's fwnode?
> > Also I'm puzzled why it's not working w/o this patch: GPIO library
> > effectively assigns parent's fwnode (okay, of_node right now).
>
> Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
> Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
I see. Can you point me out to the code where we get the node and
where it's being retrieved / filled?
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 4, 2021 at 6:33 PM Andy Shevchenko
<[email protected]> wrote:
> On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas <[email protected]> wrote:
Let me summarize what we can do this independently on any of my
patches and be okay with.
In the regmap GPIO configuration you supply struct fwnode_handle *fwnode.
You can you fwnode API in the actual GPIO controller driver.
Inside gpio-regmap simply do this for now
gc->of_node = to_of_node(config->fwnode);
The last part is an amendment I have told about, but it can be done
later on by switching the entire GPIO chip to use fwnode instead of
of_node.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
> El 4 mar 2021, a las 17:33, Andy Shevchenko <[email protected]> escribió:
>
> On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>> El 4 mar 2021, a las 16:28, Andy Shevchenko <[email protected]> escribió:
>>> On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>>>> El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
>>>>> On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
>>>>>>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
>>>>>>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
>>>>>>> <[email protected]> wrote:
>>>>>
>>>>>>>> + * @of_node: (Optional) The device node
>>>>>>>
>>>>>>>> + struct device_node *of_node;
>>>>>>>
>>>>>>> Can we use fwnode from day 1, please?
>>>>>>
>>>>>> Could you explain this? I haven’t dealt with fwnode never :$
>>>>>> BTW, this is done to fix this check when parsing gpio ranges:
>>>>>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
>>>>>
>>>>> Use struct fwnode_handle pointer instead of OF-specific one.
>>>>
>>>> But is that compatible with the current gpiolib-of code? :$
>>>
>>> Yes (after a bit of amendment I have sent today as v2:
>>> https://lore.kernel.org/linux-gpio/[email protected]/T/#u).
>>
>> Well that doesn’t fulfill my definition of “current gpiolib-of code”…
>> @Linus what should I do about this?
>
> Well, fwnode is a generic, and I strongly against spreading
> OF-specific code when we have fwnode working. But let's hear Linus
> out, of course!
>
> But it seems you are right and the library needs a few more amendments.
Yes, but I’m trying to do as few amendments as possible since I already have quite a large amount of patches :)
>
>>>>> Also here is the question, why do you need to have that field in the
>>>>> regmap config structure and can't simply use the parent's fwnode?
>>>>> Also I'm puzzled why it's not working w/o this patch: GPIO library
>>>>> effectively assigns parent's fwnode (okay, of_node right now).
>>>>
>>>> Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
>>>> Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
>>>
>>> I see. Can you point me out to the code where we get the node and
>>> where it's being retrieved / filled?
>>
>> Sure, this is where the child node is searched: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L100-L109
>> Then the gpio child node is probed and assigned here: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L51
>
> So, this is not (*yet) in upstream, correct?
No it’s not, but I've already changed the approach several times and I’m starting to get tired about it...
>
> So, why not to switch to fwnode API in that driver as well?
>
> When you do that and supply fwnode thru the regmap configuration, in
> the gpio-regmap we may assign it to of_node (via to_of_node() API).
>
>> Basically, I based that part of the code on the ingenic pin controller: https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/pinctrl/pinctrl-ingenic.c#L2485-L2491
>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/Documentation/devicetree/bindings/pinctrl/ingenic%2Cpinctrl.yaml#L155-L176
>
> This doesn't use remgap GPIO.
Yes, I know, but there aren’t any pinctrl drivers using regmap GPIO right now, so I couldn’t base my code on anything else :)
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Álvaro.
On Thu, Mar 4, 2021 at 7:24 PM Michael Walle <[email protected]> wrote:
> Am 2021-03-04 17:46, schrieb Andy Shevchenko:
> > On Thu, Mar 4, 2021 at 6:33 PM Andy Shevchenko
> > <[email protected]> wrote:
> >> On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas
> >> <[email protected]> wrote:
> >
> > Let me summarize what we can do this independently on any of my
> > patches and be okay with.
> >
> > In the regmap GPIO configuration you supply struct fwnode_handle
> > *fwnode.
> > You can you fwnode API in the actual GPIO controller driver.
> > Inside gpio-regmap simply do this for now
> >
> > gc->of_node = to_of_node(config->fwnode);
>
> If doing so, can we please have a comment saying that config->fwnode
> might be NULL in which case the fwnode of the parent is used?
Good comments are always welcome!
> > The last part is an amendment I have told about, but it can be done
> > later on by switching the entire GPIO chip to use fwnode instead of
> > of_node.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 5, 2021 at 9:45 AM Álvaro Fernández Rojas <[email protected]> wrote:
> > El 4 mar 2021, a las 17:33, Andy Shevchenko <[email protected]> escribió:
> > On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>> El 4 mar 2021, a las 16:28, Andy Shevchenko <[email protected]> escribió:
> >>> On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>>>> El 4 mar 2021, a las 16:17, Andy Shevchenko <[email protected]> escribió:
> >>>>> On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas <[email protected]> wrote:
> >>>>>>> El 4 mar 2021, a las 11:35, Andy Shevchenko <[email protected]> escribió:
> >>>>>>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
> >>>>>>> <[email protected]> wrote:
> >>>>>
> >>>>>>>> + * @of_node: (Optional) The device node
> >>>>>>>
> >>>>>>>> + struct device_node *of_node;
> >>>>>>>
> >>>>>>> Can we use fwnode from day 1, please?
> >>>>>>
> >>>>>> Could you explain this? I haven’t dealt with fwnode never :$
> >>>>>> BTW, this is done to fix this check when parsing gpio ranges:
> >>>>>> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934
> >>>>>
> >>>>> Use struct fwnode_handle pointer instead of OF-specific one.
> >>>>
> >>>> But is that compatible with the current gpiolib-of code? :$
> >>>
> >>> Yes (after a bit of amendment I have sent today as v2:
> >>> https://lore.kernel.org/linux-gpio/[email protected]/T/#u).
> >>
> >> Well that doesn’t fulfill my definition of “current gpiolib-of code”…
> >> @Linus what should I do about this?
> >
> > Well, fwnode is a generic, and I strongly against spreading
> > OF-specific code when we have fwnode working. But let's hear Linus
> > out, of course!
> >
> > But it seems you are right and the library needs a few more amendments.
>
> Yes, but I’m trying to do as few amendments as possible since I already have quite a large amount of patches :)
I understand your goal.
But as far I can say you don't need to rely on my patch series.
> >>>>> Also here is the question, why do you need to have that field in the
> >>>>> regmap config structure and can't simply use the parent's fwnode?
> >>>>> Also I'm puzzled why it's not working w/o this patch: GPIO library
> >>>>> effectively assigns parent's fwnode (okay, of_node right now).
> >>>>
> >>>> Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller).
> >>>> Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node).
> >>>
> >>> I see. Can you point me out to the code where we get the node and
> >>> where it's being retrieved / filled?
> >>
> >> Sure, this is where the child node is searched: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L100-L109
> >> Then the gpio child node is probed and assigned here: https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L51
> >
> > So, this is not (*yet) in upstream, correct?
>
> No it’s not, but I've already changed the approach several times and I’m starting to get tired about it...
I feel your pain, although I think that the best way is avoid
spreading OF-specifics over generic code.
Using fwnode API is pretty much straightforward. It has been designed
in a way to make it less invasive for existing code to be converted.
There are plenty of changes in the upstream that show how it looks
like.
You may check drivers under drivers/leds/ which have been switched to
fwnode (and AFAIK new code is usually not OF specific).
> > So, why not to switch to fwnode API in that driver as well?
> >
> > When you do that and supply fwnode thru the regmap configuration, in
> > the gpio-regmap we may assign it to of_node (via to_of_node() API).
> >
> >> Basically, I based that part of the code on the ingenic pin controller: https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/pinctrl/pinctrl-ingenic.c#L2485-L2491
> >> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/Documentation/devicetree/bindings/pinctrl/ingenic%2Cpinctrl.yaml#L155-L176
> >
> > This doesn't use remgap GPIO.
>
> Yes, I know, but there aren’t any pinctrl drivers using regmap GPIO right now, so I couldn’t base my code on anything else :)
Be a pioneer!
--
With Best Regards,
Andy Shevchenko