On 23/05/14 16:13, Alexander Shiyan wrote: >> Would it be possible to add the new driver along the old driver, and use >> the new driver only for the boards you have, and for boards for which >> it's clear the the old driver is not working? This could be merged for 3.16. > > At this time yes, we can. But since I plan to add multiplatform support > for this SOC, this seems not possible. > I can try to make multiplatform support optional, then it could be done... Hmm, why is that not possible with multiplatform support? What do you mean with multiplatform support here? While the drivers would handle the same device, if they have different names then they are different device drivers from Linux's perspective. Why can't one board use the old driver, and an other board use the new driver? > If there will be two drivers, I will do the following: remove the non-DT > support (for new driver) and will create a patch for 3.16 (this patch will > no affect to arm-soc). There would be no one using the driver in 3.16, then, right? > After that, I will do optional multiplatform support for this CPU and move > the boards, which do not use FB. > After this architecture will be ready to add DT support, and after all boards > will be converted, I'll remove the old version of the driver. > > OK? I'm a bit unclear what the multiplatform stuff means here, but yes, generally sounds ok. But I don't want to make this more difficult for you than it needs to. As I said, I'm fine with the current patches, if we skip 3.16 and get them to linux-next right after the merge window. If nobody would use the new driver in 3.16 anyway (in your proposal above), would this be the easiest way? Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
