On 20-11-23 11:32:33, Dan Williams wrote: > On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky <ben.widawsky@xxxxxxxxx> wrote: > [..] > > > -ENXIO is fine with me. I just don't see it as often so I don't > > > really know what it is. > > > > > > Bjorn > > > > Dan, Bjorn, I did a fairly randomized look at various probe functions and ENODEV > > seems to be more common. My sort of historical use has been > > - ENODEV: General, couldn't establish device presence > > - ENXIO: Device was there but something is totally misconfigured > > - E*: A matching errno for exactly what went wrong > > > > My question though is, would it be useful to propagate the error up through > > probe? > > The error from probe becomes the modprobe exit code, or the write to > the 'bind' attribute errno. So, it's a choice between "No such device > or address", or "No such device". The "or address" mention makes a > small bit more sense to me since the device is obviously present as it > is visible in lspci, but either error code clearly indicates a driver > problem so ENODEV is fine. > > For the other error codes I think it would be confusing to return > something like EINVAL from probe as that would be mistaken as an > invalid argument to the modprobe without stracing to see that it came > from the result of a sysfs write Currently in this path there are 2 general reasons for failure: 1. Driver internal problem, ENOMEM or some such. 2. Device problem (the memory device capability isn't present). I think I'll return ENODEV for the former and ENXIO for the latter. If that sounds good to everyone else.
