>> We can agree or disagree about whether a part should be tri-stated in >> init/sleep() and under what circumstances, but why bother when someone >> has gone to the trouble of declaring a perfectly good tr-state >> interface in dvb-core, taht automatically asserts and de-asserts any >> dvb_frontend device from the bus, optionally. > > > Because I simply don't want to any new demod users for that callback unless > needed for some strange reason. I see, I understand your concern, perhaps you should have raised this in your first response. Are you the maintainer for dvb-core now? So two options come to mind: 1. The si2168_init() brings the part onto the bus, and _sleep() takes the device off the bus, regardless? Any by default, the device is not on the bus after attach takes place. 2. The bridge specifically calls ts_bus_control() on the si2168 fe ops, as and when the bridge requires it? This feels like a reasonable middle-ground approach. Your thoughts? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
