On 29 October 2014 10:32, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Ulf, > > On Wed, Oct 29, 2014 at 10:26 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 28 October 2014 21:31, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >>> On Tue, Oct 28, 2014 at 3:38 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>>> Typically an ->attach_dev() callback would fetch some PM resourses. >>>> >>>> Those operations, like for example clk_get() may fail with different >>>> errors, including -EPROBE_DEFER. Instead of ignoring these errors and >>>> potentially only print an error message, let's propagate them to give >>>> callers the option to handle them. >>>> >>>> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >>> >>> Given that several patch series using ->attach_dev() are already floating >>> around and will be in -next soon, what is the plan of getting this in? >>> Doing it ASAP (in v3.18-rc3)? >>> Delaying this to v3.19-rc2, which will require an atomic fixing of its users? >>> Any other option? >> >> I would prefer if we consider 3.18-rc[x|. That's applies also to the >> below patchset, which actually fixes an issue. It would simplify the >> process of handling other SOC specific patches which adds PM domain >> support. >> >> [PATCH v3 0/9] PM / Domains: Fix race conditions during boot > > v3.18-rc[x] sounds fine. > >> Obviously the patches needs to be reviewed, I guess we are still in >> the process of doing that. > > Indeed. > > Perhaps we can get just the prototype change of ->attach_dev() in first? > That leaves some time for reviewing the code changes to actually handle > the return value, and unblocks platform patches using ->attach_dev() soon, > which are planned to enter in v3.19-rc. That's an option. On the other hand, that would mean that the errors that the attach_dev() callback would return from you SOC specific code, would just be ignored until v3.19-rc. That's not so good, hiding errors. :-) Let's see what Rafael thinks. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |