On 11/14/16 14:16, Rob Herring wrote: > On Mon, Nov 14, 2016 at 12:44 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: >> On 11/14/16 03:04, Hans de Goede wrote: >>> Hi, >>> >>> On 14-11-16 08:34, Frank Rowand wrote: >>>> Hi Hans, Pantelis, >>>> >>>> On 11/12/16 18:15, Frank Rowand wrote: >>>>> On 11/04/16 07:42, Hans de Goede wrote: >>>>>> From: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >>>>>> >>>>>> Changesets are very powerful, but the lack of a helper API >>>>>> makes using them cumbersome. Introduce a simple copy based >>>>>> API that makes things considerably easier. >>>>>> >>>>>> To wit, adding a property using the raw API. >>>>>> >>>>>> struct property *prop; >>>>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL); >>>>>> prop->name = kstrdup("compatible"); >>>>>> prop->value = kstrdup("foo,bar"); >>>>>> prop->length = strlen(prop->value) + 1; >>>>>> of_changeset_add_property(ocs, np, prop); >>>>>> >>>>>> while using the helper API >>>>>> >>>>>> of_changeset_add_property_string(ocs, np, "compatible", >>>>>> "foo,bar"); >>>>>> >>>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >>>>>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> >>>>>> --- >>>>>> Changes in v2 (hdegoede@xxxxxxxxxx): >>>>>> -Address review comments from: >>>>>> https://www.spinics.net/lists/kernel/msg2252845.html >>>>> >>>>> That points to the May 9 version 1 patches from Pantelis (as expected), >>>>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4 >>>>> seems to have disappeared? >>>>> >>>>> Pantelis then sent a version 2 set of the patches on May 16. >>>>> >>>>> Your version is a modification of the May 9 patches (as would be expected >>>>> of a version 2). It is confusing to have two different version 2 patch >>>>> sets. I don't have any brilliant ideas on how this patch set could have >>>>> been named differently to avoid that confusion. >>>>> >>>>> The point of this little side-track is simply to note the existence of two >>>>> different version 2 series so I won't be confused when I revisit this >>>>> thread in the future. >>>>> >>>>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling >>>>>> -Remove (by manual inlining) these 2 static helpers: >>>>>> __of_changeset_add_update_property_u32 >>>>>> __of_changeset_add_update_property_bool >>>>>> -Remove the following exported helper method: >>>>>> of_changeset_node_move_to >>>>> >>>>> Not all comments were addressed. >>>>> >>>>> There are some other changes made that are not noted in the changelog. >>>>> >>>>> I am still reading through the patches. I will reply again either with >>>>> a reviewed-by or specific comments when I finish. >>>> >>>> Replying here for the entire patchset (there was no patch 0 to reply to). >>>> >>>> After reading through the patches, my reply is meta instead of specific >>>> comments about the code. >>>> >>>> There are very few users of change sets in tree. I do not see the need to >>>> add these helpers until such users are likely to appear. >>>> >>>> I would expect change sets to be _mostly_ used internally by the device tree >>>> overlay framework, not directly by drivers. If change sets are an attractive >>>> technology for drivers, I want to approach that usage very carefully to avoid >>>> inappropriate use, which could be very difficult to reign in after the fact. >>>> >>>> Even if helpers should be added, this seems to be an overly complex approach. >>>> If the need for these helpers becomes apparent I can provide review comments >>>> with the specifics about how it appears to be overly complex. >>>> >>>> Can you please provide some more insights into the needs driving the desire >>>> to have change set helpers and the expected use cases of them? Please put >>>> your architect's hat on when replying to this question. >>> >>> My use case for this is discussed in this thread: >>> https://www.spinics.net/lists/arm-kernel/msg536111.html >>> >>> With the dt-bindings for the hardware-manager I want to add here: >>> https://www.spinics.net/lists/arm-kernel/msg536109.html >>> >>> Note that there is a lot of discussion in this thread whether or >>> not this belongs in the kernel. I strongly believe though that >>> some functionality like this will be needed in the kernel for >>> ARM+dt devices going forward, just like there is plenty of x86 >>> code which adjusts itself to specific hardware, because whether >>> we like it or not hardware (revisions) will always have quirks. >> >> Thanks! That context should have been provided with the patches. >> >> The use case discussion is important and I am paying a lot of >> attention to that discussion and many other discussions about >> dynamic device trees. I don't think it makes sense to apply the >> change set helper patches yet, given the unsettled state of the >> various dynamic device tree discussions. > > These helpers are useful and easier to use than the existing API > independent of any issues to sort out with how we use overlays. So I > plan to take them whether there's a user right away or not. > > Rob OK, expect a more detailed review from me this week. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html