On Mon, Jun 15 2026, Halil Pasic <[email protected]> wrote: > On Fri, 12 Jun 2026 17:54:07 +0200 > William Bezenah <[email protected]> wrote: > >> Since commit 8c58a229688c ("s390/cio: Do not unregister the >> subchannel based on DNV"), subchannel behavior following a device >> detach has been updated and results in -EINVAL being propagated >> rather than -ENODEV, originating from ccw_device_start_timeout_key() >> in cio/device_ops. In the end, the virtio driver has no ability to >> react to the difference between device and subchannel states here, >> and during detach, both -ENODEV and -EINVAL indicate the device >> cannot be used and should not be treated as errors requiring >> attention. Update error handling in virtio_ccw_del_vq() and >> virtio_ccw_drop_indicator() to suppress -EINVAL in addition to >> -ENODEV. > > Hi William! > > Are you saying that ccw_device_start() started returning -EINVAL > since 8c58a229688c ("s390/cio: Do not unregister the subchannel based on > DNV")? Or did I somehow read the paragraph wrong? > > The funcition ccw_device_start is documented to return: > * Returns: > > * %0, if the operation was successful; > > * -%EBUSY, if the device is busy, or status pending; > > * -%EACCES, if no path specified in @lpm is operational; > > * -%ENODEV, if the device is not operational. > and the commit message does not say a thing about introducing -EINVAL to > the mix.
The function may return -EINVAL for non-enabled subchannels (i.e. pmcw.ena == 0), maybe we get an all-zeroes schib with dnv == 0? I'd expect it not to be enabled in that case anyway.
