On Fri, Oct 6, 2017 at 3:37 PM, Thomas Monjalon <tho...@monjalon.net> wrote: > 06/10/2017 15:12, Shreyansh Jain: >> On Friday 06 October 2017 04:51 AM, Thomas Monjalon wrote: >> > 19/09/2017 20:51, Jan Blunck: >> >> On Mon, Sep 18, 2017 at 1:36 PM, Hemant Agrawal <hemant.agra...@nxp.com> >> >> wrote: >> >>> Tested-by: Hemant Agrawal <hemant.agra...@nxp.com> >> >>> >> >>> >> >>> On 8/12/2017 3:52 PM, Shreyansh Jain wrote: >> >>>> >> >>>> Bus scan is responsible for finding devices over *all* buses. >> >>>> Some of these buses might not be able to scan but that should >> >>>> not prevent other buses to be scanned. >> >>>> >> >> >> >> If scanning the bus fails this is signaling an error. In that case we >> >> might even want to unregister the bus. >> > >> > A scan error seems important enough to be reported to the caller. >> > OK to continue scanning other buses, but an error code should be returned. >> >> Isn't that counter intuitive if the scanning continues after error and >> an error is expected to be returned from it? >> What if there are more than one error? Which one is reported. > > Both are reported with the same code. > Anyway, there is no way to know which bus is failing, > except from log. >
Correct. Also there is no way to handle that failure except for reporting it to the log in all detail. >> As for cleanup, bus un-registration is not correct. Scan has failed, >> which might mean some assumption that bus took for scanning for devices >> doesn't exist for time being or present platform. Either way, I think >> whatever rollback needs to be done for scan failure, would be done by >> the bus->scan() implementation. >> >> Let me know what you think - I will make changes to the patch and push >> again. > > We may need more opinion here. > > Mine is that we should not hide a scan failure. Hide scan failures? Do you mean hiding it from the log? I wouldn't do that. > I would return an error code if any of the scan has failed, > but would process every scans. FWIW I agree.
