[PATCH] include: platform_device: add pdev_info(), pdev_warn, ... convencience macros

--- include/linux/platform_device.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 98c2a7c7108e..723c209d3760 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -368,4 +368,11 @@

[PATCH] include: platform_device: add pdev_info(), pdev_warn, ... convencience macros

--- include/linux/platform_device.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 98c2a7c7108e..723c209d3760 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -368,4 +368,11 @@

Re: [RFC 0/5] drivers: Add boot constraints core

On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering

Re: [RFC 0/5] drivers: Add boot constraints core

On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering

Re: [RFC 0/5] drivers: Add boot constraints core

On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very

Re: [RFC 0/5] drivers: Add boot constraints core

On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very

Re: [RFC 0/5] drivers: Add boot constraints core

On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just

Re: [RFC 0/5] drivers: Add boot constraints core

On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just

Best practise for a polling device driver ?

Hi folks, I'm currently writing a driver for an (pseudo-)serial device (actually, a bunch of HW fifo's, which look like serial controllers to the host), which only supports polling, no interrupts. So far, I'm just using a kthread in a loop, but that would have to run w/ high priority sleep very

Best practise for a polling device driver ?

Hi folks, I'm currently writing a driver for an (pseudo-)serial device (actually, a bunch of HW fifo's, which look like serial controllers to the host), which only supports polling, no interrupts. So far, I'm just using a kthread in a loop, but that would have to run w/ high priority sleep very

Re: Directly accessing serial ports from drivers w/o TTYs ?

On 26.06.2017 14:51, Alan Cox wrote: Hi, You can write your own driver for the physical hardware and claim it in your driver. Shouldn't normally be needed except for bizarre cases when a serial link is used for something very non tty like (eg as GPIO lines). In my case, it's not really a

Re: Directly accessing serial ports from drivers w/o TTYs ?

On 26.06.2017 14:51, Alan Cox wrote: Hi, You can write your own driver for the physical hardware and claim it in your driver. Shouldn't normally be needed except for bizarre cases when a serial link is used for something very non tty like (eg as GPIO lines). In my case, it's not really a

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 26.06.2017 00:47, Randy Dunlap wrote: > but why not just do that in userspace. Patch up syslogd (which one, actually?) to decode all the dozens of different cases that print out errno values ? Applying your argument more consequently - why do we have human-readable messages at all, instead

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 26.06.2017 00:47, Randy Dunlap wrote: > but why not just do that in userspace. Patch up syslogd (which one, actually?) to decode all the dozens of different cases that print out errno values ? Applying your argument more consequently - why do we have human-readable messages at all, instead

Directly accessing serial ports from drivers w/o TTYs ?

