Hi, > Very interesting discussion, especially the argument that "we already shipped" > would not be a convincing argument. > > I had senior kernel maintainers tell me and the company I work for that we should > submit _all_ our platform specific kernel code and drivers for inclusion into > the upstream kernel. Yes, great. Really! > This exchange suggests that "it is a shipping product" does not count for such > submissions, and that "Benefit for the kernel" would be the deciding factor > instead. Which of course is a very vague statement - if code supporting > Chromebookis is of no benefit for the kernel, support for my company's products > for sure is much less so. First, let me state that I did not intend to say that the arbitrator muxer here has NO benefit for the kernel. I was aware there might be arguments for that and I wanted some more discussion to make that clearer to me. Simon's mail was very helpful in that regard and I will comment on that somewhen later. Still, I do have problems with "we already shipped it". If the driver is bad or the underlying concept is fragile, I want the freedom to reject a patch, product shipped or not. I will be supportive to find a proper solution, promised. If all fails, there is still staging/ or the possibility of out-of-tree patches. > Which kind of leaves me in a bind. On one side I promote that we should submit > all our kernel code, on the other side there is a very compelling case to be > made that it won't be accepted anyway. That doesn't make my life easier - Concentrate on argumenting why the driver is useful and it will be fine. "we already shipped this" feels a bit like blackmailing to me. And since most drivers do have well thought reasons for their existance, I'd primarily like to hear about those. > essentially since it supports those who say that we should not submit anything > in the first place. And believe me, there are many of those. > > Just to give some examples: > - I2C multiplexers. We have a bunch of those. Looking at this exchange, > it doesn't look good to get that code included. Multiplexers should be easy going, it is the arbitration which is discussed here. I am open to consider some generic arbitration schemes. What I am reluctant to do is to allow every board to have its own arbitration scheme. This would be board support hosted in the I2C directory. Meh. > It would be nice have to get some well defined guidelines for "acceptable" > contributions. "Benefit for the kernel" sure isn't one. I don't think it is possible to write down concrete guidelines for this. "According to rule 4a) of the guidelines you have to accept my patch"? That would be a mess, I think. Regards, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
