* Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers
From: Javier Martinez Canillas @ 2015-08-20 21:50 UTC (permalink / raw)
To: Brian Norris
Cc: linux-kernel, Andrzej Hajda, linux-fbdev, Michael Hennerich,
linux-iio, linux-wireless, Lee Jones,
Jean-Christophe Plagniol-Villard, linux-mtd, Lauro Ramos Venancio,
Søren Andersen, devel, Randy Dunlap, Masanari Iida,
Jiri Kosina, Devendra Naga, Tomi Valkeinen, Kyungmin Park,
Krzysztof Kozlowski, Greg Kroah-Hartman, Aloisio Almeida Jr,
Jonathan Cameron, Stephen Warren, Urs Fässler, Adrian Hunter,
Mauro Carvalho Chehab, Aya Mahfouz, George McCollister,
Samuel Ortiz, Manfred Schlaegl, linux-omap, Hartmut Knaack,
Ulf Hansson, Antonio Borneo, Andrea Galbusera, Michael Welling,
Fabian Frederick, Mark Brown, linux-mmc, linux-spi,
Lars-Peter Clausen, David Woodhouse, netdev, linux-media,
Peter Meerwald
In-Reply-To: <20150820211152.GI74600@google.com>
Hello Brian,
On 08/20/2015 11:11 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
>> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
>
> ^^^ I'm dying to know how this sentence ends :)
>
Sigh, I did some last minute restructuring of the cover letter and
seems I missed a sentence. I meant to said:
"and patches #9 to #17 solves c)."
>> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
>> the device was registered using OF. But this patch is included in the
>> series only as an RFC for illustration purposes since changing that
>> without first applying all the other patches in this series, will break
>> module autoloading for the drivers of devices registered using OF but
>> that lacks an of_match_table. I'll repost patch #18 once all the patches
>> in this series have landed.
>
> On a more productive note, the patches I've looked at look good to me.
> The missing aliases are a problem enough that should be fixed (i.e.,
> part (b)). I'll leave the SPI framework changes to others to comment on.
>
Great, thanks a lot for your feedback.
> Brian
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers
From: Brian Norris @ 2015-08-20 21:11 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Andrzej Hajda, linux-fbdev, Michael Hennerich,
linux-iio, linux-wireless, Lee Jones,
Jean-Christophe Plagniol-Villard, linux-mtd, Lauro Ramos Venancio,
Søren Andersen, devel, Randy Dunlap, Masanari Iida,
Jiri Kosina, Devendra Naga, Tomi Valkeinen, Kyungmin Park,
Krzysztof Kozlowski, Greg Kroah-Hartman, Aloisio Almeida Jr,
Jonathan Cameron, Stephen Warren, Urs Fässler, Adrian Hunter,
Mauro Carvalho Chehab, Aya Mahfouz, George McCollister,
Samuel Ortiz, Manfred Schlaegl, linux-omap, Hartmut Knaack,
Ulf Hansson, Antonio Borneo, Andrea Galbusera, Michael Welling,
Fabian Frederick, Mark Brown, linux-mmc, linux-spi,
Lars-Peter Clausen, David Woodhouse, netdev, linux-media,
Peter Meerwald
In-Reply-To: <1440054451-1223-1-git-send-email-javier@osg.samsung.com>
On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
^^^ I'm dying to know how this sentence ends :)
> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
> the device was registered using OF. But this patch is included in the
> series only as an RFC for illustration purposes since changing that
> without first applying all the other patches in this series, will break
> module autoloading for the drivers of devices registered using OF but
> that lacks an of_match_table. I'll repost patch #18 once all the patches
> in this series have landed.
On a more productive note, the patches I've looked at look good to me.
The missing aliases are a problem enough that should be fixed (i.e.,
part (b)). I'll leave the SPI framework changes to others to comment on.
Brian
^ permalink raw reply
* Re: [PATCH v1, TRIVIAL] Fix pxafb nonstd field documentation and add errata info
From: Petr Cvek @ 2015-08-20 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55D5B232.9090006@ti.com>
Dne 20.8.2015 v 12:55 Tomi Valkeinen napsal(a):
>
>
> On 08/08/15 21:20, Petr Cvek wrote:
>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 2d98de5..8f485ec 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -1893,6 +1893,11 @@ config FB_PXA_OVERLAY
>> bool "Support PXA27x/PXA3xx Overlay(s) as framebuffer"
>> default n
>> depends on FB_PXA && (PXA27x || PXA3xx)
>> + ---help---
>> + Using the overlay 2 and YUV420 mode on a PXA27x C0 chip revision will
>> + hang the LCD until the next SoC restart (errata E24).
>
> Shouldn't the driver handle this? It should not allow the combination to
> be used.
>
> Tomi
>
Probably, but I don't know which revisions are OK and which are not. Errata document:
Marvell® PXA270M Processor Specification Update
MV-S900957-00
has only 3 revisions, but PXA Manual lists 6 (2.2.5.1 Processor ID Register) and one revision from errata is not shown in my PXA Manual. I can exclude mine revision (from "system_rev" variable), but there should be some warning somewhere in configuration.
BTW There is software workaround, but I was not able to set registers right (it requires to send some data through FIFO in different mode).
Petr
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: yalin wang @ 2015-08-20 11:30 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <55D5B3A9.6040901@ti.com>
> On Aug 20, 2015, at 19:02, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>
> On 10/08/15 13:12, yalin wang wrote:
>> This change to use swab32(bitrev32()) to implement reverse_order()
>> function, have better performance on some platforms.
>
> Which platforms? Presuming you tested this, roughly how much better
> performance? If you didn't, how do you know it's faster?
i investigate on arm64 platforms:
for (j = dsize; j--;) {
tmp = data[k++];
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
bac: 110006a4 add w4, w21, #0x1
bb0: 5ac000a3 rbit w3, w5
if (dsize) {
NVDmaStart(info, par, RECT_EXPAND_TWO_COLOR_DATA(0), dsize);
for (j = dsize; j--;) {
tmp = data[k++];
bb4: 110006d6 add w22, w22, #0x1
bb8: 5ac00861 rev w1, w3
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
bbc: b9041e64 str w4, [x19,#1052]
bc0: 8b3548c2 add x2, x6, w21, uxtw #2
bc4: b9000041 str w1, [x2]
this is the disassemble code after apply the patch,
only need:
rbit w3, w5
rev w1, w3
2 instruction to get the reverse_order() result,
apparently after than the origianl macro code.
>
>> Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
>> ---
>> drivers/video/fbdev/riva/fbdev.c | 19 ++++++-------------
>> 1 file changed, 6 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
>> index f1ad274..4803901 100644
>> --- a/drivers/video/fbdev/riva/fbdev.c
>> +++ b/drivers/video/fbdev/riva/fbdev.c
>> @@ -40,6 +40,7 @@
>> #include <linux/init.h>
>> #include <linux/pci.h>
>> #include <linux/backlight.h>
>> +#include <linux/swab.h>
>> #include <linux/bitrev.h>
>> #ifdef CONFIG_PMAC_BACKLIGHT
>> #include <asm/machdep.h>
>> @@ -84,6 +85,7 @@
>> #define SetBit(n) (1<<(n))
>> #define Set8Bits(value) ((value)&0xff)
>>
>> +#define reverse_order(v) swab32(bitrev32(v))
>> /* HW cursor parameters */
>> #define MAX_CURS 32
>>
>> @@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
>> return (VGA_RD08(par->riva.PVIO, 0x3cc));
>> }
>>
>> -static inline void reverse_order(u32 *l)
>
> I would suggest to do the work in the inline function, instead of a
> macro. And if you keep the function prototype the same, then the changes
> to each reverse_order call site are not needed.
>
ok, i will change to a inline function.
^ permalink raw reply
* Re: [RFC] fbdev/nvidia:change reverse_order() macro
From: Tomi Valkeinen @ 2015-08-20 11:04 UTC (permalink / raw)
To: yalin wang, adaplas, plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1440053547-24193-1-git-send-email-yalin.wang2010@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
On 20/08/15 09:52, yalin wang wrote:
> This change reverse_order() to swab32(bitrev32()), so that
> it can have better performance on some platforms.
>
> Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
> ---
> drivers/video/fbdev/nvidia/nv_accel.c | 4 ++--
> drivers/video/fbdev/nvidia/nv_local.h | 13 ++++---------
> 2 files changed, 6 insertions(+), 11 deletions(-)
I have more or less the same comments here as for the riva patch, except
in this one I'd change the macro to an static inline function.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Tomi Valkeinen @ 2015-08-20 11:02 UTC (permalink / raw)
To: yalin wang, adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <C21B8761-0447-45A6-B833-742E3B4C13DE@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On 10/08/15 13:12, yalin wang wrote:
> This change to use swab32(bitrev32()) to implement reverse_order()
> function, have better performance on some platforms.
Which platforms? Presuming you tested this, roughly how much better
performance? If you didn't, how do you know it's faster?
> Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
> ---
> drivers/video/fbdev/riva/fbdev.c | 19 ++++++-------------
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
> index f1ad274..4803901 100644
> --- a/drivers/video/fbdev/riva/fbdev.c
> +++ b/drivers/video/fbdev/riva/fbdev.c
> @@ -40,6 +40,7 @@
> #include <linux/init.h>
> #include <linux/pci.h>
> #include <linux/backlight.h>
> +#include <linux/swab.h>
> #include <linux/bitrev.h>
> #ifdef CONFIG_PMAC_BACKLIGHT
> #include <asm/machdep.h>
> @@ -84,6 +85,7 @@
> #define SetBit(n) (1<<(n))
> #define Set8Bits(value) ((value)&0xff)
>
> +#define reverse_order(v) swab32(bitrev32(v))
> /* HW cursor parameters */
> #define MAX_CURS 32
>
> @@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
> return (VGA_RD08(par->riva.PVIO, 0x3cc));
> }
>
> -static inline void reverse_order(u32 *l)
I would suggest to do the work in the inline function, instead of a
macro. And if you keep the function prototype the same, then the changes
to each reverse_order call site are not needed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v1, TRIVIAL] Fix pxafb nonstd field documentation and add errata info
From: Tomi Valkeinen @ 2015-08-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C64864.6070405@tul.cz>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On 08/08/15 21:20, Petr Cvek wrote:
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2d98de5..8f485ec 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1893,6 +1893,11 @@ config FB_PXA_OVERLAY
> bool "Support PXA27x/PXA3xx Overlay(s) as framebuffer"
> default n
> depends on FB_PXA && (PXA27x || PXA3xx)
> + ---help---
> + Using the overlay 2 and YUV420 mode on a PXA27x C0 chip revision will
> + hang the LCD until the next SoC restart (errata E24).
Shouldn't the driver handle this? It should not allow the combination to
be used.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: atmel: fix warning for const return value
From: Tomi Valkeinen @ 2015-08-20 10:51 UTC (permalink / raw)
To: Sudip Mukherjee, Rob Herring
Cc: linux-kernel, linux-fbdev, Nicolas Ferre,
Jean-Christophe Plagniol-Villard
In-Reply-To: <20150807052221.GC3537@sudip-pc>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
On 07/08/15 08:22, Sudip Mukherjee wrote:
> On Mon, Jul 27, 2015 at 10:41:41AM -0500, Rob Herring wrote:
>> A const on a return value is meaningless and generates a warning on some
>> versions of gcc:
>>
>> drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on function return type
> maybe this one should have been static instead of const.
I think that makes sense. I will apply the following patch instead of Rob's,
if no one complains.
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu Aug 20 13:46:10 2015 +0300
video: fbdev: atmel: fix warning for const return value
A const on a return value is meaningless and generates a warning on some
versions of gcc:
drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on function return type
The function in question is only used inside the .c file, so the author
of the code most likely means "static" instead of "const".
Change the const to static.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index abadc490fa1f..016cae1425a4 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -999,7 +999,7 @@ static const char *atmel_lcdfb_wiring_modes[] = {
[ATMEL_LCDC_WIRING_RGB] = "RGB",
};
-const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
+static int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
{
const char *mode;
int err, i;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Tomi Valkeinen @ 2015-08-20 9:16 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jingoo Han
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAJKOXPc=k8r64_LuUGBaoOK87h07_zXUn_LoQ50KWfbk-1u69w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On 24/07/15 09:12, Krzysztof Kozlowski wrote:
> 2015-07-08 13:34 GMT+09:00 Jingoo Han <jingoohan1@gmail.com>:
>>
>> On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski <k.kozlowski.k@gmail.com> wrote:
>>>
>>> The platform_device_id is not modified by the driver and core uses it as
>>> const.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
>>
>> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>>
>> Best regards,
>> Jingoo Han
>
> Seems nobody is picking it up, so I merge it through Samsung-SoC tree.
> If there are any objections please let me know.
I can pick this up if you didn't already do that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] drivers: video: fbdev: vga: fixed coding style
From: Tomi Valkeinen @ 2015-08-20 9:07 UTC (permalink / raw)
To: Cristian Ardelean, plagnioj; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1436592450-5388-1-git-send-email-cristian97.ardelean@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
Hi,
On 11/07/15 08:27, Cristian Ardelean wrote:
> Fixed most of the coding style issues suggested by checkpatch.pl
> tool. Mainly converted spaces to tabs. Left remaining errors and
> warnings up to decision of the developers.
>
> Signed-off-by: Cristian Ardelean <cristian97.ardelean@gmail.com>
> ---
> drivers/video/fbdev/vga16fb.c | 386 ++++++++++++++++++++---------------------
> 1 file changed, 193 insertions(+), 193 deletions(-)
I don't want patches that clean up formatting for random old drivers.
For drivers that are in active development such patches may make sense,
but this one is just needless change, possibly causing conflicts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: remove unnecessary memset in vfb
From: Tomi Valkeinen @ 2015-08-20 9:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Marcin Chojnacki
Cc: Jean-Christophe PLAGNIOL-VILLARD, Linux Fbdev development list,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdW9g4h0EX_gZsXiTfaXsOTtqOqVN+SN=GtV8zNRQo_LXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]
On 20/08/15 11:21, Geert Uytterhoeven wrote:
> On Thu, Jun 18, 2015 at 3:01 PM, Marcin Chojnacki <marcinch7@gmail.com> wrote:
>> In vfb_probe memory is allocated using rvmalloc which automatically
>> sets the allocated memory to zero. This patch removes the second
>> unnecessary memset in vfb_probe.
>>
>> Signed-off-by: Marcin Chojnacki <marcinch7@gmail.com>
>> ---
>> drivers/video/fbdev/vfb.c | 8 --------
>> 1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
>> index 70a897b..b2d38b7 100644
>> --- a/drivers/video/fbdev/vfb.c
>> +++ b/drivers/video/fbdev/vfb.c
>> @@ -490,14 +490,6 @@ static int vfb_probe(struct platform_device *dev)
>> if (!(videomemory = rvmalloc(videomemorysize)))
>> return retval;
>>
>> - /*
>> - * VFB must clear memory to prevent kernel info
>> - * leakage into userspace
>> - * VGA-based drivers MUST NOT clear memory if
>> - * they want to be able to take over vgacon
>> - */
>> - memset(videomemory, 0, videomemorysize);
>> -
>
> As vfb also serves as a sample driver, I think it would be worthwhile to move
> the comment to rvmalloc().
I changed the patch as follows:
commit c0a3229313d6931a77e0c1e1c22e398c0312bf6f
Author: Marcin Chojnacki <marcinch7@gmail.com>
Date: Thu Jun 18 15:01:52 2015 +0200
fbdev: remove unnecessary memset in vfb
In vfb_probe memory is allocated using rvmalloc which automatically
sets the allocated memory to zero. This patch removes the second
unnecessary memset in vfb_probe.
Signed-off-by: Marcin Chojnacki <marcinch7@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index 70a897b1e458..b9c2f81fb6b9 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -51,7 +51,14 @@ static void *rvmalloc(unsigned long size)
if (!mem)
return NULL;
- memset(mem, 0, size); /* Clear the ram out, no junk to the user */
+ /*
+ * VFB must clear memory to prevent kernel info
+ * leakage into userspace
+ * VGA-based drivers MUST NOT clear memory if
+ * they want to be able to take over vgacon
+ */
+
+ memset(mem, 0, size);
adr = (unsigned long) mem;
while (size > 0) {
SetPageReserved(vmalloc_to_page((void *)adr));
@@ -490,14 +497,6 @@ static int vfb_probe(struct platform_device *dev)
if (!(videomemory = rvmalloc(videomemorysize)))
return retval;
- /*
- * VFB must clear memory to prevent kernel info
- * leakage into userspace
- * VGA-based drivers MUST NOT clear memory if
- * they want to be able to take over vgacon
- */
- memset(videomemory, 0, videomemorysize);
-
info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
if (!info)
goto err;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH] fbdev: remove unnecessary memset in vfb
From: Geert Uytterhoeven @ 2015-08-20 8:21 UTC (permalink / raw)
To: Marcin Chojnacki
Cc: Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <1434632512-128161-1-git-send-email-marcinch7@gmail.com>
On Thu, Jun 18, 2015 at 3:01 PM, Marcin Chojnacki <marcinch7@gmail.com> wrote:
> In vfb_probe memory is allocated using rvmalloc which automatically
> sets the allocated memory to zero. This patch removes the second
> unnecessary memset in vfb_probe.
>
> Signed-off-by: Marcin Chojnacki <marcinch7@gmail.com>
> ---
> drivers/video/fbdev/vfb.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
> index 70a897b..b2d38b7 100644
> --- a/drivers/video/fbdev/vfb.c
> +++ b/drivers/video/fbdev/vfb.c
> @@ -490,14 +490,6 @@ static int vfb_probe(struct platform_device *dev)
> if (!(videomemory = rvmalloc(videomemorysize)))
> return retval;
>
> - /*
> - * VFB must clear memory to prevent kernel info
> - * leakage into userspace
> - * VGA-based drivers MUST NOT clear memory if
> - * they want to be able to take over vgacon
> - */
> - memset(videomemory, 0, videomemorysize);
> -
As vfb also serves as a sample driver, I think it would be worthwhile to move
the comment to rvmalloc().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
From: Tomi Valkeinen @ 2015-08-20 8:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jean-Christophe Plagniol-Villard, linux-omap,
linux-fbdev, linux-kernel
In-Reply-To: <1436510250-5633-1-git-send-email-k.kozlowski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On 10/07/15 09:37, Krzysztof Kozlowski wrote:
> Hi,
>
>
> The i2c drivers also do not have to set 'owner' field because
> i2c_register_driver() will do it instead.
>
> 'owner' is removed from i2c drivers, which I was able to compile
> with allyesconfig (arm, arm64, i386, x86_64, ppc64).
> Only compile-tested.
>
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
>
>
> Best regards,
> Krzysztof
>
>
> Krzysztof Kozlowski (2):
> video: fbdev: Drop owner assignment from i2c_driver
> video: fbdev: Drop owner assignment from platform_driver
>
> drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 -
> drivers/video/fbdev/ssd1307fb.c | 1 -
> 2 files changed, 2 deletions(-)
>
Thanks, queued for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: remove unnecessary memset in vfb
From: Tomi Valkeinen @ 2015-08-20 7:56 UTC (permalink / raw)
To: Marcin Chojnacki, plagnioj; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1434632512-128161-1-git-send-email-marcinch7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
On 18/06/15 16:01, Marcin Chojnacki wrote:
> In vfb_probe memory is allocated using rvmalloc which automatically
> sets the allocated memory to zero. This patch removes the second
> unnecessary memset in vfb_probe.
>
> Signed-off-by: Marcin Chojnacki <marcinch7@gmail.com>
> ---
> drivers/video/fbdev/vfb.c | 8 --------
> 1 file changed, 8 deletions(-)
Thanks, queued for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] framebuffer: disable vgacon on microblaze arch
From: Tomi Valkeinen @ 2015-08-20 7:54 UTC (permalink / raw)
To: Nicolai Stange, Jean-Christophe Plagniol-Villard
Cc: Geert Uytterhoeven, linux-fbdev, linux-kernel
In-Reply-To: <87d20u5dji.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On 17/06/15 22:40, Nicolai Stange wrote:
> Fix an allmodconfig link failer on microblaze:
> drivers/built-in.o: In function `vgacon_save_screen':
> drivers/video/console/.tmp_vgacon.o:(.text+0x8fc10):
> undefined reference to `screen_info'
>
> Disable vgacon on microblaze because the symbol
> struct screen_info screen_info;
> is not defined for the microblaze arch.
>
> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Thanks, queued for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: radeon: Remove 'struct timeval' usage
From: Tomi Valkeinen @ 2015-08-20 7:51 UTC (permalink / raw)
To: Tina Ruchandani, Arnd Bergmann
Cc: y2038, Benjamin Herrenschmidt, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel
In-Reply-To: <20150525040716.GA4448@tinar>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Hi Tina,
On 25/05/15 07:07, Tina Ruchandani wrote:
> 'struct timeval' uses a 32-bit representation for the
> seconds field which will overflow in the year 2038 and beyond.
> This patch replaces the usage of 'struct timeval' with
> ktime_t which uses a 64-bit time representation and does not
> suffer from the y2038 problem. This patch is part of a larger
> effort to remove all instances of 'struct timeval', 'struct
> timespec', time_t and other 32-bit timekeeping variables
> from the kernel.
> The patch also replaces the use of real time (do_gettimeofday)
> with monotonic time (ktime_get).
>
> Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
I had dropped this from 4.2 as there were issues reported, but forgot to
write a mail about it...
Can you send a updated patch with the issues fixed?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: remove unneeded initialization in few places
From: Tomi Valkeinen @ 2015-08-20 7:39 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
On 08/06/15 02:02, Alexey Klimov wrote:
> Small minor cleanup.
> This patch removes unneeded initializations of variables
> in few places in different functions and one empty line.
>
> Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
> ---
> drivers/video/fbdev/udlfb.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
Thanks, queued for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 04/18] OMAPDSS: panel-sony-acx565akm: Export OF module alias information
From: Javier Martinez Canillas @ 2015-08-20 7:07 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, linux-fbdev,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-omap
In-Reply-To: <1440054451-1223-1-git-send-email-javier@osg.samsung.com>
The SPI core always reports the MODALIAS uevent as "spi:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: SPI id table or OF match table).
So drivers needs to export the SPI id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and SPI id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same SPI device name for example.
To avoid the above, the SPI core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
index 90cbc4c3406c..c581231c74a5 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
@@ -898,6 +898,7 @@ static const struct of_device_id acx565akm_of_match[] = {
{ .compatible = "omapdss,sony,acx565akm", },
{},
};
+MODULE_DEVICE_TABLE(of, acx565akm_of_match);
static struct spi_driver acx565akm_driver = {
.driver = {
--
2.4.3
^ permalink raw reply related
* [PATCH 00/18] Export SPI and OF module aliases in missing drivers
From: Javier Martinez Canillas @ 2015-08-20 7:07 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Andrzej Hajda, linux-fbdev,
Michael Hennerich, linux-iio, linux-wireless, Lee Jones,
Jean-Christophe Plagniol-Villard, linux-mtd, Lauro Ramos Venancio,
Søren Andersen, devel, Randy Dunlap, Masanari Iida,
Jiri Kosina, Devendra Naga, Tomi Valkeinen, Kyungmin Park,
Krzysztof Kozlowski, Greg Kroah-Hartman, Aloisio Almeida Jr,
Jonathan Cameron, Stephen Warren, Urs Fässler, Adrian Hunter,
Mauro Carvalho Chehab, Aya Mahfouz, Brian Norris,
George McCollister, Samuel Ortiz, Manfred Schlaegl, linux-omap,
Hartmut Knaack, Ulf Hansson, Antonio Borneo, Andrea Galbusera,
Michael Welling, Fabian Frederick, Mark Brown, linux-mmc,
linux-spi, Lars-Peter Clausen, David Woodhouse, netdev,
linux-media, Peter Meerwald
Hello,
Short version:
This patch series is the SPI equivalent of the I2C one posted before [0].
This series add the missing MODULE_DEVICE_TABLE() for OF and SPI tables
to export that information so modules have the correct aliases built-in
and autoloading works correctly.
Longer version:
The SPI core always reports the MODALIAS uevent as "spi:<modalias>"
regardless of the mechanism that was used to register the device (i.e:
OF or board code) and the table that is used later to match the driver
with the device (i.e: SPI id table or OF match table).
But this means that OF-only drivers needs to have both OF and SPI id
tables that have to be kept in sync and also the device node's compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same SPI device name for example.
Also, there are many SPI drivers whose module auto-loading is not working
because of this fact that the SPI core always reports the MODALIAS as
spi:<modalias> and many developers didn't expect this since is not how
other subsystems behave.
I've identified SPI drivers with 3 types of different issues:
a) Those that have an spi_table but are not exported. The match works
if the driver is built-in but since the ID table is not exported,
module auto-load won't work.
b) Those that have a of_table but are not exported. This is currently
not an issue since even when the of_table is used to match the dev
with the driver, an OF modalias is not reported by the SPI core.
But if the SPI core is changed to report the MODALIAS of the form
of:N*T*C as it's made by other subsystems, then module auto-load
will break for these drivers.
c) Those that don't have an of_table but should since are OF drivers
with DT bindings doc for them. Since the SPI core does not report
a OF modalias and since spi_match_device() fallbacks to match the
device part of the compatible string with the SPI device ID table,
many OF drivers don't have an of_table to match. After all having
a SPI device ID table is mandatory so it works without a of_table.
So, in order to not make mandatory to have a SPI device ID table, all
these three kind of issues have to be addressed. This series does that.
I split the changes so the patches in this series are independent and
can be picked individually by subsystem maintainers.
Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
Patch #18 changes the logic of spi_uevent() to report an OF modalias if
the device was registered using OF. But this patch is included in the
series only as an RFC for illustration purposes since changing that
without first applying all the other patches in this series, will break
module autoloading for the drivers of devices registered using OF but
that lacks an of_match_table. I'll repost patch #18 once all the patches
in this series have landed.
[0]: https://lkml.org/lkml/2015/7/30/519
Best regards,
Javier
Javier Martinez Canillas (18):
iio: Export SPI module alias information in missing drivers
staging: iio: hmc5843: Export missing SPI module alias information
mtd: dataflash: Export OF module alias information
OMAPDSS: panel-sony-acx565akm: Export OF module alias information
mmc: mmc_spi: Export OF module alias information
staging: mt29f_spinand: Export OF module alias information
net: ks8851: Export OF module alias information
[media] s5c73m3: Export OF module alias information
mfd: cros_ec: spi: Add OF match table
iio: dac: ad7303: Add OF match table
iio: adc: max1027: Set struct spi_driver .of_match_table
mfd: stmpe: Add OF match table
iio: adc: mcp320x: Set struct spi_driver .of_match_table
iio: as3935: Add OF match table
iio: adc128s052: Add OF match table
iio: frequency: adf4350: Add OF match table
NFC: trf7970a: Add OF match table
spi: (RFC, don't apply) report OF style modalias when probing using DT
drivers/iio/adc/max1027.c | 1 +
drivers/iio/adc/mcp320x.c | 1 +
drivers/iio/adc/ti-adc128s052.c | 8 ++++++++
drivers/iio/amplifiers/ad8366.c | 1 +
drivers/iio/dac/ad7303.c | 7 +++++++
drivers/iio/frequency/adf4350.c | 9 +++++++++
drivers/iio/proximity/as3935.c | 7 +++++++
drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 +
drivers/mfd/cros_ec_spi.c | 7 +++++++
drivers/mfd/stmpe-spi.c | 13 +++++++++++++
drivers/mmc/host/mmc_spi.c | 1 +
drivers/mtd/devices/mtd_dataflash.c | 1 +
drivers/net/ethernet/micrel/ks8851.c | 1 +
drivers/nfc/trf7970a.c | 7 +++++++
drivers/spi/spi.c | 8 ++++++++
drivers/staging/iio/magnetometer/hmc5843_spi.c | 1 +
drivers/staging/mt29f_spinand/mt29f_spinand.c | 1 +
.../video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
18 files changed, 76 insertions(+)
--
2.4.3
^ permalink raw reply
* [RFC] fbdev/nvidia:change reverse_order() macro
From: yalin wang @ 2015-08-20 6:52 UTC (permalink / raw)
To: adaplas, plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: yalin wang
This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/video/fbdev/nvidia/nv_accel.c | 4 ++--
drivers/video/fbdev/nvidia/nv_local.h | 13 ++++---------
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_accel.c b/drivers/video/fbdev/nvidia/nv_accel.c
index ad6472a..c21cb34 100644
--- a/drivers/video/fbdev/nvidia/nv_accel.c
+++ b/drivers/video/fbdev/nvidia/nv_accel.c
@@ -382,7 +382,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
for (j = RECT_EXPAND_TWO_COLOR_DATA_MAX_DWORDS; j--;) {
tmp = data[k++];
- reverse_order(&tmp);
+ tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
@@ -394,7 +394,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
for (j = dsize; j--;) {
tmp = data[k++];
- reverse_order(&tmp);
+ tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
}
diff --git a/drivers/video/fbdev/nvidia/nv_local.h b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..a0eb1f3 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,13 @@
#ifdef __LITTLE_ENDIAN
+#include <linux/swab.h>
#include <linux/bitrev.h>
-#define reverse_order(l) \
-do { \
- u8 *a = (u8 *)(l); \
- a[0] = bitrev8(a[0]); \
- a[1] = bitrev8(a[1]); \
- a[2] = bitrev8(a[2]); \
- a[3] = bitrev8(a[3]); \
-} while(0)
+#define reverse_order(v) swab32(bitrev32(v))
+
#else
-#define reverse_order(l) do { } while(0)
+#define reverse_order(v) (v)
#endif /* __LITTLE_ENDIAN */
#endif /* __NV_LOCAL_H__ */
--
1.9.1
^ permalink raw reply related
* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-08-19 8:11 UTC (permalink / raw)
To: Peter Teoh
Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha,
omap, linux-fbdev, LKML, Pavel Machek, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <CAHnt0GX6442mtZ=J6CS_60TyTeUu==oROcf4Y=upHGSr71X3EA@mail.gmail.com>
On Tuesday 18 August 2015 07:11:27 Peter Teoh wrote:
> On Fri, Jul 24, 2015 at 9:03 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > Hello,
> >
> > when on N900 (real HW or qemu) I run this command
> >
> > / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
> >
> > then kernel crash with this error message
> >
> > / # [ 29.904113] Division by zero in kernel.
> > ** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
> > (cfb_imageblit+0xac/0x464)
> > ** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> > ** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> >
> > I suspect that problem is in omapdss.
> >
> > I do not know if size 0 make sense, but Maemo userspace is calling above
> > commands and on Nokia's 2.6.28 kernel there is no crash or error message.
> >
> > IMHO Division by zero in kernel should not be there even if userspace
> > call "incorrect" command.
> >
> > --
> > Pali Rohár
> > pali.rohar@gmail.com
>
>
>
> Not sure if my analysis is correct. According to the recent pull
> (4.2.0-rc4+), the code is still vulnerable to this division by zero:
>
> Inside drivers/video/fbdev/core/cfbimgblt.c:
>
> void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
> {
> u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
> u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
> u32 width = image->width;
> u32 dx = image->dx, dy = image->dy;
> u8 __iomem *dst1;
>
> if (p->state != FBINFO_STATE_RUNNING)
> return;
>
> bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
> start_index = bitstart & (32 - 1);
> pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
>
> bitstart /= 8;
> bitstart &= ~(bpl - 1);
> dst1 = p->screen_base + bitstart;
>
> if (p->fbops->fb_sync)
> p->fbops->fb_sync(p);
>
> if (image->depth = 1) {
> if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
> p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
> fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
> bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
> } else {
> fgcolor = image->fg_color;
> bgcolor = image->bg_color;
> }
>
> if (32 % bpp = 0 && !start_index && !pitch_index &&
> ((width & (32/bpp-1)) = 0) &&
> bpp >= 8 && bpp <= 32)
> fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> else
> slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> start_index, pitch_index);
> } else
> color_imageblit(image, p, dst1, start_index, pitch_i
>
>
> Notice that bpp is not checked for zero, and thus bpp=0 is totally
> feasible? resulting in 32/bpp crashing the kernel?
>
Hm... this could really be a problem! But how to patch it? Which branch
should be called (fast_ or slow_ function) if bpp is zero?
And is there some way to force kernel to dump backtrace into dmesg when
division by zero occur?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH] staging: sm750fb: fix improper typedef usage
From: Brian Stottler @ 2015-08-19 2:27 UTC (permalink / raw)
To: linux-fbdev
Fix typedef usage which does not comply with kernel style guidelines.
Signed-off-by: Brian Stottler <brianstottler@gmail.com>
---
drivers/staging/sm750fb/ddk750_chip.c | 31 ++++++++++++++--------------
drivers/staging/sm750fb/ddk750_chip.h | 35 ++++++++++++++------------------
drivers/staging/sm750fb/ddk750_display.c | 2 +-
drivers/staging/sm750fb/ddk750_display.h | 12 +++++------
drivers/staging/sm750fb/ddk750_dvi.c | 12 +++++------
drivers/staging/sm750fb/ddk750_dvi.h | 4 ++--
drivers/staging/sm750fb/ddk750_mode.c | 10 +++++----
drivers/staging/sm750fb/ddk750_mode.h | 18 ++++++++--------
drivers/staging/sm750fb/ddk750_power.c | 2 +-
drivers/staging/sm750fb/ddk750_power.h | 7 +++----
drivers/staging/sm750fb/ddk750_sii164.c | 2 +-
drivers/staging/sm750fb/ddk750_sii164.h | 4 ++--
drivers/staging/sm750fb/sm750_hw.c | 8 ++++----
13 files changed, 69 insertions(+), 78 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index f4975d2..1297525 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -2,20 +2,19 @@
#include "ddk750_reg.h"
#include "ddk750_chip.h"
#include "ddk750_power.h"
-typedef struct _pllcalparam {
+struct pllcalparam {
unsigned char power;/* d : 0~ 6*/
unsigned char pod;
unsigned char od;
unsigned char value;/* value of 2 power d (2^d) */
-}
-pllcalparam;
+};
-logical_chip_type_t getChipType(void)
+enum logical_chip_type_t getChipType(void)
{
unsigned short physicalID;
char physicalRev;
- logical_chip_type_t chip;
+ enum logical_chip_type_t chip;
physicalID = devId750; /* either 0x718 or 0x750 */
physicalRev = revId750;
@@ -44,12 +43,12 @@ inline unsigned int twoToPowerOfx(unsigned long x)
return result;
}
-inline unsigned int calcPLL(pll_value_t *pPLL)
+inline unsigned int calcPLL(struct pll_value_t *pPLL)
{
return (pPLL->inputFreq * pPLL->M / pPLL->N / twoToPowerOfx(pPLL->OD) / twoToPowerOfx(pPLL->POD));
}
-unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL)
+unsigned int getPllValue(enum clock_type_t clockType, struct pll_value_t *pPLL)
{
unsigned int ulPllReg = 0;
@@ -85,7 +84,7 @@ unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL)
unsigned int getChipClock(void)
{
- pll_value_t pll;
+ struct pll_value_t pll;
#if 1
if (getChipType() = SM750LE)
return MHz(130);
@@ -102,7 +101,7 @@ unsigned int getChipClock(void)
*/
void setChipClock(unsigned int frequency)
{
- pll_value_t pll;
+ struct pll_value_t pll;
unsigned int ulActualMxClk;
#if 1
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
@@ -252,7 +251,7 @@ unsigned int ddk750_getVMSize(void)
}
-int ddk750_initHw(initchip_param_t *pInitParam)
+int ddk750_initHw(struct initchip_param_t *pInitParam)
{
unsigned int ulReg;
@@ -405,10 +404,10 @@ unsigned int absDiff(unsigned int a, unsigned int b)
M = {1,...,255}
N = {2,...,15}
*/
-unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
+unsigned int calcPllValue(unsigned int request_orig, struct pll_value_t *pll)
{
/* used for primary and secondary channel pixel clock pll */
- static pllcalparam xparm_PIXEL[] = {
+ static struct pllcalparam xparm_PIXEL[] = {
/* 2^0 = 1*/ {0, 0, 0, 1},
/* 2^ 1 =2*/ {1, 0, 1, 2},
/* 2^ 2 = 4*/ {2, 0, 2, 4},
@@ -419,7 +418,7 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
};
/* used for MXCLK (chip clock) */
- static pllcalparam xparm_MXCLK[] = {
+ static struct pllcalparam xparm_MXCLK[] = {
/* 2^0 = 1*/ {0, 0, 0, 1},
/* 2^ 1 =2*/ {1, 0, 1, 2},
/* 2^ 2 = 4*/ {2, 0, 2, 4},
@@ -433,7 +432,7 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
unsigned int RN, quo, rem, fl_quo;
unsigned int input, request;
unsigned int tmpClock, ret;
- pllcalparam *xparm;
+ struct pllcalparam *xparm;
#if 1
if (getChipType() = SM750LE) {
@@ -492,7 +491,7 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
unsigned int calcPllValue2(
unsigned int ulRequestClk, /* Required pixel clock in Hz unit */
-pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
+struct pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
)
{
unsigned int M, N, OD, POD = 0, diff, pllClk, odPower, podPower;
@@ -590,7 +589,7 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
-unsigned int formatPllReg(pll_value_t *pPLL)
+unsigned int formatPllReg(struct pll_value_t *pPLL)
{
unsigned int ulPllReg = 0;
diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h
index 4e030e8..495726f 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -8,29 +8,26 @@
#include <linux/io.h>
/* This is all the chips recognized by this library */
-typedef enum _logical_chip_type_t
+enum logical_chip_type_t
{
SM_UNKNOWN,
SM718,
SM750,
SM750LE,
-}
-logical_chip_type_t;
+};
-
-typedef enum _clock_type_t
+enum clock_type_t
{
MXCLK_PLL,
PRIMARY_PLL,
SECONDARY_PLL,
VGA0_PLL,
VGA1_PLL,
-}
-clock_type_t;
+};
-typedef struct _pll_value_t
+struct pll_value_t
{
- clock_type_t clockType;
+ enum clock_type_t clockType;
unsigned long inputFreq; /* Input clock frequency to the PLL */
/* Use this when clockType = PANEL_PLL */
@@ -38,11 +35,10 @@ typedef struct _pll_value_t
unsigned long N;
unsigned long OD;
unsigned long POD;
-}
-pll_value_t;
+};
/* input struct to initChipParam() function */
-typedef struct _initchip_param_t
+struct initchip_param_t
{
unsigned short powerMode; /* Use power mode 0 or 1 */
unsigned short chipClock; /**
@@ -71,18 +67,17 @@ typedef struct _initchip_param_t
*/
/* More initialization parameter can be added if needed */
-}
-initchip_param_t;
+};
-logical_chip_type_t getChipType(void);
-unsigned int calcPllValue(unsigned int request, pll_value_t *pll);
-unsigned int calcPllValue2(unsigned int, pll_value_t *);
-unsigned int formatPllReg(pll_value_t *pPLL);
+enum logical_chip_type_t getChipType(void);
+unsigned int calcPllValue(unsigned int request, struct pll_value_t *pll);
+unsigned int calcPllValue2(unsigned int, struct pll_value_t *);
+unsigned int formatPllReg(struct pll_value_t *pPLL);
void ddk750_set_mmio(void __iomem *, unsigned short, char);
unsigned int ddk750_getVMSize(void);
-int ddk750_initHw(initchip_param_t *);
-unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL);
+int ddk750_initHw(struct initchip_param_t *);
+unsigned int getPllValue(enum clock_type_t clockType, struct pll_value_t *pPLL);
unsigned int getChipClock(void);
void setChipClock(unsigned int);
void setMemoryClock(unsigned int frequency);
diff --git a/drivers/staging/sm750fb/ddk750_display.c b/drivers/staging/sm750fb/ddk750_display.c
index a3e6720..29dd62d 100644
--- a/drivers/staging/sm750fb/ddk750_display.c
+++ b/drivers/staging/sm750fb/ddk750_display.c
@@ -230,7 +230,7 @@ static void swPanelPowerSequence(int disp, int delay)
}
-void ddk750_setLogicalDispOut(disp_output_t output)
+void ddk750_setLogicalDispOut(enum disp_output_t output)
{
unsigned int reg;
if(output & PNL_2_USAGE){
diff --git a/drivers/staging/sm750fb/ddk750_display.h b/drivers/staging/sm750fb/ddk750_display.h
index ae0f84c..13b4d76 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -86,7 +86,7 @@
CRT means crt path DSUB
*/
#if 0
-typedef enum _disp_output_t
+enum disp_output_t
{
NO_DISPLAY = DPMS_OFF,
@@ -126,10 +126,9 @@ typedef enum _disp_output_t
CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
-}
-disp_output_t;
+};
#else
-typedef enum _disp_output_t{
+enum disp_output_t{
do_LCD1_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|DAC_ON,
do_LCD1_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|DAC_ON,
#if 0
@@ -150,11 +149,10 @@ typedef enum _disp_output_t{
do_CRT_PRI = CRT_2_PRI|PRI_TP_ON|DPMS_ON|DAC_ON,
do_CRT_SEC = CRT_2_SEC|SEC_TP_ON|DPMS_ON|DAC_ON,
#endif
-}
-disp_output_t;
+};
#endif
-void ddk750_setLogicalDispOut(disp_output_t);
+void ddk750_setLogicalDispOut(enum disp_output_t);
int ddk750_initDVIDisp(void);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index b2bf7e6..1a5da03 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -9,7 +9,7 @@
/* This global variable contains all the supported driver and its corresponding
function API. Please set the function pointer to NULL whenever the function
is not supported. */
-static dvi_ctrl_device_t g_dcftSupportedDviController[] +static struct dvi_ctrl_device_t g_dcftSupportedDviController[] {
#ifdef DVI_CTRL_SII164
{
@@ -43,7 +43,7 @@ int dviInit(
unsigned char pllFilterValue
)
{
- dvi_ctrl_device_t *pCurrentDviCtrl;
+ struct dvi_ctrl_device_t *pCurrentDviCtrl;
pCurrentDviCtrl = g_dcftSupportedDviController;
if(pCurrentDviCtrl->pfnInit != NULL)
{
@@ -64,10 +64,10 @@ int dviInit(
*/
unsigned short dviGetVendorID(void)
{
- dvi_ctrl_device_t *pCurrentDviCtrl;
+ struct dvi_ctrl_device_t *pCurrentDviCtrl;
pCurrentDviCtrl = g_dcftSupportedDviController;
- if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
+ if (pCurrentDviCtrl != (struct dvi_ctrl_device_t *)0)
return pCurrentDviCtrl->pfnGetVendorId();
return 0x0000;
@@ -83,10 +83,10 @@ unsigned short dviGetVendorID(void)
*/
unsigned short dviGetDeviceID(void)
{
- dvi_ctrl_device_t *pCurrentDviCtrl;
+ struct dvi_ctrl_device_t *pCurrentDviCtrl;
pCurrentDviCtrl = g_dcftSupportedDviController;
- if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
+ if (pCurrentDviCtrl != (struct dvi_ctrl_device_t *)0)
return pCurrentDviCtrl->pfnGetDeviceId();
return 0x0000;
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h b/drivers/staging/sm750fb/ddk750_dvi.h
index 83bbd6d..63d3195 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -26,7 +26,7 @@ typedef unsigned char (*PFN_DVICTRL_CHECKINTERRUPT)(void);
typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
/* Structure to hold all the function pointer to the DVI Controller. */
-typedef struct _dvi_ctrl_device_t
+struct dvi_ctrl_device_t
{
PFN_DVICTRL_INIT pfnInit;
PFN_DVICTRL_RESETCHIP pfnResetChip;
@@ -38,7 +38,7 @@ typedef struct _dvi_ctrl_device_t
PFN_DVICTRL_ISCONNECTED pfnIsConnected;
PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
-} dvi_ctrl_device_t;
+};
#define DVI_CTRL_SII164
diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
index 74313ff..43eb28f 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -13,7 +13,8 @@
HW only supports 7 predefined pixel clocks, and clock select is
in bit 29:27 of Display Control register.
*/
-static unsigned long displayControlAdjust_SM750LE(mode_parameter_t *pModeParam, unsigned long dispControl)
+static unsigned long displayControlAdjust_SM750LE(
+ struct mode_parameter_t *pModeParam, unsigned long dispControl)
{
unsigned long x, y;
@@ -75,7 +76,8 @@ static unsigned long displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
/* only timing related registers will be programed */
-static int programModeRegisters(mode_parameter_t *pModeParam, pll_value_t *pll)
+static int programModeRegisters(struct mode_parameter_t *pModeParam,
+ struct pll_value_t *pll)
{
int ret = 0;
int cnt = 0;
@@ -185,9 +187,9 @@ static int programModeRegisters(mode_parameter_t *pModeParam, pll_value_t *pll)
return ret;
}
-int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock)
+int ddk750_setModeTiming(struct mode_parameter_t *parm, enum clock_type_t clock)
{
- pll_value_t pll;
+ struct pll_value_t pll;
unsigned int uiActualPixelClk;
pll.inputFreq = DEFAULT_INPUT_CLOCK;
pll.clockType = clock;
diff --git a/drivers/staging/sm750fb/ddk750_mode.h b/drivers/staging/sm750fb/ddk750_mode.h
index 4e8fab3..97118cf 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -3,29 +3,28 @@
#include "ddk750_chip.h"
-typedef enum _spolarity_t
+enum spolarity_t
{
POS = 0, /* positive */
NEG, /* negative */
-}
-spolarity_t;
+};
-typedef struct _mode_parameter_t
+struct mode_parameter_t
{
/* Horizontal timing. */
unsigned long horizontal_total;
unsigned long horizontal_display_end;
unsigned long horizontal_sync_start;
unsigned long horizontal_sync_width;
- spolarity_t horizontal_sync_polarity;
+ enum spolarity_t horizontal_sync_polarity;
/* Vertical timing. */
unsigned long vertical_total;
unsigned long vertical_display_end;
unsigned long vertical_sync_start;
unsigned long vertical_sync_height;
- spolarity_t vertical_sync_polarity;
+ enum spolarity_t vertical_sync_polarity;
/* Refresh timing. */
unsigned long pixel_clock;
@@ -33,11 +32,10 @@ typedef struct _mode_parameter_t
unsigned long vertical_frequency;
/* Clock Phase. This clock phase only applies to Panel. */
- spolarity_t clock_phase_polarity;
-}
-mode_parameter_t;
+ enum spolarity_t clock_phase_polarity;
+};
-int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
+int ddk750_setModeTiming(struct mode_parameter_t *, enum clock_type_t);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index 1e5f398..9861f3e 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -2,7 +2,7 @@
#include "ddk750_reg.h"
#include "ddk750_power.h"
-void ddk750_setDPMS(DPMS_t state)
+void ddk750_setDPMS(enum DPMS_t state)
{
unsigned int value;
if(getChipType() = SM750LE){
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
index 4e00955..51668f3 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -1,14 +1,13 @@
#ifndef DDK750_POWER_H__
#define DDK750_POWER_H__
-typedef enum _DPMS_t
+enum DPMS_t
{
crtDPMS_ON = 0x0,
crtDPMS_STANDBY = 0x1,
crtDPMS_SUSPEND = 0x2,
crtDPMS_OFF = 0x3,
-}
-DPMS_t;
+};
#define setDAC(off) \
{ \
@@ -18,7 +17,7 @@ DPMS_t;
off)); \
}
-void ddk750_setDPMS(DPMS_t);
+void ddk750_setDPMS(enum DPMS_t);
unsigned int getPowerMode(void);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index b6395b8..2518b54 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -308,7 +308,7 @@ void sii164SetPower(
* This function selects the mode of the hot plug detection.
*/
static void sii164SelectHotPlugDetectionMode(
- sii164_hot_plug_mode_t hotPlugMode
+ enum sii164_hot_plug_mode_t hotPlugMode
)
{
unsigned char detectReg;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 2b4c7d3..6db0c1e 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -4,13 +4,13 @@
#define USE_DVICHIP
/* Hot Plug detection mode structure */
-typedef enum _sii164_hot_plug_mode_t
+enum sii164_hot_plug_mode_t
{
SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit (always high). */
SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
SII164_HOTPLUG_USE_RSEN, /* Use Receiver Sense detect bit. */
SII164_HOTPLUG_USE_HTPLG /* Use Hot Plug detect bit. */
-} sii164_hot_plug_mode_t;
+};
/* Silicon Image SiI164 chip prototype */
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 84381bc..71bf943 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -117,7 +117,7 @@ int hw_sm750_inithw(struct lynx_share *share, struct pci_dev *pdev)
if(parm->master_clk = 0)
parm->master_clk = parm->chip_clk/3;
- ddk750_initHw((initchip_param_t *)&spec_share->state.initParm);
+ ddk750_initHw((struct initchip_param_t *)&spec_share->state.initParm);
/* for sm718,open pci burst */
if(share->devid = 0x718){
POKE32(SYSTEM_CTRL,
@@ -220,7 +220,7 @@ int hw_sm750_output_setMode(struct lynxfb_output* output,
struct fb_var_screeninfo* var, struct fb_fix_screeninfo* fix)
{
int ret;
- disp_output_t dispSet;
+ enum disp_output_t dispSet;
int channel;
ret = 0;
@@ -298,8 +298,8 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc* crtc,
{
int ret, fmt;
u32 reg;
- mode_parameter_t modparm;
- clock_type_t clock;
+ struct mode_parameter_t modparm;
+ enum clock_type_t clock;
struct lynx_share *share;
struct lynxfb_par *par;
^ permalink raw reply related
* Re: omapdss: Division by zero in kernel
From: Peter Teoh @ 2015-08-18 14:11 UTC (permalink / raw)
To: Pali Rohár
Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha,
omap, linux-fbdev, LKML, Pavel Machek, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <201507241803.42891@pali>
On Fri, Jul 24, 2015 at 9:03 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
> Hello,
>
> when on N900 (real HW or qemu) I run this command
>
> / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
>
> then kernel crash with this error message
>
> / # [ 29.904113] Division by zero in kernel.
> ** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
> (cfb_imageblit+0xac/0x464)
> ** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> ** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
>
> I suspect that problem is in omapdss.
>
> I do not know if size 0 make sense, but Maemo userspace is calling above
> commands and on Nokia's 2.6.28 kernel there is no crash or error message.
>
> IMHO Division by zero in kernel should not be there even if userspace
> call "incorrect" command.
>
> --
> Pali Rohár
> pali.rohar@gmail.com
Not sure if my analysis is correct. According to the recent pull
(4.2.0-rc4+), the code is still vulnerable to this division by zero:
Inside drivers/video/fbdev/core/cfbimgblt.c:
void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
{
u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
u32 width = image->width;
u32 dx = image->dx, dy = image->dy;
u8 __iomem *dst1;
if (p->state != FBINFO_STATE_RUNNING)
return;
bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
start_index = bitstart & (32 - 1);
pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
bitstart /= 8;
bitstart &= ~(bpl - 1);
dst1 = p->screen_base + bitstart;
if (p->fbops->fb_sync)
p->fbops->fb_sync(p);
if (image->depth = 1) {
if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
} else {
fgcolor = image->fg_color;
bgcolor = image->bg_color;
}
if (32 % bpp = 0 && !start_index && !pitch_index &&
((width & (32/bpp-1)) = 0) &&
bpp >= 8 && bpp <= 32)
fast_imageblit(image, p, dst1, fgcolor, bgcolor);
else
slow_imageblit(image, p, dst1, fgcolor, bgcolor,
start_index, pitch_index);
} else
color_imageblit(image, p, dst1, start_index, pitch_i
Notice that bpp is not checked for zero, and thus bpp=0 is totally
feasible? resulting in 32/bpp crashing the kernel?
--
Regards,
Peter Teoh
^ permalink raw reply
* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-08-18 14:00 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <20150728115602.GL13765@pali>
On Tuesday 28 July 2015 13:56:02 Pali Rohár wrote:
> On Friday 24 July 2015 18:03:42 Pali Rohár wrote:
> > Hello,
> >
> > when on N900 (real HW or qemu) I run this command
> >
> > / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
> >
> > then kernel crash with this error message
> >
> > / # [ 29.904113] Division by zero in kernel.
> > ** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
> > (cfb_imageblit+0xac/0x464)
> > ** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> > ** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> > (fbcon_scroll+0x6a0/0xcbc)
> > ** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> >
> > I suspect that problem is in omapdss.
> >
> > I do not know if size 0 make sense, but Maemo userspace is calling above
> > commands and on Nokia's 2.6.28 kernel there is no crash or error message.
> >
> > IMHO Division by zero in kernel should not be there even if userspace
> > call "incorrect" command.
> >
>
> PING! Any idea what to do with Division by zero in kernel?
>
PING again! Can somebody look at this Division by zero in kernel?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH] video: fbdev: Use devm_clk_get
From: Vaishali Thakkar @ 2015-08-18 3:40 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen, linux-fbdev, linux-kernel
This patch introduces the use of managed resource function
devm_clk_get instead of clk_get and removes corresponding calls
to clk_put in the probe and remove functions.
To be compatible with the change various gotos are replaced with
direct returns, and unneeded label failed_put_clk is dropped.
Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
---
drivers/video/fbdev/pxa168fb.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index e209b03..efb57c0 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -615,7 +615,7 @@ static int pxa168fb_probe(struct platform_device *pdev)
return -EINVAL;
}
- clk = clk_get(&pdev->dev, "LCDCLK");
+ clk = devm_clk_get(&pdev->dev, "LCDCLK");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "unable to get LCDCLK");
return PTR_ERR(clk);
@@ -624,21 +624,18 @@ static int pxa168fb_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res = NULL) {
dev_err(&pdev->dev, "no IO memory defined\n");
- ret = -ENOENT;
- goto failed_put_clk;
+ return -ENOENT;
}
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "no IRQ defined\n");
- ret = -ENOENT;
- goto failed_put_clk;
+ return -ENOENT;
}
info = framebuffer_alloc(sizeof(struct pxa168fb_info), &pdev->dev);
if (info = NULL) {
- ret = -ENOMEM;
- goto failed_put_clk;
+ return -ENOMEM;
}
/* Initialize private data */
@@ -776,8 +773,6 @@ failed_free_fbmem:
info->screen_base, fbi->fb_start_dma);
failed_free_info:
kfree(info);
-failed_put_clk:
- clk_put(clk);
dev_err(&pdev->dev, "frame buffer device init failed with %d\n", ret);
return ret;
@@ -813,7 +808,6 @@ static int pxa168fb_remove(struct platform_device *pdev)
info->screen_base, info->fix.smem_start);
clk_disable(fbi->clk);
- clk_put(fbi->clk);
framebuffer_release(info);
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox