Le Thu, 24 Feb 2022 15:58:04 +0100, Hans de Goede <hdegoede@xxxxxxxxxx> a écrit : [...] > > can be addressed, but it's not necessarily immediate. > > > > My preferred solutions would be swnode or device-tree overlays but > > since there to is no consensus on how to add this support, how > > can we go on with this series ? > > FWIW I think that the convert subsystems + drivers to use the fwnode > abstraction layer + use swnode-s approach makes sense. For a bunch of > x86/ACPI stuff like Type-C muxing/controllers/routing but also MIPI > cameras we have already been moving in that direction since sometimes > a bunch of info seems to be hardcoded in Windows drivers rather then > "spelled out" in the ACPI tables so from the x86 side we are seeing > a need to have platform glue code which replaces the hardcoding on > the Windows side and we have been using the fwnode abstraction + > swnodes for this, so that we can keep using the standard Linux > abstractions/subsystems for this. > > As Mark already mentioned the regulator subsystem has shown to > be a bit problematic here, but you don't seem to need that? Hi Hans, Indeed, I don't need this subsystem. However, I'm still not clear why this subsystem in particular is problematic. Just so that I can recognize the other subsystems with the same pattern, could you explain me why it is problematic ? > > Your i2c subsys patches looked reasonable to me. IMHO an important > thing missing to give you some advice whether to try 1. or 3. first > is how well / clean the move to the fwnode abstractions would work > for the other subsystems. Actually, I did the conversion for pinctrl, gpios, i2c, reset, clk, syscon, mdio but did not factorized all the of code on top of fwnode adaptation. I did it completely for mdio and reset subsystems. Porting them to fwnode was rather straightforward, and almost all the of_* API now have a fwnode_* variant. While porting them to fwnode, I mainly had to modify the "register" and the "get" interface of these subsystems. I did not touched the enumeration part if we can call it like this and thus all the CLK_OF_DECLARE() related stuff is left untouched. > > Have you already converted other subsystems and if yes, can you > give us a pointer to a branch somewhere with the conversion for > other subsystems ? All the preliminary work I did is available at the link at [1]. But as I said, I did not converted completely all the subsystems, only reset [2] (for which I tried to convert all the drivers and fatorized OF on top of fwnode functions) and mdio [3] which proved to be easily portable. I also modified the clk framework [4] but did not went to the complete factorization of it. I converted the fixed-clk driver to see how well it could be done. Biggest difficulty is to keep of_xlate() and fwnode_xlate() (if we want to do so) to avoid modifying all drivers (even though not a lot of them implements custom of_xlate() functions). If backward compatibility is really needed, it can potentially be done, at the cost of keeping of_xlate() member and by converting the fwnode stuff to OF world (which is easily doable). Conversion to fwnode API actually proved to be rather straightforward except for some specific subsystem (syscon) which I'm not quite happy with the outcome, but again, I wanted the community feedback before going further in this way so there is room for improvement. Regards, [1] https://github.com/clementleger/linux/tree/fwnode_support [2] https://github.com/clementleger/linux/tree/fwnode_reset [3] https://github.com/clementleger/linux/tree/fwnode_mdio [4] https://github.com/clementleger/linux/tree/fwnode_clk > > Regards, > > Hans -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
