> > That probably needs a bit of tweaking to getthe best results > > Does this make you lean one way or the other in how I would best > implement this driver? I would always start from what we have. I wonder actually if there is a bit of a disconnect here from the line of questions. I know in a lot of environments the model is concept design internal approval/verification consult with other stakeholders commit to model build release but in the Linux space the model is don't break anyone elses stuff get it working figure out as you go what is needed if it doesn't work out adjust polish as it becomes clear what can be done better repeat So even if you submit initial patches to make it work with 8250.c and it turns out that actually this was the wrong thing everyone will be happy with the patches that then relocate it. In addition what tends to occur is that the rules change anyway. You get half way through submitting support for 256 byte fifos and someone comes along with another different device that has the feature and so on. So I would start from 8250.c and get trivial stuff like the fifo changes, the PCI identifiers and so forth in as a small set of patches and then work long the rest of it. Even 'don't break other people's stuff' isn't a hard rule. The real rule is 'if you break other people's stuff fix it back up' - because it happens, and it's unavoidable. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
