From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Fri, 07 Feb 2020 00:10:21 +0000 Subject: Re: [PATCH 1/3] fbdev/g364fb: Fix build failure Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="-1463811774-1984420675-1581033946=:13" List-Id: References: In-Reply-To: To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= Cc: linux-fbdev@vger.kernel.org, Thomas Bogendoerfer , Paul Burton , Bartlomiej Zolnierkiewicz , James Hogan , open list , Ralf Baechle , "open list:BROADCOM NVRAM DRIVER" , Thomas Bogendoerfer , dri-devel@lists.freedesktop.org, Laurent Vivier This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811774-1984420675-1581033946=:13 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Fri, 7 Feb 2020, Philippe Mathieu-Daud=C3=A9 wrote: > On Wed, Feb 5, 2020 at 11:18 PM Finn Thain = wrote: > > On Wed, 5 Feb 2020, Philippe Mathieu-Daud=C3=A9 wrote: > > > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote: > > > > > > > > This patch resolves these compiler errors and warnings -- > > > > > > > > CC drivers/video/fbdev/g364fb.o > > > > drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor': > > > > drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first us= e in this function) > > > > drivers/video/fbdev/g364fb.c:137:9: note: each undeclared identifie= r is reported only once for each function it appears in > > > > drivers/video/fbdev/g364fb.c:137:7: error: implicit declaration of = function 'fontwidth' [-Werror=3Dimplicit-function-declaration] > > > > drivers/video/fbdev/g364fb.c:137:23: error: 'p' undeclared (first u= se in this function) > > > > drivers/video/fbdev/g364fb.c:137:38: error: 'y' undeclared (first u= se in this function) > > > > drivers/video/fbdev/g364fb.c:137:7: error: implicit declaration of = function 'fontheight' [-Werror=3Dimplicit-function-declaration] > > > > drivers/video/fbdev/g364fb.c: In function 'g364fb_init': > > > > drivers/video/fbdev/g364fb.c:233:24: error: 'fbvar' undeclared (fir= st use in this function) > > > > drivers/video/fbdev/g364fb.c:234:24: error: 'xres' undeclared (firs= t use in this function) > > > > > > 18 years unnoticed... > > > > > > > More likely, it was noticed by those without the skills or time to get= =20 > > it fixed upstream. > > > > Those with the hardware skills and platform knowledge to be affected=20 > > by an obscure bug aren't necessarily also capable of fixing a kernel=20 > > bug, sending a patch upstream and getting it past code review. > > > > Getting a patch into the Linux kernel is itself a lot of work, unless= =20 > > you've had years of experience with that constantly changing process=20 > > (which varies significantly between subsystems). >=20 > I see, I'm not custom to kernel workflow. >=20 > > Kernel developers are only human and do accidentally introduce=20 > > breakage in their work (as contributors) while ironically (as=20 > > reviewers) they raise the bar for random fixes from users not versed=20 > > in the 10000+ lines of Documentation/process/*.rst > > > > Broken code does not mean zero potential users or zero frustrated=20 > > users yet I often hear kernel developers disingenuously claim that it= =20 > > does. They have an incentive to make that claim and often there's=20 > > no-one reading the mailing lists to push back. >=20 > But broken code is also bad example of code. The removed code is still=20 > buried in the git tree. >=20 Some bugs may never be noticed and yet everyone assumes that they are=20 present (hence "defence in depth" and all of the complexity that entails). My complaint was really about broken code being used as a rationale to=20 remove additional code (whatever its quality). For example, some maintainers would say, "18 years unnoticed... don't stop= =20 at g364fb_cursor(), remove the entire driver". ---1463811774-1984420675-1581033946=:13--