lkml.org 
[lkml]   [2020]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 4/9] cxl/mem: Map memory device registers
On 20-11-23 11:32:33, Dan Williams wrote:
> On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky <ben.widawsky@intel.com> 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.

\
 
 \ /
  Last update: 2020-11-23 21:01    [W:0.555 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site