Re: [PATCH] platform/x86: intel_pmc_core: export platform global_reset via sysfs.
On 01.04.21 23:31, Tomas Winkler wrote: Hi, During PCH manufacturing a global reset has to be induced in order for configuration changes take affect upon following platform reset. This setting was commonly done by accessing PMC registers via /dev/mem but due to security concern /dev/mem access is much restricted, hence the reason for exposing this setting via dedicated sysfs interface. To prevent post manufacturing abuse the register is protected by hardware locking. could you please define "manufacturing" ? The chip or board ? Is there any use for this, after the machine 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 -- +49-151-27565287
Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library
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 that this driver would write to the wrong mmio space ? If it's unhidden, pci-core should see it and start the usual probing, right ? --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
Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
On 27.03.21 10:46, Henning Schild wrote: In this case, they seem to be assigned to certain specific functions (by physical labels on the box), so IMHO the LED names should reflect that in some ways. The choice for "status" was because of /* Miscelleaus functions. Use functions above if you can. */ And those known names do not really come with an explanation of their meaning. Names like "bluetooth" seem obvious, but "activity" or "indicator" leave a lot of room for speculation. Maybe we should revise these and add more functions ? Can you 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 software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
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 usual case. Or some external chip ? The code smells a bit like two entirely different wdt's that just have some similarities. If that's the case, I'd rather split it into two separate drivers and let the parent driver (board file) instantiate the correct one. --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
Re: [PATCH v1 0/3] drivers/char: remove /dev/kmem for good
On 24.03.21 20:24, Andrew Morton wrote: We do tend to think about distros. I bet there are a number of weird embedded type systems using /dev/kmem - it's amazing what sorts of hacks those people will put up with the get something out the door. There certainly are (seen lots of such 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 cert, bsi, fd, ... --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
Re: [PATCH RFC 0/3] drivers/char: remove /dev/kmem for good
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 good. I'll happily do this for the next merge window, but would really want distros to confirm that they don't enable it. I can confirm that it's certainly not enabled on any of the machines I have, but.. Debian has CONFIG_DEVKMEM disabled since 2.6.31. SLES, too. (but no idea since when exactly) --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
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
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 these are different fields. I've been talking about the average consumer products. OTOH, there're also very expensive vendors that are exceptionally bad, eg. National instruments (who even are capable of breaking rpm so badly with their proprietary packages that they open up 0day holes - i once filed a report @FD on such a case). IMHO, the expensive ones don't care either. Does eg. Dell publish board schematics ? Do they even publish exact part lists (exact chipsets) along with their brochures, so customers can check wether their HW is supported, before buying and trying out ? They do it because they are allowed to do it and not because they explicitly want to annoyance their customers. Yes, they're just ignorant. They can still do that, because buy their pretty expensive cheap-hardware. And that's mostly driven by purchase people inside the customer organisations, who just don't care how much damage they do to their own employers, by dictating purchase of expensive broken-by-design hardware. ... but that's nothing we here have any influence on - except for dissuasion and purchase boycott ... In any case, I still fail to see why giving operators an debug knob should make anything worse. [ And often, even a combination of them isn't enough. Did you know that even Google doesn't get all specs necessary to replace away the ugly FSP blob ? (it's the same w/ AMD, but meanwhile I'm pissed enought to reverse engineer their AGESA blob). ] I don't know about this specific Google case, but from my previous experience. The reasons why vendor says no to Google are usually due to licensing and legal issues and not open source vs. proprietary. In short words: Google did (still does?) build their own mainboards and FW (IIRC that's where LinuxBoot came from), but even with their HUGE quantities (they buy cpus in quantities of truck loads) they still did not manage to get any specs for writing their own early init w/o the proprietary FSP. The licensing / legal issues can either be: a) we, the mightly Intel Corp., have been so extremly stupid for licensing some vital IP stuff (what exactly could that be, in exactly the prime domain of Intel ?) and signing such insane crontracts, that we're not allowed to tell anybody how to actually use our own products (yes: initializing the CPU and built-in interfaces belongs exactly into that category) b) we, the mighty Intel Corp., couldn't build something on our own, but just stolen IP (in our primary domain) and are scared that anybody could find out from just reading some early setup code. c) we, the mighty Intel Corp., rule the world and we give a phrack on what some tiny Customers like Google want from us. d) we, the mightly Intel Corp., did do what our name tells: INTEL, and we don't want anybody raise unpleasant questions. choose your poison :P --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
Re: [PATCH v2] leds: apu: extend support for PC Engines APU1 with newer firmware
On 06.03.21 17:51, Alexander Dahl wrote: Hi, If you give me a hint, which tree or patchset should be tested, and some hints what should be tested, I can try. haven't written anything for apu1 yet (as I dont have one), but I wrote the drivers for apu2/3/4. My idea (which I never actually started on) was writing a separate gpio driver (not LED) for the old Soc in apu1 and add instantiation w/ leds-gpio, keys, etc, into the pcengines-apu2 driver. Thanks for that work. I have to admit someone from the fli4l linux router distribution team also wrote LED and button drivers for the APU boards, but never managed to upstream those. :-/ If someone is interested, those are spread in our Subversion repository, but the apu drivers are here: https://repo.nettworks.org/svn/fli4l/branches/4.0/trunk/src/packages/src/src/fli4l/hwsupp/pcengines-apu/ hmm, maybe I could pick up pieces 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 have those lying around. ;-) Well, somebody has to make his hands dirty, write those drivers, bring them to mainline, and maintain them. --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
Re: [PATCH v9 2/4] pinctrl: pinmux: Add pinmux-select debugfs file
On 13.03.21 19:47, Geert Uytterhoeven wrote: I've already been playing with similar idea, but for external muxes. For example, some boards have multiple SIM slots that can be switched via some gpio pin. Not sure whether traditional pinmux would be a good match for that. If you want 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 UARTs. See patternProperties in Documentation/devicetree/bindings/serial/serial.yaml. Or do you mean something different? in my case, the SIM cards are connected directly to the baseband (there're extra lines on the m2 slots for that). CPU doesn't ever see any of this traffic, just can select which SIM card is routed to the m2 slot via gpio. --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
Re: [PATCH] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
On 24.02.21 17:23, Guenter Roeck wrote: Unfortunately that does not reflect reality, which was the reason for the above two commits. Problem here is that the cost is not paid by the driver authors, but by architectures which don't support HAS_IOMEM, specifically s390. Driver authors tend to enable COMPILE_TEST but never test on a system with HAS_IOMEM=n (and/or ignore test results provided by build robots). Still, I believe the bug should be fixed at the source. Maybe these bots do so much traffic that nobody really cares about them. Do they directly address the author and 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 it is often up to others to track down and fix the problems. Fortunately, there are still more than a few people who are still interested in 32-bit builds, and problems with those builds tend to get fixed quickly. This is not the case with HAS_IOMEM related issues, where the burden is on very few people. Could we set up a separate build bot for those configurations, with a different from: address and an a special warning text, so maintainers quickly see they *should* pay attention. IMHO, this is primarily a problem of handling the massive traffic on lkml and sorting out whats relevant for oneself. --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
Re: AHCI SATA Runtime PM
On 04.03.21 16:34, Alexander Monakov wrote: I have a laptop where two unused AHCI SATA controllers are present (but obviously nothing can be hotplugged into them). Apparently due to the above, they do not enter runtime autosuspend. if nothing ever can connect to them, shouldn't they be 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 -- +49-151-27565287
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
On 18.03.21 18:22, Leon Romanovsky wrote: Which email client do you use? Your responses are grouped as one huge block without any chance to respond to you on specific point or answer to your question. I'm reading this thread in Tbird, and threading / quoting all looks nice. I see your flow and understand your position, but will repeat my position. We need to make sure that vendors will have incentive to supply quirks. I really doubt we can influence that by any technical decision here in the kernel. And regarding vendors, see Amey response below about his touchpad troubles. The cheap electronics vendors don't care about their users. IMHO, the expensive ones don't care either. Does eg. Dell publish board schematics ? Do they even publish exact part lists (exact chipsets) along with their brochures, so customers can check wether their HW is supported, before buying and trying out ? Doesn't seem so. I've personally seen a lot cases where some supposedly supported HW turned out to be some completely different and unsupported HW that's sold under exactly the same product ID. One of many reasons for not giving them a single penny anymore. IMHO, there're only very few changes of convincing some HW vendor for doing a better job on driver side: a) product is targeted for a niche that can't live without Linux (eg. embedded) b) it's really *dangerous* for your market share if anything doesn't work properly on Linux (eg. certan server machines) c) somebody *really* big (like Google) is gun-pointing at some supplier, who's got a lot to loose d) a *massive* worldwide shitstorm against the vendor [ And often, even a combination of them isn't enough. Did you know that even Google doesn't get all specs necessary to replace away the ugly FSP blob ? (it's the same w/ AMD, but meanwhile I'm pissed enought to reverse engineer their AGESA blob). ] You see, what we do here in the kernel has no practical influence on those hw vendors. --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
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
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 development/debugging. And even if people out there play around and find their own workarounds, these can give us maintainers valuable insights and save us a lot of time. As mentioned earlier not all vendors care about Linux and not all of the population can afford to buy new HW just to run Linux. At least in the x86 world (arm is *much* better here), even the (supposedly) Linux-friendly ones often don't really care, especially if the board isn't the newerst model anymore. Unfortunately, what we do or don't do in the kernel has practically no influence on board vendor decisions. The best we can practically achieve at their side is slowing them down on smearing bullshit into FW and acpi tables. Even getting some useful documentation from vendors is a really rare thing. ARM world with device tree, of course, is much better (except for closed consumer devices like "smartphones" or acpi-poisoned arm64 boxes). At least for profession embedded boards. --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
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
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 are already completely overstrained w/ anything software-related. A good reason why we should try to get rid firmware, as much as we can. It's really sad. A *decent* vendor would just provide a clean DT and (actually matching!) schematics. But that's really hard to find, these days :( --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
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
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 pcengines apu* boards happen to be such candidates: they've got three m.2 slots, but not all wired in the same way (depending on actual model, not all have pcie wired). Reset lines are driven via gpio, and some devices (I recall some lte basebands) sometimes need an explicit reset in order to come up properly. I have to check the schematics for the diffrent models, how exactly these gpios are wired. (i've got reports that some production lines don't have them wired at all - but couldn't confirm this on my own). BTW: any idea how to inject board specific reset methods, after the host brigde driver is already active ? In my case, apu boards, the pci host bridge is probed via acpi and the apu board driver (which sets up gpios, leds, keys, ...) comes much later. --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
Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver
On 16.03.21 08:44, Viresh Kumar wrote: FWIW, this limits this driver to support a single device ever. We can't bind multiple devices to this driver now. Yeah, perhaps we will never be required to do so, but who knows. Actually, I believe multiple devices really should be possible. The major benefit of virtio-i2c is either bridging certan real bus'es into a confined workload, or creating virtual hw testbeds w/o having to write a complete emulation (in this case, for dozens of different i2c controllers) - and having multiple i2c interfaces in one machine isn't exactly 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
Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
On 15.03.21 12:19, Pavel Machek wrote: But I still don't like the naming. simantic-ipc: prefix is useless. Having 6 status leds is not good, either. Do we have some standard naming policy those kinds of LEDs ? In this case, they seem to be assigned to certain specific functions (by physical labels on the box), so IMHO the LED names should reflect that in some ways. There're other cases (eg. apu board familiy) that just have several front panel leds w/o any dedication, so we can just count them up. --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
Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices
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 with a LED and a watchdog driver both
MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");
Uh, isn't that a bit too broad ? This basically implies that Siemens
will never produce boards with different configurations.
and doing the identification with the inline dmi from that header,
doing p2sb with the support to come ... possibly a "//TODO\ninline" in
the meantime.
So no "main platform" driver anymore, but still central platform
headers.
Not sure how this sounds, but i think making that change should be
possible. And that is what i will try and go for in v3.
Dropping the main drivers/platform/x86 driver sounds good to me,
I was already wondering a bit about its function since it just
instantiates devs to which the other ones bind to then instantiate
more devs (in the LED case).
hmm, IMHO that depends on whether the individual sub-devices can be
more generic than just that specific machine. (@Hanning: could you
tell us more about that ?).
Another question is how they're actually probed .. only dmi or maybe
also pci dev ? (i've seen some refs to pci stuff in the led driver, but
missed the other code thats called here).
IMHO, if the whole thing lives on some PCI device (which can be probed
via pci ID), and that device has the knowledge, where the LED registers
actually are (eg. based on device ID, pci mmio mapping, ...) then there
should be some parent driver that instantiates the led devices (and
possibly other board specific stuff). That would be a clear separation,
modularization. In that case, maybe this LED driver could even be
replaced by some really generic "register-based-LED" driver, which just
needs to be fed with some parameters like register ranges, bitmasks, etc.
OTOH, if everything can be derived entirely from DMI match, w/o things
like pci mappings involved (IOW: behaves like directly wired to the
cpu's mem/io bus, no other "intelligent" bus involved), and it's all
really board specific logic (no generic led or gpio controllers
involved), then it might be better to have entirely separate drivers.
-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
Re: [RFC PATCH v2 0/7] Extend regulator notification support
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 first I tried to catch up the water ... until the ceiling lining came down and turned my living room into a large shower room. Panic turned into insanity, and I was just singing in the rain ... :o Best wishes for your repair. --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
Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
On 15.03.21 11:48, Andy Shevchenko wrote: Hi, I have a question, why we can't provide a GPIO driver which is already in the kernel and, with use of the patch series I sent, to convert this all magic to GPIO LEDs as it's done for all normal cases? Do we alread have a generic led driver that for cases that just set/clear bits in some mem/io location ? If not, that would be really great to have. --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
Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
d->value = swab16(ipcled->value);
Uff, better use explicit endian conversion macros (eg. be*_to_cpu()) for
that.
Also, I wouldn't change those global structs, instead put those data
into device priv data and make the global stuff const. You could also
use the same field for both port-io and mmap'ed variants. And adding
regmap to the equation, could use the same led ops for both. (IMHO,
the little bit of overhead by regmap shouldn't matter here)
+ ipcled++;
+ }
+ ipcled = simatic_ipc_leds_io;
+ }
+ type = IORESOURCE_IO;
+ if (!devm_request_region(dev, res->start,
+resource_size(res),
+KBUILD_MODNAME)) {
+ dev_err(dev,
+ "Unable to register IO resource at %pR\n",
+ res);
+ return -EBUSY;
+ }
+ break;
+ case SIMATIC_IPC_DEVICE_127E:
+ res = _ipc_led_mem_res;
+ ipcled = simatic_ipc_leds_mem;
+ type = IORESOURCE_MEM;
+
+ /* get GPIO base from PCI */
+ res->start = simatic_ipc_get_membase0(PCI_DEVFN(13, 0));
+ if (res->start == 0)
+ return -ENODEV;
Where does that device actually sit on ? Some generic card ? Some ASIC
or FPGA ?
It seems this driver is instantiated by another one, which already knows
what device we're actually dealing with (as it sets plat->devmode).
Why not letting that parent device also tell the io resource to this
driver ?
+ while (ipcled->value) {
+ cdev = >cdev;
+ cdev->brightness_set = simatic_ipc_led_set_io;
+ cdev->brightness_get = simatic_ipc_led_get_io;
+ if (type == IORESOURCE_MEM) {
+ cdev->brightness_set = simatic_ipc_led_set_mem;
+ cdev->brightness_get = simatic_ipc_led_get_mem;
+ }
Why not if/else ?
+ cdev->max_brightness = LED_ON;
+ cdev->name = ipcled->name;
+
+ err = devm_led_classdev_register(dev, cdev);
+ if (err < 0)
+ return err;
+ ipcled++;
+ }
+
+ return 0;
+}
+
+static struct platform_driver led_driver = {
Why not calling it simatic_ipc_led_driver ?
+ .probe = simatic_ipc_leds_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ },
+};
+
+module_platform_driver(led_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" KBUILD_MODNAME);
+MODULE_AUTHOR("Henning Schild ");
--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
Re: EDAC list as Trojan Horse distribution ??
On 16.03.21 20:51, Luck, Tony wrote: Nothing new - just the next spammer attempt. But this was a new class of Spam. So far i got only mass mailing... This was personalized based on my previous e-Mail (did not include this part in my mail) Somewhat new - combining trawling of public mailing lists for addresses with a phishing attack trying to get you to open a (presumably) malicious payload. I'm getting those kind of spam for aeons, just another one today. --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
Re: [RFC PATCH 07/12] gpio: amd-fch: add oftree probing support
On 11.03.21 11:42, Andy Shevchenko wrote: Hi, You are a bit late. We have built-in device properties (and corresponding API, which recently becomes swnode) which aims exactly this. Is there some compact notation for swnode's that's as small and simple as some piece of DTS ? My reasons for choosing built-in dtb have been: * it's a very small and compact notation for describing devices * no more open-coded registrations, etc * no more need for board drivers (except for the little piece of DT) --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
Re: [PATCH v9 2/4] pinctrl: pinmux: Add pinmux-select debugfs file
On 02.03.21 06:30, Drew Fustini wrote: Hi folks, Add "pinmux-select" to debugfs which will activate a pin function for a given pin group: echo "" > pinmux-select The write operation pinmux_select() handles this by checking that the names map to valid selectors and then calling ops->set_mux(). I've already been playing with similar idea, but for external muxes. For example, some boards have multiple SIM slots that can be switched via some gpio pin. Not sure whether traditional pinmux would be a good match for that. --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
Re: [RFC PATCH 07/12] gpio: amd-fch: add oftree probing support
On 01.03.21 15:51, Linus Walleij wrote: Hi, I don't know what the idea is with this but register are not normally defined in the DTS files. The registers are determined from the compatible value. The idea is basically replacing the pdata struct by oftree node. (subsequent patches in this queue use this by doing the board setup via compiled-in dtb, instead of the currently hardcoded tables). On these SoCs, the gpio setup is a little bit more complex than just having a fixed range of registers (one per pin): the actual meaning depends und Soc model and board type - some regs aren'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 for GPIOs - the others shouldn't ever be touched. And this specific subset is soc/board specific. --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
Re: [PATCH] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
On 24.02.21 15:08, Masahiro Yamada wrote:
I read the commit log of the following two:
- bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML")
- 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
Both are talking about HAS_IOMEM dependency missing 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 covering 'em up.
--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
Re: [RFC PATCH 09/12] drivers: base: reintroduce find_bus()
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 field upgrades. Many of the devices (eg. the customer, I've originally wrote the apu board driver for, deployed them in really remote locations, sometimes even just reachable by ship, heli or horse, litterally) b) Explicit blacklisting somewhere in apci enumeration code could work, but I really hate the idea of such board and bios version specific quirks in a place, completely unrelated to the actual board driver. Actually, I'm also hoping to find a proper way for having those things in one file per board, in the future. (probably not applicable for early stuff, or _OSI(Linux), etc) And what problem are you really trying to solve here by doing this? The problem is that *some* bios versions (that came much later, after pcengines-apuv2 driver went into production) added a few things that the driver is already doing - different versions doing it differently (eg. even enumerating gpio connected leds with completely different names, etc), and still some gpio connected devices missing. Some versions (just forgot, which one it's been exactly) even enumerate *some* gpios (and LEDs behind them) as a different device, whose Linux driver just happens to work. Meanwhile I can't find any reference of that in the coreboot source, anymore. As you can see: bios is anything but reliable on that platform. What I'm trying to achieve: the kernel should behave exactly the same, no matter what board revision, bios version, kernel version, etc. (there should be especially no need to have special per-board quirks in userland, depending on board rev, bios version, kernel version). If you've got a better solution, I'll be glad to hear it. --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
Re: RFC: oftree based setup of composite board devices
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 things (leds, keys, reset lines, etc) attached to it. Now we've got lots of different bios versions in the field, enumerating only some of the devices. For example, older ones didn't even contain the gpio, later ones added just gpio, other ones just added LEDs (with different names than the Linux driver already mainlined and field-deployed at that time), but still other lines unhandled, etc, etc. etc. A big mess :( And I can't ask everybody to do bios uprade on devices far out in the field (litterally open field, sometimes offshore, ...). So, I need a usable solution, that's also maintainable, w/o testing each single combination of board, bios, etc. IOW: without relying on bios (except for board identification) OTOH, I'm also looking for a solution get rid writing those kind of relatively huge board drivers, that pretty are much like old fashioned board files from pre-DT times - just made up of lots of tables and a few trivial register-something calls. Sounds pretty much like the original use case of oftree. The primary difference between classic oftree and this scanario: * this is additional to existing platform information, which is incomplete or even incorrect (and that can't be fixed) * extra carrier boards that are detected by other means, but no enumeration of the devices on it. This is something I've wanted to see for a while. There's use cases for DT based systems too. The example I'd like to see supported are USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then plug more than one of those in. My understanding from the past is that the experts (those who understand both devicetree and ACPI) regard trying to mix devicetree and ACPI in a single running Linux kernel image is insanity, or at least likely to be confusing, difficult, and problematic. Well, mixing different, overlapping data sources tends to be tricky. The same problem exists with the classic approach of hand-written board drivers. So there have to be clear border lines. In my case (eg. apu2+ boards), the overlap is only that some bios versions enumerate the gpio chip, others even some of the gpio-based devices. I'm attempting to solve this by just kicking out those duplicate devices, if they exist. The alternative could be leaving them in an trying to bind the missing ones to them. But that would be really complicatd and needs to be well crafted for lots of different board and bios versions - a kind of complexity we wanna avoid. My use cases are actually a bit easier than the average dt overlay cases, as I have almost no interactions with already existing devices (except that some specific devices have to be moved out of the way) The original DT overlay use case, arbitrary expansion boards (eg. on raspi), are trickier, if the overlays shall be generic over a wider range of base boards (eg. same overlay for any raspi or odroid). This is something calling for an own (pseudo-)bus type that handles the correct probing ... I've hacked up something similar for the APU2+'s combined msata/usb/mpcie ports. BTW: I've already been thinking of ways for internally transforming ACPI tables into DT data structures (struct device_node) at an early point, before probing. But that would be another research project with unknown outcome, and most likely a HUGE change. Not what I'm talking about now. From the devicetree side, I expect nightmares for me if devicetree and ACPI are mixed in a single running kernel image. Note that I'm not talking about arbitrary configurations. Just re-using existing device tree code to express things that are currently open coded C into DT. It's NOT trying to boot an ACPI-based machine with DT. (which would be yet another research project) Multiple root nodes and disjoint trees both seem problematic. Existing subsystems and drivers expect a single cohesive tree. Changing that architecture looks to me to be a painful exercise. Yes, it's not entirely trivial, but managable. My experiments seemed to work so far, and I couldn't see general blockers yet. Drivers usually expect certain sub-nodes, but haven't found any that expect their node being embedded in some other one. (maybe there really are some, but the likehood that they're applicable in these use cases looks pretty low). --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
Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
On 15.02.21 02:18, Frank Rowand wrote: The RCAR use of overlays that are built into the driver are a known pattern that is explicitly not to be repeated. Well, that driver indeed looks quite complex - if belive unnecessarily. But can't judge on these devices, don't have one of them. In my case, I believe it's a simple and straightforward approach, instead of writing a whole driver, that just consists of a bunch of tables and some trivial setup calls. DT seems to be a perfect choice for that, since it's a very short and precise language for describing hw layout, w/o any piece of imperative code. The only point where I'm still not satisfied with: module auto-loading requires the match data in the kernel module. But i'd like to have everything in one source file and not having to write individual modules for invididual boards anymore. Finally, there should 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 -- --- 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
Re: [RFC PATCH 09/12] drivers: base: reintroduce find_bus()
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 better idea ? What I actually need is a way to unbdind a specific device, identified by bus name and device name. The problem to be solved here is dropping devices that have been enumerated in a bad way by firmware (ACPI in this case), and then recreating it in a clean, consistent way. If there was a variant of bus_find_device_by_name() which takes the name instead of ptr to the bus, that would also be okay for me. --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
Re: [PATCH] lib: vsprintf: check for NULL device_node name in device_node_string()
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 this? More information, please!
Observed it when applying a broken overlay. (sorry, didn't keep that
broken code :o). In this case, the device_node was left without a name
(pointing to NULL).
+ pr_warn("device_node without name. Kernel bug
?\n");
If it's not once, then it's possible to have log spammed with this, right?
It only has occoured once for me. I don't think spamming could happen,
unless one's hacking deeply in the oftree code.
+ p = "";
We have different standard de facto for NULL pointers to be printed. Actually
if you wish, you may gather them under one definition (maybe somewhere under
printk) and export to everybody to use.
Seen it in Petr's reply ... going to use that in v2.
--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
Re: [PATCH v2] leds: apu: extend support for PC Engines APU1 with newer firmware
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'm available. Do you also happen to have different apu2/3/4 boards (various hw revs and bios versions) for testing ? I've still got some open issues, eg. regarding pcie reset lines, etc. --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
Re: [PATCH] lib: vsprintf: check for NULL device_node name in device_node_string()
On 18.02.21 13:53, Petr Mladek wrote: Please, use if (check_pointer(, 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 problem anyway. And it is better to avoid recursion in this path. thx, going to use it in v2. --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
Re: of overlay: how to insert new nodes with references to it
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 the overlay. Therefore applying the
overlay fails:
"OF: resolver: node label 'gpio1' not found in live devicetree
symbols table"
Shouldn't the symbol be added to __local_fixups__ instead of __fixups__
?
How can I force dtc to do that ?
after playing around a while, found out that I need to use full path
references instead of labels or just node names, eg.
gpios = <&{/fragment@0/__overlay__/gpio1} 0 GPIO_ACTIVE_HIGH>;
--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
of overlay: how to insert new nodes with references to it
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 - obviously it can't exist there, since it's added by the overlay. Therefore applying the overlay fails: "OF: resolver: node label 'gpio1' not found in live devicetree symbols table" Shouldn't the symbol be added to __local_fixups__ instead of __fixups__ ? How can I force dtc to do that ? --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
[PATCH] lib: vsprintf: check for NULL device_node name in device_node_string()
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 print out an extra
warning.
Signed-off-by: Enrico Weigelt, metux IT consult
---
lib/vsprintf.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..050a60b88073 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2013,6 +2013,10 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
break;
case 'n': /* name */
p = fwnode_get_name(of_fwnode_handle(dn));
+ if (!p) {
+ pr_warn("device_node without name. Kernel bug
?\n");
+ p = "";
+ }
precision = str_spec.precision;
str_spec.precision = strchrnul(p, '@') - p;
buf = string(buf, end, p, str_spec);
--
2.11.0
Re: [PATCH v2] leds: apu: extend support for PC Engines APU1 with newer firmware
On 16.02.21 14:30, Andreas Eberlein wrote:
Hi,
The DMI_PRODUCT_NAME entry on current firmware of PC Engines APU1 changed
from "APU" to "apu1"
This modification adds the missing DMI data and thereby the LED support for
the PC Engines APU1 with firmware versions >= 4.6.8.
Do you have a device for more intensive testing ?
In that case I'd like to suggest splitting the driver into gpio and
gpio-based LED (using leds-gpio) - just like already I did for apu2/3/4.
Maybe this even could also be moveed into the apu2 driver. This probably
just makes sense if there're more gpio-connected devices than just LED)
Personally, I don't have access to the old apu1 board (IIRC not even
produced anymore for several years), so I didn't dare to touch anything
here.
Note that apu1 vs. apu2/3/4 have completely different SOC with different
gpio logic - that was one of the reasons for writing a completely new
driver for apu2+ from scrath, rather than extending the old one.
--- a/drivers/leds/leds-apu.c
+++ b/drivers/leds/leds-apu.c
@@ -83,6 +83,7 @@ static const struct apu_led_profile apu1_led_profile[] = {
};
static const struct dmi_system_id apu_led_dmi_table[] __initconst = {
+ /* PC Engines APU with factory bios "SageBios_PCEngines_APU-45" */
{
.ident = "apu",
.matches = {
@@ -90,6 +91,14 @@ static const struct dmi_system_id apu_led_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "APU")
}
},
+ /* PC Engines APU with "Mainline" bios >= 4.6.8 */
+ {
+ .ident = "apu",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "apu1")
+ }
+ },
{}
};
MODULE_DEVICE_TABLE(dmi, apu_led_dmi_table);
@@ -173,7 +182,7 @@ static int __init apu_led_init(void)
int err;
if (!(dmi_match(DMI_SYS_VENDOR, "PC Engines") &&
- dmi_match(DMI_PRODUCT_NAME, "APU"))) {
+ (dmi_match(DMI_PRODUCT_NAME, "APU") || dmi_match(DMI_PRODUCT_NAME,
"apu1" {
pr_err("No PC Engines APUv1 board detected. For APUv2,3 support,
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ö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
Re: [PATCH] of: property: fw_devlink: Ignore interrupts property for some configs
On 15.02.21 23:42, Saravana Kannan wrote:
Hi,
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 79b68519fe30..5036a362f52e 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1300,6 +1300,9 @@ static struct device_node *parse_interrupts(struct
device_node *np,
{
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;
wouldn't it be better to #ifdef-out the whole code in this case ?
--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
BUG: broken overlay causes very strange kernel crash
abe83 [ 48.409796] RBP: 0008 R08: R09: [ 48.409796] R10: R11: 0246 R12: [ 48.409796] R13: R14: R15: 0019 [ 76.410225] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [init:1] [ 76.410225] Modules linked in: [ 76.410225] CPU: 0 PID: 1 Comm: init Tainted: G D L 5.11.0-rc7-00105-g4fb1c4f664da-dirty #247 [ 76.410225] Hardware name: PC engines Standard PC (i440FX + PIIX, 1996)/APU3, BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 044 [ 76.410225] RIP: 0010:native_queued_spin_lock_slowpath+0x20/0x1d0 [ 76.410225] Code: 84 00 00 00 00 00 0f 1f 40 00 8b 05 fa 15 9b 00 85 c0 7e 18 ba 01 00 00 00 8b 07 85 c0 75 09 3e 0f b1 17 85 c0 78 [ 76.410225] RSP: 0018:c9013ae0 EFLAGS: 0202 [ 76.410225] RAX: 0001 RBX: 888000256000 RCX: 01ad [ 76.410225] RDX: 0001 RSI: 0001 RDI: 88800025e380 [ 76.410225] RBP: c9013ae8 R08: 88800048c268 R09: 8880019fe3f4 [ 76.410225] R10: R11: d0918a8dd08d9e89 R12: 88800025e200 [ 76.410225] R13: R14: 81895e52 R15: 88800025e380 [ 76.410225] FS: 7f1f631eb740() GS:888007a0() knlGS: [ 76.410225] CS: 0010 DS: ES: CR0: 80050033 [ 76.410225] CR2: 003a CR3: 009b4000 CR4: 06b0 [ 76.410225] Call Trace: [ 76.410225] ? _raw_spin_lock+0x20/0x30 [ 76.410225] ext2_error+0x60/0x90 [ 76.410225] ? kmem_cache_alloc+0x1a/0x150 [ 76.410225] ext2_get_inode+0x5e/0x130 [ 76.410225] ? iget_locked+0x1e3/0x1f0 [ 76.410225] ext2_iget+0x81/0x420 [ 76.410225] ext2_lookup+0x79/0xb0 [ 76.410225] __lookup_slow+0x79/0x130 [ 76.410225] walk_component+0x139/0x1b0 [ 76.410225] link_path_walk.part.0+0x224/0x350 [ 76.410225] ? path_init+0x2bd/0x3e0 [ 76.410225] path_lookupat+0x3a/0x1b0 [ 76.410225] filename_lookup+0xa5/0x170 [ 76.410225] ? __check_object_size+0x131/0x150 [ 76.410225] ? strncpy_from_user+0x53/0x140 [ 76.410225] ? getname_flags+0x47/0x170 [ 76.410225] ? __do_sys_wait4+0x84/0x90 [ 76.410225] user_path_at_empty+0x35/0x40 [ 76.410225] do_faccessat+0x7a/0x240 [ 76.410225] __x64_sys_access+0x18/0x20 [ 76.410225] do_syscall_64+0x32/0x50 [ 76.410225] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 76.410225] RIP: 0033:0x7f1f632dbc77 [ 76.410225] Code: 77 01 c3 48 8b 15 f1 b1 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 15 08 [ 76.410225] RSP: 002b:7ffe90e9bce8 EFLAGS: 0246 ORIG_RAX: 0015 [ 76.410225] RAX: ffda RBX: 0019 RCX: 7f1f632dbc77 [ 76.410225] RDX: RSI: 0006 RDI: 557fcababe83 [ 76.410225] RBP: 0008 R08: R09: [ 76.410225] R10: R11: 0246 R12: [ 76.410225] R13: R14: R15: 0019 [ 86.094296] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: -- --- 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
Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
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 often is anything but easy (as soon as we leave the field of average Joh Doe's home PC) If the usecase is to explicitly work around deployed firmware that cannot and will not be upgraded/fixed by describing the hardware using DT instead, based on just the DMI ID then we should spell that out explicitly. Okay, maybe I should have stated this more clearly. OTOH, the scope is also a little bit greater: certain external cards that don't need much special handling for the card itself, just enumerate devices (and connections between them) using existing drivers. That's a pretty common scenario in industrial backplane systems, where we have lots of different (even application specific) cards, usually composed of standard chips, that can be identified by some ID, but cannot describe themselves. We have to write lots of specific drivers for them, usually just for instantiating existing drivers. (we rarely see such code going towards mainline). A similar case (mainlined) seems to be the RCAR display unit - they're using dt overlays that are built into the driver and applied by it based on the detected DU at runtime. RCAR seems to be a pure DT platform, so that's an obvious move. APU2/3/4 is ACPI based, so I went in a different direction - but I'm now investigating how to make DT overlays work on an ACPI platform (eg. needs some initial nodes, ...) In case that's successful, I'll rework my RFC to use overlays, and it will become much smaller (my oftree core changes then won't be necessary anymore). It feels a bit like fixing a problem using a different hardware description just because we can. Look in drivers/gpio/gpiolib-acpi.c table gpiolib_acpi_quirks[]. It's just an example how this is fixed using fine granular ACPI-specific mechanisms at several places in the kernel instead of just tossing out the whole description and redoing it in device tree. I'm quite reluctant to put everything in there. Theoretically, for apu case, I could prevent enumerating the incomplete gpios there, but the actual driver setup still remains (certainly don't wanna put that into such a global place). But the original problem of having to write so much code for just instantiating generic drivers remains. And distributing knowledge of certain devices over several places doesn't feel like a good idea to me. --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
Re: [PATCH] of: base: improve error message in of_phandle_iterator_next()
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 sending it the 2nd time, missed your last mail in the mail flood :o Seems my mail sorting rules are still quite imperfect. I suspect I'm not the only one with those problems - how do you folks handle that ? --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
Re: RFC: oftree based setup of composite board devices
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 enumerated via firmware. Traditionally we had to write board specific drivers that check for board identification (DMI strings, etc), 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 together ? It's all in documentation. https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id Thanks, but I'm still unsure how this helps me. I'm not intending to touch any firmware (and expect people in the field flashing new fw). I have to live with what we find in the field (otherwise I'd just write omplete DTs for the corresponding boards and throw out ACPI :p) https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html Are you suggesting I should load SSDT overlays at runtime (from userland ?) instead of using DT ? Please, please, read documentation beforehand! I actually did read that documentation, but unfortunately it doesn't tell me how to use additional DTs on ACPI systems. You already know my apu board driver - that's my first example usecase. Sorry, but I forgot about it. Can you summarize what is your use case that really needs so intrusive and hard work? The current APU2/3/4 driver is pretty much fine (except that possibly some more bios-version specific quirks might be needed). It basically just instantiates a bunch of other devices (gpio, led, input, ...) and connects them. All of that (except for the DMI match table) already can be easily expressed in DT, so this calls for a generalization. At that point I tried to achieve the following goals: * a generic mechanism for detecting boards (and later pci cards, usb dongles, etc) and probing the devices from the corresponding DT * have everything that makes up an individual board in one DT(S) * ability to blacklist (kick out) specific devices already probed via ACPI, so they don't conflict. (*1) * match rules shall be inside the DTS * future match rules shall also check for bios versions etc * adding new boards shall be possible by just adding another DTS to the tree (not a whole module) * supporting several board variants (w/ small differences) by one DTS * sometimes existing devices (eg. enumerated by acpi) need to be kicked out (buggy firmware, ...) * can't rely on any special userland tweaks Show an example why either of the above is needed in your case and tell what is the exact issue. In the specific APU case (note that my proposal is a generic mechanism for a whole class of similar usecases), *some* bios versions already enumerate *some* gpios, later versions already enumerate some LEDs but different naming than the driver's, etc., etc. (at time of writing the driver, apu bios didn't support any of that). For preventing conflicts and consistency between all bios versions, it's IMHO better to just remove the conflicting devices if they're enumerated by bios. Yes, that driver represents hardware. MFD already has some support for composite devices. We have the auxiliary bus for some other interesting cases, etc. Depending on the hardware in question you have to choose a proper bus and locking (access synchronisation) schema. Yes, but similar to the apu case, I'd like to be able describe those devices just by a DT (instead of lots of C code). Those things could be expressed via DTS, so we don't need to write individual drivers anymore. It seems you are trying to create something like "universal quirk". Brave idea, but from my experience a fiasco is what will be out of it. The hardware has a lot of different issues and levels of issues and it is close to impossible to describe everything possible and predict the future... Good luck! Dont worry, I don't try create some one-fits-all-solution. It's just for a specific class of use cases, where we need additional devices that can't be (reliably) enumerated via firmware or buses. * need to split the information into several places (instead of having all in one DTS) * need to have one separate module board, or merge the dmi tables. Have no idea what you are talking about here, sorry. Well, for now I have the matching criteria (DMI strings) within the DT - don't need any additional code per board. For using the existing mechanisms, I would need to move that out into a separate .c file, something I'd like to avoid. My goal is having everything that describes a board into one DTS (source) file. I'm confused, you are talking about non-DT platforms in the cover-le
Re: [RFC PATCH 12/12] platform/x86/of: add support for PC Engines APU v2/3/4 boards
On 09.02.21 01:06, Rob Herring wrote:
Hi,
+/ {
+apu2x {
+compatible = "virtual,dmi-board";
+dmi-sys-vendor = "PC engines";
+dmi-board-name =
+ "APU2",
+ "apu2",
+ "PC engines apu2",
+ "APU3",
+ "apu3",
+ "PC engines apu3",
+ "APU4",
+ "apu4",
+ "PC engines apu4";
I think these DMI properties just need to be the compatible string(s).
We already have a way to do matching with DT and don't need a
secondary way. If you can
It's not easy fitting that into one string, because we've got lots of
combinations that need to be matched. In this specific case, I haven't
seen any board where the vendor name isn't an exact match of the given
string (that's why it's only one entry), but in the past seen several
boards where even this changes between bios versions. The board names,
more varying.
Something that's not reflected in this example yet: there're even more
subtle differences between production series (eg. certain pins 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 node really needs to go. It's clearly Linuxisms. It either has to
go in the kernel or userspace.
Note that the whole thing here *is* a Linuxism. This kind of DTs is
built into the kernel, not in firmware or anywhere else. This stuff is
only for cases where firmware is not giving, or giving broken
information. And it's for replacing hand-written C code by a machine
readable description.
I had to put that in, since in some cases firmware (-versions) already
enumerates some devices, but does it in a wrong or incomplete way.
So, these devices need to be removed first, before the correct ones
can be initialized. (note that this patch, for now, is just an hacking
example - some details are still broken).
If anybody has a better idea how to do that, let me know.
In general, I'd like to have everything for one board (family) in one
declarative file.
+};
+devices {
+gpio1: gpio1 {
+compatible = "amd,fch-gpio";
This of course will need to be documented.
Yes, but that's a different issue. It's still in RFC stage.
The gpio-amd-fch changes are in this patch queue for a complete example,
but probably will be upstreamed separately.
+gpio-controller;
+status = "okay";
nit: That's the default.
Okay, dropping it.
--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
Re: RFC: oftree based setup of composite board devices
On 10.02.21 11:30, Andy Shevchenko wrote: Hi, 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 board specific drivers that check for board identification (DMI strings, etc), 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 together ? You already know my apu board driver - that's my first example usecase. There're few things I don't know how to solve w/ overlays: * match rules shall be inside the DTS * future match rules shall also check for bios versions etc * adding new boards shall be possible by just adding another DTS to the tree (not a whole module) * supporting several board variants (w/ small differences) by one DTS * sometimes existing devices (eg. enumerated by acpi) need to be kicked out (buggy firmware, ...) * can't rely on any special userland tweaks The approach can be easily be extended to other kinds of composite devices, eg. PCI cards or USB dongles. What do you mean? PCI and USB are self-enumerated. What's wrong with them? In general yes, but of course you need drivers for them. Sometimes those devices are composites of other devices, wired up in some special way. Traditionally, we'd need to write a special driver that just don't do much more than instantiating other drivers. Those things could be expressed via DTS, so we don't need to write individual drivers anymore. Yet some drawbacks of the current implementation: * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based modprobing anyways) What?! https://lwn.net/Articles/233385/ `git grep -n 'MODULE_DEVICE_TABLE(dmi'` Shame on me, I really must have missed that all the time, thanks for the hint. But that has some drawbacks in my case: * need to split the information into several places (instead of having all in one DTS) * need to have one separate module board, or merge the dmi tables. My goal is having everything that describes a board into one DTS (source) file. --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
Re: RFC: oftree based setup of composite board devices
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 compiled into the ofboard driver (which itself can be a module). And yes, that's pretty much what I want. It's meant for drop-in replacement of composite board drivers, in cases where this driver doesn't do more than initializing other drivers. Therefore, it should work without any special userland actions, and it should put all board specific stuff into dtb. 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 board specific drivers that check for board identification (DMI strings, etc), then initialize the actual devices and their links (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT. This is something I've wanted to see for a while. There's use cases for DT based systems too. The example I'd like to see supported are USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then plug more than one of those in. Yes, that's also on my 2do list (eg. adcs behind some usb-i2c dongle) I think there's a couple of approaches we could take. Either support multiple root nodes as you have done or keep a single root and add child nodes to them. I think the latter would be less invasive. In the non-DT cases, we'd just always create an empty skeleton DT. A 3rd variation on a DT system is we could want to create parent nodes if they don't exist to attach this DT to so we have a full hierarchy. I'm already investigating this idea. Actually, I'm also thinking a bit further, whether for the future it could make sense converting the acpi tables into oftree at runtime. Not sure whether it's good idea, but maybe we could consolidate the platform driver probing into one, more generic mechanism. Yet some drawbacks of the current implementation: * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based modprobing anyways) I think we need to use either firmware loading or udev mechanisms to load the FDTs. In my usecase neither would not be a good idea, because: a) on common machines (eg. pc's) we can't touch firmware easily (if we could, we wouldn't need those board drivers in the first place - we'd just fix the firmware :p) b) I'd like to have my new mechanism as a drop-in replacement for existing drivers, reduce the init boilerplace to just a piece of dt. Don't wanna force users to do userland changes on a kernel upgrade. Userland-driven approach IMHO makes sense for extra devices behind some interfaces, that itself is probed otherwise, and we don't know hat the user has attached to it (eg. USB->SPI adapter). * can't reconfigure or attach to devices outside the individual DT's (eg. probed by PCI, etc) Not sure I follow. Let's take an example: I've got a PCI card with a bunch of generic chips, where we already have drivers for. A traditional driver would be probed the usual pci way, and then instantiate sub-devices directly. That's lots of boilerplace code, whose semantics could be described entirely via DT. In order to make that work, I need two things: 1. create a pci device instance (when the card is found) 2. instantiate all sub-devices with the card device as parent Another problem: I've got extra devices behind an interface that itself already is enumerated by firmware or some bus, but the extra devices aren't. (eg. acpi already enumerates some gpio's, but not what's connected to them, eg. leds, keys, ...). In this case, I somehow need to get these parent devices into my DT's scope, so the additional devices can refer to them. --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
[RFC PATCH 05/12] of: kobj: __of_attach_node_sysfs(): add optional basename parameter
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 IT consult
---
drivers/of/base.c | 2 +-
drivers/of/dynamic.c| 4 ++--
drivers/of/kobj.c | 7 +--
drivers/of/of_private.h | 6 +++---
drivers/of/unittest.c | 6 +++---
5 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 649c2a32bb48..be63493bd232 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -177,7 +177,7 @@ void __init of_core_init(void)
return;
}
for_each_of_allnodes(np) {
- __of_attach_node_sysfs(np);
+ __of_attach_node_sysfs(np, NULL);
if (np->phandle &&
!phandle_cache[of_phandle_cache_hash(np->phandle)])
phandle_cache[of_phandle_cache_hash(np->phandle)] = np;
}
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 9a824decf61f..63768f0dc60e 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -243,7 +243,7 @@ int of_attach_node(struct device_node *np)
__of_attach_node(np);
raw_spin_unlock_irqrestore(_lock, flags);
- __of_attach_node_sysfs(np);
+ __of_attach_node_sysfs(np, NULL);
mutex_unlock(_mutex);
of_reconfig_notify(OF_RECONFIG_ATTACH_NODE, );
@@ -635,7 +635,7 @@ static int __of_changeset_entry_apply(struct
of_changeset_entry *ce)
switch (ce->action) {
case OF_RECONFIG_ATTACH_NODE:
- __of_attach_node_sysfs(ce->np);
+ __of_attach_node_sysfs(ce->np, NULL);
break;
case OF_RECONFIG_DETACH_NODE:
__of_detach_node_sysfs(ce->np);
diff --git a/drivers/of/kobj.c b/drivers/of/kobj.c
index a32e60b024b8..511d7e8b9068 100644
--- a/drivers/of/kobj.c
+++ b/drivers/of/kobj.c
@@ -112,20 +112,23 @@ void __of_update_property_sysfs(struct device_node *np,
struct property *newprop
__of_add_property_sysfs(np, newprop);
}
-int __of_attach_node_sysfs(struct device_node *np)
+int __of_attach_node_sysfs(struct device_node *np, const char *basename)
{
const char *name;
struct kobject *parent;
struct property *pp;
int rc;
+ if (!basename)
+ basename = "base";
+
if (!of_kset)
return 0;
np->kobj.kset = of_kset;
if (!np->parent) {
/* Nodes without parents are new top level trees */
- name = safe_name(_kset->kobj, "base");
+ name = safe_name(_kset->kobj, basename);
parent = NULL;
} else {
name = safe_name(>parent->kobj, kbasename(np->full_name));
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index d9e6a324de0a..371f4da77161 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -63,7 +63,7 @@ int __of_add_property_sysfs(struct device_node *np, struct
property *pp);
void __of_remove_property_sysfs(struct device_node *np, struct property *prop);
void __of_update_property_sysfs(struct device_node *np, struct property
*newprop,
struct property *oldprop);
-int __of_attach_node_sysfs(struct device_node *np);
+int __of_attach_node_sysfs(struct device_node *np, const char *basename);
void __of_detach_node_sysfs(struct device_node *np);
#else
static inline int __of_add_property_sysfs(struct device_node *np, struct
property *pp)
@@ -73,7 +73,7 @@ static inline int __of_add_property_sysfs(struct device_node
*np, struct propert
static inline void __of_remove_property_sysfs(struct device_node *np, struct
property *prop) {}
static inline void __of_update_property_sysfs(struct device_node *np,
struct property *newprop, struct property *oldprop) {}
-static inline int __of_attach_node_sysfs(struct device_node *np)
+static inline int __of_attach_node_sysfs(struct device_node *np, const char
*basename)
{
return 0;
}
@@ -135,7 +135,7 @@ extern int __of_update_property(struct device_node *np,
extern void __of_update_property_sysfs(struct device_node *np,
struct property *newprop, struct property *oldprop);
-extern int __of_attach_node_sysfs(struct device_node *np);
+extern int __of_attach_node_sysfs(struct device_node *np, const char
*basename);
extern void __of_detach_node(struct device_node *np);
extern void __of_detach_node_sysfs(struct device_node *np);
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index eb51bc147440..caf4ade8b141 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -1391,7 +1391,7 @@ static void attach_node_and_children(struct device_node
*np)
of_node_clear_flag(np, OF_DETACHED);
raw_spi
[RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
Lots of boards have extra devices that can't be fully probed via bus'es
(like PCI) or generic firmware mechanisms like ACPI. Often those capabilities
are just partial or even highly depend on firmware version.
Instead of hand-writing board specific drivers merely for the correct
initialization / parameterization of generic drivers, hereby introducing
a generic mechanism, using the already well supported oftree.
These oftrees are compiled into the driver, which first tries to match
machine identifications (eg. DMI strings) against rules defined in the
individual oftrees, and 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 | 2 +
drivers/platform/Makefile | 1 +
drivers/platform/of/Kconfig | 41 ++
drivers/platform/of/Makefile | 5 ++
drivers/platform/of/drv.c | 123 +
drivers/platform/of/init.c| 126 ++
drivers/platform/of/ofboard.h | 8 +++
7 files changed, 306 insertions(+)
create mode 100644 drivers/platform/of/Kconfig
create mode 100644 drivers/platform/of/Makefile
create mode 100644 drivers/platform/of/drv.c
create mode 100644 drivers/platform/of/init.c
create mode 100644 drivers/platform/of/ofboard.h
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 18fc6a08569e..9ac6d4e2a762 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -15,3 +15,5 @@ source "drivers/platform/mellanox/Kconfig"
source "drivers/platform/olpc/Kconfig"
source "drivers/platform/surface/Kconfig"
+
+source "drivers/platform/of/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index 4de08ef4ec9d..ca4d74701fd7 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/
obj-$(CONFIG_GOLDFISH) += goldfish/
obj-$(CONFIG_CHROME_PLATFORMS) += chrome/
obj-$(CONFIG_SURFACE_PLATFORMS)+= surface/
+obj-$(CONFIG_PLATFORM_OF_DRV) += of/
diff --git a/drivers/platform/of/Kconfig b/drivers/platform/of/Kconfig
new file mode 100644
index ..a0b5a641a7c6
--- /dev/null
+++ b/drivers/platform/of/Kconfig
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# X86 Platform Specific Drivers
+#
+
+menuconfig PLATFORM_OF_DRV
+ tristate "Platform support via device tree"
+ select OF
+ select OF_FLATTREE
+ help
+ Say Y here to get to see options for board support that's initialized
+ via compiled-in flattened device trees.
+
+ This is entirely independent from traditional DT-based booting (or DT
+ overlays) and meant for additional devices on non-OF-based (eg. APCI)
+ boards or composite devices behind probing-capable busses (eg. PCI).
+
+ Instead of writing individual drivers for just the initialization of
+ subdevices, this option provides a generic mechanism for describing
+ these devices via device tree.
+
+ If you say N, all options in this submenu will be skipped and
disabled.
+
+if PLATFORM_OF_DRV
+
+config PLATFORM_OF_DRV_SYSFS_DTB
+ bool "Expose device tree binaries in sysfs"
+ default y
+ depends on SYSFS
+ help
+ Say Y here to enable exposing device tree binaries at /sys/firmware.
+
+config PLATFORM_OF_DRV_SYSFS_DT
+ bool "Expose parsed device tree in sysfs"
+ default y
+ depends on SYSFS
+ help
+ Say Y here to enable exposing device tree nodes at
+ /sys/firmware/devicetree.
+
+endif # PLATFORM_OF_DRV
diff --git a/drivers/platform/of/Makefile b/drivers/platform/of/Makefile
new file mode 100644
index ..84cf3003c500
--- /dev/null
+++ b/drivers/platform/of/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+ofboard-y := init.o drv.o
+
+obj-$(CONFIG_PLATFORM_OF_DRV) += ofboard.o
diff --git a/drivers/platform/of/drv.c b/drivers/platform/of/drv.c
new file mode 100644
index ..ff7006c24cf7
--- /dev/null
+++ b/drivers/platform/of/drv.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2021 metux IT consult
+ * Author: Enrico Weigelt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ofboard.h"
+
+static bool __init ofboard_match_dmi(struct device *dev)
+{
+#ifdef CONFIG_DMI
+ const char *board = dmi_get_system_info(DMI_BOARD_NAME);
+ const char *vendor = dmi_get_system_info(DMI_SYS_VENDOR);
+ const struct device_node *node = dev->of_node;
+
+ if (!of_match_string(node, "dmi-sys-vendor", vendor))
+ return false
[RFC PATCH 06/12] of: kobj: introduce of_attach_tree_sysfs()
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/kobj.c | 17 +
include/linux/of.h | 7 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/of/kobj.c b/drivers/of/kobj.c
index 511d7e8b9068..96dc5a2753f4 100644
--- a/drivers/of/kobj.c
+++ b/drivers/of/kobj.c
@@ -166,3 +166,20 @@ void __of_detach_node_sysfs(struct device_node *np)
of_node_put(np);
}
+
+void of_attach_tree_sysfs(struct device_node *root, const char* base)
+{
+ struct device_node *np;
+
+ if (!root)
+ return;
+
+ /* need to from our parent, so we don't traverse above our root,
+* if it's actually a subtree */
+ root->parent = NULL;
+
+ __of_attach_node_sysfs(root, base);
+ for_each_of_allnodes_from(root, np)
+ __of_attach_node_sysfs(np, base);
+}
+EXPORT_SYMBOL_GPL(of_attach_tree_sysfs);
diff --git a/include/linux/of.h b/include/linux/of.h
index 3612429632f4..c2fb12ce07f9 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -421,6 +421,8 @@ extern int of_update_property(struct device_node *np,
struct property *newprop);
extern int of_attach_node(struct device_node *);
extern int of_detach_node(struct device_node *);
+extern void of_attach_tree_sysfs(struct device_node *root, const char* base);
+
#define of_match_ptr(_ptr) (_ptr)
/**
@@ -1010,6 +1012,11 @@ static inline phys_addr_t
of_dma_get_max_cpu_address(struct device_node *np)
return PHYS_ADDR_MAX;
}
+static inline void of_attach_tree_sysfs(struct device_node *root,
+ const char* base)
+{
+}
+
#define of_match_ptr(_ptr) NULL
#define of_match_node(_matches, _node) NULL
#endif /* CONFIG_OF */
--
2.11.0
[RFC PATCH 12/12] platform/x86/of: add support for PC Engines APU v2/3/4 boards
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/apu2x.dts | 86 +++
drivers/platform/of/init.c| 7
4 files changed, 110 insertions(+)
create mode 100644 drivers/platform/of/apu2x.dts
diff --git a/drivers/platform/of/Kconfig b/drivers/platform/of/Kconfig
index a0b5a641a7c6..e13b6ee8c316 100644
--- a/drivers/platform/of/Kconfig
+++ b/drivers/platform/of/Kconfig
@@ -38,4 +38,19 @@ config PLATFORM_OF_DRV_SYSFS_DT
Say Y here to enable exposing device tree nodes at
/sys/firmware/devicetree.
+config PLATFORM_OF_DRV_PCENGINES_APU2
+ bool "Support PC Engines APU2/3/4 mainboards"
+ depends on INPUT
+ depends on GPIOLIB
+ depends on X86
+ select GPIO_AMD_FCH
+ select KEYBOARD_GPIO_POLLED
+ select LEDS_GPIO
+ select INPUT_KEYBOARD
+ help
+ Say Y to enable devicetree based support for PC Engines APU2/3/4
+ mainboards. This supersedes the older pcengines-apu2 driver.
+
+ Supports Gpios, front panel LEDs and front button.
+
endif # PLATFORM_OF_DRV
diff --git a/drivers/platform/of/Makefile b/drivers/platform/of/Makefile
index 84cf3003c500..dd4a13c18f16 100644
--- a/drivers/platform/of/Makefile
+++ b/drivers/platform/of/Makefile
@@ -2,4 +2,6 @@
ofboard-y := init.o drv.o
+ofboard-$(CONFIG_PLATFORM_OF_DRV_PCENGINES_APU2) += apu2x.dtb.o
+
obj-$(CONFIG_PLATFORM_OF_DRV) += ofboard.o
diff --git a/drivers/platform/of/apu2x.dts b/drivers/platform/of/apu2x.dts
new file mode 100644
index ..c16a59eb2a0e
--- /dev/null
+++ b/drivers/platform/of/apu2x.dts
@@ -0,0 +1,86 @@
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+
+/ {
+apu2x {
+compatible = "virtual,dmi-board";
+dmi-sys-vendor = "PC engines";
+dmi-board-name =
+ "APU2",
+ "apu2",
+ "PC engines apu2",
+ "APU3",
+ "apu3",
+ "PC engines apu3",
+ "APU4",
+ "apu4",
+ "PC engines apu4";
+unbind {
+acpi = "PNP0076:00", "PNP0B00:00";
+platform = "platform-framebuffer.0", "PNP0103:00";
+};
+devices {
+gpio1: gpio1 {
+compatible = "amd,fch-gpio";
+gpio-controller;
+status = "okay";
+ngpios=<7>;
+#gpio-cells=<2>;
+gpio-regs = <
+AMD_FCH_GPIO_REG_GPIO57 // led1
+AMD_FCH_GPIO_REG_GPIO58 // led2
+AMD_FCH_GPIO_REG_GPIO59_DEVSLP1 // led3
+AMD_FCH_GPIO_REG_GPIO32_GE1 // modesw
+AMD_FCH_GPIO_REG_GPIO33_GE2 // simawap
+AMD_FCH_GPIO_REG_GPIO55_DEVSLP0 // mpcie2
+AMD_FCH_GPIO_REG_GPIO51 // mpcie3
+>;
+gpio-line-names =
+"front-led1",
+"front-led2",
+"front-led3",
+"front-button",
+"simswap",
+"mpcie2_reset",
+"mpcie3_reset";
+};
+front-leds {
+compatible = "gpio-leds";
+led@0 {
+gpios = < 0 GPIO_ACTIVE_HIGH>;
+color = ;
+default-state = "keep";
+label = "apu:green:1";
+};
+led@1 {
+gpios = < 1 GPIO_ACTIVE_HIGH>;
+color = ;
+default-state = "keep";
+label = "apu:green:2";
+};
+led@2 {
+gpios = < 2 GPIO_ACTIVE_HIGH>;
+color = ;
+default-state = "keep";
+label = "apu:green:3";
+};
+};
+front-keys {
+compatible = "gpio-keys-polled";
+address-cells = <1>;
+size-cells = <0>;
+poll-interval = <100>;
+button@1 {
+linux,code = ;
+label = "front button";
+debounce-interval = <10>;
+gpios = < 3 GPIO_ACTIVE_HIGH>;
+};
+};
+};
+};
+};
diff
[RFC PATCH 09/12] drivers: base: reintroduce find_bus()
---
drivers/base/bus.c | 14 ++
include/linux/device/bus.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 450d3ed6cf1f..a06ae2786092 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -754,13 +754,19 @@ EXPORT_SYMBOL_GPL(device_reprobe);
*
* Note that kset_find_obj increments bus' reference count.
*/
-#if 0
-struct bus_type *find_bus(char *name)
+struct bus_type *find_bus(const char *name)
{
struct kobject *k = kset_find_obj(bus_kset, name);
- return k ? to_bus(k) : NULL;
+ struct subsys_private *subsys_priv;
+
+ if (!k)
+ return NULL;
+
+ subsys_priv = container_of(to_kset(k), struct subsys_private, subsys);
+
+ return subsys_priv->bus;
}
-#endif /* 0 */
+EXPORT_SYMBOL_GPL(find_bus);
static int bus_add_groups(struct bus_type *bus,
const struct attribute_group **groups)
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 36a1dae26c95..b4cbcfe176c5 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -254,6 +254,8 @@ void bus_sort_breadthfirst(struct bus_type *bus,
int (*compare)(const struct device *a,
const struct device *b));
+struct bus_type *find_bus(const char *name);
+
/**
* bus_unregister_device_by_name - remove device by bus id from specific bus
* and unregister it from device core
--
2.11.0
[RFC PATCH 01/12] of: base: improve error message in of_phandle_iterator_next()
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/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1297,8 +1297,8 @@ int of_phandle_iterator_next(struct of_phandle_iterator
*it)
if (it->cells_name) {
if (!it->node) {
- pr_err("%pOF: could not find phandle\n",
- it->parent);
+ pr_err("%pOF: could not find phandle %d\n",
+ it->parent, it->phandle);
goto err;
}
--
2.11.0
[RFC PATCH 07/12] gpio: amd-fch: add oftree probing support
Add support for probing via device tree.
---
drivers/gpio/gpio-amd-fch.c | 58 +
include/dt-bindings/gpio/amd-fch-gpio.h | 36 +++
include/linux/platform_data/gpio/gpio-amd-fch.h | 24 ++
3 files changed, 98 insertions(+), 20 deletions(-)
create mode 100644 include/dt-bindings/gpio/amd-fch-gpio.h
diff --git a/drivers/gpio/gpio-amd-fch.c b/drivers/gpio/gpio-amd-fch.c
index 2a21354ed6a0..32024f99dae5 100644
--- a/drivers/gpio/gpio-amd-fch.c
+++ b/drivers/gpio/gpio-amd-fch.c
@@ -136,12 +136,61 @@ static int amd_fch_gpio_request(struct gpio_chip *chip,
return 0;
}
+static struct amd_fch_gpio_pdata *load_pdata(struct device *dev)
+{
+ struct amd_fch_gpio_pdata *pdata;
+ int ret;
+
+ pdata = devm_kzalloc(dev, sizeof(struct amd_fch_gpio_pdata),
+GFP_KERNEL);
+ if (!pdata)
+ goto nomem;
+
+ pdata->gpio_num = of_property_count_elems_of_size(dev->of_node,
+ "gpio-regs",
+ sizeof(u32));
+ pdata->gpio_reg = devm_kzalloc(dev, sizeof(int)*pdata->gpio_num,
+ GFP_KERNEL);
+ if (!pdata->gpio_reg)
+ goto nomem;
+
+ pdata->gpio_names = devm_kzalloc(dev, sizeof(char*)*pdata->gpio_num,
+GFP_KERNEL);
+ if (!pdata->gpio_names)
+ goto nomem;
+
+ ret = of_property_read_variable_u32_array(dev->of_node, "gpio-regs",
+ pdata->gpio_reg,
+ pdata->gpio_num,
+ pdata->gpio_num);
+ if (ret != pdata->gpio_num) {
+ dev_err(dev, "failed reading gpio-regs from DT: %d\n", ret);
+ return NULL;
+ }
+
+ ret = of_property_read_string_array(dev->of_node, "gpio-line-names",
+ pdata->gpio_names, pdata->gpio_num);
+ if (ret != pdata->gpio_num) {
+ dev_err(dev, "failed reading gpio-names from DT: %d\n", ret);
+ return NULL;
+ }
+
+ return pdata;
+
+nomem:
+ dev_err(dev, "load_pdata: failed allocating memory\n");
+ return NULL;
+}
+
static int amd_fch_gpio_probe(struct platform_device *pdev)
{
struct amd_fch_gpio_priv *priv;
struct amd_fch_gpio_pdata *pdata;
pdata = dev_get_platdata(>dev);
+ if (!pdata)
+ pdata = load_pdata(>dev);
+
if (!pdata) {
dev_err(>dev, "no platform_data\n");
return -ENOENT;
@@ -165,6 +214,9 @@ static int amd_fch_gpio_probe(struct platform_device *pdev)
priv->gc.get_direction = amd_fch_gpio_get_direction;
priv->gc.get= amd_fch_gpio_get;
priv->gc.set= amd_fch_gpio_set;
+#ifdef CONFIG_OF_GPIO
+ priv->gc.of_node= pdev->dev.of_node;
+#endif
spin_lock_init(>lock);
@@ -177,9 +229,15 @@ static int amd_fch_gpio_probe(struct platform_device *pdev)
return devm_gpiochip_add_data(>dev, >gc, priv);
}
+static const struct of_device_id amd_fch_gpio_of_match[] = {
+ { .compatible = "amd,fch-gpio" },
+ {}
+};
+
static struct platform_driver amd_fch_gpio_driver = {
.driver = {
.name = AMD_FCH_GPIO_DRIVER_NAME,
+ .of_match_table = amd_fch_gpio_of_match,
},
.probe = amd_fch_gpio_probe,
};
diff --git 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 definitions
+ *
+ * Copyright (C) 2020 metux IT consult
+ * Author: Enrico Weigelt
+ *
+ */
+
+#ifndef __DT_BINDINGS_GPIO_AMD_FCH_REGS_H
+#define __DT_BINDINGS_GPIO_AMD_FCH_REGS_H
+
+/*
+ * gpio registers addresses
+ *
+ * these regs need to be assigned by board setup, since they're wired
+ * in very board specifici was, rarely documented, this should not be
+ * available to users.
+ */
+#define AMD_FCH_GPIO_REG_GPIO490x40
+#define AMD_FCH_GPIO_REG_GPIO500x41
+#define AMD_FCH_GPIO_REG_GPIO510x42
+#define AMD_FCH_GPIO_REG_GPIO55_DEVSLP00x43
+#define AMD_FCH_GPIO_REG_GPIO570x44
+#define AMD_FCH_GPIO_REG_GPIO580x45
+#define AMD_FCH_GPIO_REG_GPIO59_DEVSLP10x46
+#define AMD_FCH_GPIO_REG_GPIO640x47
+#define AMD_FCH_GPIO_REG_GPIO68
[RFC PATCH 10/12] export bus_get() / bus_put()
---
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 struct kset *system_kset;
static int __must_check bus_rescan_devices_helper(struct device *dev,
void *data);
-static struct bus_type *bus_get(struct bus_type *bus)
+struct bus_type *bus_get(struct bus_type *bus)
{
if (bus) {
kset_get(>p->subsys);
@@ -47,12 +47,14 @@ static struct bus_type *bus_get(struct bus_type *bus)
}
return NULL;
}
+EXPORT_SYMBOL_GPL(bus_get);
-static void bus_put(struct bus_type *bus)
+void bus_put(struct bus_type *bus)
{
if (bus)
kset_put(>p->subsys);
}
+EXPORT_SYMBOL_GPL(bus_put);
static ssize_t drv_attr_show(struct kobject *kobj, struct attribute *attr,
char *buf)
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index b4cbcfe176c5..8d6b45df0a82 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -120,6 +120,9 @@ extern void bus_unregister(struct bus_type *bus);
extern int __must_check bus_rescan_devices(struct bus_type *bus);
+struct bus_type *bus_get(struct bus_type *bus);
+void bus_put(struct bus_type *bus);
+
struct bus_attribute {
struct attributeattr;
ssize_t (*show)(struct bus_type *bus, char *buf);
--
2.11.0
[RFC PATCH 08/12] drivers: base: introduce bus_remove_device_by_name()
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/base/bus.c | 16
include/linux/device/bus.h | 9 +
2 files changed, 25 insertions(+)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index a9c23ecebc7c..450d3ed6cf1f 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -178,6 +178,22 @@ static const struct kset_uevent_ops bus_uevent_ops = {
static struct kset *bus_kset;
+int bus_unregister_device_by_name(struct bus_type *bus, const char *name)
+{
+ struct device *dev;
+
+ dev = bus_find_device_by_name(bus, NULL, name);
+ if (!dev)
+ return -ENOENT;
+
+ device_driver_detach(dev);
+ device_unregister(dev);
+ put_device(dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(bus_unregister_device_by_name);
+
/* Manually detach a device from its associated driver. */
static ssize_t unbind_store(struct device_driver *drv, const char *buf,
size_t count)
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 1ea5e1d1545b..36a1dae26c95 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -253,6 +253,15 @@ int bus_for_each_drv(struct bus_type *bus, struct
device_driver *start,
void bus_sort_breadthfirst(struct bus_type *bus,
int (*compare)(const struct device *a,
const struct device *b));
+
+/**
+ * bus_unregister_device_by_name - remove device by bus id from specific bus
+ * and unregister it from device core
+ * @bus: bus type
+ * @name: name of the device to remove
+ */
+int bus_unregister_device_by_name(struct bus_type *bus, const char *name);
+
/*
* Bus notifiers: Get notified of addition/removal of devices
* and binding/unbinding of drivers to devices.
--
2.11.0
[RFC PATCH 03/12] of: base: record root node in interator and use it for phandle lookup
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 detached case, phandle cache can't be used, so we have a
little performance penalty on repeated phandle lookups.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/of/base.c | 13 -
include/linux/of.h | 1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 6b3d1e817808..e5ef611ed233 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1249,6 +1249,7 @@ int of_phandle_iterator_init(struct of_phandle_iterator
*it,
{
const __be32 *list;
int size;
+ struct device_node *walk;
memset(it, 0, sizeof(*it));
@@ -1270,6 +1271,16 @@ int of_phandle_iterator_init(struct of_phandle_iterator
*it,
it->phandle_end = list;
it->cur = list;
+ /*
+* find the root of our tree and record it, if we're dealing with an
+* detached oftree - in non-detached case, we record NULL, for clear
+* distinction between these two cases.
+*/
+ for (walk=(struct device_node*)np;
+walk->parent;
+walk=(struct device_node*)walk->parent);
+ it->root = ((walk == of_root) ? NULL : walk);
+
return 0;
}
EXPORT_SYMBOL_GPL(of_phandle_iterator_init);
@@ -1297,7 +1308,7 @@ int of_phandle_iterator_next(struct of_phandle_iterator
*it)
* Find the provider node and parse the #*-cells property to
* determine the argument length.
*/
- it->node = of_find_node_by_phandle(it->phandle);
+ it->node = of_find_node_by_phandle_from(it->root, it->phandle);
if (it->cells_name) {
if (!it->node) {
diff --git a/include/linux/of.h b/include/linux/of.h
index c285141653e5..dbf2c7442389 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -82,6 +82,7 @@ struct of_phandle_iterator {
const char *cells_name;
int cell_count;
const struct device_node *parent;
+ struct device_node *root;
/* List size information */
const __be32 *list_end;
--
2.11.0
[RFC PATCH 04/12] of: base: introduce of_match_string()
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
include/linux/of.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index e5ef611ed233..649c2a32bb48 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -287,6 +287,38 @@ const void *of_get_property(const struct device_node *np,
const char *name,
EXPORT_SYMBOL(of_get_property);
/*
+ * of_match_string - match a propery against given string
+ * @node: device_node to look up at
+ * @name: name of the property
+ * @value: value to match against
+ *
+ * Look for property by name and match all string elements against value.
+ * Returns true if the property exists and any one of the string elements
+ * matches the given value.
+ */
+bool of_match_string(const struct device_node *node, const char* name,
+const char* value)
+{
+ struct property *prop;
+ const char *walk;
+
+ if (!name || !value)
+ return false;
+
+ prop = of_find_property(node, name, NULL);
+ if (!prop)
+ return false;
+
+ for (walk=of_prop_next_string(prop, NULL); walk;
+walk=of_prop_next_string(prop, walk)) {
+ if (strcmp(walk, value)==0)
+ return true;
+ }
+ return true;
+}
+EXPORT_SYMBOL_GPL(of_match_string);
+
+/*
* arch_match_cpu_phys_id - Match the given logical CPU and physical id
*
* @cpu: logical cpu index of a core/thread
diff --git a/include/linux/of.h b/include/linux/of.h
index dbf2c7442389..3612429632f4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -355,6 +355,8 @@ extern bool of_device_is_big_endian(const struct
device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
+extern bool of_match_string(const struct device_node *node, const char* name,
+ const char* value);
extern struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
extern struct device_node *of_get_next_cpu_node(struct device_node *prev);
extern struct device_node *of_get_cpu_state_node(struct device_node *cpu_node,
--
2.11.0
RFC: oftree based setup of composite board devices
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 board specific drivers that check for board identification (DMI strings, etc), then initialize the actual devices and their links (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT. This patch queue does a bunch of preparations in oftree code, so we can support multiple fully independent DT's (not using DT overlays). And then adds a generic driver parses compiled-in fdt blobs, checks for mathing DMI strings and initializes the devices. As an example, the last patch adds an alternative implementation for the PC engines APU2/3/4 board family based on device tree. The approach can be easily be extended to other kinds of composite devices, eg. PCI cards or USB dongles. Yet some drawbacks of the current implementation: * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based modprobing anyways) * can't reconfigure or attach to devices outside the individual DT's (eg. probed by PCI, etc) have fun, --mtx
[RFC PATCH 02/12] of: base: introduce of_find_node_by_phandle_from()
Introducing a variant of of_find_node_by_phandle() that starts off a
different root node. This root can also point to an detached oftree,
which has no relations to primary oftree, even on platforms that natively
don't have oftree at all (eg. ACPI platforms).
Note that this has nothing to do 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/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1187,13 +1187,15 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
EXPORT_SYMBOL_GPL(of_modalias_node);
/**
- * of_find_node_by_phandle - Find a node given a phandle
+ * of_find_node_by_phandle_from - Find a node given a phandle
+ * @root: root of the tree (on NULL default to of_root)
* @handle:phandle of the node to find
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
*/
-struct device_node *of_find_node_by_phandle(phandle handle)
+struct device_node *of_find_node_by_phandle_from(struct device_node *root,
+phandle handle)
{
struct device_node *np = NULL;
unsigned long flags;
@@ -1211,19 +1213,21 @@ struct device_node *of_find_node_by_phandle(phandle
handle)
np = phandle_cache[handle_hash];
if (!np) {
- for_each_of_allnodes(np)
+ for_each_of_allnodes_from(root, np) {
if (np->phandle == handle &&
!of_node_check_flag(np, OF_DETACHED)) {
- phandle_cache[handle_hash] = np;
+ if (!root)
+ phandle_cache[handle_hash] = np;
break;
}
+ }
}
of_node_get(np);
raw_spin_unlock_irqrestore(_lock, flags);
return np;
}
-EXPORT_SYMBOL(of_find_node_by_phandle);
+EXPORT_SYMBOL(of_find_node_by_phandle_from);
void of_print_phandle_args(const char *msg, const struct of_phandle_args *args)
{
diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..c285141653e5 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -282,7 +282,12 @@ static inline struct device_node
*of_find_node_by_path(const char *path)
return of_find_node_opts_by_path(path, NULL);
}
-extern struct device_node *of_find_node_by_phandle(phandle handle);
+extern struct device_node *of_find_node_by_phandle_from(
+ struct device_node* root, phandle handle);
+static inline struct device_node *of_find_node_by_phandle(phandle handle)
+{
+ return of_find_node_by_phandle_from(NULL, handle);
+}
extern struct device_node *of_get_parent(const struct device_node *node);
extern struct device_node *of_get_next_parent(struct device_node *node);
extern struct device_node *of_get_next_child(const struct device_node *node,
--
2.11.0
[PATCH] of: base: improve error message in of_phandle_iterator_next()
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/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1297,8 +1297,8 @@ int of_phandle_iterator_next(struct of_phandle_iterator
*it)
if (it->cells_name) {
if (!it->node) {
- pr_err("%pOF: could not find phandle\n",
- it->parent);
+ pr_err("%pOF: could not find phandle %d\n",
+ it->parent, it->phandle);
goto err;
}
--
2.11.0
[PATCH] firmware: Kconfig: fix indentions
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
index 3f14dffb9669..490931b800ee 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -86,8 +86,8 @@ config EDD
BIOS tries boot from. This information is then exported via sysfs.
This option is experimental and is known to fail to boot on some
- obscure configurations. Most disk controller BIOS vendors do
- not yet implement this feature.
+ obscure configurations. Most disk controller BIOS vendors do
+ not yet implement this feature.
config EDD_OFF
bool "Sets default behavior for EDD detection to off"
@@ -99,14 +99,14 @@ config EDD_OFF
using the kernel parameter 'edd={on|skipmbr|off}'.
config FIRMWARE_MEMMAP
-bool "Add firmware-provided memory map to sysfs" if EXPERT
-default X86
-help
- Add the firmware-provided (unmodified) memory map to
/sys/firmware/memmap.
- That memory map is used for example by kexec to set up parameter area
- for the next kernel, but can also be used for debugging purposes.
+ bool "Add firmware-provided memory map to sysfs" if EXPERT
+ default X86
+ help
+ Add the firmware-provided (unmodified) memory map to
/sys/firmware/memmap.
+ That memory map is used for example by kexec to set up parameter area
+ for the next kernel, but can also be used for debugging purposes.
- See also Documentation/ABI/testing/sysfs-firmware-memmap.
+ See also Documentation/ABI/testing/sysfs-firmware-memmap.
config EFI_PCDP
bool "Console device selection via EFI PCDP or HCDP table"
@@ -133,9 +133,9 @@ config EFI_PCDP
<http://www.dig64.org/specifications/>
config DMIID
-bool "Export DMI identification via sysfs to userspace"
-depends on DMI
-default y
+ bool "Export DMI identification via sysfs to userspace"
+ depends on DMI
+ default y
help
Say Y here if you want to query SMBIOS/DMI system identification
information from userspace through /sys/class/dmi/id/ or if you want
@@ -170,7 +170,7 @@ config ISCSI_IBFT
select ISCSI_BOOT_SYSFS
select ISCSI_IBFT_FIND if X86
depends on ACPI && SCSI && SCSI_LOWLEVEL
- default n
+ default n
help
This option enables support for detection and exposing of iSCSI
Boot Firmware Table (iBFT) via sysfs to userspace. If you wish to
--
2.11.0
[PATCH] of: base: improve error msg in of_phandle_iterator_next()
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/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1297,8 +1297,8 @@ int of_phandle_iterator_next(struct of_phandle_iterator
*it)
if (it->cells_name) {
if (!it->node) {
- pr_err("%pOF: could not find phandle\n",
- it->parent);
+ pr_err("%pOF: could not find phandle %d\n",
+ it->parent, it->phandle);
goto err;
}
--
2.11.0
[PATCH] scripts: kconfig: fix HOSTCC call
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, metux IT consult
---
scripts/kconfig/mconf-cfg.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
index fcd4acd4e9cb..40fa449ed049 100755
--- a/scripts/kconfig/mconf-cfg.sh
+++ b/scripts/kconfig/mconf-cfg.sh
@@ -35,7 +35,7 @@ fi
# As a final fallback before giving up, check if $HOSTCC knows of a default
# ncurses installation (e.g. from a vendor-specific sysroot).
-if echo '#include ' | "${HOSTCC}" -E - >/dev/null 2>&1; then
+if echo '#include ' | ${HOSTCC} -E - >/dev/null ; then
echo cflags=\"-D_GNU_SOURCE\"
echo libs=\"-lncurses\"
exit 0
--
2.11.0
[PATCH v2] arch: consolidate pm_power_off callback
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 forgotten removal of pm_power_off in arch/powerpc, as reported by lkp
---
arch/alpha/kernel/process.c| 6 --
arch/arc/kernel/reset.c| 3 ---
arch/arm/kernel/reboot.c | 6 ++
arch/arm64/kernel/process.c| 6 +-
arch/c6x/kernel/process.c | 10 ++
arch/csky/kernel/power.c | 10 +++---
arch/h8300/kernel/process.c| 3 ---
arch/hexagon/kernel/reset.c| 3 ---
arch/ia64/kernel/process.c | 5 +
arch/m68k/kernel/process.c | 3 ---
arch/microblaze/kernel/process.c | 3 ---
arch/mips/kernel/reset.c | 6 +-
arch/nds32/kernel/process.c| 7 ++-
arch/nios2/kernel/process.c| 3 ---
arch/openrisc/kernel/process.c | 3 ---
arch/parisc/kernel/process.c | 9 +++--
arch/powerpc/kernel/setup-common.c | 8 ++--
arch/powerpc/xmon/xmon.c | 4 ++--
arch/riscv/kernel/reset.c | 9 -
arch/s390/kernel/setup.c | 3 ---
arch/sh/kernel/reboot.c| 6 +-
arch/x86/kernel/reboot.c | 15 ---
arch/x86/xen/enlighten_pv.c| 4 ++--
arch/xtensa/kernel/process.c | 4
include/linux/pm.h | 2 ++
kernel/reboot.c| 10 ++
26 files changed, 42 insertions(+), 109 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 6c71554206cc..df0df869751d 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -43,12 +43,6 @@
#include "proto.h"
#include "pci_impl.h"
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
#ifdef CONFIG_ALPHA_WTINT
/*
* Sleep the CPU.
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index fd6c3eb930ba..3a27b6a202d4 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,6 +26,3 @@ void machine_power_off(void)
/* FIXME :: power off ??? */
machine_halt();
}
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 0ce388f15422..9e1bf0e9b3e0 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -19,8 +20,6 @@ typedef void (*phys_reset_t)(unsigned long, bool);
* Function pointers to optional machine specific functions
*/
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
/*
* A temporary stack to use for CPU reset. This is static so that we
@@ -118,8 +117,7 @@ void machine_power_off(void)
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
}
/*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6616486a58fe..a5d4c1e80abd 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -67,9 +67,6 @@ EXPORT_SYMBOL(__stack_chk_guard);
/*
* Function pointers to optional machine specific functions
*/
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
static void noinstr __cpu_do_idle(void)
@@ -172,8 +169,7 @@ void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
}
/*
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 9f4fd6a40a10..8b4b24476162 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -25,12 +26,6 @@ void (*c6x_halt)(void);
extern asmlinkage void ret_from_fork(void);
extern asmlinkage void ret_from_kernel_thread(void);
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
void arch_cpu_idle(void)
{
unsigned long tmp;
@@ -71,8 +66,7 @@ void machine_halt(void)
void machine_power_off(void)
{
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
halt_loop();
}
diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
index 923ee4e381b8..c702e66ce03a 100644
--- a/arch/csky/kernel/power.c
+++ b/arch/csky/kernel/power.c
@@ -2,23 +2,19 @@
// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
#include
-
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
+#include
void ma
Re: [PATCH] arch: consolidate pm_power_off callback
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 >> code duplication in all individual archs. >> >> Signed-off-by: Enrico Weigelt, metux IT consult > > Thanks for your patch! > >> --- a/arch/alpha/kernel/process.c >> +++ b/arch/alpha/kernel/process.c >> @@ -43,12 +43,6 @@ >> #include "proto.h" >> #include "pci_impl.h" >> >> -/* >> - * Power off function, if any >> - */ >> -void (*pm_power_off)(void) = machine_power_off; > > Assignments like these are lost in the conversion. Yes, but this doesn't seem to be ever called anyways. (in arch/alpha) And, BTW, letting it point to machine_power_off() doesn't make much sense, since it's the arch's machine_power_off() function, who're calling pm_power_off(). Actually, we could remove pm_power_off completely from here, assuming nobody would *build* any drivers that register themselves into pm_power_off. If you feel better with it, I could post a patch that just removes pm_power_off from arch/alpha. --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
Re: [PATCH v3] drivers: clk: make gpio-gated clock support optional
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_driver(). Okay, I'll rework it and post a v4. thx. --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
[PATCH] arch: consolidate pm_power_off callback
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/kernel/reset.c| 3 ---
arch/arm/kernel/reboot.c | 6 ++
arch/arm64/kernel/process.c| 6 +-
arch/c6x/kernel/process.c | 10 ++
arch/csky/kernel/power.c | 10 +++---
arch/h8300/kernel/process.c| 3 ---
arch/hexagon/kernel/reset.c| 3 ---
arch/ia64/kernel/process.c | 5 +
arch/m68k/kernel/process.c | 3 ---
arch/microblaze/kernel/process.c | 3 ---
arch/mips/kernel/reset.c | 6 +-
arch/nds32/kernel/process.c| 7 ++-
arch/nios2/kernel/process.c| 3 ---
arch/openrisc/kernel/process.c | 3 ---
arch/parisc/kernel/process.c | 9 +++--
arch/powerpc/kernel/setup-common.c | 5 ++---
arch/powerpc/xmon/xmon.c | 4 ++--
arch/riscv/kernel/reset.c | 9 -
arch/s390/kernel/setup.c | 3 ---
arch/sh/kernel/reboot.c| 6 +-
arch/x86/kernel/reboot.c | 15 ---
arch/x86/xen/enlighten_pv.c| 4 ++--
arch/xtensa/kernel/process.c | 4
include/linux/pm.h | 2 ++
kernel/reboot.c| 10 ++
26 files changed, 42 insertions(+), 106 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 6c71554206cc..df0df869751d 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -43,12 +43,6 @@
#include "proto.h"
#include "pci_impl.h"
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
#ifdef CONFIG_ALPHA_WTINT
/*
* Sleep the CPU.
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index fd6c3eb930ba..3a27b6a202d4 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,6 +26,3 @@ void machine_power_off(void)
/* FIXME :: power off ??? */
machine_halt();
}
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 0ce388f15422..9e1bf0e9b3e0 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -19,8 +20,6 @@ typedef void (*phys_reset_t)(unsigned long, bool);
* Function pointers to optional machine specific functions
*/
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
/*
* A temporary stack to use for CPU reset. This is static so that we
@@ -118,8 +117,7 @@ void machine_power_off(void)
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
}
/*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6616486a58fe..a5d4c1e80abd 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -67,9 +67,6 @@ EXPORT_SYMBOL(__stack_chk_guard);
/*
* Function pointers to optional machine specific functions
*/
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
-
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
static void noinstr __cpu_do_idle(void)
@@ -172,8 +169,7 @@ void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
}
/*
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 9f4fd6a40a10..8b4b24476162 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -25,12 +26,6 @@ void (*c6x_halt)(void);
extern asmlinkage void ret_from_fork(void);
extern asmlinkage void ret_from_kernel_thread(void);
-/*
- * power off function, if any
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
void arch_cpu_idle(void)
{
unsigned long tmp;
@@ -71,8 +66,7 @@ void machine_halt(void)
void machine_power_off(void)
{
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
halt_loop();
}
diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
index 923ee4e381b8..c702e66ce03a 100644
--- a/arch/csky/kernel/power.c
+++ b/arch/csky/kernel/power.c
@@ -2,23 +2,19 @@
// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
#include
-
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
+#include
void machine_power_off(void)
{
local_irq_disable();
- if (pm_power_off)
- pm_power_off();
+ do_power_off();
[PATCH 07/23] arch: parisc: drop misleading warning on spurious IRQ
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 actually would want it to print the hw irq. Since all call sites already print out more detailed and correct information, we just don't need to duplicate this in each single arch. So just drop it. Signed-off-by: Enrico Weigelt, metux IT consult --- arch/parisc/include/asm/hardirq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/include/asm/hardirq.h b/arch/parisc/include/asm/hardirq.h index fad29aa6f45f..78b581f00bb3 100644 --- a/arch/parisc/include/asm/hardirq.h +++ b/arch/parisc/include/asm/hardirq.h @@ -34,6 +34,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat); #define __ARCH_IRQ_STAT #define inc_irq_stat(member) this_cpu_inc(irq_stat.member) #define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member) -#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", irq) +#define ack_bad_irq(irq) #endif /* _PARISC_HARDIRQ_H */ -- 2.11.0
[PATCH 02/23] arch: alpha: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/kernel/irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index f6d2946edbd2..c1980eea75a6 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -35,7 +35,6 @@ DEFINE_PER_CPU(unsigned long, irq_pmi_count);
void ack_bad_irq(unsigned int irq)
{
irq_err_count++;
- printk(KERN_CRIT "Unexpected IRQ trap at vector %u\n", irq);
}
#ifdef CONFIG_SMP
--
2.11.0
[PATCH 03/23] arch: arm: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm/include/asm/hw_irq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
index cecc13214ef1..5305c7e33aee 100644
--- a/arch/arm/include/asm/hw_irq.h
+++ b/arch/arm/include/asm/hw_irq.h
@@ -9,7 +9,6 @@ static inline void ack_bad_irq(int irq)
{
extern unsigned long irq_err_count;
irq_err_count++;
- pr_crit("unexpected IRQ trap at vector %02x\n", irq);
}
#define ARCH_IRQ_INIT_FLAGS(IRQ_NOREQUEST | IRQ_NOPROBE)
--
2.11.0
[PATCH 10/23] arch: sh: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/sh/kernel/irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c
index ab5f790b0cd2..c14a142efe60 100644
--- a/arch/sh/kernel/irq.c
+++ b/arch/sh/kernel/irq.c
@@ -31,7 +31,6 @@ atomic_t irq_err_count;
void ack_bad_irq(unsigned int irq)
{
atomic_inc(_err_count);
- printk("unexpected IRQ trap at vector %02x\n", irq);
}
#if defined(CONFIG_PROC_FS)
--
2.11.0
[PATCH 08/23] arch: powerpc: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/powerpc/include/asm/hardirq.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hardirq.h
b/arch/powerpc/include/asm/hardirq.h
index f133b5930ae1..4138193c2367 100644
--- a/arch/powerpc/include/asm/hardirq.h
+++ b/arch/powerpc/include/asm/hardirq.h
@@ -27,10 +27,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
#define __ARCH_IRQ_STAT
#define __ARCH_IRQ_EXIT_IRQS_DISABLED
-static inline void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
-}
+#define ack_bad_irq(irq)
extern u64 arch_irq_stat_cpu(unsigned int cpu);
#define arch_irq_stat_cpu arch_irq_stat_cpu
--
2.11.0
[PATCH 12/23] arch: x86: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/x86/kernel/irq.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index c5dd50369e2f..5c66c44b6b60 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -36,9 +36,6 @@ atomic_t irq_err_count;
*/
void ack_bad_irq(unsigned int irq)
{
- if (printk_ratelimit())
- pr_err("unexpected IRQ trap at vector %02x\n", irq);
-
/*
* Currently unexpected vectors happen only on SMP and APIC.
* We _must_ ack these because every local APIC has only N
--
2.11.0
[PATCH 14/23] kernel: generic counter for interrupt errors
We currently have counters for spurious interrupt spread over all the
individual architectures. Mostly done in the arch's ack_bad_irq(),
sometimes also in arch specific drivers.
It's time to consolidate this code duplication:
* introduce a global counter and inlined accessors
* increase 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 | 4
kernel/irq/irqdesc.c | 2 ++
4 files changed, 25 insertions(+)
create mode 100644 include/asm-generic/irq-err.h
diff --git a/include/asm-generic/irq-err.h b/include/asm-generic/irq-err.h
new file mode 100644
index ..33c75eb50c10
--- /dev/null
+++ b/include/asm-generic/irq-err.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_GENERIC_IRQ_ERR_H
+#define __ASM_GENERIC_IRQ_ERR_H
+
+extern atomic_t irq_err_counter;
+
+static inline void irq_err_inc(void)
+{
+ atomic_inc(_err_counter);
+}
+
+static inline int irq_err_get(void)
+{
+ return atomic_read(_err_counter);
+}
+
+#endif /* __ASM_GENERIC_IRQ_ERR_H */
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 0b0cdf206dc4..93585dab9bd0 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "internals.h"
@@ -20,6 +21,7 @@ static void ack_bad(struct irq_data *data)
struct irq_desc *desc = irq_data_to_desc(data);
print_irq_desc(data->irq, desc);
+ irq_err_inc();
ack_bad_irq(data->irq);
}
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 762a928e18f9..ad90f5a56c3a 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -13,11 +13,14 @@
#include
#include
#include
+#include
#include
#include "internals.h"
+atomic_t irq_err_counter;
+
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
void (*handle_arch_irq)(struct pt_regs *) __ro_after_init;
#endif
@@ -34,6 +37,7 @@ void handle_bad_irq(struct irq_desc *desc)
print_irq_desc(irq, desc);
kstat_incr_irqs_this_cpu(desc);
+ irq_err_inc();
ack_bad_irq(irq);
}
EXPORT_SYMBOL_GPL(handle_bad_irq);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 62a381351775..6192672be4d2 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "internals.h"
@@ -684,6 +685,7 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned
int hwirq,
if (printk_ratelimit())
pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
irq, hwirq, nr_irqs);
+ irq_err_inc();
ack_bad_irq(irq);
ret = -EINVAL;
} else {
--
2.11.0
[PATCH 15/23] arch: mips: use generic irq error counter
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/irq.c | 7 +++
arch/mips/sni/rm200.c | 3 ++-
arch/mips/vr41xx/common/icu.c | 3 ++-
arch/mips/vr41xx/common/irq.c | 5 +++--
drivers/gpio/gpio-vr41xx.c | 4 ++--
7 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/mips/include/asm/hw_irq.h b/arch/mips/include/asm/hw_irq.h
index 9e8ef5994c9c..b75fe2c4377f 100644
--- a/arch/mips/include/asm/hw_irq.h
+++ b/arch/mips/include/asm/hw_irq.h
@@ -8,10 +8,6 @@
#ifndef __ASM_HW_IRQ_H
#define __ASM_HW_IRQ_H
-#include
-
-extern atomic_t irq_err_count;
-
/*
* interrupt-retrigger: NOP for now. This may not be appropriate for all
* machines, we'll see ...
diff --git a/arch/mips/kernel/irq-gt641xx.c b/arch/mips/kernel/irq-gt641xx.c
index 93bcf5736a6f..e2c877287bee 100644
--- a/arch/mips/kernel/irq-gt641xx.c
+++ b/arch/mips/kernel/irq-gt641xx.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#define GT641XX_IRQ_TO_BIT(irq) (1U << (irq - GT641XX_IRQ_BASE))
@@ -97,7 +98,7 @@ void gt641xx_irq_dispatch(void)
}
}
- atomic_inc(_err_count);
+ irq_err_inc();
}
void __init gt641xx_irq_init(void)
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index c98be305fab6..3ea3e4280648 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -8,6 +8,7 @@
* Copyright (C) 1992 Linus Torvalds
* Copyright (C) 1994 - 2000 Ralf Baechle
*/
+#include
#include
#include
#include
@@ -27,17 +28,15 @@
void *irq_stack[NR_CPUS];
-atomic_t irq_err_count;
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
- seq_printf(p, "%*s: %10u\n", prec, "ERR", atomic_read(_err_count));
+ seq_printf(p, "%*s: %10u\n", prec, "ERR", irq_err_get());
return 0;
}
asmlinkage void spurious_interrupt(void)
{
- atomic_inc(_err_count);
+ irq_err_inc();
}
void __init init_IRQ(void)
diff --git a/arch/mips/sni/rm200.c b/arch/mips/sni/rm200.c
index d84744ca871d..c61d60a4dcc5 100644
--- a/arch/mips/sni/rm200.c
+++ b/arch/mips/sni/rm200.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define RM200_I8259A_IRQ_BASE 32
@@ -270,7 +271,7 @@ void sni_rm200_mask_and_ack_8259A(struct irq_data *d)
"spurious RM200 8259A interrupt: IRQ%d.\n", irq);
spurious_irq_mask |= irqmask;
}
- atomic_inc(_err_count);
+ irq_err_inc();
/*
* Theoretically we do not have to handle this IRQ,
* but in Linux this does not cause problems and is
diff --git a/arch/mips/vr41xx/common/icu.c b/arch/mips/vr41xx/common/icu.c
index 7b7f25b4b057..462f559ad978 100644
--- a/arch/mips/vr41xx/common/icu.c
+++ b/arch/mips/vr41xx/common/icu.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
static void __iomem *icu1_base;
static void __iomem *icu2_base;
@@ -640,7 +641,7 @@ static int icu_get_irq(unsigned int irq)
printk(KERN_ERR "spurious ICU interrupt: %04x,%04x\n", pend1, pend2);
- atomic_inc(_err_count);
+ irq_err_inc();
return -1;
}
diff --git a/arch/mips/vr41xx/common/irq.c b/arch/mips/vr41xx/common/irq.c
index 8f68446ff2d9..b2580de08e25 100644
--- a/arch/mips/vr41xx/common/irq.c
+++ b/arch/mips/vr41xx/common/irq.c
@@ -10,6 +10,7 @@
#include
#include
+#include
typedef struct irq_cascade {
int (*get_irq)(unsigned int);
@@ -46,7 +47,7 @@ static void irq_dispatch(unsigned int irq)
irq_cascade_t *cascade;
if (irq >= NR_IRQS) {
- atomic_inc(_err_count);
+ irq_err_inc();
return;
}
@@ -66,7 +67,7 @@ static void irq_dispatch(unsigned int irq)
ret = cascade->get_irq(irq);
irq = ret;
if (ret < 0)
- atomic_inc(_err_count);
+ irq_err_inc();
else
irq_dispatch(irq);
if (!irqd_irq_disabled(idata) && chip->irq_unmask)
diff --git a/drivers/gpio/gpio-vr41xx.c b/drivers/gpio/gpio-vr41xx.c
index 98cd715ccc33..c1dbd933d291 100644
--- a/drivers/gpio/gpio-vr41xx.c
+++ b/drivers/gpio/gpio-vr41xx.c
@@ -18,7 +18,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -217,7 +217,7 @@ static int giu_get_irq(unsigned int irq)
printk(KERN_ERR "spurious GIU interrupt: %04x(%04x),%04x(%04x)\n",
maskl, pendl, maskh, pendh);
- atomic_inc(_err_count);
+ irq_err_inc();
return -EINVAL;
}
--
2.11.0
[PATCH 17/23] arch: arm: use generic irq error counter
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/irq.c | 6 ++
drivers/irqchip/irq-omap-intc.c | 5 ++---
4 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 706efafbf972..d9ae8998240d 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
#include
#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
#include
diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
index 5305c7e33aee..adbbeb11b930 100644
--- a/arch/arm/include/asm/hw_irq.h
+++ b/arch/arm/include/asm/hw_irq.h
@@ -5,12 +5,6 @@
#ifndef _ARCH_ARM_HW_IRQ_H
#define _ARCH_ARM_HW_IRQ_H
-static inline void ack_bad_irq(int irq)
-{
- extern unsigned long irq_err_count;
- irq_err_count++;
-}
-
#define ARCH_IRQ_INIT_FLAGS(IRQ_NOREQUEST | IRQ_NOPROBE)
#endif
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 698b6f636156..72c3b8ce74db 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -32,7 +32,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -41,8 +41,6 @@
#include
#include
-unsigned long irq_err_count;
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
#ifdef CONFIG_FIQ
@@ -51,7 +49,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
#ifdef CONFIG_SMP
show_ipi_list(p, prec);
#endif
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index d360a6eddd6d..2682c6e814c2 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -15,7 +15,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -328,7 +328,6 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
static asmlinkage void __exception_irq_entry
omap_intc_handle_irq(struct pt_regs *regs)
{
- extern unsigned long irq_err_count;
u32 irqnr;
irqnr = intc_readl(INTC_SIR);
@@ -351,7 +350,7 @@ omap_intc_handle_irq(struct pt_regs *regs)
*/
if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) {
pr_err_once("%s: spurious irq!\n", __func__);
- irq_err_count++;
+ irq_err_inc();
omap_ack_irq(NULL);
return;
}
--
2.11.0
[PATCH 06/23] arch: mips: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/mips/include/asm/hardirq.h | 3 +--
arch/mips/kernel/irq.c | 9 -
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/mips/include/asm/hardirq.h b/arch/mips/include/asm/hardirq.h
index c977a86c2c65..75444120e6cb 100644
--- a/arch/mips/include/asm/hardirq.h
+++ b/arch/mips/include/asm/hardirq.h
@@ -10,8 +10,7 @@
#ifndef _ASM_HARDIRQ_H
#define _ASM_HARDIRQ_H
-extern void ack_bad_irq(unsigned int irq);
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
#include
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index 85b6c60f285d..c98be305fab6 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -27,15 +27,6 @@
void *irq_stack[NR_CPUS];
-/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk("unexpected IRQ # %d\n", irq);
-}
-
atomic_t irq_err_count;
int arch_show_interrupts(struct seq_file *p, int prec)
--
2.11.0
(repost) cleaning up handling of bad IRQs
Hello friends, << reposting, since first queue didn't go through completely, due to mailer problem >> 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 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 anyways. So, I've had a closer look and came to these conclusions: 1. The warning message doesn't need to be duplicated in the per architecture ack_bad_irq() functions. All, but one callers already do their own warning. Thus just adding a pr_warn() call there, printing out more useful data like the hardware IRQ number, and dropping all warnings from all the ack_bad_irq() functions. 2. Many of the ack_bad_irq()'s count up the spurious interrupts - lots of duplications over the various archs. Some of them using atomic_t, some just plain ints. Consolidating this by introducing a global counter with inline'd accessors and doing the upcounting in the (currently 3) call sites of ack_bad_irq(). After that, step by step changing all archs to use the new counter. 3. For all but one arch (x86), ack_bad_irq() became a no-op. On x86, it's just a call to ack_APIC_irq(), in order to prevent lockups when IRQs missed to be ack'ed on the APIC. Could we perhaps do this in some better place ? In that case, ack_bad_irq() could easily be removed entirely. have fun, --mtx
[PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ
Add a warning on spurious IRQs to __handle_domain_irq(), also telling the
linux IRQ number (if any), the hw IRQ number and the max nr of IRQs.
That's far more informative than the warnings in (some of) the individual
arch's ack_bad_irq()'s. These aren't really helpful since 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/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index e810eb9906ea..62a381351775 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -681,6 +681,9 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned
int hwirq,
* than crashing, do something sensible.
*/
if (unlikely(!irq || irq >= nr_irqs)) {
+ if (printk_ratelimit())
+ pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
+ irq, hwirq, nr_irqs);
ack_bad_irq(irq);
ret = -EINVAL;
} else {
--
2.11.0
[PATCH 16/23] arch: alpha: use generic irq error counter
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/kernel/irq.c | 12 +++-
arch/alpha/kernel/irq_alpha.c| 5 +++--
arch/alpha/kernel/perf_event.c | 6 +++---
5 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/arch/alpha/include/asm/hardirq.h b/arch/alpha/include/asm/hardirq.h
index 5ce5b34e8a1a..0bbc9947e364 100644
--- a/arch/alpha/include/asm/hardirq.h
+++ b/arch/alpha/include/asm/hardirq.h
@@ -2,9 +2,6 @@
#ifndef _ALPHA_HARDIRQ_H
#define _ALPHA_HARDIRQ_H
-void ack_bad_irq(unsigned int irq);
-#define ack_bad_irq ack_bad_irq
-
#include
#endif /* _ALPHA_HARDIRQ_H */
diff --git a/arch/alpha/include/asm/hw_irq.h b/arch/alpha/include/asm/hw_irq.h
index e2d81ac0d934..0be79f3a6cae 100644
--- a/arch/alpha/include/asm/hw_irq.h
+++ b/arch/alpha/include/asm/hw_irq.h
@@ -2,8 +2,6 @@
#ifndef _ALPHA_HW_IRQ_H
#define _ALPHA_HW_IRQ_H
-
-extern volatile unsigned long irq_err_count;
DECLARE_PER_CPU(unsigned long, irq_pmi_count);
#ifdef CONFIG_ALPHA_GENERIC
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index c1980eea75a6..2b7dad83e0dc 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -25,18 +25,12 @@
#include
#include
#include
-
+#include
#include
#include
-volatile unsigned long irq_err_count;
DEFINE_PER_CPU(unsigned long, irq_pmi_count);
-void ack_bad_irq(unsigned int irq)
-{
- irq_err_count++;
-}
-
#ifdef CONFIG_SMP
static char irq_user_affinity[NR_IRQS];
@@ -79,7 +73,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
for_each_online_cpu(j)
seq_printf(p, "%10lu ", per_cpu(irq_pmi_count, j));
seq_puts(p, " Performance Monitoring\n");
- seq_printf(p, "ERR: %10lu\n", irq_err_count);
+ seq_printf(p, "ERR: %10lu\n", irq_err_get());
return 0;
}
@@ -109,7 +103,7 @@ handle_irq(int irq)
if (!desc || ((unsigned) irq > ACTUAL_NR_IRQS &&
illegal_count < MAX_ILLEGAL_IRQS)) {
- irq_err_count++;
+ irq_err_inc();
illegal_count++;
printk(KERN_CRIT "device_interrupt: invalid interrupt %d\n",
irq);
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index d17e44c99df9..3b6373cf73d9 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "proto.h"
#include "irq_impl.h"
@@ -30,7 +31,7 @@ EXPORT_SYMBOL(__min_ipl);
static void
dummy_perf(unsigned long vector, struct pt_regs *regs)
{
- irq_err_count++;
+ irq_err_inc();
printk(KERN_CRIT "Performance counter interrupt!\n");
}
@@ -60,7 +61,7 @@ do_entInt(unsigned long type, unsigned long vector,
handle_ipi(regs);
return;
#else
- irq_err_count++;
+ irq_err_inc();
printk(KERN_CRIT "Interprocessor interrupt? "
"You must be kidding!\n");
#endif
diff --git a/arch/alpha/kernel/perf_event.c b/arch/alpha/kernel/perf_event.c
index e7a59d927d78..d855cece7bb1 100644
--- a/arch/alpha/kernel/perf_event.c
+++ b/arch/alpha/kernel/perf_event.c
@@ -16,7 +16,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -823,7 +823,7 @@ static void alpha_perf_event_irq_handler(unsigned long
la_ptr,
/* la_ptr is the counter that overflowed. */
if (unlikely(la_ptr >= alpha_pmu->num_pmcs)) {
/* This should never occur! */
- irq_err_count++;
+ irq_err_inc();
pr_warn("PMI: silly index %ld\n", la_ptr);
wrperfmon(PERFMON_CMD_ENABLE, cpuc->idx_mask);
return;
@@ -846,7 +846,7 @@ static void alpha_perf_event_irq_handler(unsigned long
la_ptr,
if (unlikely(!event)) {
/* This should never occur! */
- irq_err_count++;
+ irq_err_inc();
pr_warn("PMI: No event at index %d!\n", idx);
wrperfmon(PERFMON_CMD_ENABLE, cpuc->idx_mask);
return;
--
2.11.0
[PATCH 18/23] arch: arm64: use generic irq error counter
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 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index cbfa7b6f2e09..760922571084 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -13,7 +13,8 @@
#include
#include
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
+
#include
#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1
@@ -85,10 +86,4 @@ do {
\
write_sysreg(___hcr, hcr_el2); \
} while (0)
-static inline void ack_bad_irq(unsigned int irq)
-{
- extern unsigned long irq_err_count;
- irq_err_count++;
-}
-
#endif /* __ASM_HARDIRQ_H */
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 2499b895efea..0edc565ea735 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -33,7 +33,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -798,8 +798,6 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
static void smp_cross_call(const struct cpumask *target, unsigned int ipinr);
-unsigned long irq_err_count;
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
unsigned int cpu, i;
@@ -813,7 +811,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, " %s\n", ipi_types[i]);
}
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
--
2.11.0
[PATCH 19/23] arch: c6x: use generic irq error counter
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/irq.c | 11 ++-
3 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/c6x/include/asm/hardirq.h b/arch/c6x/include/asm/hardirq.h
index f37d07d31040..f70f6113e53a 100644
--- a/arch/c6x/include/asm/hardirq.h
+++ b/arch/c6x/include/asm/hardirq.h
@@ -9,9 +9,6 @@
#ifndef _ASM_C6X_HARDIRQ_H
#define _ASM_C6X_HARDIRQ_H
-extern void ack_bad_irq(int irq);
-#define ack_bad_irq ack_bad_irq
-
#include
#endif /* _ASM_C6X_HARDIRQ_H */
diff --git a/arch/c6x/include/asm/irq.h b/arch/c6x/include/asm/irq.h
index 9da4d1afd0d7..f42c5747c3ee 100644
--- a/arch/c6x/include/asm/irq.h
+++ b/arch/c6x/include/asm/irq.h
@@ -45,6 +45,4 @@ struct pt_regs;
extern asmlinkage void c6x_do_IRQ(unsigned int prio, struct pt_regs *regs);
-extern unsigned long irq_err_count;
-
#endif /* _ASM_C6X_IRQ_H */
diff --git a/arch/c6x/kernel/irq.c b/arch/c6x/kernel/irq.c
index b9f7cfa2ed21..9f9d798925de 100644
--- a/arch/c6x/kernel/irq.c
+++ b/arch/c6x/kernel/irq.c
@@ -21,12 +21,10 @@
#include
#include
#include
-
+#include
#include
#include
-unsigned long irq_err_count;
-
static DEFINE_RAW_SPINLOCK(core_irq_lock);
static void mask_core_irq(struct irq_data *data)
@@ -114,13 +112,8 @@ void __init init_IRQ(void)
set_creg(ICR, 0xfff0);
}
-void ack_bad_irq(int irq)
-{
- irq_err_count++;
-}
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
--
2.11.0
[PATCH 09/23] arch: s390: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/s390/include/asm/hardirq.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/s390/include/asm/hardirq.h b/arch/s390/include/asm/hardirq.h
index dfbc3c6c0674..56d95fcb310a 100644
--- a/arch/s390/include/asm/hardirq.h
+++ b/arch/s390/include/asm/hardirq.h
@@ -21,9 +21,6 @@
#define __ARCH_HAS_DO_SOFTIRQ
#define __ARCH_IRQ_EXIT_IRQS_DISABLED
-static inline void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
-}
+#define ack_bad_irq(irq)
#endif /* __ASM_HARDIRQ_H */
--
2.11.0
[PATCH 11/23] arch: sparc: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/sparc/include/asm/hardirq_64.h | 2 +-
arch/sparc/kernel/irq_64.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/sparc/include/asm/hardirq_64.h
b/arch/sparc/include/asm/hardirq_64.h
index 75b92bfe04b5..874151f520de 100644
--- a/arch/sparc/include/asm/hardirq_64.h
+++ b/arch/sparc/include/asm/hardirq_64.h
@@ -14,6 +14,6 @@
#define local_softirq_pending_ref \
__cpu_data.__softirq_pending
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* !(__SPARC64_HARDIRQ_H) */
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 3ec9f1402aad..ea2a52f7fe53 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -284,11 +284,6 @@ static unsigned int sysino_exists(u32 devhandle, unsigned
int devino)
return irq;
}
-void ack_bad_irq(unsigned int irq)
-{
- pr_crit("BAD IRQ ack %d\n", irq);
-}
-
void irq_install_pre_handler(int irq,
void (*func)(unsigned int, void *, void *),
void *arg1, void *arg2)
--
2.11.0
[PATCH 13/23] arch: generic: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
include/asm-generic/hardirq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/asm-generic/hardirq.h b/include/asm-generic/hardirq.h
index 7317e8258b48..f5a0240cbf52 100644
--- a/include/asm-generic/hardirq.h
+++ b/include/asm-generic/hardirq.h
@@ -19,7 +19,6 @@ DECLARE_PER_CPU_ALIGNED(irq_cpustat_t, irq_stat);
#ifndef ack_bad_irq
static inline void ack_bad_irq(unsigned int irq)
{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
}
#endif
--
2.11.0
[PATCH 04/23] arch: c6x: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/kernel/irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/c6x/kernel/irq.c b/arch/c6x/kernel/irq.c
index e4c53d185b62..b9f7cfa2ed21 100644
--- a/arch/c6x/kernel/irq.c
+++ b/arch/c6x/kernel/irq.c
@@ -116,7 +116,6 @@ void __init init_IRQ(void)
void ack_bad_irq(int irq)
{
- printk(KERN_ERR "IRQ: spurious interrupt %d\n", irq);
irq_err_count++;
}
--
2.11.0
[PATCH 05/23] arch: ia64: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/ia64/include/asm/hardirq.h | 2 +-
arch/ia64/kernel/irq.c | 9 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/ia64/include/asm/hardirq.h b/arch/ia64/include/asm/hardirq.h
index ccde7c2ba00f..dddaafaf84e0 100644
--- a/arch/ia64/include/asm/hardirq.h
+++ b/arch/ia64/include/asm/hardirq.h
@@ -22,6 +22,6 @@
extern void __iomem *ipi_base_addr;
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* _ASM_IA64_HARDIRQ_H */
diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
index ecef17c7c35b..1365c7cf2095 100644
--- a/arch/ia64/kernel/irq.c
+++ b/arch/ia64/kernel/irq.c
@@ -28,15 +28,6 @@
#include
/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq,
smp_processor_id());
-}
-
-/*
* Interrupt statistics:
*/
--
2.11.0
[PATCH 06/23] arch: mips: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/mips/include/asm/hardirq.h | 3 +--
arch/mips/kernel/irq.c | 9 -
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/mips/include/asm/hardirq.h b/arch/mips/include/asm/hardirq.h
index c977a86c2c65..75444120e6cb 100644
--- a/arch/mips/include/asm/hardirq.h
+++ b/arch/mips/include/asm/hardirq.h
@@ -10,8 +10,7 @@
#ifndef _ASM_HARDIRQ_H
#define _ASM_HARDIRQ_H
-extern void ack_bad_irq(unsigned int irq);
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
#include
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index 85b6c60f285d..c98be305fab6 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -27,15 +27,6 @@
void *irq_stack[NR_CPUS];
-/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk("unexpected IRQ # %d\n", irq);
-}
-
atomic_t irq_err_count;
int arch_show_interrupts(struct seq_file *p, int prec)
--
2.11.0
[PATCH 11/23] arch: sparc: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/sparc/include/asm/hardirq_64.h | 2 +-
arch/sparc/kernel/irq_64.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/sparc/include/asm/hardirq_64.h
b/arch/sparc/include/asm/hardirq_64.h
index 75b92bfe04b5..874151f520de 100644
--- a/arch/sparc/include/asm/hardirq_64.h
+++ b/arch/sparc/include/asm/hardirq_64.h
@@ -14,6 +14,6 @@
#define local_softirq_pending_ref \
__cpu_data.__softirq_pending
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* !(__SPARC64_HARDIRQ_H) */
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 3ec9f1402aad..ea2a52f7fe53 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -284,11 +284,6 @@ static unsigned int sysino_exists(u32 devhandle, unsigned
int devino)
return irq;
}
-void ack_bad_irq(unsigned int irq)
-{
- pr_crit("BAD IRQ ack %d\n", irq);
-}
-
void irq_install_pre_handler(int irq,
void (*func)(unsigned int, void *, void *),
void *arg1, void *arg2)
--
2.11.0
[PATCH 07/23] arch: parisc: drop misleading warning on spurious IRQ
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 actually would want it to print the hw irq. Since all call sites already print out more detailed and correct information, we just don't need to duplicate this in each single arch. So just drop it. Signed-off-by: Enrico Weigelt, metux IT consult --- arch/parisc/include/asm/hardirq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/include/asm/hardirq.h b/arch/parisc/include/asm/hardirq.h index fad29aa6f45f..78b581f00bb3 100644 --- a/arch/parisc/include/asm/hardirq.h +++ b/arch/parisc/include/asm/hardirq.h @@ -34,6 +34,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat); #define __ARCH_IRQ_STAT #define inc_irq_stat(member) this_cpu_inc(irq_stat.member) #define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member) -#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", irq) +#define ack_bad_irq(irq) #endif /* _PARISC_HARDIRQ_H */ -- 2.11.0
[PATCH 13/23] arch: generic: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
include/asm-generic/hardirq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/asm-generic/hardirq.h b/include/asm-generic/hardirq.h
index 7317e8258b48..f5a0240cbf52 100644
--- a/include/asm-generic/hardirq.h
+++ b/include/asm-generic/hardirq.h
@@ -19,7 +19,6 @@ DECLARE_PER_CPU_ALIGNED(irq_cpustat_t, irq_stat);
#ifndef ack_bad_irq
static inline void ack_bad_irq(unsigned int irq)
{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
}
#endif
--
2.11.0
[PATCH 18/23] arch: arm64: use generic irq error counter
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 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index cbfa7b6f2e09..760922571084 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -13,7 +13,8 @@
#include
#include
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
+
#include
#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1
@@ -85,10 +86,4 @@ do {
\
write_sysreg(___hcr, hcr_el2); \
} while (0)
-static inline void ack_bad_irq(unsigned int irq)
-{
- extern unsigned long irq_err_count;
- irq_err_count++;
-}
-
#endif /* __ASM_HARDIRQ_H */
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 2499b895efea..0edc565ea735 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -33,7 +33,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -798,8 +798,6 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
static void smp_cross_call(const struct cpumask *target, unsigned int ipinr);
-unsigned long irq_err_count;
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
unsigned int cpu, i;
@@ -813,7 +811,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, " %s\n", ipi_types[i]);
}
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
--
2.11.0
[PATCH 17/23] arch: arm: use generic irq error counter
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/irq.c | 6 ++
drivers/irqchip/irq-omap-intc.c | 5 ++---
4 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 706efafbf972..d9ae8998240d 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
#include
#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
#include
diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
index 5305c7e33aee..adbbeb11b930 100644
--- a/arch/arm/include/asm/hw_irq.h
+++ b/arch/arm/include/asm/hw_irq.h
@@ -5,12 +5,6 @@
#ifndef _ARCH_ARM_HW_IRQ_H
#define _ARCH_ARM_HW_IRQ_H
-static inline void ack_bad_irq(int irq)
-{
- extern unsigned long irq_err_count;
- irq_err_count++;
-}
-
#define ARCH_IRQ_INIT_FLAGS(IRQ_NOREQUEST | IRQ_NOPROBE)
#endif
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 698b6f636156..72c3b8ce74db 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -32,7 +32,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -41,8 +41,6 @@
#include
#include
-unsigned long irq_err_count;
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
#ifdef CONFIG_FIQ
@@ -51,7 +49,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
#ifdef CONFIG_SMP
show_ipi_list(p, prec);
#endif
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index d360a6eddd6d..2682c6e814c2 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -15,7 +15,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -328,7 +328,6 @@ static int __init omap_init_irq(u32 base, struct
device_node *node)
static asmlinkage void __exception_irq_entry
omap_intc_handle_irq(struct pt_regs *regs)
{
- extern unsigned long irq_err_count;
u32 irqnr;
irqnr = intc_readl(INTC_SIR);
@@ -351,7 +350,7 @@ omap_intc_handle_irq(struct pt_regs *regs)
*/
if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) {
pr_err_once("%s: spurious irq!\n", __func__);
- irq_err_count++;
+ irq_err_inc();
omap_ack_irq(NULL);
return;
}
--
2.11.0
[PATCH 09/23] arch: s390: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/s390/include/asm/hardirq.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/s390/include/asm/hardirq.h b/arch/s390/include/asm/hardirq.h
index dfbc3c6c0674..56d95fcb310a 100644
--- a/arch/s390/include/asm/hardirq.h
+++ b/arch/s390/include/asm/hardirq.h
@@ -21,9 +21,6 @@
#define __ARCH_HAS_DO_SOFTIRQ
#define __ARCH_IRQ_EXIT_IRQS_DISABLED
-static inline void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
-}
+#define ack_bad_irq(irq)
#endif /* __ASM_HARDIRQ_H */
--
2.11.0
[PATCH 04/23] arch: c6x: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/kernel/irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/c6x/kernel/irq.c b/arch/c6x/kernel/irq.c
index e4c53d185b62..b9f7cfa2ed21 100644
--- a/arch/c6x/kernel/irq.c
+++ b/arch/c6x/kernel/irq.c
@@ -116,7 +116,6 @@ void __init init_IRQ(void)
void ack_bad_irq(int irq)
{
- printk(KERN_ERR "IRQ: spurious interrupt %d\n", irq);
irq_err_count++;
}
--
2.11.0
cleanup handling of bad IRQs
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 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 anyways. So, I've had a closer look and came to these conclusions: 1. The warning message doesn't need to be duplicated in the per architecture ack_bad_irq() functions. All, but one callers already do their own warning. Thus just adding a pr_warn() call there, printing out more useful data like the hardware IRQ number, and dropping all warnings from all the ack_bad_irq() functions. 2. Many of the ack_bad_irq()'s count up the spurious interrupts - lots of duplications over the various archs. Some of them using atomic_t, some just plain ints. Consolidating this by introducing a global counter with inline'd accessors and doing the upcounting in the (currently 3) call sites of ack_bad_irq(). After that, step by step changing all archs to use the new counter. 3. For all but one arch (x86), ack_bad_irq() became a no-op. On x86, it's just a call to ack_APIC_irq(), in order to prevent lockups when IRQs missed to be ack'ed on the APIC. Could we perhaps do this in some better place ? In that case, ack_bad_irq() could easily be removed entirely. have fun, --mtx
[PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ
Add a warning on spurious IRQs to __handle_domain_irq(), also telling the
linux IRQ number (if any), the hw IRQ number and the max nr of IRQs.
That's far more informative than the warnings in (some of) the individual
arch's ack_bad_irq()'s. These aren't really helpful since 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/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index e810eb9906ea..62a381351775 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -681,6 +681,9 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned
int hwirq,
* than crashing, do something sensible.
*/
if (unlikely(!irq || irq >= nr_irqs)) {
+ if (printk_ratelimit())
+ pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
+ irq, hwirq, nr_irqs);
ack_bad_irq(irq);
ret = -EINVAL;
} else {
--
2.11.0
[PATCH 05/23] arch: ia64: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/ia64/include/asm/hardirq.h | 2 +-
arch/ia64/kernel/irq.c | 9 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/ia64/include/asm/hardirq.h b/arch/ia64/include/asm/hardirq.h
index ccde7c2ba00f..dddaafaf84e0 100644
--- a/arch/ia64/include/asm/hardirq.h
+++ b/arch/ia64/include/asm/hardirq.h
@@ -22,6 +22,6 @@
extern void __iomem *ipi_base_addr;
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* _ASM_IA64_HARDIRQ_H */
diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
index ecef17c7c35b..1365c7cf2095 100644
--- a/arch/ia64/kernel/irq.c
+++ b/arch/ia64/kernel/irq.c
@@ -28,15 +28,6 @@
#include
/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq,
smp_processor_id());
-}
-
-/*
* Interrupt statistics:
*/
--
2.11.0
[PATCH 19/23] arch: c6x: use generic irq error counter
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/irq.c | 11 ++-
3 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/c6x/include/asm/hardirq.h b/arch/c6x/include/asm/hardirq.h
index f37d07d31040..f70f6113e53a 100644
--- a/arch/c6x/include/asm/hardirq.h
+++ b/arch/c6x/include/asm/hardirq.h
@@ -9,9 +9,6 @@
#ifndef _ASM_C6X_HARDIRQ_H
#define _ASM_C6X_HARDIRQ_H
-extern void ack_bad_irq(int irq);
-#define ack_bad_irq ack_bad_irq
-
#include
#endif /* _ASM_C6X_HARDIRQ_H */
diff --git a/arch/c6x/include/asm/irq.h b/arch/c6x/include/asm/irq.h
index 9da4d1afd0d7..f42c5747c3ee 100644
--- a/arch/c6x/include/asm/irq.h
+++ b/arch/c6x/include/asm/irq.h
@@ -45,6 +45,4 @@ struct pt_regs;
extern asmlinkage void c6x_do_IRQ(unsigned int prio, struct pt_regs *regs);
-extern unsigned long irq_err_count;
-
#endif /* _ASM_C6X_IRQ_H */
diff --git a/arch/c6x/kernel/irq.c b/arch/c6x/kernel/irq.c
index b9f7cfa2ed21..9f9d798925de 100644
--- a/arch/c6x/kernel/irq.c
+++ b/arch/c6x/kernel/irq.c
@@ -21,12 +21,10 @@
#include
#include
#include
-
+#include
#include
#include
-unsigned long irq_err_count;
-
static DEFINE_RAW_SPINLOCK(core_irq_lock);
static void mask_core_irq(struct irq_data *data)
@@ -114,13 +112,8 @@ void __init init_IRQ(void)
set_creg(ICR, 0xfff0);
}
-void ack_bad_irq(int irq)
-{
- irq_err_count++;
-}
-
int arch_show_interrupts(struct seq_file *p, int prec)
{
- seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_count);
+ seq_printf(p, "%*s: %10lu\n", prec, "Err", irq_err_get());
return 0;
}
--
2.11.0
[PATCH 14/23] kernel: generic counter for interrupt errors
We currently have counters for spurious interrupt spread over all the
individual architectures. Mostly done in the arch's ack_bad_irq(),
sometimes also in arch specific drivers.
It's time to consolidate this code duplication:
* introduce a global counter and inlined accessors
* increase 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 | 4
kernel/irq/irqdesc.c | 2 ++
4 files changed, 25 insertions(+)
create mode 100644 include/asm-generic/irq-err.h
diff --git a/include/asm-generic/irq-err.h b/include/asm-generic/irq-err.h
new file mode 100644
index ..33c75eb50c10
--- /dev/null
+++ b/include/asm-generic/irq-err.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_GENERIC_IRQ_ERR_H
+#define __ASM_GENERIC_IRQ_ERR_H
+
+extern atomic_t irq_err_counter;
+
+static inline void irq_err_inc(void)
+{
+ atomic_inc(_err_counter);
+}
+
+static inline int irq_err_get(void)
+{
+ return atomic_read(_err_counter);
+}
+
+#endif /* __ASM_GENERIC_IRQ_ERR_H */
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 0b0cdf206dc4..93585dab9bd0 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "internals.h"
@@ -20,6 +21,7 @@ static void ack_bad(struct irq_data *data)
struct irq_desc *desc = irq_data_to_desc(data);
print_irq_desc(data->irq, desc);
+ irq_err_inc();
ack_bad_irq(data->irq);
}
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 762a928e18f9..ad90f5a56c3a 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -13,11 +13,14 @@
#include
#include
#include
+#include
#include
#include "internals.h"
+atomic_t irq_err_counter;
+
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
void (*handle_arch_irq)(struct pt_regs *) __ro_after_init;
#endif
@@ -34,6 +37,7 @@ void handle_bad_irq(struct irq_desc *desc)
print_irq_desc(irq, desc);
kstat_incr_irqs_this_cpu(desc);
+ irq_err_inc();
ack_bad_irq(irq);
}
EXPORT_SYMBOL_GPL(handle_bad_irq);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 62a381351775..6192672be4d2 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "internals.h"
@@ -684,6 +685,7 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned
int hwirq,
if (printk_ratelimit())
pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
irq, hwirq, nr_irqs);
+ irq_err_inc();
ack_bad_irq(irq);
ret = -EINVAL;
} else {
--
2.11.0
[PATCH 10/23] arch: sh: drop misleading warning on spurious IRQ
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 actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/sh/kernel/irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c
index ab5f790b0cd2..c14a142efe60 100644
--- a/arch/sh/kernel/irq.c
+++ b/arch/sh/kernel/irq.c
@@ -31,7 +31,6 @@ atomic_t irq_err_count;
void ack_bad_irq(unsigned int irq)
{
atomic_inc(_err_count);
- printk("unexpected IRQ trap at vector %02x\n", irq);
}
#if defined(CONFIG_PROC_FS)
--
2.11.0
