e left the factory ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net
On 09.03.21 09:42, Henning Schild wrote:
The device will respond to MMIO while being hidden. I am afraid nothing
stops a collision, except for the assumption that the BIOS is always
right and PCI devices never get remapped. But just guessing here.
What could go wrong if it is remapped, except
u find out some more details, what these LEDs really had been
intented for ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free s
On 29.03.21 19:49, Henning Schild wrote:
Hi,
This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.
Where does the wdt actually come from ?
Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a pretty
crap), another good reason for
kicking it out asap.
But those systems tend to carry a lot of specialized changes anyway, so
they can just add "revert David's patch" to their pile.
Often those kind of people aren't capable of that. If anyone finds such
systems, report them to c
On 19.03.21 18:33, Sebastian Andrzej Siewior wrote:
On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote:
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for
On 19.03.21 13:59, Leon Romanovsky wrote:
I really doubt we can influence that by any technical decision here in
the kernel.
There are subsystems that succeeded to do it, for example netdev, RDMA e.t.c.
I'd guess either hi-end / server or embedded products - already
mentioned that thes
s for the FCH functionality that's
not supported yet (eg. wdt) ... not sure how much they differ between
different SoC versions.
Personally, I'd rather have mainline drivers for all that boards.
Don't know if it still makes sense for the older wrap or alix boards,
though. I also hav
to be able to use both, then I guess gpio-mux is what you
are looking for. Obviously, it will also require support in the bus
core. On what bus are those SIMs? (I guess the answer will be UART and
then unfortunately UARTs are not represented as busses).
We do have support for devices connected to
d the corresponding maintainer ?
(if that ever happens to one of my drivers, please let me know)
To a lesser degree, we see the same happen with 32-bit targets. Driver
authors often don't compile their drivers in 32-bit mode (just look
at 32-bit i386 builds in next-20210224 to see an example). Then i
power off
entirely ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -
Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 18.03.21 18:43, Amey Narkhede wrote:
Well I didn't present it as new use case. I just gave existing
usecase based on existing reset attribute. Nothing new here.
Nothing really changes wrt that use case.
As a board driver maintainer, I fully support your case. At least as a
develo
On 18.03.21 18:35, Leon Romanovsky wrote:
I see it as a good example of cheap solution. Vendor won't fix your
touchpad because distros provide workaround. The same will be with reset.
Usually, vendor won't fix it, anyways, regardless of any kernel
workarounds.
Most Vendors a
On 15.03.21 00:55, Pali Rohár wrote:
Moreover for mPCIe form factor cards, boards can share one PERST# signal
with more PCIe cards and control this signal via GPIO. So asserting
PERST# GPIO can trigger Warm reset for more PCIe cards, not just one. It
depends on board or topology.
The
y rare.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
gehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 17.03.21 21:03, Hans de Goede wrote:
Hi,
It just identifies the box and tells subsequent drivers which one it
is, which watchdog and LED path to take. Moving the knowledge of which
box has which LED/watchdog into the respective drivers seems to be the
better way to go.
So we would end up
On 11.03.21 06:32, Matti Vaittinen wrote:
...This is what happens when you suddenly pause work for over a week
because it starts to rain in the kitchen >.<;
Uups :(
I once had raining in the living room. (fortunately, just a rented
appartment, so let the owner do everything). At f
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
TATUS "-2" },
+ {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
+ {1 << 5, "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3" },
+ {0, ""},
+};
Wouldn't it be better to name them like they're label
liche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
hlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
x27;t even gpios.
(I'm still in progress of RE'ing the bios blob, to find out more,
eg. pinmux setups, etc). Writing to the wrong regs can cause weird
effects (actually not even sure whether it could lead to damage)
In essence: only a specific subset of the register range can be used
fo
in many drivers.
So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me.
I don't like idea of hidden indirect dependencies. If a driver needs
iomem, then it should depend on it. Yes, a lot of drivers might need
to be fixed, but IMHO we should do that, instead of cover
On 24.02.21 09:00, Greg KH wrote:
Have the firmware code do it itself, do nto try to "reach across" like
this.
By "firmware code" you mean Linux acpi core or the board's bios ?
a) Fixing BIOS would be the cleanest solution, but we cant expect all
users to do fi
On 15.02.21 02:12, Frank Rowand wrote:
Why not compile in ACPI data (tables?) instead of devicetree description?
The problem is a bit more complex than it might seem.
Let's take the APU2/37/4 boards as an example. They've got some aux
devices, eg. some gpio controller, and some th
hould be one
dts per board and really minimal effort adding another dts.
(hmm, maybe I should try generating glue code from dt ?)
BTW: I've already rewritten much of it, using overlay instead of an
completely own detached tree (so, some of the prev patches will fall
off the queue).
--mtx
On 13.02.21 11:20, Greg KH wrote:
On Mon, Feb 08, 2021 at 11:22:00PM +0100, Enrico Weigelt, metux IT consult
wrote:
---
drivers/base/bus.c | 14 ++
include/linux/device/bus.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
Um, no.
Why not ? Do you have a
On 17.02.21 14:50, Andy Shevchenko wrote:
On Wed, Feb 17, 2021 at 01:15:43PM +0100, Enrico Weigelt, metux IT consult
wrote:
Under rare circumstances it may happen that a device node's name is NULL
(most likely kernel bug in some other place).
What circumstances? How can I reproduce
On 19.02.21 21:51, Zbyněk Kocur wrote:
Hi Zbyněk,
Thanks for adding to the discussion. I tested the proposed modification on APU1
with different versions of bios.
The LED subsystem now behaves the same as the APU2 and higher. If it needs more
tests on various boards
from PCengines, I&#
On 18.02.21 13:53, Petr Mladek wrote:
Please, use
if (check_pointer(&buf, end, p, spec))
return buf;
It will print "(null)" instead of the name. It should be enough
to inform the user this way. The extra pr_warn() does not help
much to localize the probl
y the shanwan quirks are detected - instead
of searching for a single specific device name, it will now apply when
the device name includes "shanwan" in it at all. An example why this
is important would be that I have a shanwan device that is identified
as "Shanwan PLAYSTATION(R)3 C
On 18.02.21 10:14, Enrico Weigelt, metux IT consult wrote:
Hi folks,
answering myself ;-)
Problem: dtc adds my new 'gpio1' node to the __fixups__ list, which is
used for resolving symbols against the live tree - obviously it can't
exist there, since it's added by th
Hello folks,
I'm trying to use an overlay to add several new nodes with references
between them (eg. a gpio controller and devices using the gpios).
Problem: dtc adds my new 'gpio1' node to the __fixups__ list, which is
used for resolving symbols against the live tree - obv
Under rare circumstances it may happen that a device node's name is NULL
(most likely kernel bug in some other place). In such situations anything
but helpful, if the debug printout crashes, and nobody knows what actually
happened here.
Therefore protect it by an explicit NULL check and prin
enable CONFIG_PCENGINES_APU2\n");
return -ENODEV;
}
Looks good to me. But don't dare giving official ack, since I don't
have an apu1 board for testing.
Is Alan Mizrahi (original author) still here ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails könne
,
{
struct of_phandle_args sup_args;
+ if (!IS_ENABLED(CONFIG_OF_IRQ) || IS_ENABLED(CONFIG_PPC))
+ return NULL;
+
if (strcmp(prop_name, "interrupts") &&
strcmp(prop_name, "interrupts-extended"))
return NULL
Hi folks,
while playing around with overlays, I've encountered a funny crash,
that even seems to affect the filesystem. No idea what really happens,
as oftree code detected the broken phandle.
What I did:
* i've written a driver that loads a builtin oftree overlay and tries
t
On 12.02.21 10:58, Linus Walleij wrote:
Hi,
I think Intel people often take the stance that the ACPI DSDT (or whatever)
needs to be fixed.
It should, actually board/firmware vendors should think more carefully
and do it right in the first place. But reality is different. And
firmware upgrade
On 11.02.21 21:13, Rob Herring wrote:
On Mon, Feb 8, 2021 at 10:58 AM Enrico Weigelt, metux IT consult
wrote:
Also print out the phandle ID on error message, as a debug aid.
I already have this patch applied in my tree. Why do you keep sending it?
Sorry, didn't know that when sendi
On 11.02.21 12:41, Andy Shevchenko wrote:
Hi,
On Thu, Feb 11, 2021 at 1:15 PM Enrico Weigelt, metux IT consult
wrote:
On 10.02.21 11:30, Andy Shevchenko wrote:
Use cases are boards with non-oftree firmware (ACPI, etc) where certain
platform devices can't be directly enumerate
not
wired, etc). Supporting such things would need adding more matching
rules and possibly runtime DT manipulations.
+unbind {
+acpi = "PNP0076:00", "PNP0B00:00";
+platform = "platform-framebuffer.0", "PNP0103:00";
This n
then initialize the actual devices and their links
(eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT.
In ACPI we support DT compatible strings, and we support overlays for
a long time. Would it work for you?
please tell me more, how ACPI and DT can already work toge
On 09.02.21 00:48, Rob Herring wrote:
Hi,
here's an RFC for using compiled-in dtb's for initializing board devices
that can't be probed via bus'es or firmware.
I'm not convinced compiled in is the mechanism we want.
To make it clear, I'm talking of DTBs co
Introduce additional parameter for specifying the name of the base directory
underneath /sys/firmware/devicetree. This is for scenarios where we want
entirely separate oftree instances. Passing NULL falls back to the existing
base name 'base'.
Signed-off-by: Enrico Weigelt, metux
on success, probes the devices that are defined
by them.
For the time being, we just support matching on DMI_BOARD_NAME and
DMI_SYS_VENDOR - other criteria, even bus- or ACPI-id's can be added later,
when needed.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/platform/Kconfig |
Introduce helper for attaching an (separate) oftree into sysfs.
This is useful, when drivers use their own internal device trees,
separate from the platform's global one, and wanna make it visible
to userspace via sysfs.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/k
Add oftree based support for PC Engines APUv2/3/4 board family.
This is entirely separate from the existing pcengines-apuv2 driver.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/platform/of/Kconfig | 15
drivers/platform/of/Makefile | 2 +
drivers/platform/of
ific bus
* and unregister it from device core
--
2.11.0
Also print out the phandle ID on error message, as a debug aid.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..8a348f0d3c5e 100644
--- a
a/include/dt-bindings/gpio/amd-fch-gpio.h
b/include/dt-bindings/gpio/amd-fch-gpio.h
new file mode 100644
index ..7a47e6debcdb
--- /dev/null
+++ b/include/dt-bindings/gpio/amd-fch-gpio.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+/*
+ * AMD FCH gpio platform data definit
---
drivers/base/bus.c | 6 --
include/linux/device/bus.h | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index a06ae2786092..2ef92a3c5d7b 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -39,7 +39,7 @@ static s
Introduce a helper for detaching a named device from bus and
unregistering it. This is helpful eg. if some board specific driver
needs to remove an unwanted device that had been probed via firmware,
but should be handled differently.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers
For detached oftree support, find the root node and record it, on iterator
creation. If we find the root of the global oftree, record NULL, in order to
have a clear distinction between detached and non-detached cases. The recorded
root node is then used for resolving phandles.
Note that in the
Introduce a new helper function that looks up a given propery and
matches all string elements against a given string. This is useful
if we want to check wether one string element of some property
matches a given string.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 32
Hello folks,
here's an RFC for using compiled-in dtb's for initializing board devices
that can't be probed via bus'es or firmware.
Use cases are boards with non-oftree firmware (ACPI, etc) where certain
platform devices can't be directly enumerated via firmware. Traditionally
we had to write boar
with oftree overlays.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 14 +-
include/linux/of.h | 7 ++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8a348f0d3c5e..6b3d1e817808 100644
--- a/dr
Also print out the phandle ID on error message, as a debug aid.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..8a348f0d3c5e 100644
--- a
Make the indentions consistent with everywhere else in the kernel.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/firmware/Kconfig | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
Also print out the phandle ID on error message, as a debug aid.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..8a348f0d3c5e 100644
--- a
The change c0f975af1745391749e4306aa8081b9a4d2cced8 introduces a bug when
HOSTCC contains parameters: the whole command line is treated as the program
name (with spaces in it). Therefore, we have to remove the quotes.
Fixes: c0f975af1745391749e4306aa8081b9a4d2cced8
Signed-off-by: Enrico Weigelt
Move the pm_power_off callback into one global place and also add an
function for conditionally calling it (when not NULL), in order to remove
code duplication in all individual archs.
Reported-by: kernel test robot
Signed-off-by: Enrico Weigelt, metux IT consult
changes v2:
* fix
On 22.12.20 19:54, Geert Uytterhoeven wrote:
Hi,
> On Tue, Dec 22, 2020 at 7:46 PM Enrico Weigelt, metux IT consult
> wrote:
>> Move the pm_power_off callback into one global place and also add an
>> function for conditionally calling it (when not NULL), in order to remove
&
On 20.12.20 06:30, Stephen Boyd wrote:
> It looks like it needs to be a bool Kconfig to match how it used to be.
> A module would be interesting, but would require more changes
> presumably, like getting rid of builtin_platform_driver() and replacing
> it with module_platform_dri
Move the pm_power_off callback into one global place and also add an
function for conditionally calling it (when not NULL), in order to remove
code duplication in all individual archs.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/kernel/process.c| 6 --
arch/arc
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
crease the counter in all call sites of ack_bad_irq()
* subsequent patches will transform the individual archs one by one
Signed-off-by: Enrico Weigelt, metux IT consult
---
include/asm-generic/irq-err.h | 17 +
kernel/irq/dummychip.c| 2 ++
kernel/irq/handle.c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/mips/include/asm/hw_irq.h | 4
arch/mips/kernel/irq-gt641xx.c | 3 ++-
arch/mips/kernel/
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/hw_irq.h | 6 --
arch/arm/kernel/
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
p at vector' warnings"
https://www.spinics.net/lists/kernel/msg3763137.html
Turned out that the whole message, as it is right now, doesn't make much
sense at at all - not just incorrect wording, but also not quite useful
information. And the whole ack_bad_irq() thing deserves a cleanup a
nce either the
other callers already had printed more detailed information or (when called
by __handle_domain_irq()) the printout just doesn't tell anything useful.
Signed-off-by: Enrico Weigelt, metux IT consult
---
kernel/irq/irqdesc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kern
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/include/asm/hardirq.h | 3 ---
arch/alpha/include/asm/hw_irq.h | 2 --
arch/alpha/k
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm64/include/asm/hardirq.h | 9 ++---
arch/arm64/kernel/smp.c | 6 ++
2
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/include/asm/hardirq.h | 3 ---
arch/c6x/include/asm/irq.h | 2 --
arch/c6x/kernel/
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o "0x" prefix.
* the printed linux irq isn't meaningful in all
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm64/include/asm/hardirq.h | 9 ++---
arch/arm64/kernel/smp.c | 6 ++
2
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/hw_irq.h | 6 --
arch/arm/kernel/
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we
Hello friends,
here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:
"arch: fix 'unexpected IRQ trap at vector' warnings"
https://www.spinics.net/lists/kernel/msg3763137.html
Turned out that the whol
nce either the
other callers already had printed more detailed information or (when called
by __handle_domain_irq()) the printout just doesn't tell anything useful.
Signed-off-by: Enrico Weigelt, metux IT consult
---
kernel/irq/irqdesc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kern
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o "0x" prefix.
* the printed linux irq isn't meaningful in all
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/include/asm/hardirq.h | 3 ---
arch/c6x/include/asm/irq.h | 2 --
arch/c6x/kernel/
crease the counter in all call sites of ack_bad_irq()
* subsequent patches will transform the individual archs one by one
Signed-off-by: Enrico Weigelt, metux IT consult
---
include/asm-generic/irq-err.h | 17 +
kernel/irq/dummychip.c| 2 ++
kernel/irq/handle.c
1 - 100 of 949 matches
Mail list logo
