On Wed, 12 Jun 2019 17:54:34 +0200 Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > On Wed, 12 Jun 2019 09:14:39 +0200 > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > Ok, looked at driverctl. Extending this one for non-PCI seems like a > > reasonable path. However, we would also need to extend any non-PCI > > device type we want to support with a driver_override attribute like > > you did for PCI in 782a985d7af26db39e86070d28f987cad2 -- so this is > > only for newer kernels. Adding that attribute for subchannels looks > > feasible at a glance, but I have not tried to actually do it :) > > > > Halil, do you think that would make sense? > > Looks doable. Did not quite figure out the details yet, but it seems > that for PCI driver_override has more benefits than for cio (compared > to simple unbind/bind), as matching and probing seems to be more > elaborate for PCI. The benefit I see are > 1) the ability to exclude the device form driver binding, and > 2) having the same mechanism and thus consistent experience for pci and > cio. Yes, we should provide the same mechanism, even if it is much simpler for the css bus. > > What we IMHO should not do is make driver_override the override the > sch->st == id->type check. Agreed. The number of possible ids is much lower on the css bus, and a driver wanting to match to any device may simply specify all of them (not that this looks very useful). I'm currently playing with this change; will send out a patch when I have it in reasonable shape. > > Regards, > Halil > > > > > [This might also help with the lcs vs. ctc confusion on a certain 3088 > > cu model if this is added for ccw devices as well; but I'm not sure if > > these are still out in the wild at all. Probably not worth the effort > > for that.] >
