[PATCH] drivers: ntb: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/ntb/Kconfig | 20 ++-- drivers/ntb/hw/amd/Kconfig | 4 ++-- drivers/ntb/hw/idt/Kconfig | 41 - drivers/ntb/hw/intel/Kconfig | 4 ++-- drivers/ntb/hw/mscc/Kconfig

[PATCH] drivers: infiniband: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/infiniband/hw/bnxt_re/Kconfig | 10 +- drivers/infiniband/ulp/iser/Kconfig | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/infiniband/hw/bnxt_re/Kconfig b/drivers/infiniband/hw/bnxt_re

[PATCH] drivers: pcmcia: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/pcmcia/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig index fab92ba..1fc7ded 100644 --- a/drivers/pcmcia/Kconfig +++ b/drivers/pcmcia

[PATCH] drivers: input: Kconfig: pedantic claenups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/input/misc/Kconfig| 26 +- drivers/input/mouse/Kconfig | 26 +- drivers/input/serio/Kconfig | 2 +- drivers/input/tablet/Kconfig | 20

[PATCH] arch: um: drivers: Kconfig: formatting cleanup

Signed-off-by: Enrico Weigelt, metux IT consult --- arch/um/drivers/Kconfig | 352 1 file changed, 176 insertions(+), 176 deletions(-) diff --git a/arch/um/drivers/Kconfig b/arch/um/drivers/Kconfig index 2b1aaf7..2638e46 100644 --- a/arch/um

[PATCH] drivers: nvme: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/nvme/host/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig index 0f345e2..ce361c9 100644 --- a/drivers/nvme/host/Kconfig +++ b/drivers/nvme/host

[PATCH] drivers: fpga: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/fpga/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 0bb7b5c..d6562df 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -25,9 +25,9

[PATCH] sound: soc: qcom: Kconfig: formatting cleanup

Signed-off-by: Enrico Weigelt, metux IT consult --- sound/soc/qcom/Kconfig | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 804ae0d..a748ad0 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc

[PATCH] arch: um: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- arch/um/Kconfig | 52 ++-- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/arch/um/Kconfig b/arch/um/Kconfig index ec9711d..216ee50 100644 --- a/arch/um/Kconfig +++ b/arch/um

[PATCH] drivers: mmc: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/mmc/host/Kconfig | 43 ++- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 28fcd8f..de7a38d 100644 --- a/drivers/mmc/host

[PATCH] fs: cifs: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- fs/cifs/Kconfig | 120 1 file changed, 60 insertions(+), 60 deletions(-) diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig index f1ddc9d..76724ef 100644 --- a/fs/cifs/Kconfig +++ b/fs/cifs

[PATCH] drivers: ata: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/ata/Kconfig | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 8218db1..ae72350 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -32,7

[PATCH] drivers: leds: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/leds/Kconfig | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index a72f97f..2b5ae50 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -56,7

[PATCH] drivers: uio: Kconfig: pedantic cleanups

--- drivers/uio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 7e8dc78..4286b73 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -17,7 +17,7 @@ config UIO_CIF depends on PCI help Dri

[PATCH] scripts: helper for mailing patches from git to the maintainers

: ./scripts/git-send-patch HEAD^ ./scripts/git-send-patch linus/master --dry-run Signed-off-by: Enrico Weigelt, metux IT consult --- scripts/git-send-patch | 63 ++ 1 file changed, 63 insertions(+) create mode 100755 scripts/git-send-patch diff

[PATCH] fs: 9p: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- fs/9p/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/fs/9p/Kconfig b/fs/9p/Kconfig index 11045d8..e416057 100644 --- a/fs/9p/Kconfig +++ b/fs/9p/Kconfig @@ -31,13 +31,13 @@ endif config

[PATCH] fs: binfmt: mark aout as broken

difficult. Therefore, markt it BROKEN right now, sit back and just wait for somebody complaining :p Signed-off-by: Enrico Weigelt, metux IT consult --- fs/Kconfig.binfmt | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt index b795f8d..05074f4 100644 --- a/fs/Kcon

Re: [PATCH] x86: Deprecate a.out support

In fact, I'd be happy to deprecate a.out entirely, but if somebody > _does_ complain, I'd like to be able to bring it back without the core > dumping. Maybe make it depend on BROKEN ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH] drivers: watchdog: Kconfig: pedantic cleanups

Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/watchdog/Kconfig | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 57f017d..38509d5 100644 --- a/drivers/watchdog/Kconfig +++ b

