Re: [PATCH v1] s390/virtio_ccw: Also suppress -EINVAL on device detach

[Halil Pasic <pasic@linux.ibm.com>]

On Tue, 16 Jun 2026 09:58:38 +0200
Peter Oberparleiter <oberpar@linux.ibm.com> wrote:

> >> So the commit didn't introduce -EINVAL as a new return value, rather,
> >> it changed the subchannel lifecycle such that existing paths now
> >> propagate -EINVAL rather than -ENODEV during the device detach
> >> scenario.  
> > 
> > I'm not convinced returning -EINVAL in the given situation is the
> > right thing to do. Peter, would you mind to chime in?  
> 
> I tend to agree that an attempt to start I/O for a subchannel that has
> DNV 0 should result in ENODEV rather than EINVAL, though the latter is
> still valid when a driver tries to start I/O on a subchannel that is not
> enabled for I/O.
> 

That would be a "programming error". I think it would be nice to document
that ccw_device_start() can return -EINVAL as well, and that the semantic
of EINVAL is basically execution of the function was not attempted,
because of a programming error. Or if we think that the list is not
exhaustive even after adding -EINVAL, we should state that as well in
some way one can program against.


> We'll make sure to design the fix for 8c58a229688c in away that ENODEV
> will be returned when DNV is 0. Assuming that this is the only situation
> where virtio-ccw's ccw_io_helper() receives -EINVAL from
> ccw_device_start__timeout_key() during detach, the subject patch should
> no longer be necessary.

I fully agree! With the semantic of -EINVAL pinned down to programming
error, logging the condition seems to be the right thing to do. So we
should keep the old handing IMHO. 

Regards,
Halill