On Thu, May 08, 2014 at 01:14:40PM +0300, Tomi Valkeinen wrote: > On 08/05/14 11:27, Alexander Shiyan wrote: > > >>> At this time the driver has three user. > >>> Only one of them should theoretically work. > >>> clps711x-autcpu12 should not work in the absence of memblock_reserve(). > >>> clps711x-p720t should not work due to physical address limitation as i > >>> noticed before. Board means to use SRAM instead of SDRAM. > >>> Only clps711x-edb7211 should work fine (in theory). > >>> Is this a good reason to replace the driver? I think yes. > >> > >> Ok, if the situation is that bad, maybe we can just switch to the new > >> driver. Have you verified that those boards do not work from anyone? Or > >> asked someone to test the new driver with those boards? > > > > I'm not familiar with other users of this platform . > > I am do not have these boards, all that I have written before that it's just a theory. > > Firm in which I work, uses its own board with CLPS711X CPU , this board is the > > only way to check for changes on real hardware . > > Ok. That makes me a bit nervous... You're removing a driver, which may > (or may not) have been working for other users. And adding a new one, > which may not (or may) work for the other users. Keep the old one around under another Kconfig name, mark it BROKEN, and if nobody speaks up in a couple of releases, remove it? > >> I'm still not really happy about it, and I'd much rather see the current > >> driver fixed. But if no one having those boards is up to the task > >> (probably not if they have not been working at all), maybe just ditching > >> the old driver and adding a new is the only way forward. > >> > >> One change that I think would be good is to change the series to first > >> remove the old driver, and then add the new one, with the same file name > >> as the old one. That way git log will show the history for both the new > >> and the old driver. > > > > In this case git-bisect will be broken. Is this OK? > > I think this is such a big change for the users of the driver that it's > not an issue. Of course, kernel should still build at all steps, but I > think it's fine if the fb driver in question will be out for a commit or > two. Agreed. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
