On Fri, 2010-05-14 at 12:03 +0200, ext Guruswamy, Senthilvadivu wrote: > > > -----Original Message----- > > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > > Sent: Friday, May 14, 2010 12:54 PM > > To: Guruswamy, Senthilvadivu > > Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx; > > tony@xxxxxxxxxxx; Hiremath, Vaibhav > > Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB <snip> > > The patch set makes VRFB optional. What happens if VRFB is turned off, > > and the user uses VRFB for a framebuffer? > [Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3. > User would have got an option to turn it OFF if it had appeared in > the menuconfig selections. I did not give that option in menuconfig > explicitly. > ie config OMAP2_VRFB > bool <No name given here> > > Suppose on a build the user deliberately gives "CONFIG_OMAP2_VRFB not set", > then VRFB functions are made as empty functions by the compiler. > > This is fine as long as the user does not say omapfb.vrfb=1. > > But if the user sets omapfb.vrfb=1, then it is a wrong usage of the bootargs > as he has already deliberately changed the defconfig to say "VRFB not set". > > The result of his experiment: No bootup on the board as the vaddr of VRFB > is populated nor of the normal RAM buffer. The kernel should be able to cope with that. While giving wrong boot arguments to the kernel causing it to not boot is bad, it could be somewhat acceptable. But if the user changes the rotation type via sysfs file, and the kernel crashes (which is what I fear will happen), it's totally unacceptable. If it's possible to turn VRFB off, then the code should handle the case where VRFB is not there. Meaning, returning error values or somehow else failing gracefully, and informing the user of wrong arguments. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
