On 23.04.2020 18:20, Cornelia Huck wrote: > On Thu, 23 Apr 2020 16:52:24 +0200 > Vineeth Vijayan <vneethv@xxxxxxxxxxxxxxxxxx> wrote: >> Then we could also change the way ccw_device_call_sch_unregister() >> works, where >> the subchannel-unregister is happening from an upper layer. > > Hm, what's the problem here? This seems to be mostly a case of "we did > I/O to the device and it appeared not operational; so we go ahead and > unregister the subchannel"? Childless I/O subchannels are a bit useless. Hey Conny, sparked by your proposal, Vineeth and myself looked at the corresponding CIO code and wondered if things couldn't be done in a generally better/cleaner way. So here we'd like to get your opinion. In particular, as it is currently, a child-driver (IO subchannel driver, vfio-ccw, etc.) unregisters a device owned by a parent-device-driver (CSS), which feels from a high-level-view like a layering violation: only the parent driver should register and unregister the parent device. Also in case no subchannel driver is available (e.g. due to driver_override=none), there would be no subchannel ADD event at all. So, tapping into you historical expertise about CIO, is there any reason for doing it this way beyond being nice to userspace tooling that subchannels with non-working CCW devices are automatically hidden by unregistering them? Removing the child-unregisters-parent logic this would also enable manual rebind of subchannels for which only a different driver than the default one can successfully talk to the child device, though I'm unaware of any current application for that. Regards, Peter -- Peter Oberparleiter Linux on Z Development - IBM Germany
