* [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
* [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
* 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
* 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] 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: 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] 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: 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] 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 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 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] 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 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: [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: [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: 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: [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: [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 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 RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-08-21 1:46 UTC (permalink / raw)
To: Tomi Valkeinen, Jingoo Han
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <55D59AE2.7090201@ti.com>
On 20.08.2015 18:16, Tomi Valkeinen wrote:
>
>
> 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.
Could you? It would be great.
Kukjin did not pick it up so it is still waiting for some attention. :)
Best regards,
Krzysztof
^ permalink raw reply
* [RFC V2] fbdev/nvidia:change reverse_order() macro
From: yalin wang @ 2015-08-21 3:36 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_local.h | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_local.h b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..2c6baa1 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,19 @@
#ifdef __LITTLE_ENDIAN
+#include <linux/swab.h>
#include <linux/bitrev.h>
+static inline void reverse_order(u32 *data)
+{
+ *data = swab32(bitrev32(*data));
+}
-#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)
#else
-#define reverse_order(l) do { } while(0)
-#endif /* __LITTLE_ENDIAN */
+static inline void reverse_order(u32 *data)
+{
+
+}
+
+#endif /* __LITTLE_ENDIAN */
#endif /* __NV_LOCAL_H__ */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Tomi Valkeinen @ 2015-08-21 5:57 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: <55D682F3.5090800@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On 21/08/15 04:46, Krzysztof Kozlowski wrote:
> On 20.08.2015 18:16, Tomi Valkeinen wrote:
>>
>>
>> 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.
>
> Could you? It would be great.
> Kukjin did not pick it up so it is still waiting for some attention. :)
Ok. I've queued this for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [RFC V2] fbdev/riva:change to use generice function to implement reverse_order()
From: yalin wang @ 2015-08-21 5:59 UTC (permalink / raw)
To: adaplas, plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: yalin wang
This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/video/fbdev/riva/fbdev.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..ccf0f82 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>
@@ -453,11 +454,7 @@ static inline unsigned char MISCin(struct riva_par *par)
static inline void reverse_order(u32 *l)
{
- u8 *a = (u8 *)l;
- a[0] = bitrev8(a[0]);
- a[1] = bitrev8(a[1]);
- a[2] = bitrev8(a[2]);
- a[3] = bitrev8(a[3]);
+ *l = swab32(bitrev32(*l));
}
/* ------------------------------------------------------------------------- *
--
1.9.1
^ permalink raw reply related
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Tomi Valkeinen @ 2015-08-21 6:41 UTC (permalink / raw)
To: yalin wang; +Cc: adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <867D66CD-9A3B-4536-B537-8C065C85E497@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 20/08/15 14:30, yalin wang wrote:
>
>> 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:
Ok. So is any arm64 platform actually using these devices? If these
devices are mostly used by 32bit x86 platforms, optimizing them for
arm64 doesn't make any sense.
Possibly the patches are still good for x86 also, but that needs to be
proven.
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-21 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55D63391.3080403@tul.cz>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On 20/08/15 23:07, Petr Cvek wrote:
> 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.
No, configuration or kernel docs is not the right place for this. The
user is not going to see that. And a single kernel image is supposed to
run on different soc/board versions, so you can't do selections like
this in the kernel config.
The driver should detect the bad revision, and then apply the
workaround, or if that's not possible, refuse the use of the
configuration that leads to the HW bug. Or if even that's not possible,
the driver should print a warning when starting, so that the user is
able to see it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
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