Le Wed, 23 Mar 2022 16:07:26 +0100, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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@xxxxxxxxxx/ > 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