[PATCH] drivers: input: keyboard: Kconfig: formatting cleanup

Formatting of Kconfig files doesn't look so pretty, so just take damp cloth and clean it up. Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/input/keyboard/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/input/keyboard/Kcon

[PATCH] drivers: iio: Kconfig: pedantic cleanup

Formatting of Kconfig files doesn't look so pretty, so just take damp cloth and clean it up. Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/iio/Kconfig | 24 +-- drivers/iio/accel/Kconfig | 48 +++--- drivers/iio/adc/Kconfig

Re: [PATCH 2/3] x86: apuv2: fix input dependencies

n a small tool that allows easy kernel reconfiguration on a higher level: you can just pick some board templates and enable high level features like eth, gpu, etc - it automatically creates a .config for you. I'm going announce it on lkml soon. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

guidelines on creating defconfigs

r at least some consensus on what shall be included in a defconfig. thx --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH] drivers: gpio: Kconfig: pedantic formatting cleanups

Align the Kconfig formatting with the vast majority of the Kconfig files, to make it a bit easier / more pleasant to read ;-) Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/gpio/Kconfig | 50 +- 1 file changed, 25 insertions(+), 25

[PATCH] drivers: x86: pcengines-apuv2: fix dependencies

...@infradead.org Reported-by: kbuild test robot Reported-by: a...@arndb.de Reported-by: rdun...@infradead.org Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/platform/x86/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86

Re: [PATCH 2/3] x86: apuv2: fix input dependencies

'. Otherwise the driver won't appear at all if INPUT or INPUT_KEYBOARD aren't enabled (eg. when you start w/ minimal config - which I do frequently), and people have a hard time actually finding/enabling it. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: [PATCH 1/3] x86: apuv2: remove unused variable

