On Tue, 16 Jun 2026 09:58:38 +0200 Peter Oberparleiter <[email protected]> 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
