drivers/reset/core.c | 91 ++++++++++++++++++++++++-------- include/linux/of.h | 18 +++++++ include/linux/reset-controller.h | 14 ++++- include/linux/reset.h | 14 +++++ 4 files changed, 114 insertions(+), 23 deletions(-)
This series is part of a larger series which aims at adding fwnode support in multiple subsystems [1]. The goal of this series was to add support for software node in various subsystem but in a first time only the fwnode support had gained consensus and will be added to multiple subsystems. For the moment ACPI node support is excluded from the fwnode support to avoid creating an unspecified ACPI reset device description. With these modifications, both driver that uses the fwnode_ API or the of_ API to register the reset controller will be usable by consumer whatever the type of node that is used. One question raised by this series is that I'm not sure if all reset drivers should be modified to use the new fwnode support or keep the existing device-tree support. Maintainer advice on that particular question will be welcome. [1] https://lore.kernel.org/netdev/YhPSkz8+BIcdb72R@smile.fi.intel.com/T/ Clément Léger (2): of: add function to convert fwnode_reference_args to of_phandle_args reset: add support for fwnode drivers/reset/core.c | 91 ++++++++++++++++++++++++-------- include/linux/of.h | 18 +++++++ include/linux/reset-controller.h | 14 ++++- include/linux/reset.h | 14 +++++ 4 files changed, 114 insertions(+), 23 deletions(-) -- 2.34.1
Hi Clément, On Mi, 2022-03-23 at 10:50 +0100, Clément Léger wrote: > This series is part of a larger series which aims at adding fwnode > support in multiple subsystems [1]. The goal of this series was to > add support for software node in various subsystem but in a first > time only the fwnode support had gained consensus and will be added > to multiple subsystems. Could you explain the purpose of this a little? From the referenced mail it looks like this would be intended allow to register reset controllers via software node? Are there any real systems where this would be useful? > For the moment ACPI node support is excluded from the fwnode support > to avoid creating an unspecified ACPI reset device description. Are there any plans or ongoing discussions to specify such a description in the future? Right now I'm only aware of the ACPI _RST method as used by this patch: [1] https://lore.kernel.org/all/20220307135626.16673-1-kyarlagadda@nvidia.com/ > One question raised by this series is that I'm not sure if all reset > drivers should be modified to use the new fwnode support or keep the > existing device-tree support. Maintainer advice on that particular > question will be welcome. I would prefer not to have to switch all those small DT-only reset controller drivers all over the tree from of_node to fwnode. On the other hand, I think it would be good to avoid the direct of_node assignment, possibly by letting devm_reset_controller_register() initialize of_node or fwnode from the device for most cases, and by adding of_reset_controller_register() and fwnode_reset_controller_register() variants that take the node as an argument for the rest. That could allow to eventually get rid of the of_node pointer. For those drivers that provide their own .of_xlate, I'm not sure it would make sense to force them to use .fwnode_xlate if they don't already have a reason to use fwnode on their own. regards Philipp
Le Wed, 23 Mar 2022 16:07:26 +0100, Philipp Zabel <p.zabel@pengutronix.de> a écrit : > Hi Clément, > > On Mi, 2022-03-23 at 10:50 +0100, Clément Léger wrote: > > This series is part of a larger series which aims at adding fwnode > > support in multiple subsystems [1]. The goal of this series was to > > add support for software node in various subsystem but in a first > > time only the fwnode support had gained consensus and will be added > > to multiple subsystems. > > Could you explain the purpose of this a little? From the referenced > mail it looks like this would be intended allow to register reset > controllers via software node? Are there any real systems where this > would be useful? Hi Philipp and thanks for reviewing this series. As you noticed, the initial goal of the primary series was to add fwnode support in order to allow registering devices with software nodes. Since a lot of subsystem are of-centric, It was needed to modify them to use fwnode and thus accept the use of software nodes. The device I'm trying to support is a PCIe card that uses a lan9662 SoC. This card is meant to be used an ethernet switch with 2 x RJ45 ports and 2 x 10G SFPs. The lan966x SoCs can be used in two different ways: - It can run Linux by itself, on ARM64 cores included in the SoC. This use-case of the lan966x is currently being upstreamed, using a traditional Device Tree representation of the lan996x HW blocks [1] A number of drivers for the different IPs of the SoC have already been merged in upstream Linux. - It can be used as a PCIe endpoint, connected to a separate platform that acts as the PCIe root complex. In this case, all the devices that are embedded on this SoC are exposed through PCIe BARs and the ARM64 cores of the SoC are not used. Since this is a PCIe card, it can be plugged on any platform, of any architecture supporting PCIe. Appart from adding software node support, the fwnode API would also allow to add ACPI support more easily later. > > > For the moment ACPI node support is excluded from the fwnode support > > to avoid creating an unspecified ACPI reset device description. > > Are there any plans or ongoing discussions to specify such a > description in the future? Right now I'm only aware of the ACPI _RST > method as used by this patch: > > [1] https://lore.kernel.org/all/20220307135626.16673-1-kyarlagadda@nvidia.com/ > On that side, I must say I'm not really competent regarding ACPI which I do not know enough to answer you on that point. The discussions we had with Mark Brown regarding fwnode ACPI support pointed out the fact that we should not create unwanted ACPI support by using the same descriptions/specifications that exists for the device-tree. In order to avoid that, we suggested to explicitely left out ACPI with this fwnode support. This will allow to specify that support later and integrate it in the subsystem that have been converted to fwnode. > > One question raised by this series is that I'm not sure if all reset > > drivers should be modified to use the new fwnode support or keep the > > existing device-tree support. Maintainer advice on that particular > > question will be welcome. > > I would prefer not to have to switch all those small DT-only reset > controller drivers all over the tree from of_node to fwnode. That makes sense. > On the other hand, I think it would be good to avoid the direct of_node > assignment, possibly by letting devm_reset_controller_register() > initialize of_node or fwnode from the device for most cases, and by > adding of_reset_controller_register() and > fwnode_reset_controller_register() variants that take the node as an > argument for the rest. > That could allow to eventually get rid of the of_node pointer. Ok, I see that. Do you want this to be done in this series ? > > For those drivers that provide their own .of_xlate, I'm not sure it > would make sense to force them to use .fwnode_xlate if they don't > already have a reason to use fwnode on their own. No indeed and that's why I added the fwnode_xlate -> of_xlate translation function, this will allow to keep the existing of_xlate support. > > regards > Philipp Regards, -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
On Mi, 2022-03-23 at 17:05 +0100, Clément Léger wrote: [...] > > As you noticed, the initial goal of the primary series was to add > fwnode support in order to allow registering devices with software > nodes. Since a lot of subsystem are of-centric, It was needed to > modify them to use fwnode and thus accept the use of software nodes. > > The device I'm trying to support is a PCIe card that uses a lan9662 > SoC. This card is meant to be used an ethernet switch with 2 x RJ45 > ports and 2 x 10G SFPs. The lan966x SoCs can be used in two different > ways: > > - It can run Linux by itself, on ARM64 cores included in the SoC. This > use-case of the lan966x is currently being upstreamed, using a > traditional Device Tree representation of the lan996x HW blocks [1] > A number of drivers for the different IPs of the SoC have already > been merged in upstream Linux. > > - It can be used as a PCIe endpoint, connected to a separate platform > that acts as the PCIe root complex. In this case, all the devices > that are embedded on this SoC are exposed through PCIe BARs and the > ARM64 cores of the SoC are not used. Since this is a PCIe card, it > can be plugged on any platform, of any architecture supporting PCIe. > > Appart from adding software node support, the fwnode API would also > allow to add ACPI support more easily later. Thank you for the explanation. So this would be used by the sparx5 switch reset driver to provide the microchip,lan966x-switch-reset controller via software node? If that needs to be converted to fwnode anyway, it would be nice to include the conversion in this series as an example. [...] > On that side, I must say I'm not really competent regarding ACPI > which I do not know enough to answer you on that point. > > The discussions we had with Mark Brown regarding fwnode ACPI support > pointed out the fact that we should not create unwanted ACPI support > by using the same descriptions/specifications that exists for the > device-tree. In order to avoid that, we suggested to explicitely left > out ACPI with this fwnode support. This will allow to specify that > support later and integrate it in the subsystem that have been > converted to fwnode. Ok. > > > > On the other hand, I think it would be good to avoid the direct of_node > > assignment, possibly by letting devm_reset_controller_register() > > initialize of_node or fwnode from the device for most cases, and by > > adding of_reset_controller_register() and > > fwnode_reset_controller_register() variants that take the node as an > > argument for the rest. > > That could allow to eventually get rid of the of_node pointer. > > Ok, I see that. Do you want this to be done in this series ? Just thinking out loudly, before starting to drop the rcdev->of_node assigment from drivers en masse, I'd like to use the opportunity and turn reset_controller_register() and friends into macros that provide the module owner as a parameter, so the explicit rcdev->owner = THIS_MODULE assignment can be removed from the drivers as well. I think that is better done separately. > > For those drivers that provide their own .of_xlate, I'm not sure it > > would make sense to force them to use .fwnode_xlate if they don't > > already have a reason to use fwnode on their own. > > No indeed and that's why I added the fwnode_xlate -> of_xlate > translation function, this will allow to keep the existing of_xlate > support. Ok. regards Philipp
Le Thu, 24 Mar 2022 11:08:15 +0100, Philipp Zabel <p.zabel@pengutronix.de> a écrit : > > - It can be used as a PCIe endpoint, connected to a separate platform > > that acts as the PCIe root complex. In this case, all the devices > > that are embedded on this SoC are exposed through PCIe BARs and the > > ARM64 cores of the SoC are not used. Since this is a PCIe card, it > > can be plugged on any platform, of any architecture supporting PCIe. > > > > Appart from adding software node support, the fwnode API would also > > allow to add ACPI support more easily later. > > Thank you for the explanation. So this would be used by the sparx5 > switch reset driver to provide the microchip,lan966x-switch-reset > controller via software node? Exactly. > > If that needs to be converted to fwnode anyway, it would be nice to > include the conversion in this series as an example. Yes indeed, the sparx5 driver was modified in my private tree. I will change it to use fwnode. > > [...] > > On that side, I must say I'm not really competent regarding ACPI > > which I do not know enough to answer you on that point. > > > > The discussions we had with Mark Brown regarding fwnode ACPI support > > pointed out the fact that we should not create unwanted ACPI support > > by using the same descriptions/specifications that exists for the > > device-tree. In order to avoid that, we suggested to explicitely left > > out ACPI with this fwnode support. This will allow to specify that > > support later and integrate it in the subsystem that have been > > converted to fwnode. > > Ok. > > > > > > > On the other hand, I think it would be good to avoid the direct of_node > > > assignment, possibly by letting devm_reset_controller_register() > > > initialize of_node or fwnode from the device for most cases, and by > > > adding of_reset_controller_register() and > > > fwnode_reset_controller_register() variants that take the node as an > > > argument for the rest. > > > That could allow to eventually get rid of the of_node pointer. > > > > Ok, I see that. Do you want this to be done in this series ? > > Just thinking out loudly, before starting to drop the > rcdev->of_node assigment from drivers en masse, I'd like to use the > opportunity and turn reset_controller_register() and friends into > macros that provide the module owner as a parameter, so the explicit > rcdev->owner = THIS_MODULE assignment can be removed from the drivers > as well. Indeed, that seems like a good thing to do, direct assignments are often a pain to change all other the place. BTW, once drivers are converted to avoid direct assignment of the of_node field, it will be removable, the fwnode field will be sufficient for all operations. Thanks, Clément -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
© 2016 - 2026 Red Hat, Inc.