Hi folks, is there already a way for accessing serial ports from drivers, w/o having to go through the TTY subsystem ? Serdev seems provide a connection between arbitrary TTYs to device drivers. But this implies always having a TTY for each UART (even if it's never used outside the kernel). Is

Directly accessing serial ports from drivers w/o TTYs ?

Hi folks, is there already a way for accessing serial ports from drivers, w/o having to go through the TTY subsystem ? Serdev seems provide a connection between arbitrary TTYs to device drivers. But this implies always having a TTY for each UART (even if it's never used outside the kernel). Is

RFC: abstraction for RPC'ish hardware drivers ? mailbox ? netif ?

Hi folks, I'm currently implementing drivers for an industrial backplane, (*1) which uses some kind of rpc / command-response mechanism. There're different variants, eg. some proprietary serial interface, USB link, pci cards, etc. On top of that there's a block-based command- response mechanism

RFC: abstraction for RPC'ish hardware drivers ? mailbox ? netif ?

Hi folks, I'm currently implementing drivers for an industrial backplane, (*1) which uses some kind of rpc / command-response mechanism. There're different variants, eg. some proprietary serial interface, USB link, pci cards, etc. On top of that there's a block-based command- response mechanism

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 25.06.2017 22:10, Joe Perches wrote: >> Yeah, that's still an open problem. Actually, I still haven't found out, >> how it's done w/ all the other kernel-internal conversions. > > Everything else uses "%p", hmm, but errno's aren't pointers. Isn't %p checked for pointer values ? >> Already

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 25.06.2017 22:10, Joe Perches wrote: >> Yeah, that's still an open problem. Actually, I still haven't found out, >> how it's done w/ all the other kernel-internal conversions. > > Everything else uses "%p", hmm, but errno's aren't pointers. Isn't %p checked for pointer values ? >> Already

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 25.06.2017 19:27, Joe Perches wrote: > Every use of %M is going to cause gcc when using __printf to emit > a warning like: > > unknown conversion type character ‘M’ in format [-Wformat=] Yeah, that's still an open problem. Actually, I still haven't found out, how it's done w/ all the other

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

On 25.06.2017 19:27, Joe Perches wrote: > Every use of %M is going to cause gcc when using __printf to emit > a warning like: > > unknown conversion type character ‘M’ in format [-Wformat=] Yeah, that's still an open problem. Actually, I still haven't found out, how it's done w/ all the other

[PATCH] lib: vsprintf: add printf format conversion %M for errno strings

Adding a new format conversion for *printf() and friends. If CONFIG_ERRNO_PRINTF_VERBOSE is enabled, prints human-readable strerror()-like texts, otherwise just the number. --- lib/Kconfig| 19 +++ lib/vsprintf.c | 172 - 2 files

[PATCH] lib: vsprintf: add printf format conversion %M for errno strings

Adding a new format conversion for *printf() and friends. If CONFIG_ERRNO_PRINTF_VERBOSE is enabled, prints human-readable strerror()-like texts, otherwise just the number. --- lib/Kconfig| 19 +++ lib/vsprintf.c | 172 - 2 files

printk + errno texts

Hi folks, I'd like to introduce a new printk() conversion which prints out errno values as readable text. Where are these things defined ? I'd guess the actual translation must be somewhere in lib/vsprintf.c, but where are the format string checks defined ? thx --mtx

printk + errno texts

Hi folks, I'd like to introduce a new printk() conversion which prints out errno values as readable text. Where are these things defined ? I'd guess the actual translation must be somewhere in lib/vsprintf.c, but where are the format string checks defined ? thx --mtx

Re: [GIT PULL] remoteproc for 4.2

) --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 -- https://www.facebook.com/MELAG.Medizintechnik [http://www.melag.de/fbbanner.png]<https://www.facebook.com/MELAG.Medizintechnik> MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger H

Re: [GIT PULL] remoteproc for 4.2

) --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 -- https://www.facebook.com/MELAG.Medizintechnik [http://www.melag.de/fbbanner.png]https://www.facebook.com/MELAG.Medizintechnik MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis

Re: Uses of Linux backports in the industry

wireless-testing) and stabilize that by cherry-picking individual patches on top of it. Can you estimate the required workforce ? Some statistics on that would be really nice. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG

Re: Uses of Linux backports in the industry

having no GPU, therefore no GL/GSL, therefore no QtQuick/QML. Pavel already mentioned the correct way to go: chip vendors should provide proper (mainline'able) patches, or at least full specs. And I'll add: those who dont, should simply be boycotted. cu -- Enrico Weigelt, metux IT consult +49-151-2

Re: Uses of Linux backports in the industry

Am 29.05.2015 um 19:36 schrieb Theodore Ts'o: > Yes, it's ugly, but there still are some SOC and drivers that aren't available on newer kernels. Why so, exactly ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenb

Re: Uses of Linux backports in the industry

Am 29.05.2015 um 17:01 schrieb Richard Weinberger: Hi, On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult wrote: Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. Enterprise distribution

Re: Uses of Linux backports in the industry

Am 29.05.2015 um 19:36 schrieb Theodore Ts'o: Yes, it's ugly, but there still are some SOC and drivers that aren't available on newer kernels. Why so, exactly ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg

Re: Uses of Linux backports in the industry

Am 29.05.2015 um 17:01 schrieb Richard Weinberger: Hi, On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult weig...@melag.de wrote: Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Actually, I really wonder why folks are sticking to ancient kernels on newer hardware

Re: Uses of Linux backports in the industry

wireless-testing) and stabilize that by cherry-picking individual patches on top of it. Can you estimate the required workforce ? Some statistics on that would be really nice. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG

Re: Uses of Linux backports in the industry

