I need to be short, since I'm about to travel. On Mon, 16 Mar 2009 15:28:02 +0100 Jean Delvare <kh...@linux-fr.org> wrote:
> Ah yeah, now I remember. You're the one who considers 2.6.18 a bleeding > edge kernel suitable for upstream development. This explains a lot. I have 3 separated environments, being the first with the bleeding edge Fedora rawhide core (2.6.29-rc-git + several linux-next patches), for development. For sure, this is not stable, and an intermediate with 2.6.27 (Fedora 10), for normal tests. But for sure I don't want to loose time or data running my production data on an unstable environment. Then, I use RHEL5 on my main machines: it is rock solid. On all of those environments, I need my devices properly working with the bleeding edge v4l/dvb drivers. > > > will almost certainly cause compatibility breakages. I can't see any gain to > > the end user of a board that it is properly supported that such change > > would do. > > I'm literally speechless. What's the gain of the change for a user whose card already works? If everything went ok, he will just have what he had before. The difference affects only users of boards not supported yet (or badly supported). > > The reasons I see are in order to provide a more consistent internal model > > to represent the devices, and to support devices with more complex > > approaches > > like devices that have some I2C muxes and switches on their buses, to solve > > the > > address problems we're currently facing with such devices. > > Abstracting the numerous improvements brought by the new binding model > for older devices, which by themselves justify the move IMHO, the key > issue here is that the old model and the new model do not mix properly. > The different device lifetime cycles make it pretty much impossible to > come up with a sane locking model. This is the reason why I want the > legacy model to die now. Ok, that's the reason why we're changing: we need the new model for a small subset of devices (5%? maybe even less). On those devices, I2C switches do exist and this causes troubles with the old model. Since both models don't mix, we're migrating even the drivers that won't need such model. > > > Also, please let's not lose focus here. The important thing here is to > > > finish the conversion to the new i2c device driver binding model, and > > > quickly. > > > > For finishing the conversion, I agree that we just need some kind of > > workaround > > to allow both IR and Audio to work, but we shouldn't loose how it would be > > done > > in the final version. > > For finishing the conversion, we don't need to do anything. The > PIC16C54 support is already broken today if I understood Hans > correctly. We certainly want to fix that someday, but this is unrelated > to the model conversion. It may or may not work. With the current behaviour, someone may load either driver (IR or audio). So, both things work, but not simultaneously. Anyway, you got me wrong: I don't think that pic16c54 is an enough reason for justify any changes on the i2c model. However, there are several devices that have processors connected via i2c (including several DVB based devices using Cypress processors). IMO, we will need sooner or later some solution for using the sub-address as a different device, but we may postpone such discussion to another time. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
