On Wed, Nov 28, 2018 at 08:56:01AM -0800, Doug Anderson wrote: > Hi, > > On Thu, Oct 25, 2018 at 9:38 AM Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> wrote: > > > > The real llcc_slide_getd() function returns ERR_PTR() encoded errors > > so the stub function should too. > > > > Signed-off-by: Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> > > --- > > include/linux/soc/qcom/llcc-qcom.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > What's the plan with this patch series? > > Andy: I think patches #1 and #2 are all set to go. They just seem > like nice cleanups and have no comments on them. We're going to land > them in the Chrome OS 4.19 tree so it'd be convenient to keep things > synced up if you were able to land them too. > > > Stephen / Jordan: can you come to a conclusion about what you want to > do about patch #3? Land it as-is? Drop it? Spin it? > > ...I guess to summarize the argument (correct me if I'm wrong): > > Stephen would prefer it so that if the LLCC API returns an error that > clients _shouldn't_ just shrug it off. They should treat it as an > important error. ...but if LLCC API returns NULL then that's > something that can be ignored. ...so if you meant to use LLCC and > you're getting back -ENODEV then you should yell about it, but if you > compile out LLCC they you won't hit your IS_ERR() and you'll be fine. I still lean on the side of consistency with error codes but I'm not militant about it. My current version of the GPU patch handles NULL so we can drop this. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
