Hi, On 19.05.2014 13:05, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, May 19, 2014 11:46:10 AM Amit Kachhap wrote: >> On 5/15/14, Zhang Rui <rui.zhang@xxxxxxxxx> wrote: >>> On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote: >>>> Hi, >>>> >>>> This patch series contains various cleanups for EXYNOS thermal >>>> driver. Overall it decreases driver's LOC by 13%. It is based >>>> on next-20140428 kernel. It should not cause any functionality >>>> changes. >>>> >>> Amit, >>> >>> what do you think of this patch set? >>> >>> thanks, >>> rui >> >> I agreed to many of the cleanups in the patch but tmu controller >> features should be retained as they will allow adding quick soc >> support and also avoid unnecessary churning of code in the future. > > The general rule in the kernel code is not to keep the dead code as > it has a maintainance cost and makes further changes usually more > difficult, not easier. There is no guarantee that the future SoCs > support will use the dead code (i.e. TYPE_TWO_POINT_TRIMMING support > has been introudced more than 2.5 years but no users of it has been > ever added) and in the meantime all other code changes has to take > the dead code into account. I also have more Exynos thermal driver > changes in the work and it would be much easier to do them without > the need to support unused SoC features. Please consider this in > your opinion. I'd also like to add that I don't see any correlation with mentioned dead code and possibility of adding new SoCs. The code is mostly related to unused/untested features and support for new SoCs might just be added without those optional features. Moreover, less features (especially untested) means less hassle to add new SoC, because you have less things to test. Especially considering the fact that you would have to test originally untested code and fix it if it turns out to be broken. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |