| Message ID | 1438142842-31603-1-git-send-email-dja@axtens.net (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Michael Ellerman |
| Headers | show |
On Wed, 2015-07-29 at 14:07 +1000, Daniel Axtens wrote: > Previously, when attaching a context in dedicated mode, we ignored Previously? You mean currently? Now is before this patch is applied. > the result of add_process_element, which could potentially fail. > > If add_process_element returns and error, pass it back to the caller. ^ I can fix. > Signed-off-by: Daniel Axtens <dja@axtens.net> > > --- > > I'm not sure if this is worth sending to stable: it doesn't fix > any actual bug, it just lets us know earlier if we've failed. > > However, if mpe, Mikey or Ian feel like it should go to stable I > have no objection to that either. stable_kernel_rules.txt says: - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing). So I think not. But rules are flexible so I can be convinced otherwise if anyone has a good argument. cheers
On Wed, 2015-07-29 at 14:25 +1000, Michael Ellerman wrote: > On Wed, 2015-07-29 at 14:07 +1000, Daniel Axtens wrote: > > Previously, when attaching a context in dedicated mode, we ignored > > Previously? You mean currently? Now is before this patch is applied. I do mean currently. Apologies for the temporal confusion :) > > > the result of add_process_element, which could potentially fail. > > > > If add_process_element returns and error, pass it back to the caller. > ^ > > I can fix. > Many thanks: it's good to know that my spelling mistakes will only be immortalised in the list archives rather than in the kernel's git history. :p
On Wed, 2015-07-29 at 14:40 +1000, Daniel Axtens wrote: > On Wed, 2015-07-29 at 14:25 +1000, Michael Ellerman wrote: > > On Wed, 2015-07-29 at 14:07 +1000, Daniel Axtens wrote: > > > Previously, when attaching a context in dedicated mode, we ignored > > > > Previously? You mean currently? Now is before this patch is applied. > I do mean currently. Apologies for the temporal confusion :) > > > > > > the result of add_process_element, which could potentially fail. > > > > > > If add_process_element returns and error, pass it back to the caller. > > ^ > > > > I can fix. > > > Many thanks: it's good to know that my spelling mistakes will only be > immortalised in the list archives rather than in the kernel's git > history. :p Not to mention the double negative in the patch subject! "Don't ignore"... come on!?!? :-P Mikey
On Wed, 2015-29-07 at 04:07:22 UTC, Daniel Axtens wrote: > Previously, when attaching a context in dedicated mode, we ignored > the result of add_process_element, which could potentially fail. > > If add_process_element returns and error, pass it back to the caller. > > Signed-off-by: Daniel Axtens <dja@axtens.net> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/368857c16c595eb7537c cheers
diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c index debd97147b58..22c06d91faa8 100644 --- a/drivers/misc/cxl/native.c +++ b/drivers/misc/cxl/native.c @@ -551,9 +551,7 @@ static int attach_afu_directed(struct cxl_context *ctx, u64 wed, u64 amr) if ((result = cxl_afu_check_and_enable(ctx->afu))) return result; - add_process_element(ctx); - - return 0; + return add_process_element(ctx); } static int deactivate_afu_directed(struct cxl_afu *afu)
Previously, when attaching a context in dedicated mode, we ignored the result of add_process_element, which could potentially fail. If add_process_element returns and error, pass it back to the caller. Signed-off-by: Daniel Axtens <dja@axtens.net> --- I'm not sure if this is worth sending to stable: it doesn't fix any actual bug, it just lets us know earlier if we've failed. However, if mpe, Mikey or Ian feel like it should go to stable I have no objection to that either. --- drivers/misc/cxl/native.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)