; @@ -208,7 +208,6 @@ static struct platform_device * __init apu_create_pdev( > > static int __init apu_board_init(void) > { > - int rc; > const struct dmi_system_id *id; > > id = dmi_first_match(apu_gpio_dmi_table); > ACK. Reviewed-By: Enrico Weigelt,

Re: [PATCH 3/3] x86: apuv2: select LEDS_CLASS

@@ config PCENGINES_APU2 > depends on INPUT && INPUT_KEYBOARD > select GPIO_AMD_FCH > select KEYBOARD_GPIO_POLLED > + select LEDS_CLASS > select LEDS_GPIO > help > This driver provides support for the front button and LEDs on >

APUv2/v3 board support v4

Hi folks, this is version 4 of my APUv2/APUv3 series. changes in v4: * fixed spinlocks (using own field instead of gc.bgpio_lock) * dropped superflous dependency on GPIO_GENERIC * initialize gc.base = -1 * added Reviewed-By tags changes in v3: * gpio driver * drop unncessary gpio id c

[PATCH v4 1/2] gpio: AMD G-Series PCH gpio driver

und on x86. Cc: linux-g...@vger.kernel.org Cc: linus.wall...@linaro.org Cc: bgolaszew...@baylibre.com Cc: dvh...@infradead.org Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Enrico Weigelt, metux IT consult -

[PATCH v4 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS| 5 + drivers/platform/x86/Kconfig | 12 ++ drivers/platform/x86/Makefile | 1 + drivers/platfor

[PATCH v3 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS| 5 + drivers/platform/x86/Kconfig | 12 ++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/pcengines-apuv2.c

APUv2/v3 board support V3

Hi folks, this is version 3 of my APUv2/APUv3 series. change in V3: * gpio driver * drop unncessary gpio id checks * cleanup amd_fch_gpio_set() * move iores outside probe() * shorter NULL checks and correct error in probe() * apu board driver * drop unneeded init.h * drop un

[PATCH v3 1/2] gpio: AMD G-Series PCH gpio driver

und on x86. Cc: linux-g...@vger.kernel.org Cc: linus.wall...@linaro.org Cc: bgolaszew...@baylibre.com Cc: dvh...@infradead.org Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS | 7

Re: APUv2/v3 board support V2

On 14.02.19 13:33, Andy Shevchenko wrote: > It's there from several releases. But it's not a send-email option, > it's format-patch one. > send-email passes those commands to format-patch. oh, wasn't aware of that. thx. --mtx -- Enrico Weigelt, metux IT co

Re: APUv2/v3 board support V2

il doesn't seem to have a corresponding flag :( --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: [PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

nd "gpio-keys-polled" in my case. I've just got one instance of each right now and used PLATFORM_DEVID_NONE. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

the board specific register assignments. >> +struct amd_fch_gpio_pdata { >> +struct resource res; >> +int gpio_num; >> +struct amd_fch_gpio_reg *gpio_reg; >> +int gpio_base; >> +}; > > Drop gpio_base. We don't hardcode the GPIO base anymore. Done. I had to patch gpio-keys-polled driver first. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

thing. Can't speak about standard ICs/SoCs, but i've seen such things in some of my client's fpga designs. For example incomplete decoders, gpios attached to internal state machines, etc, etc So, I've learned to be *very* cautious with undocumented registers. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH 2/2] input: keyboard: gpio_keys_polled: use gpio lookup table

Support the recently introduced gpio lookup tables for attaching to gpio lines. So, harcoded gpio numbers aren't needed anymore. Cc: Dmitry Torokhov Cc: linux-in...@vger.kernel.org Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/input/keyboard/gpio_keys_polled.c

gpio-keys-polled enhancements v2

Hi folks, here's v2 of my gpio-keys-polled enhancements queue. I'm using this to allow it to be initialized by some other platform driver (in my case for the APUv2 board), when no proper fw data (oftree or acpi) is available. --mtx -- Enrico Weigelt, metux IT consult Free software

[PATCH 1/2] input: keyboard: gpio-keys-polled: use input name from pdata if available

Instead of hardcoding the input name to the driver name ('gpio-keys-polled'), allow the passing a name via platform data ('name' field was already present), but default to old behaviour in case of NULL. Cc: Dmitry Torokhov Cc: linux-in...@vger.kernel.org Signed-off-by: Enri

Re: [PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available

etc. The driver then would be probed via PCI, declare it's own bus and probe the individual devices by it's own of subtree. Well, that's gonna take a lot more discussions ... --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH 1/2] gpio: AMD G-Series PCH gpio driver

und on x86. Cc: linux-g...@vger.kernel.org Cc: linus.wall...@linaro.org Cc: bgolaszew...@baylibre.com Cc: dvh...@infradead.org Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS | 7

APUv2/v3 board support V2

vice of some toplevel PCH device ? (which then could also maintain the base address, etc) Note: the keyboard device needs separate patch for gpiod_lookup_table support in gpio-keys-polled driver. I'll sent it separately. --mtx -- Enrico Weigelt, metux IT consult Free software an

[PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

Cc: a...@infradead.org Cc: platform-driver-...@vger.kernel.org Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS| 5 + drivers/platform/x86/Kconfig | 13 ++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/pcengines-apuv2.c

Re: [PATCH] checkpatch: Add test for SPDX-License-Identifier on wrong line #

On 08.02.19 21:44, Joe Perches wrote: > Warn when any SPDX-License-Identifier: tag is not created > on the proper line number. By the way: there are corner cases, which can't have it at the first line, eg. scripts. --mtx -- Enrico Weigelt, metux IT consult Free software and Lin

debian packaging refinements

Hi folks, here're some small patches for making mkdebian a bit more flexible, so it can be used eg. with an given debian/rules file. I'm using this along w/ local (adding debian/rules and .config) in order to build the kernel via usual debian toolchains (git-buildpackage, git-buildpackage, ...) i

[PATCH 3/3] scripts: mkdebian: fix dependencies

We missed some build dependencies in the generated debian/control file. Signed-off-by: Enrico Weigelt, metux IT consult --- scripts/package/mkdebian | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian index ff226be..1caaf0b

[PATCH 2/3] scripts: mkdebian: allow renaming generated debian/rules

Add new environment variable KDEB_RULES for controlling where the generated debian rules are written to. By defaults, it's debian/rules, but packagers might override it for providing their own rules file. Signed-off-by: Enrico Weigelt, metux IT consult --- scripts/package/mkdebian | 5 +++

[PATCH 1/3] Makefile: add kernelarch target for printing arch and localversion

trivial rule to print out the kernel arch and localversion, so external tools, like distro packagers, can easily get it. Signed-off-by: Enrico Weigelt, metux IT consult --- Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 86cf35d..68c3e08 100644 --- a

[PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available

Instead of hardcoding the input name to the driver name ('gpio-keys-polled'), allow the passing a name via platform data ('name' field was already present), but default to old behaviour in case of NULL. Signed-off-by: Enrico Weigelt, metux IT consult --- dr

Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

ally linear (or maybe the pin naming is just weird) What I really don't want is undocumented registers or lines being exposed as gpio somewhere (not knowing what they actually do). Therefore, I'd like to add only those gpio registers that I can confirm being safe - at least until I've m

Re: [PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

_id (the leds-gpio instance ?) and the gpio chip. In the example, these seem to be autogenerated - how can I retrieve them from my actual devices ? By the way: does that also work with gpio-keys-polled ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

ct amd_fch_gpio_reg - GPIO register definition >> + * @reg: register index >> + * @name: signal name >> + */ >> +struct amd_fch_gpio_reg { >> +int reg; >> +const char* name; >> +}; > > Isn't this provided by GPIO library? We have so called labels. hmm, haven't found a proper struct yet. struct gpio indeed has a label and two int fields. but it doesn't seem to be designed for holding register addresses ... using this one here feels quite abusive. (and a waste of memory, too). for consistency, I could rename 'name' to 'label', if you wish. thanks for your review. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

From: "Enrico Weigelt, metux IT consult" GPIO platform driver for the AMD G-series PCH (eg. on GX-412TC) This driver doesn't registers itself automatically, as it needs to be provided with platform specific configuration, provided by some board driver setup code. Didn

[PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

From: "Enrico Weigelt, metux IT consult" Driver for PCengines APUv2 board that supports GPIOs via AMD PCH and attached LEDs and keys. Cc: linux-g...@vger.kernel.org Cc: linus.wall...@linaro.org Cc: bgolaszew...@baylibre.com Cc: dvh...@infradead.org Cc: a...@infradead.org Cc: platf

[PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

on x86. Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS| 7 + drivers/gpio/Kconfig | 10 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-amd-fch.c

[PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys platform driver

Driver for PCengines APUv2 board that supports GPIOs via AMD PCH and attached LEDs and keys. Signed-off-by: Enrico Weigelt, metux IT consult --- MAINTAINERS| 5 + drivers/platform/x86/Kconfig | 9 ++ drivers/platform/x86/Makefile | 1

[PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available

Instead of hardcoding the input name to the driver name ('gpio-keys-polled'), allow the passing a name via platform data ('name' field was already present), but default to old behaviour in case of NULL. Signed-off-by: Enrico Weigelt, metux IT consult --- dr

RFC: refactoring the deb build

Hello folks, here are some patches for build process that allow building debian packages right the usual canonical way (eg. via dpkg-buildpackage or dck-buildpackage), instead 'manually' setting up the build environment and calling make. So, from a debian native perspective, turning it from head

[PATCH 1/4] Makefile: add kernelarch rule that prints the kernel architecture and localversion

trivial rule to print out the kernel arch and localversion, so external tools, like distro packagers, can easily get it. Signed-off-by: Enrico Weigelt, metux IT consult --- Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 3142e67..2719907 100644 --- a

[PATCH 2/4] scripts: mkdebian: allow renaming generated debian/rules

Add new environment variable KDEB_RULES for controlling where the generated debian rules are written to. By defaults, it's debian/rules, but packagers might override it for providing their own rules file. Signed-off-by: Enrico Weigelt, metux IT consult --- scripts/package/mkdebian | 5 +++

[PATCH 3/4] scripts: mkdebian: fix dependencies

We missed some build dependencies in the generated debian/control file. Signed-off-by: Enrico Weigelt, metux IT consult --- scripts/package/mkdebian | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian index ff226be..1caaf0b

[PATCH 4/4] debian: add generic rule file

Adding a generic debian rule file, so we can build the directly via usual Debian package build tools (eg. git-buildpackage, dck-buildpackage, etc). It expects the .config file already placed in the source tree. The rule file contains a rule for creating debian/control and other metadata - this is

Re: GRSec is vital to Linux security

On 23.01.19 21:46, Ivan Ivanov wrote: > Linux really needs to stop adding new features and > refactor itself to a smaller and more secure codebase before going > forward. Maybe 1 year break would be nice. Do you have some actual proposals / patches ? --mtx -- Enrico Weigelt, metux I

Re: Can we drop upstream Linux x32 support?

roduction), but in industrial world, the product lifetimes are much longer - 20+yrs years usualstandard.are pretty common. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

[PATCH] .gitignore: add some missing excludes

For now they're all catched by ".*", but some folks might remove that in order to add their own .config file. Signed-off-by: Enrico Weigelt, metux IT consult --- .gitignore | 6 ++ scripts/kconfig/.gitignore | 1 + 2 files changed, 7 insertions(+) diff --git

[PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available

Instead of hardcoding the input name to the driver name ('gpio-keys-polled'), allow the passing a name via platform data ('name' field was already present), but default to old behaviour in case of NULL. Signed-off-by: Enrico Weigelt, metux IT consult --- dr

platform device initialization order

he correct initialization order ? thx --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

nately, I have no idea, what exactly you've seen in the mirror. I can only judge on what I've seen here in the last decades. And I like you exactly that way. Especially the rude part, eg. when it's about corporations like NVidia, or people who try to refit the Kernel for their broken userland stuff. If I may propose a patches to your /dev/brain, the only issue would be 100% strict GPL enforcement ;-) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

ing out how things work > themselves, and sometimes there is just not enough time to say anything. Yes. I've been demotivated by this problem myself. But I know, I can't expect anybody else do to my homework for me. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

roid stuff, ...) went a long way towards mainline, some still have a long way to go. That's just because it's these topics are far from being trivial. And that shouldn't stop anybody. > If I understand the context correctly, the previous "regime" could be > the culprit

Re: RFC: build config via DT names

On 12.02.2018 23:24, Frank Rowand wrote: There is a tool to aid this process: scripts/dtc/dt_to_config. It is not a 100% solution, but it is very helpful. The problem is difficult enough that this tool led to a conference talk. The slides are at https://elinux.org/images/5/50/Dt_debugging_part

Re: [PATCH] p9caps: add Plan9 capability devices

On 13.02.2018 07:16, Serge E. Hallyn wrote: + /* make sure only one instance per namespace can be opened */ > > ... at a time yeah, right. might be better to keep this state in the user_ns itself, would avoid kzalloc below. thought about, but hesitated to touch user_ns. might not be t

p9caps: add Plan9 capability devices

v2 of the p9caps patch

[PATCH] p9caps: add Plan9 capability devices

From: "Enrico Weigelt, metux IT consult" This driver implements the Plan9 capability devices, used for switching user id via capability tokens. https://9p.io/sys/doc/auth.html --- drivers/staging/Kconfig | 2 + drivers/staging/Makefile| 1 + drivers/staging/p9ca

[PATCH] p9caps: add Plan9 capability devices

From: "Enrico Weigelt, metux IT consult" This driver implements the Plan9 capability devices, used for switching user id via capability tokens. https://9p.io/sys/doc/auth.html --- drivers/staging/Kconfig | 2 + drivers/staging/Makefile| 1 + drivers/staging/p9ca

RFC: build config via DT names

eparate from the actual drivers - they just enable them automatically. Of course they'll have to be maintained by the driver maintainers. What do you think about this idea ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

user_namespace: add aux data

Hi folks, is there any way for drivers to add aux data to user namespaces ? I'm currently implementing plan9-like capabilities authentication, and I'd like to keep this separate by user-ns. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...

adding plan9-like usernames to the kernel

s) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

Re: Proposal: single defconfig for all ARM

--> enable hdmi display --> enable sdma --> enable usb ... --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287

gpio + separate interrupts on rising / falling

Hi folks, I've got device with some strange device that triggers two irqs via one line. Rising means buffer A filled, falling mean buffer B filled. I'd like to handle that via two separate interrupts. Is it possible to register both an rising and an falling edge irq on the same line ? --mtx

imx6: CSI for ADCs (fpga)

Hi folks, did anyone already use the imx6's csi port for anything other than cameras ? I'm thinking about using it for an ADC (in fpga). Theoretically it should be possible to transfer non-video data, but the question here is whether the ipu might interfer here (eg. trying colorspace conversion

dtc: imx6 warnings on unit address format errors

Hi folks, I'm getting lots of warnings from dtc about unit address format errors: For example in imx6q.dtsi: ocram: sram@0090 { The node name's address part has leading zeros which dtc doesn't like. It doesn't seem to have a big influence (yet ?), but I'd guess this warning is there

[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 d

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 colourfu

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 curious

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 seri

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 o

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

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 wa

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 ke

[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 ch

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: Uses of Linux backports in the industry

to latest 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 Register

<    4   5   6   7   8   9   10   >