On Fri, Mar 16, 2012 at 3:39 AM, Jingoo Han <jg1.han@xxxxxxxxxxx> wrote: >> > So, your code can be removed. >> >> I don't think so. It does not break anything yet. One who make >> changes, should ensure backwards compatibility, at least talking about >> functionality and hardware (LCD) support, which was added few months >> ago. Remember, we talk about kernel parameters line - now it lets >> bootloader to select correct LCD size. After your changes, board with >> 7" LCD wont show anything. > > [CC'ed Tushar Behera] > > Yes, your code is working. However, your code is bug. it's not a bug, because it's working like it was intended to. it was reviewed and accepted by maintainers before merging to main line. you do not have rights to drop it because you don't like it. You are doing changes - please do it correctly and do not break existing functionality. btw, you still not answered my question: why these two s3c_fb_pd_win structures in mach-mini6410.c is a problem? They are declared on the stack, but platform data uses only single one. mini6410 rewrites its s3c-fb platform data with data from one of these two structures dynamically. Why it's a bug? You want to remove this dynamic selection which could be leaved there with reworked framework too. > 'struct s3c_fb_pd_win' is used not for LCD, but for windows of FIMD IP. So, 'struct s3c_fb_pd_win' should not be used to select LCD. > The mach-aquila.c uses two 'struct s3c_fb_pd_win' like you, however 'struct s3c_fb_pd_win' don't make problem with Thomas's > patchset. It is because mach-aquila.c use 'struct s3c_fb_pd_win' for only windows of FIMD IP. > We don't have to responsibility to keep wrong code. If you have kept the rule, Thomas's patch would not make the compatibility > problem with your code. Why we should keep aberration such as your code? If you want to select two LCDs, please find other way. > > >> >> Darius A. > -- 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
 |