, therefore no GL/GSL, therefore no QtQuick/QML. Pavel already mentioned the correct way to go: chip vendors should provide proper (mainline'able) patches, or at least full specs. And I'll add: those who dont, should simply be boycotted. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG

Re: [PATCH 00/21] On-demand device registration

lel. Unfortunately, I've missed that ... could you please resend you patches? Boot time reduction is one of the topics on my 2do in several weeks. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinw

Re: [PATCH 00/21] On-demand device registration

. Unfortunately, I've missed that ... could you please resend you patches? Boot time reduction is one of the topics on my 2do in several weeks. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis

Re: Device Tree Blob (DTB) licence

sition here. This is just a dumb auto-generated footer, coming from my client's mail server over here ... I'm just too lazy for setting up an own MTA on my workstation. You can safely ignore that. -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Regist

Re: Uses of Linux backports in the industry

hacks (eg. Freescale is one of the worst). So I'll have to forward-port drivers to newer kernels - but I never had the practical need to backport one. Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287

Re: Device Tree Blob (DTB) licence

cide what's acceptable to you. We all do that. Yes, and I made the decision, that I can't tolerate any proprietary code - not on mission critical embedded systems. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlotte

Re: Device Tree Blob (DTB) licence

the decision, that I can't tolerate any proprietary code - not on mission critical embedded systems. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für

Re: Uses of Linux backports in the industry

kernel hacks (eg. Freescale is one of the worst). So I'll have to forward-port drivers to newer kernels - but I never had the practical need to backport one. Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. --mtx -- Enrico Weigelt, metux IT consult +49-151

Re: Device Tree Blob (DTB) licence

workstation. You can safely ignore that. -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte

Re: Device Tree Blob (DTB) licence

ed proprietary stuff, not at this critical point. Even for larger systems - except the crippled x86 world - I won't even allow any proprietary bootloader/firmware. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA

Re: imx53 IPU support on 4.0.4

ent ipuv3 patches, but still have lots of others (about 30) for my tqma53-based board, which might be generic enough for going into mainline someday (many of them by ptx folks). Should I post them to lkml or somewhere else ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 ME

Re: imx53 IPU support on 4.0.4

weeks ago (IIRC, on rc1) - I'm currently rebasing everything again to the recent master. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen

Re: Device Tree Blob (DTB) licence

Am 25.05.2015 um 09:14 schrieb Rob Landley: Personally, I'm sad we're starting to get ACPI for arm but if device tree data files are only available under GPL, people will hold their nose and deploy ACPI. What's the big deal with having DTS/DTB under GPL ? cu -- Enrico Weigelt, metux

Re: Device Tree Blob (DTB) licence

an just $0 price) And there shouldn't be any proprietary firmware anyways. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzt

Re: Device Tree Blob (DTB) licence

Am 25.05.2015 um 09:14 schrieb Rob Landley: Personally, I'm sad we're starting to get ACPI for arm but if device tree data files are only available under GPL, people will hold their nose and deploy ACPI. What's the big deal with having DTS/DTB under GPL ? cu -- Enrico Weigelt, metux

Re: Device Tree Blob (DTB) licence

) And there shouldn't be any proprietary firmware anyways. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis

Re: imx53 IPU support on 4.0.4

ipuv3 patches, but still have lots of others (about 30) for my tqma53-based board, which might be generic enough for going into mainline someday (many of them by ptx folks). Should I post them to lkml or somewhere else ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik

Re: imx53 IPU support on 4.0.4

weeks ago (IIRC, on rc1) - I'm currently rebasing everything again to the recent master. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen

Re: Device Tree Blob (DTB) licence

, not at this critical point. Even for larger systems - except the crippled x86 world - I won't even allow any proprietary bootloader/firmware. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis

Re: [PATCH RESEND v3 2/2] ALSA: replace CONFIG_PROC_FS with CONFIG_SND_PROC_FS

, both patches should be squashed into one, IMHO. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte

Re: [PATCH RESEND v3 2/2] ALSA: replace CONFIG_PROC_FS with CONFIG_SND_PROC_FS

, both patches should be squashed into one, IMHO. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte

imx53 IPU support on 4.0.4

Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult

imx53 IPU support on 4.0.4

Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult

Re: [PATCH 1/2] rtc: mxc: add a second clock

, -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für

Re: [PATCH 1/2] rtc: mxc: add a second clock

, -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für

Re: boot loader

Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG

Re: boot loader

Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG

Re: boot loader

- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur

Re: boot loader

- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur

Re: [RFC] How implement Secure Data Path ?

exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis

Re: [RFC] How implement Secure Data Path ?

exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis

<    5   6   7   8   9   10